ML24236A142

Enclosure 1-(REDACTED) Als v2 Methodology TR Final SE

ML24236A142
Person / Time
Site:	99902079
Issue date:	09/30/2024
From:	Stephen Philpott NRC/NRR/DANU/UAL2
To:	Schoedel A Westinghouse
References
EPID L-2022-TOP-0059, EPID L-2022-TOP-0060
Download: ML24236A142 (1)

Text

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION WESTINGHOUSE ELECTRIC COMPANY LLC - FINAL SAFETY EVALUATION FOR TOPICAL REPORTS: ADVANCED LOGIC SYSTEM V2 PLATFORM AND ADVANCED LOGIC SYSTEM V2 DEVELOPMENT PROCESS (EPID NOS. L-2022-TOP-0059 AND L-2022-TOP-0060)

SPONSOR AND SUBMITTAL INFORMATION Sponsor:

Westinghouse Electric Company LLC Sponsor Address:

51 Bridge Street Pittsburgh, PA 15223 Project No.:

99902079 Submittal Date:

December 21, 2022 Submittal Agencywide Documents Access and Management System (ADAMS) Accession No.: ML22355A230 This document contains proprietary information pursuant to Title 10 of the Code of Federal Regulations section 2.390, Public inspections, exemptions, requests for withholding.

Proprietary information is identified by text enclosed within bolded double brackets, as shown here: ((example proprietary text)).

Brief Description of the Topical Reports:

Westinghouse Electric Company LLC (WEC) has requested the U.S. Nuclear Regulatory Commissions (NRCs) review and approval of the Advanced Logic System (ALS) v2 Topical Reports for use of the ALS v2 in nuclear safety-related instrumentation and control (I&C) applications. These topical reports describe the enhancements that have been included to create the second generation of the ALS platform, known as ALS v2; and define the overall life cycle development process to identify the detailed supporting processes by which safety related I&C activities will be executed for the ALS v2 platform development and applications of the ALS v2 platform.

Additional details regarding the submittal can be found in the documents located under the ADAMS Accession package number identified above.

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION Table of Contents

3.0 TECHNICAL EVALUATION

3.1 Platform Description.................................................................................................

3.1.1 General Instrument Architecture................................................................

3.1.2 Development and Operational Concept Overview.....................................

3.1.3 Platform Digital Communications Overview...............................................

3.1.4 Platform Circuit Board Set..........................................................................

3.1.4.1 ALS-352 Digital Input Board (28/48Vdc Contact Input)..............................

3.1.4.2 ALS-361 Analog Input Board (RTD and Thermocouple)............................

3.1.4.3 ALS-371 Analog Input Board (Voltage/Current).........................................

3.1.4.4 ALS-452 Digital Output Board (Contact Output)........................................

3.1.4.5 ALS-471 Analog Output Board (Voltage/Current)......................................

3.1.4.6 ALS-651 Communication Board.................................................................

3.1.4.7 ALS-152 Core Logic Board........................................................................

3.2 Development Process..............................................................................................

3.3 Equipment Qualification............................................................................................

3.3.1 Test Overview and Type Test Configuration..............................................

3.3.2 Environmental Testing...............................................................................

3.3.3 Seismic Testing..........................................................................................

3.3.4 Electromagnetic Compatibility Testing.......................................................

3.3.4.1 Radiated and Conducted Emissions..........................................................

3.3.4.2 Radiated and Conducted Susceptibility.....................................................

3.3.4.3 Surge and Electrical Fast Transient Withstand Capability.........................

3.3.4.4 Electrostatic Discharge Withstand Testing.................................................

3.4 Platform Integrity Characteristics..............................................................................

3.4.1 Response Time.........................................................................................

3.4.2 Determinism...............................................................................................

3.4.2.1 Deterministic and Known Real Time Performance (Deterministic Computation).......................................................................

3.4.2.2 Deterministic Digital Communication for Safety Signals............................

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION 3.4.2.3 Exclusion of Software-based System Characteristics...............................

3.4.2.4 Exclusion of an Event-Driven Design.........................................................

3.4.2.5 Summary Staff Determination for Determinism..........................................

3.4.3 Self-Diagnostics, Test and Calibration Capabilities...................................

3.5 Failure Mode and Effects Analysis...........................................................................

3.6 Reliability and Availability Analysis...........................................................................

3.7 Digital Data Communication Independence and Isolation........................................

3.7.1 ALS v2 Platform Digital Data Communications..........................................

3.7.1.1 With Nonsafety Equipment.........................................................................

3.7.1.1.1 Via TxB1 and TxB2 on the ALS-152 Core Logic Board.............................

3.7.1.1.2 Via TAB and Instrument Backplane with Each Circuit Board.....................

3.7.1.2 Among Safety Divisions or with Safety Equipment....................................

3.7.2 Staff Guidance in Digital I&C-ISG-04.........................................................

3.7.2.1 Staff Position 1, Points 1 through 20 - Interdivisional Communications....

3.7.2.1.1 Point 1........................................................................................................

3.7.2.1.2 Point 2........................................................................................................

3.7.2.1.3 Point 3........................................................................................................

3.7.2.1.4 Point 4........................................................................................................

3.7.2.1.5 Point 5........................................................................................................

3.7.2.1.6 Point 6........................................................................................................

3.7.2.1.7 Point 7........................................................................................................

3.7.2.1.8 Point 8........................................................................................................

3.7.2.1.9 Point 9........................................................................................................

3.7.2.1.10 Point 10......................................................................................................

3.7.2.1.11 Point 11......................................................................................................

3.7.2.1.12 Point 12......................................................................................................

3.7.2.1.13 Point 13......................................................................................................

3.7.2.1.14 Point 14......................................................................................................

3.7.2.1.15 Point 15......................................................................................................

3.7.2.1.16 Point 16......................................................................................................

3.7.2.1.17 Point 17......................................................................................................

3.7.2.1.18 Point 18......................................................................................................

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION 3.7.2.1.19 Point 19...................................................................................................

3.7.2.1.20 Point 20......................................................................................................

3.7.2.2 Staff Position 2 - Command Prioritization..................................................

3.7.2.3 Staff Position 3 - Multidivisional Control and Display Stations..................

3.8 Diversity and Defense-in-Depth................................................................................

3.9 Compliance to IEEE Std 603-1991...........................................................................

3.9.1 Section 4 - Safety System Designation.....................................................

3.9.2 Section 5 - Safety System Criteria..........................................................- 100 -

3.9.2.1 Clause 5.1 - Single-Failure Criterion.......................................................- 100 -

3.9.2.2 Clause 5.2 - Completion of Protective Action..........................................- 101 -

3.9.2.3 Clause 5.3 - Quality.................................................................................- 101 -

3.9.2.4 Clause 5.4 - Equipment Qualification......................................................- 102 -

3.9.2.5 Clause 5.5 - System Integrity..................................................................- 102 -

3.9.2.6 Clause 5.6 - Independence.....................................................................- 104 -

3.9.2.6.1 Clause 5.6.1 -Independence between Redundant Portions of a Safety System...................................................................................- 105 -

3.9.2.6.2 Clause 5.6.2 -Independence of Effects of Design Basis Event...............- 106 -

3.9.2.6.3 Clause 5.6.3 - Independence between Safety Systems and Other Systems.........................................................................................- 106 -

3.9.2.7 Clause 5.7 - Capability for Test and Calibration......................................- 106 -

3.9.2.8 Clause 5.8 - Information Displays...........................................................- 106 -

3.9.2.8.1 Clause 5.8.1 - Displays for Manually Controlled Actions.........................- 107 -

3.9.2.8.2 Clause 5.8.2 - System Status Indication.................................................- 107 -

3.9.2.8.3 Clause 5.8.3 - Indication of Bypasses.....................................................- 108 -

3.9.2.8.4 Clause 5.8.4 - Location...........................................................................- 108 -

3.9.2.9 Clause 5.9 - Control of Access................................................................- 109 -

3.9.2.10 Clause 5.10 - Repair...............................................................................- 110 -

3.9.2.11 Clause 5.11 - Identification......................................................................- 110 -

3.9.2.12 Clause 5.12 - Auxiliary Features.............................................................- 111 -

3.9.2.13 Clause 5.13 - Multi-Unit Stations.............................................................- 111 -

3.9.2.14 Clause 5.14 - Human Factors Considerations........................................- 112 -

3.9.2.15 Clause 5.15 - Reliability...........................................................................- 112 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION 3.9.3 Section 6 - Sense and Command Features - Functional and Design Requirements.............................................................................- 113 -

3.9.3.1 Clause 6.1 - Automatic Control...............................................................- 113 -

3.9.3.2 Clause 6.2 - Manual Control....................................................................- 114 -

3.9.3.3 Clause 6.3 - Interaction Between the S & C and Other Systems............- 115 -

3.9.3.4 Clause 6.4 - Derivation of System Inputs................................................- 116 -

3.9.3.5 Clause 6.5 - Capability for Testing and Calibration.................................- 117 -

3.9.3.6 Clause 6.6 - Operating Bypasses............................................................- 118 -

3.9.3.7 Clause 6.7 - Maintenance Bypass...........................................................- 118 -

3.9.3.8 Clause 6.8 - Setpoints.............................................................................- 119 -

3.9.4 Section 7 - Execute Features - Functional and Design Requirements..- 120 -

3.9.5 IEEE Section 8 - Power Source Requirements.......................................- 121 -

3.10 Conformance with IEEE Std 7-4.3.2-2003..............................................................- 122 -

3.10.1 IEEE Std 7-4.3.2 Section 4 - Safety System Design Basis.....................- 122 -

3.10.2 IEEE Std 7-4.3.2 Section 5 - Safety System Criteria...............................- 122 -

3.10.2.1 IEEE Std 7-4.3.2 Clause 5.1 - Single-Failure Criterion...........................- 122 -

3.10.2.2 IEEE Std 7-4.3.2 Clause 5.2 - Completion of Protective Action..............- 123 -

3.10.2.3 IEEE Std 7-4.3.2 Clause 5.3 - Quality.....................................................- 123 -

3.10.2.3.1 IEEE Std 7-4.3.2 Clause 5.3.1 - Software Development.........................- 123 -

3.10.2.3.1.1 IEEE Std 7-4.3.2 Clause 5.3.1.1 - Software Quality Metrics...................- 123 -

3.10.2.3.2 IEEE Std 7-4.3.2 Clause 5.3.2 - Software Tools.....................................- 124 -

3.10.2.3.3 IEEE Std 7-4.3.2 Clause 5.3.3 - Verification and Validation....................- 125 -

3.10.2.3.4 IEEE Std 7-4.3.2 Clause 5.3.4 - Independent V&V (IV&V) Requirements-126 -

3.10.2.3.5 IEEE Std 7-4.3.2 Clause 5.3.5 - Software Configuration Management...- 127 -

3.10.2.3.6 IEEE Std 7-4.3.2 Clause 5.3.6 - Software Project Risk Management.....- 129 -

3.10.2.4 IEEE Std 7-4.3.2 Clause 5.4 - Equipment Qualification..........................- 130 -

3.10.2.4.1 IEEE Std 7-4.3.2 Clause 5.4.1 - Computer System Testing....................- 130 -

3.10.2.4.2 IEEE Std 7-4.3.2 Clause 5.4.2 - Qualification of Existing Commercial Computers...........................................................................- 131 -

3.10.2.5 IEEE Std 7-4.3.2 Clause 5.5 - System Integrity......................................- 132 -

3.10.2.5.1 IEEE Std 7-4.3.2 Clause 5.5.1 - Design for Computer Integrity..............- 132 -

3.10.2.5.2 IEEE Std 7-4.3.2 Clause 5.5.2 - Design for Test and Calibration............- 133 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION 3.10.2.5.3 IEEE Std 7-4.3.2 Clause 5.5.3 - Fault detection and Self-diagnostics....- 134 -

3.10.2.6 IEEE Std 7-4.3.2 Clause 5.6 - Independence.........................................- 135 -

3.10.2.7 IEEE Std 7-4.3.2 Clause 5.7 - Capability for Test and Calibration..........- 137 -

3.10.2.8 IEEE Std 7-4.3.2 Clause 5.8 - Information Displays................................- 137 -

3.10.2.9 IEEE Std 7-4.3.2 Clause 5.9 - Control of Access....................................- 137 -

3.10.2.10 IEEE Std 7-4.3.2 Clause 5.10 - Repair....................................................- 137 -

3.10.2.11 IEEE Std 7-4.3.2 Clause 5.11 - Identification..........................................- 137 -

3.10.2.12 IEEE Std 7-4.3.2 Clause 5.12 - Auxiliary Features.................................- 138 -

3.10.2.13 IEEE Std 7-4.3.2 Clause 5.13 - Multi-Unit Stations.................................- 138 -

3.10.2.14 IEEE Std 7-4.3.2 Clause 5.14 - Human Factors Considerations.............- 138 -

3.10.2.15 IEEE Std 7-4.3.2 Clause 5.15 - Reliability...............................................- 139 -

3.10.3 Section 6 - Sense and Command Features - Functional and Design Requirements...............................................................................- 140 -

3.10.4 Section 7 - Execute Features - Functional and Design Requirements..- 140 -

3.10.5 IEEE Std 7-4.3.2 Section 8 - Power Source Requirements....................- 140 -

3.11 Platform Generic Change Process.........................................................................- 140 -

3.11.1 Record of Changes Document.................................................................- 141 -

4.1 Limitations and Conditions.....................................................................................- 141 -

4.2 Generic Open Items...............................................................................................- 141 -

4.3 Plant-Specific Action Items.....................................................................................- 144 -

5.0 REFERENCES

...........................................................................................................- 149 -

6.0 CONCLUSION

...........................................................................................................- 151 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION

1.0 INTRODUCTION

By letter dated December 21, 2022 (Reference 1), Westinghouse Electric Company LLC (WEC) submitted the Advanced Logic System [(ALS)] v2 [(Version 2)] Platform Topical Report, the Advanced Logic System v2 Development Process Topical Report, and an initial set of supporting documents for the U.S. Nuclear Regulatory Commission (NRC) staffs safety evaluation (SE). By emails sent on February 3, 2023 (Reference 2), and March 3, 2023 (Reference 3), respectively, the NRC staff accepted the subject topical reports for review. WEC also provided supplemental information to support this SE (Reference 4).

The original ALS Platform Topical Report (Reference 5), hereafter referred to as the ALS Platform Topical Report, as amended by Reference 1, identifies the scope of the requested platform SE. The SE of the ALS v2 platform is limited to the development and test plans to design, the verification and validation (V&V), and perform equipment qualifications (EQs) for variants of seven circuit boards. The SE scope excludes the development, integration, and testing of a specific system, factory acceptance test of a system, or maintenance activities to support a fielded system. The SE also excludes any evaluation of the platforms accuracy and response time specifications to determine whether a given configuration will meet plant-specific or application-specific needs.

The ALS v2 platform design is based on the ALS platform which was evaluated by the NRC staff and approved for use in nuclear safety applications (Reference 4). The original ALS platform was an evolution of the development method, architecture, board suite, and communication interfaces developed and approved for use in the Wolf Creek Generating Station (Wolf Creek) main steam and feedwater isolation system (see Reference 6 and Reference 7).

Like the ALS platform, the ALS v2 platform is based on field programmable gate array (FPGA) technology and is being evaluated for general application within safety systems of current and new nuclear power generating stations. As such, this SE addresses criteria that apply to digital equipment for use in nuclear power plant safety systems.

Section 2.0 of this SE identifies the applicable regulatory bases and corresponding guidance and regulatory acceptance criteria against which the NRC staff evaluated the topical report submittals. Section 3.0 of this SE provides the instrumentation and control (I&C) technical evaluation of the topical report submittals and includes a description of the ALS v2 platform.

Unless specifically described and evaluated in this SE, the evaluation and conclusions documented in the ALS Platform Topical (Reference 5) should be considered applicable to the ALS v2 platform. Section 4.0 provides the limitations and conditions that apply to applicants or licensees referencing this SE for use of the ALS v2 platform in a safety system of a nuclear power generating station. Section 5.0 provides a list of references and Section 6.0 provides the NRC staffs conclusion.

For clarity, this SE uses the term manufacturer to refer to the applicant, WEC, that submitted the topical reports for its platform while applicant refers to an applicant for a license and licensee refers to a holder of a license.

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION

2.0 REGULATORY EVALUATION

NUREG-0800, Standard Review Plan for the Review of Safety Analysis Reports for Nuclear Power Plants: LWR [Light-Water Reactor] Edition, provides the acceptance criteria for this review. NUREG-0800, which is referred to as the Standard Review Plan (SRP), sets forth a method for reviewing compliance with applicable sections of Title 10 of the Code of Federal Regulations (10 CFR) Part 50, Domestic Licensing of Production and Utilization Facilities.

Specifically, SRP Chapter 7, Revision 7, Instrumentation and Controls - Overview of Review Process, dated August 2016, addresses the requirements for I&C systems in nuclear power plants based on LWR designs. SRP Chapter 7 and the Interim Staff Guidance (ISG) documents that are associated with digital I&C (DI&C-ISG), which augment and supplement SRP Chapter 7, principally establish the review process for digital I&C systems, which the NRC staff applied in this SE.

This SE does not directly evaluate regulations and guidance at the system level and only evaluates the capabilities and characteristics of the ALS v2 platform on a generic basis with respect to support of future evaluations of safety systems at the system level.

Determination of full compliance with the applicable regulations remains subject to the platform meeting generic requirements (e.g., EQs) and a plant-specific licensing review of a full system design based on the ALS v2 platform. Generic open items (GOIs) and plant-specific action items (PSAIs) have been established to identify criteria that should be addressed by applicants and licensees referencing this SE (see Sections 4.1 and 4.2, respectively). In part, these criteria are provided to facilitate an applicants or licensees ability to establish full compliance with the design criteria and regulations identified in SRP Chapter 7, Table 7-1, applicable to the applicants or licensees digital I&C system and in effect at the time of the ALS v2 platform review. The GOIs and PSAIs do not obviate an applicants or licensees responsibility to adequately address new or changed design criteria or regulations that apply in addition to those to perform this SE when making a voluntary change to its facility.

The following regulations are applicable to the topical reports:

Regulation 10 CFR 50.54(jj) requires structures, systems, and components subject to the codes and standards in 10 CFR 50.55a to be designed, fabricated, erected, constructed, tested, and inspected to quality standards commensurate with the importance of the safety function to be performed.

Regulation 10 CFR 50.55a(h), Protection and safety systems, discusses, in part, meeting the requirements of the 1991 version of Institute of Electrical and Electronics Engineers (IEEE) Standard 603, Criteria for Safety Systems for Nuclear Power Generating Stations, including the correction sheet dated January 30, 1995.

The NRC staff also considered the application-specific 10 CFR Part 50, Appendix A, General Design Criteria (GDC) when evaluating the topical reports for use in safety systems, as follows:

o GDC 1, Quality Standards and Records o GDC 2, Design Bases for Protection Against Natural Phenomena o GDC 4, Environmental and Dynamic Effects Design Bases o GDC 13, Instrumentation and Control

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION o GDC 20, Protection System Functions o GDC 21, Protection System Reliability and Testability o GDC 22, Protection System Independence o GDC 23, Protection System Failure Modes o GDC 24, Separation of Protection and Control Systems o GDC 25, Protection System Requirements for Reactivity Control Malfunctions o GDC 29, Protection Against Anticipated Operational Occurrences The NRC staff evaluated the ALS Topical Report, as amended by Reference 1, using applicable portions of the following guidance:

Regulatory Guide (RG) 1.22, Periodic Testing of Protection System Actuation Functions, Revision 0, dated February 1972 (ML083300530), describes a method acceptable to the NRC staff for inclusion of actuation devices in the periodic tests of the protection system during reactor operation.

RG 1.47, Bypassed and Inoperable Status Indication for Nuclear Power Plant Safety Systems, Revision 1, dated February 2010 (ML092330064), describes a method acceptable to the NRC staff for complying with IEEE Std 603-1991 with regard to bypassed and inoperable status indication for nuclear power plant safety systems.

RG 1.53, Application of the Single-Failure Criterion to Safety Systems, Revision 2, dated November 2003 (ML033220006), describes a method acceptable to the NRC staff for meeting the NRCs regulations as they apply to the single-failure criterion to the electrical power, instrumentation, and control portions of nuclear power plant safety systems.

RG 1.62, Manual Initiation of Protective Actions, Revision 1, dated June 2010 (ML092530559), describes methods acceptable to the NRC staff for complying with IEEE Std 603-1991 with regard to the manual initiation of protective actions.

RG 1.75, Criteria for Independence of Electrical Safety Systems, Revision 3, dated February 2005 (ML043630448), describes a method acceptable to the NRC staff for meeting physical independence of the circuits and electrical equipment that comprise or are associated with safety systems.

RG 1.97, Criteria for Accident Monitoring Instrumentation for Nuclear Power Plants, Revision 5, dated April 2019 (ML18136A762), describes a method acceptable to the NRC staff for providing instrumentation to monitor variables for accident conditions.

RG 1.100, Seismic Qualification of Electrical and Active Mechanical Equipment and Functional Qualification of Active Mechanical Equipment for Nuclear Power Plants, Revision 4, dated May 2020 (ML19312C677), describes a method acceptable to the NRC staff for use in seismic qualification.

RG 1.118, Periodic Testing of Electric Power and Protection Systems, Revision 3, dated April 1995 (ML003739468), describes a method acceptable to the NRC staff for complying with the NRCs regulations as they apply to periodic testing of electric power and protection systems.

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION RG 1.152, Criteria for Use of Computers in Safety Systems of Nuclear Power Plants, Revision 3, dated July 2011 (ML102870022), describes a method acceptable to the NRC staff for complying with the NRCs regulations as they apply to high functional reliability and design requirements for computers used in the safety systems of nuclear power plants.

RG 1.168, Verification, Validation, Reviews, and Audits for Digital Computer Software Used in Safety Systems of Nuclear Power Plants, Revision 2, dated July 2013 (ML13073A210),

describes a method acceptable to the NRC staff for complying with the NRCs regulations as they apply to the V&V of safety system software.

RG 1.169, Configuration Management Plans for Digital Computer Software Used in Safety Systems of Nuclear Power Plants, Revision 1, dated July 2013 (ML12355A642), describes a method acceptable to the NRC staff for complying with the NRCs regulations as they apply to the configuration management (CM) of safety system software.

RG 1.170, Test Documentation for Digital Computer Software Used in Safety Systems of Nuclear Power Plants, Revision 1, dated July 2013 (ML13003A216), describes a method acceptable to the NRC staff for complying with the NRCs regulations as they apply to test documentation of safety system software.

RG 1.171, Software Unit Testing for Digital Computer Software Used in Safety Systems of Nuclear Power Plants, Revision 1, dated July 2013 (ML13004A375), describes a method acceptable to the NRC staff for complying with the NRCs regulations as they apply to the unit testing of safety system software.

RG 1.172, Software Requirement Specifications for Digital Computer Software and Complex Electronics Used in Safety Systems of Nuclear Power Plants, Revision 1, dated July 2013 (ML13007A173), describes a method acceptable to the NRC staff for complying with the NRCs regulations as they apply to preparation of software requirement specifications for safety system software.

RG 1.173, Developing Software Life-Cycle Processes for Digital Computer Software Used in Safety Systems of Nuclear Power Plants, Revision 1, dated July 2013 (ML13009A190),

describes a method acceptable to the NRC staff for complying with the NRCs regulations as they apply to the development processes for safety system software.

RG 1.180, Guidelines for Evaluating Electromagnetic and Radio-Frequency Interference in Safety-Related Instrumentation and Control Systems, Revision 2, dated December 2019 (ML19175A044), describes a method acceptable to the NRC staff for design, installation, and testing practices to address the effects of electromagnetic interference/radio-frequency interference (EMI/RFI) and power surges on safety-related I&C systems.

RG 1.209, Guidelines for Environmental Qualification of Safety-Related Computer-Based Instrumentation and Control Systems in Nuclear Power Plants, Revision 0, dated March 2007 (ML070190294), describes a method acceptable to the NRC staff for addressing the environmental qualification of safety-related computer-based I&C systems for service in mild environments at nuclear power plants.

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION DI&C-ISG-04, Task Working Group #4: Highly-Integrated Control Rooms - Communications Issues (HICRc), Revision 1, dated March 6, 2009 (ML083310185), describes methods acceptable to the NRC staff to prevent adverse interactions among safety divisions and between safety-related equipment and equipment that is not safety-related.

The NRC staff also considered applicable portions of branch technical positions (BTPs) in accordance with the review guidance established within NUREG-0800, Chapter 7, in accordance with 10 CFR 50.34(h)(3), as follows:

SRP, Appendix 7.1-C, Guidance for Evaluation of Conformance to IEEE Std 603, Revision 6, dated August 2016 (ML16019A107)

SRP, Appendix 7.1-D, Guidance for Evaluation of the Application of IEEE Std 7-4.3.2, Revision 1, dated August 2016 (ML16019A114)

BTP 7-11, Guidance on Application and Qualification of Isolation Devices, Revision 6, dated August 2016 (ML16019A184)

BTP 7-14, Guidance on Software Reviews for Digital Computer-Based Instrumentation and Control Systems, Revision 6, dated August 2016 (ML16019A308)

BTP 7-17, Guidance on Self-test and Surveillance Test Provisions, Revision 6, dated August 2016 (ML16019A316)

BTP 7-19, Guidance for Evaluation of Defense In Depth and Diversity to Address Common-Cause Failure Due to Latent Design Defects in Digital Safety Systems, Revision 8, dated January 2021 (ML20339A647)

BTP 7-21, Guidance on Digital Computer Real-Time Performance, Revision 6, dated August 2016 (ML16020A036)

3.0 TECHNICAL EVALUATION

The following subsections identify and describe the ALS v2 platforms I&C components and evaluate those components and their development against the regulatory evaluation criteria identified in Section 2.0.

3.1 Platform Description As with the original ALS platform, the ALS v2 platform consists of standardized circuit boards and FPGA programs. As a 10 CFR Part 50, Appendix B, Quality Assurance Criteria for Nuclear Power Plants and Fuel Reprocessing Plants supplier, WEC developed this platform to implement a variety of plant systems for use in nuclear power plants. The ALS v2 platform is FPGA logic-based and provides a configurable architecture that relies on the quality of the design and development process to produce platform components suitable for use in nuclear safety related applications. The development activities are discussed in the ALS v2 Development Process Topical Report (Reference 8) and are evaluated in Section 3.2 of this SE.

The ALS v2 platform supports redundant instrument configurations to further ensure continued

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION safety function operability. The ALS v2 platform provides embedded diagnostic and testing capabilities, which have been built into the ALS v2 platform through specification.

The ALS v2 platform is a modular design where generic standardized circuit boards can be combined in a variety of configurations. The ALS v2 platform offers a set of FPGA-based configurations that implement built-in design diversity to support the application-specific safety analysis required by BTP 7-19.

An ALS v2 platform-based safety-related instrument would be implemented using one or more ALS v2 chassis and peripheral equipment consisting of cabinets, power supplies, control panels, assembly panels, and a maintenance workstation. The assembly panels incorporate field terminal blocks, fuse holders, switches, and other application-specific hardware. The scope of this SE includes the set of seven standardized circuit boards, an instrument chassis, and backplane. Each instrument backplane is a standard vertically mounted circuit board into which each ALS v2 circuit board is installed within an instrument chassis. Instrument backplanes provide mating connectors for the standardized circuit boards to make standardized ALS bus connections. Application-specific field input and output connections are made through connectors on the front side of the ALS v2 boards.

As with the original ALS platform, the ALS v2 platform supports field input and output types, including digital contacts, relay contacts, analog current, analog voltage, resistance temperature detectors (RTDs), and thermocouples. The ALS v2 chassis has been modified from the original ALS design to provide an increase in input/output (I/O) density with a smaller footprint. These changes in the platform form factor are described as Category 1 changes in the ALS v2 platform topical report (Reference 9). The ALS v2 chassis still uses an industry standard 19-inch wide chassis, however, the new chassis design can accommodate a greater number of circuit boards. A maximum of 16 ALS v2 circuit boards can be installed in a single chassis as opposed to the maximum of 10 circuit boards in the original ALS chassis. In addition, the ALS v2 backplane has the capability to be used as a split backplane and operate independently in one physical chassis, which may require additional testing based on the specific application for which the split backplane will be used. The depth of the ALS v2 chassis is also reduced from the original ALS chassis design and the field connectors have been relocated from the rear of the chassis to the front of the chassis.

All ALS circuit boards have been re-designed for the ALS v2 platform and WEC provided Table 2-1 (Reference 1) to identify each of the seven circuit boards of the original ALS design with corelating circuit board numbers for the ALS v2 platform. The equivalent circuit board numbers for each platform are provided below:

Board Type ALS Board Number ALS v2 Board Number Core Logic ALS-102 ALS-152 Digital Input ALS-302 ALS-352 Analog Input ALS-311 ALS-361 (RTD/thermocouple)

Analog Input (Voltage/Current)

ALS-321 ALS-371 Digital Output ALS-402 ALS-452 Analog Output ALS-421 ALS-471 Communications ALS-601 ALS-651

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION Table 3.1-1, ALS v2 Platform Plans Document ID Title Reference WNA-PV-00129-GEN, Revision 0 Advanced Logic System v2 Software Verification and Validation Plan 25 6003-00004 ALS v2 Equipment Qualification Plan 21 6003-00006 ALS v2 Security Plan 26 WCAP-18780-P/NP Advanced Logic System v2 Development Process Topical Report 9

ALS Quality Assurance Plan Section 7 Software Safety Plan Section 8 Test Plan Section 9 Software Installation Plan Section 10 Integration Plan Section 11 Maintenance Plan Section 12 Configuration Management Plan Section 13 Security Plan Section 14 Project Specific Planning Documents Section 15 The seven standardized circuit boards provided within the ALS topical report, as amended by Reference 1, are:

1. ALS-152 Core Logic Board

2. ALS-352 Digital Input Board (48Vdc Contact Input)

3. ALS-361 Analog Input Board (RTD and Thermocouple)

4. ALS-371 Analog Input Board (Voltage/Current)

5. ALS-452 Digital Output Board (Contact Output)

6. ALS-471 Analog Output Board (Voltage/Current)

7. ALS-651 Communications Board 3.1.1 General Instrument Architecture The ALS v2 platform architecture is similar to that of the original ALS platform, which was evaluated by the NRC staff (Reference 5). A block diagram, Figure 3-3, ALS v2 Split Backplane Functional Architecture Diagram Reference, of the ALS v2 Platform Topical Report (Reference 9) shows a general ALS v2 platform architecture that uses each of the standardized circuit boards. This block diagram is similar to Figure 3.1.1-1, ALS Platform Architecture Block Diagram, for the original ALS platform that was previously evaluated except that it reflects the use of ALS v2 components. This block diagram depicts one possible configuration rather than an application specific instrument configuration. The NRC staff understands that this block diagram is consistent with the configuration that will be used for ALS v2 EQ testing.

The components of the ALS v2 system will be developed and qualified as safety-related Class 1E equipment for use in a mild environment. The NRC staff will evaluate these components against the criteria established for digital equipment that may be relied upon to perform a safety function when installed in a mild environment. The NRC staff will perform this evaluation of the ALS v2 platform components in a generic fashion without consideration for unique or additional criteria that might apply to an application-specific safety function or plant installation.

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION Figure 2-1, ALS vs ALS v3 Chassis with Boards, of the ALS v2 Platform Topical Report shows a physical representation of the ALS platform chassis for an instrument containing standardized circuit boards. This figure shows both the ALS and the ALS v2 chassis and illustrates the physical differences between these designs. The mechanical structure and backplane of the instrument were developed and will be qualified for its use as safety-related Class 1E equipment to be used in a mild environment.

The NRC staff reviewed the EQ Plan (Reference 10) for ALS v2 platform components against environmental, electromagnetic compatibility, and seismic qualification criteria applicable to safety-related Class 1E equipment for use in a mild environment. Further information related to the NRC staffs evaluation of EQ is located in Section 3.3.

The original ALS topical report included examples of ALS platform applications for potential digital modifications. It also included three proprietary appendices that showed a variety of generalized equipment architectures with varying degrees of built-in diversity (see Reference 5, Appendices A through C). For the ALS v2 topical report, these appendices, along with all the other referenced sections of the original topical report, are being revised in accordance with Table 5-1, Reference Table to Original ALS Topical Report, of the ALS v2 topical report (Reference 1), to reflect the modified designs and design concepts being used for the ALS v2 platform. This SE does not include a safety determination of adequate diversity for either the application-specific equipment or conceptual architectures provided in these modified appendices. Instead, this SE uses the modified ALS Topical Report Appendices A through C as examples. These examples would need to demonstrate the intended use of ALS v2 platform design features in order to identify and document appropriate PSAIs. System development activities will need to demonstrate how an ALS v2 platform-based system implements the degree of diversity that has been specified for the system. The final set of diversity and defense-in-depth considerations should address the overall plant instrumentation architecture with regard to potential plant vulnerabilities.

The isolation provided on the ALS v2 platform circuit boards is limited to that necessary for electromagnetic compatibility and circuit reliability. However, the board level provisions are not intended to ensure sufficient isolation exists between the ALS v2 platform-based Class 1E equipment and Non-Class-1E equipment. The ALS topical report scope, as amended by Reference 1, excludes explicit identification of the method to ensure that sufficient isolation exists between the ALS v2 platform-based Class 1E equipment and Non-Class-1E equipment.

The ALS topical report, as amended by Reference 1, states that the demonstration that this isolation criterion is met will be performed as part of a plant-specific application and qualified isolation devices will be used when required by the application.

The ALS v2 platform EQ applied type testing, which RG 1.209 identifies as the preferred method. This type testing will use a representative instrument configuration to proof-test the platforms capabilities and to establish its qualified performance for safety-related applications in nuclear power plants.

Table 3.1-2 identifies ALS v2 platform-level supporting documents that apply to the entire ALS v2 platform development.

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION the flash-based and SRAM-based FPGAs. The scope of the ALS v2 topical report and its evaluation does not include licensee administrative procedures, or the tools used to perform those activities. Additionally, ALS v2 platform design features, in a similar fashion to the ALS design features prevent the maintenance workstation from modifying any non-operationally adjustable settings required to remain constant, so the equipment remains capable of performing its application-specific instrument functions.

3.1.3 Platform Digital Communications Overview As defined in the original ALS SE, the ALS v2 platform continues to provide digital communications methods for intra-channel safety signals, unidirectional transmit-only to external equipment, bidirectional for use with a maintenance workstation, and unidirectional receive or transmit for exchanges between instrument channels or to additional non-safety equipment. While the new version of the standardized boards has the capability for enhanced communications, those ports are not currently being used and instead the platform continues to rely on the RAB and the test ALS bus (TAB).

The TAB is similar to the RAB in the following ways:

Each provides bidirectional communications, Each uses a lower-level universal asynchronous receiver/transmitter (UART) protocol, Each has a single bus master, Each uses a higher-level protocol that implements fixed-format request-and-reply messaging that applies a defined response limit for each transaction, and The backplane(s) provide a copper medium for point-to-point differential signaling.

The TAB differs from the RAB in the following ways:

A maintenance workstation, which may be non-safety, is the TABs master while a safety ALS-152 Core Logic Board is the RABs master, Unlike the RAB, the TAB does not provide a safety signal path, Unlike the RAB, the TAB is not redundant, Unlike the RAB, the TAB interface is not always active, and Unlike the RAB, the TAB neither enforces a fixed interval for messaging nor includes an automatic retry in response to a failed transaction.

For further information related to how the platforms communications function, refer to Section 3.1.1 of Reference 5.

3.1.4 Platform Circuit Board Set

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION the power management logic. As is the case with its predecessor, the ALS-471 Analog Output Board also includes features to support calibration without affecting cabling.

The NVM configuration on each ALS-471 ((

)). As is the case with its predecessor, the NRC staff understands that it can still enable or disable the channel, define the channels output as either a voltage or current, and define the channels output range for voltage or current signals. Based on a review of the information in the ALS v2 submittal, the NRC staff understands that no other changes have been made to the ALS-471 analog output board.

3.1.4.6 ALS-651 Communication Board The ALS-651 Communication Board continues to provide eight channels of unidirectional digital data communications that apply differential signaling in accordance with Electronic Industries Alliance (EIA)-422 over terminated point-to-point transmission lines. The direction of communication is configured by the ALS Test and Calibration Tool (ATCT). In addition to the EIA-422 protocol, per Reference 9, the ALS-651 Communication Board supports the EIA-485 communication protocol for internal communications. However, when the board is configured in an application-specific system, it will be evaluated as part of a PSAI.

Each channel of the ALS-651 board can be configured for transmit only or receive only operation. Per Section 3.1.3 (Reference 5), the communications operated in a unidirectional transmit only mode to external systems and related equipment. As the possibility exists for this device to receive data from external system(s), and these communication parameter changes may be managed by the general-purpose software tool, the ATCT, the platform topical report relates that its configuration parameters will be verified via a System Integration Test (SIT) and for plant installations, the intra and inter-communications parameters will be managed via a PSAI.

Also, the increased rating of the 3.3 Vdc power supply in the ALS v2 allows the removal of the H16 restriction associated with the ALS-601 board as described in Reference 20.

The NVM configuration for each ALS-651 ((

)) and can enable or disable the channel, define the channel as either a receiver or transmitter, define the channels baud rate, define the channels UART encoding scheme, and define the base communication protocol as either Byte Mode or Packet Mode. Based on a review of the information in the ALS v2 submittal, the NRC staff understands that no other changes have been made to the ALS-651 Communication Board.

3.1.4.7 ALS-152 Core Logic Board The ALS-152 Core Logic Board, as did its predecessor, the ALS-102 Core Logic Board, provides a processing resource to implement application-specific safety functions, and these safety functions are programmed into the ((

)) FPGA logic. The ALS-152 is comprised of six digital input channels, four digital output channels, and two serial data link channels.

The ALS-152 provides two transmit-only digital data communication channels. The ALS-152 communication channel configuration is identical to that of the ALS-651 channel

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION

)) as described in Reference 18 continues to provide some level of assurance that should either of the two cores (primary and secondary) within the FPGA disagree with their respective interim output points, the board will be driven to a known safe state. Additionally, as there is no actual system being constructed, how a fault and an alarm are managed is dependent of the specific application of the platform and is beyond the scope of this SE. As with the original ALS platform, the ALS v2 platform FPGAs implement ((

)) with diversity to perform functions redundantly and include timing verification logic. These features support continued functional operability or result in annunciation of an alarm for operator action.

3.2.1.1 Standardized Circuit Boards The ALS v2 Platform Topical Report (Reference 9) describes basic platform components that include standardized printed circuit boards (PCBs) [

)) which act as core logic or a type of I/O card; a backplane; and chassis. Section 1 of this SE provides descriptions of these components and their intended use in consideration of the ALS v2 Topical Report that depict notional applications of these components for a variety of safety-related digital safety systems.

The ALS v2 Platform Requirements Specification (Reference 22) specifies the top-level platform requirements for the ALS v2 platform, its architecture, backplane, and its chassis. In addition to these platform requirements, the manufacturer specifies top-level requirements for each standardized circuit board. The manufacturer continues to use a requirements management tool to support traceability of the top-level requirements specifications into lower-level product specifications, including hardware. A CM tool is used to maintain and control top-level requirements specifications, lower-level product specifications, and other design, development, and implementation products. ALS v2 documentation and products, including hardware, by name and revision, are maintained within configuration status accounting documents. The NRC staff reviewed the ALS v2 Platform Configuration Status Accounting document (6003-00007) during a regulatory audit and confirmed that it remains consistent with the original ALS document that was reviewed during the ALS platform evaluation (Reference 5).

The manufacturer identifies the requirements and the lower-level product specifications within requirements traceability matrices (RTMs). The RTMs and their use are described in the ALS v2 Verification and Validation Plan (Reference 21). The RTMs are used to map the requirements and specification identifiers to required V&V activities.

Related to the EQ, the manufacturer provided an ALS v2 Equipment Qualification Plan (Reference 10) that will be used to guide EQ efforts. When EQ testing is at or near completion, per the description of the EQ testing in Reference 21, the manufacturer will produce ALS v2 Platform EQ Summary Reports to document the completion of the platforms EQ activities.

As no other substantive EQ-related documents related to the ALS v2 were provided to the NRC staff at the time of this SE, the adequacy of the output products related to EQ and their associated acceptance criteria will be verified via a future evaluation and/or the inspection program and will be considered a PSAI as described in Section 3.3 of this SE.

The manufacturer also provided an ALS v2 Verification and Validation Plan (Reference 21) to guide hardware design verification, FPGA logic programming, and V&V integration testing activities at the platform level. Design, verification, and independent V&V (IV&V) activities

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION related to an application-specific use of the platform will be developed separately at a future point and will need to be evaluated as a PSAI (See Section 4.2, Item 23).

For each standardized circuit board, which includes the core logic and I/O board type, as well as the communications and interface board types, the manufacturer will conduct testing activities as part of its design verification process and the IV&V team will produce V&V Phase Summary Reports in accordance with Reference 21 that also document the completion of board-specific FPGA program V&V activities identified in the RTMs for those boards. Although the new interface and power connection board do not use FPGAs, the V&V plan addresses both FPGA and non-FPGA PCBs that will be tested to verify proper operability under all postulated conditions, with the test results captured in V&V summary reports.

As part of its integration testing program, the manufacturer will produce ALS Board Test system (ABTS) summary reports to document the successful completion of the identified board-specific hardware design verification and integration test (both for board-specific FPGA programs with hardware and those boards without FPGAs) activities. Additionally, the manufacturer will produce ALS v2 CM and V&V Phase Summary reports for CM and V&V, respectively.

The method discussed for IV&V activities in Reference 21 covers the generic ALS v2 platform design, verification, and IV&V activities. The review of platform level V&V activities and reports will be managed via a GOI (see Section 4.1, Item 4). Those V&V activities related to an application-specific use of the platform will be developed separately at a future point and will be evaluated as a PSAI (See Section 4.2, Item 23).

Although the NRC staff did not perform an independent design review of the ALS v2 platform output products for the different phases of the ALS v2 development process, the NRC staff reviewed the ALS v2 platform design and the development process to determine whether it supports an applicants ability to meet regulatory requirements, and whether the hardware process is of sufficient quality to produce systems, hardware, and FPGA logic programs that are suitable for use in safety-related applications in nuclear power plants.

The NRC staff reviewed the ALS Topical Report, as amended by Reference 1, ALS v2 Platform Requirements Specification (Reference 22), ALS v2 Platform Design Specification (Reference 23), and the board FPGA Requirements Specifications to determine if the manufacturers information provided descriptions of its ALS v2 platform components, explained how the integrated hardware and FPGA logic programs support safety functions, identified specific platform functions that support safety, and described how EQ and V&V activities will be performed to ensure the continued operability and performance of the platform functions. The manufacturers explanations of the ALS v2 platform components supported the NRC staffs reviews and evaluations against specific regulatory evaluation criteria. In addition, the NRC staff determined that the manufacturers information related to the ALS v2 platform, along with the information in Reference 1, is suitable for use by applicants or licensees referencing this SE.

However, because the V&V output products will only become available when plant-specific applications are developed, the implementation of the manufacturers V&V program will be a PSAI (See Section 4.2, Item 23).

3.2.1.2 Standardized FPGAs

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION Six of the seven standardized ALS v2 circuit boards (ALS-352, ALS-361, ALS-371, ALS-452, ALS-471, and ALS-651) support the use of non-application-specific FPGA logic programs

((

)). Therefore, the scope of the ALS v2 platform topical report encompasses the entire FPGA logic program development ((

))

installed within these six boards.

The NRC staff evaluated the ALS v2 platform FPGA logic program development using the set of regulatory guidance applicable to computer software development. This NRC staffs evaluation considered differences between FPGA logic program development activities and typical computer software development activities when applying the following guidance:

BTP 7-14, Guidance on Software Reviews for Digital Computer-Based Instrumentation and Control Systems RG 1.168, Verification, Validation, Reviews, and Audits for Digital Computer Software Used in Safety Systems of Nuclear Power Plants RG 1.169, Configuration Management Plans for Digital Computer Software Used in Safety Systems of Nuclear Power Plants RG 1.170, Test Documentation for Digital Computer Software Used in Safety Systems of Nuclear Power Plants RG 1.171, Software Unit Testing for Digital Computer Software Used in Safety Systems of Nuclear Power Plants RG 1.172, Software Requirement Specifications for Digital Computer Software and Complex Electronics Used in Safety Systems of Nuclear Power Plants RG 1.173, Developing Software Life-Cycle Processes for Digital Computer Software Used in Safety Systems of Nuclear Power Plants As with the original evaluation, this NRC staff evaluation does not consider guidance that applies at the system level, such as system-specific requirements development, hazards analysis, and activities associated with plant project specific life-cycle stages, from production manufacturing to system integration, and onward because the ALS v2 Topical Report and ALS v2 platform activities only cover the development of a set of components to be used in a safety related I&C system rather than the production of an actual system.

The manufacturers plans define its lifecycle development process to start with top-level platform, that includes common functionality and design features shared by multiple boards. The specification set of documents then moves to lower-level documents describing its standardized PCB ((

)) requirements that describe its development of the different FPGAs, including their design features and their limitations and constraints. The requirements specification documents for the FPGAs serve the same need as software requirements specifications. The NRC staffs evaluation addresses only the life-cycle stage of planning, or the concept and planning phase, and some documents from the requirements phase as several of the output documents related to the requirements phase and beyond have either not been completed by the manufacturer or docketed for the NRC staffs review. To meet portions of

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION BTP 7-14 that are applicable to the ALS v2 platform scope for life-cycle planning, the manufacturer stated in Table 5-1, Reference Table to Original ALS Topical Report (Reference 5), that it envisions managing its licensing submittals using the guidance specified in BTP 7-14, in a similar fashion to the Tier 2 licensing process outlined in DI&C-ISG-06, Licensing Process, for the applicable life-cycle activities (Reference 24). Beyond the reference to the manufacturer using a process similar to the Tier 2 process in Reference 24, the aspects related to how the manufacturer commits to follow the guidance of BTP 7-14 are outlined in the original SE.

The manufacturer established a CM Plan as part of its original ALS platform development process and the same document serves as the high-level CM document for the ALS v2 platform (see Reference 25). The manufacturers ALS v2 Configuration Management Plan continues to identify the items subject to CM activities, defines project milestones related to these activities, and explains the manufacturers application of a CM tool, as applied throughout the ALS v2 platform lifecycle. Per the manufacturers CM Plan, for each of the seven board types, a CM Summary Report will be produced that will provide documentary evidence that proper configuration controls will have been applied during the development of each type of PCB.

These CM activities include provisions to track the resolution of reported anomalies to the item or items that implement a corrective action (see Reference 25.

In Section 7 of the ALS Application Guidance (Reference 20), the manufacturer describes its Quality Assurance Plan (QAP) that defines the methods WEC will use to assure quality in the design and test programs related to the development of the ALS v2 platform. These approaches will be conducted in compliance with WECs Quality Management System (QMS), which the NRC staff has determined that, when properly implemented, complies with the requirements of Appendix B to 10 CFR Part 50, and 10 CFR Part 21, Reporting of Defects and Noncompliance (ML14336A487).

The QAP, working in concert with other documents (e.g., WECs QMS (ML20118C995) and ALS v2 V&V Plan (Reference 21)), describes how the manufacturer manages its non-conformances, anomalies, and applies and documents its corrective action program throughout the ALS v2 platform lifecycle.

The V&V method applied by the manufacturer, includes the use of technically independent personnel from the design team who conduct test cases on the FPGAs and associated hardware to ensure that all component, board, ((

,)) and interface, meet the individual, module, and system level requirements.

The testing of the ALS v2 platform will be derived from the requirements and design specifications for the platform. The manufacturer will use the RTM as a basis document to ensure the requirements traceability through all levels of the platform and to ensure complete test case coverage of the platform. The high-level test plan contained in Reference 8 describes the testing program as integration testing; however, it also discusses lower-level testing, including board-level testing, in which WEC commits to complying with IEEE Standard 829-1998, IEEE Standard for Software Test Documentation. Although the NRC currently endorses the 2008 version of the standard, the test plan in Reference 8, along with Section 5.2 of Reference 21 and lower-level testing requirements as described in documents reviewed during the audit, provides a foundation to support an overall acceptable test plan for the ALS v2 platform. Information related to the step-by-step development process involved with

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION between FPGA logic functions components common to multiple standardized circuit cards (including the ALS-152) and those specific to a single card.

3.2.2 Reusable Logic Elements (RLETs)

The ALS v2 platform also includes a new Reusable Logic Element (RLET) feature. A detailed description of RLETs is provided in Section 4 of the ALS v2 Platform topical report (Reference 9). This enhancement to the ALS platform design involves development of a library of RLETs that are verified and validated as nuclear safety-related functions. These RLETs are developed in accordance with ALS v2 quality and security development procedures and the ALS v2 Development Process topical report (Reference 8), which are the same processes used to develop RTL for an ALS v2 application. When an RLET is verified and validated, it can then be reused in future design applications without requiring additional development or V&V activities. RLETs are instantiated into the application source code and become part of the FPGA application during the synthesis process. By reusing RLETs that are already verified and validated, the V&V effort for an application can be reduced in scope.

The NRC staff evaluated the functional details of the features provided by these RLETs and concluded the use of RLET features should not have an adverse impact on the ability of an ALS v2 based system to perform assigned safety functions, provided the manufacturer follows its prescribed V&V Program. The NRC staff also concludes that the established level of deterministic behavior of the ALS system, as defined in Section 3.4.2 of this SE, should not been compromised by the addition of this RLET feature, as these features and related system functions will be evaluated via the manufacturers V&V program.

3.2.3 Evaluation of WCAP-18780, ALS v2 Development Process Topical Report The manufacturers plans defined the design development process to start with top-level platform and standardized circuit card requirements development. The design development process then proceeds to successively lower levels through specifications development and design implementation. The staffs evaluation addresses only the life-cycle stage of planning, or the concept and planning phase, and some documents from the requirements phase as several of the output documents related to the requirements phase and beyond have either not been completed by the manufacturer or docketed for staff review. To meet portions of BTP 7-14 that are applicable to the ALS v2 platform scope, the manufacturer continues to commit to follow the guidance cited in BTP 7-14 for the applicable life-cycle activities (see Reference 5, Sections 6.2 and 12.4).

The manufacturers processes include lower-level specifications, which the manufacturer refers to as Design Specifications, to govern FPGA logic program development. There are multiple FPGA design specifications because the manufacturer specifies the requirement of core diversity and then decomposes FPGA logic functionality between that which is common to all boards and that which is board specific. As the manufacturer explained to the NRC staff during the ALS Platform Topical Report review, the design specifications for the ALS v2 platform, once developed, will fulfill the role of Software Requirements Specifications for its FPGA development. As no changes to these documentation processes have been proposed by the manufacturer in its ALS v2 submittal, the NRC staff continues to find this approach acceptable.

Furthermore, FPGA development procedures are used to govern this design activity.

Life Cycle Planning Process for ALS v2 Application Logic

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION Digital I&C safety systems must be designed, fabricated, installed, and tested to quality standards commensurate with the level of the importance of the safety functions to be performed. The development of safety system software should progress according to a formally defined software lifecycle (SLC). Implementation of an acceptable SLC provides reasonable assurance that the necessary software quality has been instilled in the final system. BTP 7-14, Section B.2.1 provides guidance on the information to be reviewed for the SLC process planning.

Although not addressed in BTP 7-14, the manufacturer developed a separate security plan to address the criteria of RG 1.152, which provides guidance for the establishment of a secure development and operational environment (SDOE) for safety related ALS v2 FPGA logic (see Reference 26). This security plan is also included as Section 14 of the ALS v2 Development Process Topical Report (Reference 8).

While most of the information on the topics described in BTP 7-14 are contained in the ALS v2 Development Process topical report, information found in the ALS v2 Platform Topical Report and in other submittals was considered for this SE. The ALS v2 Development Process topical report includes sections with the following section numbers and titles:

(Section 4) Platform Development Plan (Section 5) Application Development Plan (Section 7) Quality Assurance Plan (Section 8) Software Safety Plan (Section 9) Test Plan (Section 10) Installation Plan (Section 11) Integration Plan (Section 12) Maintenance Plan (Section 13) Configuration Management Plan (Section 14) Security Plan The NRC staff has organized this report to follow the sequence outlined under each topic in the ALS v2 Development Process topical report.

3.2.3.1 Platform and Application Development Plan The ALS v2 Platform Development Plan describes the plan for technical project development.

BTP 7-14, Section B.3.1.2, which describes acceptance criteria for software development plans, was used as a basis for the evaluation of this plan.

WEC uses a controlled development process, which is defined within the ALS v2 Development Process topical report. The required elements of a Development Plan are defined within the following sections of the topical report:

Section 1.2, Software Classification and Categorization Section 3.2, Life Cycle Definition Section 4.2.3, Equipment and Software Classification Section 3.2, Life Cycle Definition Section 4.5.1, FPGA Development Cycle

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION Section 3.2 of the topical report defines the development lifecycle used for the development of ALS v2 logic. This life cycle is consistent with a classic waterfall model like the model discussed in Section 2.3.1 of NUREG/CR-6101, Software Reliability and Safety in Nuclear Reactor Protection Systems (ML072750055). The ALS v2 life cycle consists of the following life cycle phases:

Concept/Planning Phase Requirements Phase Design Phase Implementation Phase Integration/Test Phase Installation Phase Operation and Maintenance Phase Retirement Phase This model assumes that each phase of the life cycle is completed in sequential order from concept to the retirement phase. The NRC staff finds the WEC choice of development life cycle acceptable, since the waterfall model is well suited for projects with known and stable requirements and where few changes to requirements are anticipated. Since WEC selected an acceptable software life cycle model, the guidance criteria of Section A.1 of IEEE Std 1074-2006, Standard for Developing Software Life Cycle Processes, as endorsed by RG 1.173, has been satisfied.

3.2.3.1.1 ALS v2 Life Cycle Tasks (Inputs & Outputs)

BTP 7-14, Section B.3.1.2.4 states that an applicant should identify which tasks are included with each life cycle phase and identify the life cycle tasks inputs and outputs. The ALS v2 Software V&V Plan (Reference 21) defines V&V related tasks to be performed for each life cycle phase. Appendices A & B of the ALS v2 Software V&V Plan identify tasks which are performed for various software categories during the development life cycle process and identify the phases during which each task is performed. Appendix A also identifies organizations that are responsible for completion of these tasks and Appendix B maps these tasks to the V&V activities defined within IEEE Std 1012-2004, IEEE Standard for Software Verification and Validation.

IEEE Std 1012-2004, Clause 1.7, Conformance, states that the minimum V&V tasks are defined by the software integrity level assigned to the software. The mapping of the WEC integrity level scheme, which compares the ALS v2 Software V&V Plan (Reference 21) software integrity level to the IEEE 1012-2004 software integrity level, is in Table 3.4.1 of Reference 21.

The ALS V&V plan states that the software classification assignment leads to the identification of minimum IV&V tasks to be performed during development. Appendix A of the topical report identifies the tasks for each software integrity level and the team assigned to complete them.

This mapping table also identifies the phase of the development lifecycle in which each activity is performed.

Several V&V activities are performed multiple times during the development process. The left-hand column of Table 3.4.1 lists all of the V&V activities from Table 2 of IEEE Std 1012-2004.

Each of these activities has a corresponding activity and reference to the topical report section for the equivalent activity within the ALS v2 development process. The NRC staff reviewed the

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION activities included in this mapping table and determined that it contains sufficient detail and reference to the ALS v2 development processes to show that the V&V activities performed for safety related ALS application protection software are consistent with high criticality software developed to software integrity level (SIL) Level 4 as defined by IEEE Std 1012-2004, as endorsed by RG 1.168, Revision 2, and is therefore acceptable.

3.2.3.1.2 ALS V2 Integrity Level Scheme Section 1.2 of the ALS Development Process topical report discusses the specific classification or integrity level scheme used for the ALS v2 platform. Table 1.2-1 of the ALS v2 Development Process Topical Report compares the WEC software classification scheme with the scheme presented within IEEE Std 1012-2004.

IEEE Std 1012-2004 states that [t]his standard uses software integrity levels to determine the V&V tasks to be performed. High-integrity software requires a larger set of V&V processes and a more rigorous application of V&V tasks. Section 1.2 of the topical report defines the software classes used for ALS software as follows:

Protection (safety critical - critical performance of the system) - Safety critical software whose functionality is necessary to directly perform reactor protection system (RPS) control actions, engineered safety features actuation system (ESFAS) control actions, and safe shutdown control actions.

Important-to-safety - Safety-related software whose functionality is necessary to directly perform alternate protection system control actions, software that is relied on to monitor or test protection functions, or software that monitors plant critical safety functions.

Important-to-availability - Nonsafety-related software whose functionality is relied on to directly perform alternate protection system control actions or software to maintain operation of plant systems and equipment that are critical to maintaining an operating plant.

General purpose - Nonsafety-related software whose functionality performs some purpose other than those described in the previous classifications. This software includes tools that are used to develop software in the other classifications but is not installed in an online plant system.

Table 1.2-2, Assignment of ALS Software to Classes, of the ALS v2 Development Process topical report identifies the assignment of ALS v2 software to the classifications described above. All ALS v2 application software is classified as either Protection, which is equivalent to SIL 4 as defined in IEEE 1012-2004, or Important to Safety. This is consistent with the assumption that ALS v2 based safety systems are classified as Class 1E, as defined by IEEE Std 603-1991.

ALS Components software and logic that are classified as either Protection or Important to Safety are considered to be safety related. It is, however, understood that the subset of safety related software and logic that is classified as Important to Safety does not directly perform RPS or ESFAS safety functions. For this reason, it is acceptable for Important to Safety software to

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION (i.e. protection system). References 8 and 21, further describe the ALS v2 design process and testing and V&V activities, respectively, that support an ALS v2 systems development.

To support configuring and testing the circuit boards ((

))

WEC uses its ATCT. Section 3.6 of Reference 9 provides a description of its use which is to configure and test the ALS v2 boards, including programming the NVM for each multifunctional board to be used in a particular application. The ATCT was also used as part of the original ALS platform development, however, its use was not described in the original ALS submittal.

The ATCT uses the TAB to communicate with the ALS boards and is able to configure each of the boards of the ALS v2 platform as required for the specific application. The correct and reliable use and application of the ATCT will be verified via the V&V Program, which is managed via a GOI at the platform level (see Section 4.1, Item 4) and as a PSAI for an application specific system (see Section 4.2, Item 23).

The ALS v2 Development Process Topical Report (Reference ), Section 4.5.3, Design Tools Document and Error Reporting, and Section 7.10, Tools, Techniques and Methodologies, discuss the development support tools used to facilitate ALS v2 platform logic development. An evaluation of a tools readiness for use on a project is performed before such a tool is used to support the development of an ALS v2 application. This evaluation considers the tools past performance, extent of the tools validation performed, consistency of the tools design with planned use, use of the tools upgrades, retirement of the tool, and restrictions on the use of the tool due to its limitations. The CM, software quality assurance, and IV&V processes defined within the ALS v2 Development Process Topical Report apply to software tools and provide a means of ensuring that these tools are only used for their approved and intended purposes. The outputs of software tools undergo the V&V process as defined in the ALS v2 Software V&V Plan (Reference 21).

The NRC staff has reviewed the ALS development process topical report and concludes that the ALS v2 platform development plan and the overview of the application-specific development plan conforms with the criteria provided by IEEE Std 1074-2006. In addition, the ALS v2 Development Process Topical Report adequately addresses the software development planning activities of BTP 7-14, as applicable for FPGA logic development. The topical report describes acceptable methods of organizing the FPGA development life cycle. Therefore, the NRC staff concludes that WECs ALS v2 platform development plans are acceptable.

3.2.3.2 Quality Assurance Plan BTP 7-14, Section B.3.1.3 provides guidance in evaluating a Software QAP (SQAP). The SQAP shall conform to the requirements of 10 CFR Part 50, Appendix B, and the applicants overall QAP. The regulations at 10 CFR Part 50, Appendix B state that the applicant shall be responsible for the establishment and execution of the QAP. The applicant may delegate the work of establishing and executing the QAP, or any part thereof, but shall retain responsibility for the QAP. The SQAP would typically identify which QA procedures are applicable to specific software processes, identify particular methods chosen to implement QA procedural requirements, and augment and supplement the QAP as needed for software.

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION IEEE Std 7-4.3.2-2003, Clause 5.3.1, which is endorsed by RG 1.152, provides guidance on software QA. IEEE Std 7-4.3.2-2003, Clause 5.3.1, states, Computer software shall be developed, modified, or accepted in accordance with an approved software QA plan.

The manufacturer produced the ALS v2 platform components as an Appendix B supplier and will continue to produce ALS v2-based systems using the WEC Quality Management System (QMS).

The ALS v2 QAP, which is provided in Section 7 of the ALS v2 Development Process topical report, defines the techniques, procedures, and methods used to assure quality in the design and test activities of the ALS v2 platform and applications. In accordance with WECs QMS, the QAP establishes the QA team as independent from the development organization in terms of financial and schedule performance and identifies its role throughout the ALS v2 platform lifecycle. The ALS v2 QAP also identifies the manufacturers anomaly reporting and corrective action processes, as applied throughout the ALS v2 platform lifecycle (see Sections 7.9, 7.6.4, and 9.11.3 of Reference 8). The anomaly reporting and corrective action processes are further detailed within the ALS v2 V&V Plan (see Reference 21, Section 6.1).

QA tasks to audit software safety plan implementation and to perform process certification are listed in Table 8.3-1, Software Safety Task Assignments, of the ALS v2 development process topical report. These QA tasks are described in Section 7 of the ALS v2 Development Process Topical Report for each software life cycle phase. These descriptions include a discussion of the tasks and the responsibilities of the organizations performing software QA activities. In addition, Table A-1, FPGA/Software Tasks and Responsibilities, of the ALS v2 V&V Plan identifies organizational responsibilities for the performance of specific software SQA tasks.

Documentation requirements for the performance of QA activities are described in Section 7.5, Documentation, of the ALS v2 Development Process Topical Report.

Section 7.7 of the ALS v2 Development Process Topical Report describes reviews and audits that are performed for ALS v2 applications. Reviews are performed to verify technical adequacy and to verify the completeness of the design and development at various stages of the development life cycle. The ALS v2 development process topical report lists several review activities and defines groups responsible for the performance of these activities. The NRC staff determined that this defined a minimum set of review and audit requirements that are consistent with the criteria of IEEE Std 1028-2008, IEEE Standard for Software Reviews and Audits, which is endorsed by RG 1.168, Revision 2.

In summary, the ALS v2 QAP describes the process by which WEC manages FPGA logic and software as well as the documentation throughout the ALS v2 FPGA development life cycle. A Project Manager is responsible for ensuring that all design team activities are performed in accordance with the QA processes and procedures. The ALS v2 QAP adequately addresses the quality planning activities of BTP 7-14. The NRC staff concludes that the ALS v2 QAP meets the guidance of BTP 7-14, Section B.3.1.3 and is, therefore, acceptable.

3.2.3.3 Software Safety Plan BTP 7-14, Section B.3.1.9 provides guidance to evaluate software safety plans (SSP). The SSP should require that appropriate safety requirements be included in the software requirements specification. The SSP should define the safety-related activities to be carried out for each set of

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION life cycle activities, from requirements through operation and maintenance. The SSP should describe the boundaries and interfaces between the software safety organization and others. It should show how the software safety activities are coordinated with the development activities and the interactions between software safety organization and the software V&V organization.

The SSP should designate a single safety officer who has a clear responsibility for the safety qualities and has a clear authority to accomplish the goals of the safety requirements in the Software Requirements Specifications design and implementation of the software.

The SSP for the ALS v2 FPGA logic is in Section 8, Software Safety Plan, of the ALS v2 Development Process Topical Report. The stated purpose of this safety plan is to enable the development of safety critical software for ALS v2 projects that has reasonable assurance that software defects do not present severe consequences to public health and safety.

To accomplish this goal, the safety plan defines procedures and methods to be used for the development, procurement, maintenance, and, ultimately, retirement of all Protection class ALS v2 FPGA logic and software. The other classes of ALS v2 software and logic, Important to Safety, Important to Availability, and General Purpose, are not included in the SSP because they are not considered to be safety critical. This is because the failure of this software would not result in severe consequences to public health and safety.

Software Safety Organization Section 2 of the ALS v2 Development Process Topical Report defines the organization that is responsible for the design and implementation of the ALS v2 protection logic and software. This organization includes a quality organization, which is an independent QA department. This quality organization participates in project meetings, design reviews and performs surveillances, and audits of various development activities and periodically reports on the results of these tasks. The safety organization also includes an IV&V team, which performs product software V&V activities for ALS v2 safety-related products. The V&V team, referred to as the VT in Reference 21, is organizationally independent from the ALS v2 design team. The manufacturer will use a plant specific project quality plan to coordinate both the system development, software safety, and QA activities to identify the prescribed procedures and provide the resources needed for their execution.

During the requirements phase of the ALS v2 development life cycle process, an evaluation is performed to identify the safety critical hazards posed by the system through its interfaces. For each hazard identified, the analysis determines whether a software or FPGA logic malfunction could produce the hazardous condition. Each identified hazard is then subsequently evaluated during each development phase to determine if new hazards have been introduced during that phase, or if the evolving design has altered the results of the hazards analysis. The results of IV&V analyses performed on requirements, design, logic, test, and other technical documentation are documented in the IV&V Phase Summary Reports and in a Final IV&V Report for the system.

The safety requirements that need to be met by the ALS v2 software or logic, in order to mitigate or control system hazards, are defined in the system requirements specifications. The FPGA design description will include descriptions of the design elements that satisfy the software safety requirements.

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION The safety organization defined in the ALS v2 Development Process Topical Report considers the security risk as well as the risk to the plant if the digital system malfunctions. The critical design reviews are discussed in Section 7.7.4 of Reference 8, and identify the risks associated with the system design in a manner that is consistent with the software safety strategy.

The NRC staff reviewed the ALS v2 safety plan and finds that it addresses the topics described in the SRP and BTP 7-14, which specifies IEEE Std 1228-1994 (Reaffirmed in 2010), IEEE Standard for Software Safety Plans. The ALS v2 safety plan describes the organizational structure and responsibilities, resources, methods of accomplishment, and integration of the system safety with other program engineering and management activities. The hazards evaluations required by the safety plan will be documented in the V&V documentation. The ALS v2 safety plan identifies the international, national, industry, and company standards and guidelines to be followed by the safety organization. The NRC staff determined that the software safety activities defined in the ALS v2 safety plan will adequately identify and resolve safety issues associated with the ALS system software or FPGA logic. The NRC staff concludes that the ALS v2 safety plan adequately addresses the topics outlined in the SRP and is, therefore, acceptable.

3.2.3.4 Test Plan The acceptance criterion for software test plans is in the SRP, BTP 7-14, Section B.3.1.12, Software Test Plan, and in Section B.3.2.4, Acceptance Criteria for Testing Activities. These sections state that both RG 1.170, which endorses IEEE Std 829, IEEE Standard for Software Test Documentation, and RG 1.171, which endorses IEEE Std 1008, IEEE Standard for Software Unit Testing, identify acceptable methods to satisfy software unit testing requirements.

The test plan used for the ALS v2 system software and the FPGA logic is in Section 9 of the ALS v2 development process topical report. This plan identifies the testing activities and test documentation required to verify and validate the ALS v2 safety system software and the FPGA logic. The scope of the test plan includes testing of the ALS v2 platform component and application software and logic. The ALS v2 test plan describes and defines the test activities for the following test types:

ALS v2 Simulation Tests (9.5.1)

Integration Tests (9.5.2)

Comprehensiveness / Coverage Tests (9.5.4)

Application Integration Tests (9.6.1) o System Validation Tests (9.6.1.4) o Factory Acceptance Tests (9.6.1.5)

Site Acceptance Tests (9.6.2)

Reusable Logic Element Tests (9.7)

Regression Tests (9.10)

Test documentation is developed for ALS v2 FPGA programs that includes information on test plans, test environments and design specifications, test case specifications, test procedures, and documented test results, all of which the manufacturer maintains under CM. These documents include applicable acceptance criteria for the reviews and tests along with an evaluation of conformance with established acceptance criteria.

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION Risks associated with testing activities are addressed through regression analysis. A regression analysis is performed to determine the extent of retesting activities that may be necessary to re-verify and/or re-validate changes to a tested element. The results of this analysis are intended to identify latent design errors or programming bugs that have been introduced by software design modifications.

Site acceptance testing and installation testing are not covered under the ALS v2 test plan because they are considered to be licensee actions and are to be addressed during the development of an ALS v2 based application. As such, a project specific test plan should be developed and used to address these aspects of software test planning for an application-specific system. This action will be addressed via a PSAI.

The ALS v2 test plan is understandable, and it includes adequate provisions for retest in the event of failure of the original test. The ALS v2 test plan adequately addresses the test planning guidance of BTP 7-14, Section B.3.1.12, and based on WECs commitment to conformance with IEEE Std 829-1998, the NRC staff finds the ALS v2 test plan to be acceptable.

3.2.3.5 Installation Plan The acceptance criteria for a Software Installation Plan are in BTP 7-14, Section B.3.1.5. IEEE Std 1074-2006, Clause A.1.2.4, Plan Installation, endorsed by RG 1.173, provides an acceptable approach for software installation plans. The software installation plan includes the necessary software modifications, checkout in the target environment, and customer acceptance. If a problem arises, it must be identified and reported. BTP 7-14, Section B.3.1.5.4 states that there should be approved procedures for software installation, for combined hardware and software installation, and systems installation. There should also be a controlled process to identify, correct, and document errors in the installation procedures.

The Installation Plan for the ALS v2 system software and the FPGA logic is in Section 10 of the ALS v2 development process topical report. Its purpose is to define how to program and configure an ALS v2 PCB assembly with an FPGA binary image and an NVM memory image.

The NRC staff reviewed the ALS v2 installation plan and found that it included an adequate description of the FPGA installation process. The procedure(s) for installing the FPGA logic will be prepared before the installation and checkout phase of the ALS v2 development life cycle.

The NRC staff finds that the plans for the software installation exhibit the management, implementation, and resource characteristics outlined in BTP 7-14 and are, therefore, acceptable. However, the ALS v2 installation plan does not address the installation of the ALS v2 based system into the plant environment. Since the applicant or licensee assumes responsibility, including vendor oversight, for the plant installation phase information necessary to address the criteria of BTP 7-14, further evaluation of the site installation activities will be required and will be treated as a PSAI.

3.2.3.6 Integration Plan BTP 7-14, Section B.3.1.4, provides guidance in evaluating a Software Integration Plan (SintP).

IEEE Std 1074-2006, Clause A.1.2.8, Plan Integration, which is endorsed by RG 1.173, provides an acceptable approach to an integration plan. Clause A.1.2.8.2 states that during the

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION plan integration activity, the software requirements and the software design description are analyzed to determine the order of combining software components into an overall system. In addition, Clause A.1.2.8.2 states that the integration planned information shall be coordinated with the evaluation planned information. BTP 7-14, Section B.3.1.4.1 guidance calls for a general description of the software integration process and of the software integration organization.

The ALS v2 Integration plan is provided in Section 11 of the ALS v2 development process topical report. It also refers to activities that are performed in conjunction with the software installation and the test plans, which are evaluated in Sections 3.2.3.5 and 3.2.3.4 of this SE, respectively. This scope of the ALS v2 integration plan is to address the integration of the software (FPGA) and the hardware in three phases as follows:

1. Integration of various software modules into a single FPGA design.

2. Integration of FPGA images into hardware by programming the FPGA.

3. Testing of the integrated product as defined by the ALS v2 test plan.

WEC does not define a separate software integration organization to perform system ALS v2 platform integration related activities. Instead, integration activities are allocated to different organizations involved with the ALS v2 software and FPGA logic development processes. This allocation of integration activities is defined within various sections within the ALS v2 development process topical report. For example, Integration Tests are defined in Section 9.5.2 of the Development Process Topical Report (Reference 8) and Table A-1 of the ALS v2 V&V plan (Reference 21) and shows that the IV&V Team has the responsibility for performing integration tests for Protection Class software or logic. Conversely, the design team has the responsibility for performing integration tests for Important to Availability software or logic.

The testing aspects of ALS v2 Integration are described in Section 9, Test Plan, of the ALS v2 Development Process Topical Report. The ALS v2 software and FPGA logic testing process includes integration tests that include ALS v2 board-level hardware testing.

The NRC staff reviewed the ALS v2 development and testing processes used for both platform and application FPGA logic and found that they specify how to develop plans for integration both during the development of the FPGA logic and during integration with the FPGA hardware.

The NRC staff concludes that the plans for integration exhibit the management, implementation, and resource characteristics outlined in BTP 7-14 and are, therefore, acceptable.

3.2.3.7 Maintenance Plan The acceptance criteria for a Software Maintenance Plan are contained in BTP 7-14, Section B.3.1.6. IEEE Std 7-4.3.2-2003, Clause 5.4.2.3, endorsed by RG 1.152, provides guidance on the maintenance and CM for commercially dedicated items. IEEE Std 1074-2006, Clause A.4.2.3, Maintenance Activity Group, provides an approach for software maintenance plans. IEEE Std 1074-2006, Clause 6.3.1 states that the Maintenance Activity Group is concerned with the identification of enhancements and the resolution of software errors, faults, and failures. NUREG/CR-6101, Section 3.1.9 and Section 4.1.9 also contain guidance on Software Maintenance Plans. These sections identify the maintenance activities to be governed by the Software Maintenance Plan as failure reporting, fault correction, and re-release procedures.

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION The Maintenance Plan for the ALS v2 system is in Section 12 of the ALS v2 development process topical report. This plan specifies the requirements for the maintenance and use of Protection class and Important-to-Safety class software used in ALS v2 platform-based Systems. Activities associated with the ALS v2 maintenance phase include:

1. Failure Detection

2. Failure Reporting

3. Failure Tracking

4. Fault Correction The NRC staff reviewed the plan for maintenance of the ALS v2 FPGA logic as described in the ALS v2 Development Process Topical Report and concludes that it exhibits the characteristics for management, implementation, and resources as set forth in BTP 7-14 and is, therefore, acceptable.

3.2.3.8 Configuration Management Plan BTP 7-14, Section B.3.1.11 provides guidance for the evaluation of the Software CM Plan, and states that IEEE Std 1074-2006, Clause A.1.2.2, Plan Configuration Management, provides an acceptable approach to software CM. IEEE Std 1074-2006, Clause A.1.2.2.2 states that software CM includes the evaluation, coordination, approval or disapproval, and implementation of changes to product components (e.g., code, documentation) after a baseline has been established. Items that are to be managed should include code, documentation, plans, specifications, project policies, procedures, and other artifacts. RG 1.169 endorses IEEE Std 828-2005, Standard for Software Configuration Management Plans, as it provides an approach that the NRC staff considers to be acceptable for satisfying the agencys regulatory requirements with respect to CM plans for the safety system software, with the exceptions and additions listed in the regulatory positions of the RG. BTP 7 14, Section B.3.1.11.1 calls for the definition of the responsibilities, security, and authority of the Software CM organization.

The manufacturer established a CM plan as part of its quality plan for use throughout the original ALS platform life cycle (see Reference 5, Section 12.2.10). The ALS CM plan was evaluated as part of the original platform review and a revised version of this original CM plan is used for the ALS v2 platform (see Reference 25). The ALS, and now the ALS v2, CM Plan identifies items subject to CM activities, defines project milestones related to these activities, and explains the manufacturers application of a CM tool, as applied throughout the ALS v2 platform life cycle. These CM activities include provisions to track the resolution of reported anomalies to the item or items that implement a corrective action.

The NRC staff performed an audit review of the revised ALS CM plan and confirmed that it describes the process for configuration control including configuration identification, change request, change authorization, module and unit release history, baselines, and backups. The revised ALS CM plan also describes the CM activities related to the project baselines, the configuration change control authority and management, methods of access control, and the configuration status control log maintenance. A project-specific CM Plan that describes the management of CM data that reflect the specific methods of managing configurations will be expected to be developed as part of the project plan required for each ALS project. The ALS

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION CM Plan identifies the international, national, industry, and company standards and guidelines to be followed for the CM activity.

The NRC staff concludes the ALS CM plan continues to conform to IEEE Std 828-2005, as endorsed by RG 1.169, and IEEE Std 1074-2006, as endorsed by RG 1.173. This meets the criteria of BTP 7-14 and is, therefore, acceptable.

3.2.3.9 Security Plan RG 1.152, Revision 3, describes a method that the NRC staff considers to be acceptable to comply with the regulatory criteria to promote high functional reliability, design quality, and to establish secure development and operational environments for the use of digital computers in safety-related systems at nuclear power plants. The guidance for secure development and operational environments states that potential vulnerabilities should be addressed in each phase of the digital safety system life cycle. The overall guidance provides the basis for physical and logical access controls to be established throughout the digital system development process to address the susceptibility of a digital safety system to inadvertent access and modification.

The following is an evaluation of the ALS v2 secure development and operational environments, which the manufacturer has characterized as meeting the intent of RG 1.152, Revision 3 (see Reference 5, Section 8.2). This SE takes several factors into consideration.

First, RG 1.152 provides guidance to licensees for license amendment requests, design certifications, and combined operating licenses relating to the development of a plant-specific system. In contrast, the ALS v2 platform topical report scope does not provide a plant-specific system and its manufacturer is neither a licensee nor an applicant for a license.

Second, RG 1.152 directs much of its guidance toward traditional microprocessor-based systems with separately developed and installed operational software, where some software may be modified and maintained by nuclear plant personnel over the equipments life cycle. In contrast, the ALS v2 platform neither includes microprocessors nor separately developed and installed operational software, and the manufacturer has proposed to be the sole maintainer of its FPGA logic programming.

Third, RG 1.152 provides guidance that the safety system design features intended to ensure reliable operation should be validated as part of the overall system requirements. RG 1.152 provides further guidance that the safety system design features maintaining a secure operational environment should be addressed by the execution of system integration testing, system qualification testing, and system factory acceptance testing. This testing includes all connectivity to other systems, including external systems. In contrast, the platforms development and test scope is limited to the life cycle phases for the ALS v2 standardized circuit boards. Therefore, RG 1.152s system validation and testing scope is beyond the scope of this SE.

The ALS v2 Security Plan (Reference 26) contains an Annex which identifies platform potential security concerns and vulnerabilities within the development environment and presents an assessment of these vulnerabilities. In addition, the security plan states that the assessment of the development test environment shall be performed every three years, and when changes that

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION impact the security posture of the environment are implemented. Methods to address the vulnerabilities are defined in the ALS v2 Platform requirements documents.

The security assessments describe the basis for design features to ensure the reliable operation of the system. The ALS v2 Security Plan describes design features that can be used to address the potential for the installed operating environment to adversely influence system reliability (see Reference 26, Appendix A, Section A.2).

The ALS v2 Security Plan also identifies potential security concerns and vulnerabilities applicable to the conceptual, requirements, design, implementation, and testing life-cycle phases. The ALS v2 Security Plan provides the measures to mitigate these vulnerabilities and to prevent the introduction of undocumented or unwanted codes. Mitigation approaches address potential vulnerabilities to both internal and external threats that could challenge the confidentiality or integrity of the design. Mitigation approaches also address potential vulnerabilities to both accidental and malicious threats that could otherwise challenge the confidentiality or integrity of the design. The ALS v2 Security Plan addresses both physical and logical security control of the development environment and design products (see Reference 26, Appendix A, Section A.3).

The ALS topical report, as amended by Reference 1, addresses RG 1.152, Revision 3, and provides a description of the secure development activities performed for the development of the ALS v2 platform. The manufacturers secure development environment process addresses the V&V activities to detect and prevent the use of unintended code, and the control and monitoring of access to the development environment (see Reference 5, Section 12.6). These measures, along with the design review and CM activities detailed in other ALS v2 procedures and plans, provide protection against the introduction of unintended functionality into the ALS platform-based system.

The ALS v2 development process includes design review activities to verify the incorporation of all specified functionality. These design reviews will provide a means of identifying the inclusion of unspecified functionality. The ALS v2 Platform development processes also include V&V activities that are performed to prevent the incorporation of unintended code. Per Reference 5, the V&V team performs a combination of traceability, functional testing, code coverage analysis, code reviews, and synthesis reviews to verify that no unintended functionality exists within the design. As no modifications to this portion of the manufacturers V&V Program have been identified in the ALS v2 submittal, the NRC staff understands that the V&V team continues to perform these activities.

The original ALS topical report, as amended by Reference 1, and the ALS v2 Security Plan (Reference 26) address access control of the ALS v2 development environment and lifecycle security. These documents discuss the secure development environment activities performed during the Planning, Development, Manufacturing, and System Test life-cycle phases of a project. FPGA programs and other related configuration controlled FPGA design artifacts, including NVM configuration files, are developed, controlled, and maintained within the secure development environment which is also referred to as Secure Development Infrastructure (SDI) within the security plan. The manufacturer implements monitoring and tracking of activities performed within the SDI.

The ALS v2 Security Plan states the following:

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION Application-specific system design and test files may be developed outside of the SDI, but associated FPGA and related design files, and NVM files, are developed and controlled using the SDI.

This SE is based on the continued applicability of the ALS v2 Security Plan or an equivalent.

Therefore, applicants and licensees referencing this SE should ensure the secure development environment for future efforts, including plant-specific application development, continues to meet the regulatory evaluation criteria of RG 1.152 (see Section 4.2, Item 17).

Without a specific operational environment to assess, the NRC staff cannot reach a determination on a plant-specific ALS v2-based systems ability to withstand undesirable behavior of the connected systems and preclude inadvertent access. However, the ALS v2 platform does include design attributes and features that a licensee can apply and credit to demonstrate protection against undesirable behavior of the connected systems and the prevention of inadvertent access (see Section 3.7.2 and Section 4.2, Items 12, 13, and 14). The determination on protection against undesirable behavior from the connected systems and inadvertent access in the operational environment is a PSAI (see Section 4.2, Item 18).

Based on the NRC staffs review of the information provided by the manufacturer, the NRC staff determined that the manufacturer established a secure development environment for the ALS v2 platform that is consistent with the regulatory positions found in RG 1.152, Revision 3.

Therefore, the NRC staff concludes that the ALS v2 platform has been designed with provisions for physical and logical access controls to ensure high functional reliability and to provide mitigation against the introduction of undocumented or unwanted codes. The NRC staff also identified two PSAIs (see Section 4.2, Items 17 and 18), which are necessary to demonstrate that the RG 1.152 regulatory evaluation criteria are met for application developments and operations. The NRC staff further determined that the ALS v2 platform contains design attributes and features that licensees can apply and credit to demonstrate protection against undesirable behavior of the connected systems and the prevention of inadvertent access when addressing the operational environment.

3.2.3.10 Verification and Validation Plan The manufacturer performs independent verification, validation, review, and audit activities throughout the development of the ALS v2 platform components including the development of the FPGA logic programs for the platform. The original ALS topical report, as amended by Reference 1, describes different aspects of the V&V Plan for the ALS v2 platform. The manufacturer defined its organization and approach to provide IV&V in the ALS v2 V&V Plan (Reference 21). Within this plan the manufacturer identifies and clarifies life-cycle activities applicable to both the ALS v2 platform standardized circuit boards and the ALS v2-based systems and identifies required content for the ALS v2-based systems (see Reference 21). The activities defined in the V&V plan include the establishment of requirements, specification reviews, and the generation of RTMs. These activities provide assurance that the lower-level specifications meet parent requirements and verify that the requirements and specifications have been implemented, as specified.

The manufacturers approach to the FPGA logic program V&V continues to include incremental releases of FPGA circuit module designs and evaluations of candidate releases before they are

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION formally released. This approach ensures that subsequent releases are subjected to regression testing, which will include any previous incremental releases in addition to the most recent modifications, when necessary. The manufacturer reviews tool outputs associated with the generation of the FPGA logic programs including synthesis, place and route, and simulation results as part of its IV&V activities. The IV&V activities also include RTL simulations of the FPGA logic and post-simulation coverage analyses.

As no modifications were described in the manufacturers ALS v2 submittal (Reference 1), the NRC staff understands that the manufacturer continues to use a constrained-random test generation approach that targets the function of the device as defined by its requirements and specifications to perform black box tests on the FPGA logic programs. Additionally, the NRC staff understands that the manufacturer continues to perform coverage analysis to ensure that each FPGA HDL statement can be tested during RTL simulations and has been successfully exercised and performs as expected. Should additional constrained-random tests fail to exercise HDL statements, the manufacturer applies a white box test approach to identify additional constraints. Regardless, the manufacturer may reach a final determination that a specific HDL statement cannot be reached through simulation. In these limited cases, the manufacturer performs a manual inspection and authors a formal justification that explains why coverage of a particular HDL statement during simulation is not feasible.

The manufacturer summarizes the results of its IV&V activities within platform and individual board specific V&V Summary Reports. These documents record the percentage of the statement coverage achieved and identify when the manual evaluation and justification are considered to provide coverage in addition to the RTL simulations. In addition to the RTL simulation, the manufacturers IV&V personnel review the gate level simulations, which are performed by the design team. Finally, the released FPGA logic program is installed on its standardized circuit card and subjected to automatic and manual testing.

During a regulatory audit, the NRC staff reviewed the manufacturers lower-level planning documents that govern the ALS v2 platform FPGA logic development activities that support the documentation provided by the manufacturer in its docketed submittal. The following plans were included in this review:

1. ALS v2 Project Management Plan

2. ALS v2 Quality Management Plan

3. ALS v2 Platform Software V&V Plan

4. ALS v2 Test Plan

5. WEC Quality Management System (QMS)

6. ALS Configuration Management Plan (per WCAP-18780, using the original ALS CM Plan, 6002-00002)

7. ALS v2 V&V Plan

8. ALS v2 Platform FPGA V&V Test Plan During the development of the original SE, the NRC staff also audited the manufacturers CM and anomaly reporting and tracking processes. In the current review, the manufacturer continues to use the ALS CM Plan (Reference 25) to maintain and review its CM Program; therefore, the NRC staff did not conduct a new evaluation of the ALS CM plan and it continues to be acceptable. Based on the NRC staffs reviews of the ALS v2 platform plans, specifications,

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION IEEE Std 323-2003, IEEE Standard for Qualifying Class 1E Equipment for Nuclear Power Generating Stations.

To comply with the requirements of GDC 4, 10 CFR 50.49, Environmental Qualification of Electric Equipment Important to Safety for Nuclear Power Plants, and IEEE Std 603-1991, each applicant or licensee should establish an environmental qualification program that demonstrates that safety-related equipment will remain functional during and following design basis events.

Environmental qualifications are necessary to ensure that the I&C systems meet design-basis and performance requirements when the equipment is exposed to the normal and adverse environments associated with its installed location.

For the uses of the ALS v2 platform, the normal and adverse environments should at no time be significantly more severe than the environment that would occur during normal plant operation, including anticipated operational occurrences. This eliminates the consideration of more severe conditions that apply to equipment in environments that are materially affected by design basis events. To demonstrate compliance with the requirements of GDC 4, 10 CFR 50.49, and IEEE Std 603-1991, an applicant or licensee using the ALS v2 platform should demonstrate that the EQs performed on the ALS v2 platform envelope its plant-specific application as installed in its mild environment. This necessitates a PSAI to confirm the adequacy of the ALS v2 platforms qualification in full consideration of the plant-specific ALS v2-based I&C system and its installation.

If equipment interface/boundary conditions or installation limitations are identified during EQ testing, these conditions should be reported in the Platform EQ Summary Report. Additionally, the manufacturer may identify generic restrictions applicable to the ALS v2 projects within its ALS v2 Application Guidance and provide means for the projects to specify the implementation of applicable restrictions. The manufacturer identifies restrictions to address the requirements that have not been met and the known issues with certain ALS v2 platform configurations that have been identified during the ALS v2 product qualification activities. Furthermore, a formal review of the restrictions and identification and justification for any deviation from conforming to these restrictions should be provided for each ALS v2 project.

For clarity and to ensure full coverage, the NRC staff created two PSAIs to address the platform boundary or interface conditions and installation limitations identified in the ALS v2 Platform EQ Summary Report and the platform application restrictions in the ALS v2 Application Guidance (see Section 4.2, Items 4 and 5, respectively).

Section 4, Equipment Qualification, of the original ALS topical report, as amended by Reference 1, summarizes the manufacturers EQ processes for temperature/humidity, seismic, and electromagnetic compatibility for the ALS v2 platform.

The ALS v2 EQ Plan (Reference 10) defines the EQ standards, methodologies, and tests to be applied to the ALS v2 platform. The manufacturer has indicted that each applicant or licensee will reference the ALS v2 EQ Plan for each application specific safety-related system built from ALS v2 platform components.

ALS v2 platform components are to be tested in accordance with the EQ Plan. The results of these tests will be documented in EQ summary reports which will provide further details of the EQ tests, the results, and manufacturer conclusions derived from EQ type testing.

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION An ALS v2 Platform Qualification Evaluation will also be performed to provide the manufacturer analyses to support the extension or exclusion of platform capabilities. These analyses are intended to address the number and nature of signals used during EQ. They will also address the limited configuration of the standardized circuit boards for processing these signals. These analyses will need to be performed, because the Equipment Under Test (EUT) for the type tests will neither exercise and load the full complement of available signals nor include all unique configurations of signals that each standardized circuit board supports. In consideration of the limited EUT configuration, the ALS v2 Platform Qualification Evaluation will provide manufacturer analyses of the platform capabilities considered to be qualified through the efforts that will be summarized in the ALS v2 Platform EQ Summary Report and other board-specific testing (i.e., the ABTS Test Summary Reports).

An ALS v2 EQ Rack System Specification is the manufacturers specification for the EUT to be used in the EQ type tests. Additionally, the ALS v2 FPGA Qualification Evaluation will be used to provide manufacturer analyses of differences between FPGA programs used within the EUT and the final production versions of the FPGAs, because EUT will use only one FPGA program design variant of an earlier version than the final production versions.

This SE does not include plant-specific determinations for a specific application or installation.

The NRC staff was also unable to evaluate the EQ type testing for the seven ALS v2 platform standardized circuit boards, representative backplane, or chassis, against applicable EQ regulations, standards, and guidance because these tests were not completed at the time of this SE. Additionally, this SE includes a PSAI for applicants and licensees referencing this SE to demonstrate the adequacy of the ALS v2 platforms qualification in consideration of the applicants or licensees environmental qualification program, ALS v2-based I&C system, and installed operational environment (see Section 4.2, Item 6). This PSAI is consistent with GDC 4, 10 CFR 50.49, and IEEE Std 603-1991.

The next subsection provides an overview of the planned type testing and the test configurations to be used during ALS v2 platform EQ testing. It also provides the NRC staffs evaluations generally applicable to the manufacturers EQ activities.

3.3.1 Test Overview and Type Test Configuration The ALS v2 EQ Plan (Reference 10) requires each EQ test procedure to provide a detailed description of the test to be performed and to document the specific test setup and acceptance/performance criteria to be applied during the test. The ALS v2 EQ Plan also requires that the test procedures provide a description of the safety functions of the EUT and the measurements and methods to demonstrate that the safety functions are not affected by the test.

The manufacturer will develop test procedures to address the ALS v2 platform EQ. An ALS v2 Platform Configuration Status Accounting document is used to identify these test procedures by name and revision.

The baseline test procedure will support the individual EQ test procedures. In part, performing the baseline test procedure will demonstrate the continued operability of the identified EUT

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION safety functions. The ALS v2 Platform EQ Summary Report will provide a detailed summary of the individual qualification tests along with the acceptance and performance criteria.

To demonstrate that the identified safety functions remain operable during testing, the manufacturer requires that the ALS v2 platform meets the safety function acceptance criteria and performance criteria outlined in the ALS v2 Equipment Qualification Plan (see Reference 10). The performance criteria are applied before, during, and after the performance of an environmental test cycle, each step within the seismic test sequence, or applicable electromagnetic compatibility (EMC) tests. The manufacturer established the performance criteria to be no operational degradation, loss of function, or structural damage to EUT for each of its EQ tests except in some cases when performing the tests is not identified by the NRCs regulations, is considered optional to obtain a Conformite Europeene (CE) Mark certification, or where the testing standard allows the relaxation of the performance criteria. The NRC staff did not evaluate any optional CE Mark-related tests. However, it notes that the additional tests provide some degree of additional assurance.

The ALS v2 EQ Plan, Section 7, EQ Documentation and Reporting, identifies an individual test report for each test procedure. The manufacturers ALS v2 Platform Configuration Status Accounting identifies test reports that correspond to the test procedures for EQ: (1) the ALS v2 Environmental Qualification Report, (2) the ALS v2 Seismic Qualification Report, and (3) the ALS v2 Electromagnetic Compatibility Qualification Report. "The manufacturer did not submit individual qualification reports for the NRC staffs review. However, qualification reports will be produced to summarize the results of testing activities.

The NRC staff reviewed the ALS v2 EQ Plan and determined that the manufacturers EQ plans conform to RG 1.209 because the ALS v2 platform manufacturer will perform type testing on the seven standardized circuit boards, a backplane, and a chassis using a set of FPGA programs, representative of production FPGA programs. The NRC staff further determined that the manufacturers EQ documentation will be performed in a manner that supports evaluations by the applicants and licensees to demonstrate that plant-specific safety equipments safety functions will remain functional during and following its design basis events. However, the NRC staffs SE does not eliminate the need to perform application-specific system and installation testing (see Section 4.2, Item 23). Furthermore, the NRC staffs SE does not preclude an applicant or licensee from performing supplemental EQ on its plant-specific system application (see Section 4.2, Item 6).

3.3.2 Environmental Testing RG 1.209 endorses and provides guidance for compliance with IEEE Std 323-2003. RG 1.209 describes a method acceptable to the NRC staff for meeting the environmental qualification of safety-related computer-based I&C systems for service in mild environments at nuclear power plants.

The manufacturer committed to perform its environmental qualification in accordance with IEEE Std 323-1974, as endorsed by RG 1.89, Environmental Qualification of Certain Electric Equipment Important to Safety for Nuclear Power Plants, and IEEE Std 323-2003, as endorsed by RG 1.209 (see Reference 10, Section 3). Section 3 of the ALS v2 EQ Plan (Reference 10)

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION defines the environmental qualification approach to be used for the ALS v2 platform components. When EQ testing is completed, an ALS v2 Platform EQ Summary Report will provide a detailed summary of the environmental qualification testing and results.

The EQ testing will include baseline verification tests and performance monitoring during synergistic environmental conditions that establish maximum and minimum specified temperatures, humidity, and direct current input voltage levels. The ALS v2 Platform EQ Summary Report will establish that the environmental qualification performed on the ALS v2 platform equipment meets the technical requirements of IEEE Std 323-1974, as endorsed by RG 1.89, and IEEE Std 323-2003, as endorsed by RG 1.209.

The NRC staff reviewed the ALS Topical Report, as amended by Reference 1, and the ALS v2 EQ Plan (Reference 10) and determined that the manufacturers environmental qualification will conform to the RG 1.209, Regulatory Position 1, inclusion of potential synergistic effects, because the ALS v2 EQ plan specifies an environmental envelope consistent with a typical mild environment that includes potential synergistic effects between temperature, humidity, and input voltage on the ALS equipment to be tested (Reference 10, Table 3-2 and Figure 3-1). The NRC staff also determined that the manufacturers environmental qualification plan conforms to RG 1.209, Regulatory Position 2, because the qualification testing will be conducted on functioning equipment with FPGA programming and diagnostics that are representative of those intended to be used in the operation of an ALS v2-based system while subjecting the EUT to the manufacturers specified environmental envelope. Furthermore, this testing will exercise the portions of the equipment that the manufacturer identifies as necessary to accomplish safety functions or whose failure could impair a safety function within a configuration that the manufacturer justified as most susceptible to environmental effects and therefore most likely to reveal unacceptable performance. The NRC staff further determined that the manufacturers environmental qualification plan conforms to RG 1.209, Regulatory Position 4, because the environmental conditions are based on the manufacturers prior analyses of licensee mild environments and the manufacturer will retain evidence of its mild environment qualification by placing its environmental qualification plans, procedures, and reports under configuration control.

The applicants and licensees referencing this SE should ensure the maximum temperature within an ALS v2 cabinet does not exceed either the manufacturer specified or qualified design temperatures. The applicants and licensees referencing this SE should demonstrate that the maximum temperature rise within each cabinet containing ALS v2 components does not exceed the platform specification. The applicants and licensees referencing this SE should also demonstrate that the maximum ambient temperature at each ALS v2 platform installation location will not exceed the maximum qualified temperature during normal plant operation, including anticipated operational occurrences. Licensees should evaluate the adequacy of the design basis temperature margin in full consideration of the actual temperature rise within its plant-specific cabinet and the maximum ambient temperature at the installed cabinets location during normal plant operation, including anticipated operational occurrences (see Section 4.2, Item 6).

3.3.3 Seismic Testing RG 1.100, Revision 4, describes a method that is acceptable to the NRC staff for meeting seismic qualification. RG 1.100 endorses, with exceptions and clarifications, IEEE Std 344-

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION 2013, IEEE Std C37.98-2013, and ASME QME-1-2017. IEEE Std 344 is the IEEE Recommended Practice for Seismic Qualification of Class 1E Equipment for Nuclear Power Generating Stations.

The manufacturer committed to perform its seismic qualification in accordance with the technical requirements of IEEE Std 344-2013, as endorsed by RG 1.100, Revision 4 (Reference 10, Section 5). Section 5 of the ALS v2 EQ Plan (Reference 10) defines the seismic qualification approach being used. When EQ testing is completed, an ALS v2 Platform EQ Summary Report will provide a detailed summary of the seismic qualification testing and results.

The NRC staff reviewed the ALS Topical Report, as amended by Reference 27, and the ALS v2 EQ Plan (Reference 10) and determined that the manufacturers seismic qualification plans are consistent with the RG 1.100 endorsement of IEEE Std 344. Seismic tests conducted in accordance with this plan will establish and document a Safe Shutdown Earthquake (SSE)

Required Response Spectra (RRS) for use by applicants and licensees referencing this SE and the manufacturers seismic testing program. The seismic testing program will:

provide confirmation that seismic qualification activities include a resonance search on the EUT, ensure that the equipment will be subjected to five Operating Basis Earthquakes and one SSE based on the established SSE RRS, and verify that the type tested equipment maintains its physical integrity and capability to perform any identified system safety functions.

3.3.4 Electromagnetic Compatibility Testing RG 1.180, Revision 2, describes a method that is acceptable to the NRC staff for the design, installation, and testing practices to address the effects of EMI/RFI and power surges on safety-related I&C systems.

RG 1.180, Revision 2, endorses the MIL-STD-461G and IEC 61000 series of tests to evaluate conducted and radiated EMI/RFI and power surges on safety-related I&C systems. Figure 3.5, Acceptable Alternatives for EMI/RFI Emissions Testing, of RG 1.180 shows the acceptable emissions testing programs and indicates the conditions under which the alternative test suites can be applied.

For the ALS v2 platform, the chosen standards for conducting EMI/RFI testing are as follows:

Emissions: The MIL-STD test set of endorsed standards was chosen for emissions because of the lack of coverage that the IEC emissions tests provide. Additionally, EN 55011 was added to the MIL STD emissions test suite to satisfy the CE Mark.

Susceptibility/Immunity: The IEC test suite was chosen to maximize the overlap between the CE Mark tests and the NRC-required tests. Many of the tests have different test frequencies or limits when comparing the CE Mark requirements with the RG. The resulting test levels were chosen to envelope both the test frequencies and limits. The MIL-STD-461E: RS103 test was included to cover the 1-10 GHz frequency range that was not addressed by the IEC standards.

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION Surge, Electrical Fast Transient (EFT), and Electrostatic Discharge (ESD): The IEC test suite was chosen for Surge, EFT, and ESD testing activities.

The ALS v2 EQ Plan (Reference 10) outlines the processes for developing configuration controlled test specifications, plans, and procedures with acceptance and performance criteria to perform EMC type testing on ALS v2 equipment. The ALS v2 EQ Plan justifies a configuration of type tested equipment through its choice of board configurations with the potential to be most susceptible to electromagnetic effects and most prone to generate electromagnetic emissions, and therefore most likely to reveal an unacceptable performance. The ALS v2 EQ Plan also defines the EMC qualification approach. Upon completion of the EMI/RFI testing, an ALS v2 Platform EQ Summary Report will be developed to provide a detailed summary of the EMC qualification testing and results.

3.3.4.1 Radiated and Conducted Emissions The manufacturer committed to perform its electromagnetic emission testing in accordance with the MIL-STD-461G set of tests as endorsed by RG 1.180 (see Reference 10, Section 4, Table 4-1). The manufacturer performed additional emissions tests to meet the CE Mark certification rather than NRC regulatory guidance. When emissions tests are completed, test results will be documented in an ALS v2 Platform EQ Summary Report.

The NRC staff reviewed the ALS Topical Report, as amended by Reference 1, and the ALS v2 EQ Plan (Reference 10) and determined that the manufacturers plans for performing EMC emissions qualification tests are consistent with the RG 1.180 endorsement of MIL-STD-461E.

Emissions tests conducted in accordance with this plan will establish and document compliance with the technical requirements of the military standard, as endorsed by the NRC staffs regulatory guidance, and documentation of the equipments emission levels for use by the applicants and licensees referencing this SE.

3.3.4.2 Radiated and Conducted Susceptibility The manufacturer committed to perform its electromagnetic susceptibility testing in accordance with the IEC suite of tests as endorsed by RG 1.180 (see Reference 10, Section 4, Table 4-2).

The manufacturer performed additional susceptibility tests to meet the CE Mark certification.

The MIL-STD-461E: RS103 test was included to cover the 1-10 GHz frequency range that was not addressed by the IEC standards. When Radiated and Conducted Susceptibility tests are completed, the test results will be documented in an ALS v2 Platform EQ Summary Report.

The NRC staff reviewed the ALS Topical Report, as amended by Reference 1, and the ALS v2 EQ Plan (Reference 10) and determined that the manufacturers plans for performing EMC susceptibility qualification tests are consistent with the RG 1.180 endorsed IEC suite of tests.

Susceptibility tests conducted in accordance with this plan will establish and document compliance with the technical requirements of the IEC suite of tests, as endorsed by the NRC staffs regulatory guidance, and documentation of the equipments susceptibility qualification levels for use by the applicants and licensees referencing this SE.

3.3.4.3 Surge and Electrical Fast Transient Withstand Capability

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION The manufacturer committed to perform surge and electrical fast transient testing in accordance with the IEC suite of tests as endorsed by RG 1.180 (see Reference 10, Section 4, Table 4-5).

When surge and electrical fast transient withstand tests are completed, the test results will be documented in an ALS v2 Platform EQ Summary Report.

The NRC staff reviewed the ALS Topical Report, as amended by Reference 1, and the ALS v2 EQ Plan (Reference 10) and determined that the manufacturers plans for performing EMC surge and electrical fast transient qualification tests are consistent with the RG 1.180 endorsed IEC suite of tests.

Surge and electrical fast transient withstand tests conducted in accordance with this plan will establish and document compliance with the technical requirements of the IEC suite of tests, as endorsed by the NRC staffs regulatory guidance, and documentation of the equipments surge and electrical fast transient qualification levels for use by the applicants and licensees referencing this SE.

3.3.4.4 Electrostatic Discharge Withstand Testing The manufacturer committed to electrostatic discharge testing to meet the CE Mark certification rather than the NRCs regulatory guidance (see Reference 10, Section 4, Table 4-5). Upon the conclusion of the electrostatic discharge withstand tests, the test results will be documented in an ALS v2 Platform EQ Summary Report.

The NRC staff reviewed the ALS Topical Report, as amended by Reference 1, and the ALS v2 EQ Plan (Reference 10) and determined that the manufacturers plans for performing electrostatic discharge testing are consistent with the RG 1.180 reference to IEC 61000-4-2.

Electrostatic discharge withstands tests conducted in accordance with this plan will establish and document compliance with the technical requirements of the IEC suite of tests, as endorsed by the NRC staffs regulatory guidance, and documentation of the equipments electrostatic discharge qualification levels for use by the applicants and licensees referencing this SE.

3.4 Platform Integrity Characteristics SRP Chapter 7, Appendix 7.1-C, Section 5.5, System Integrity, states that a special concern for digital computer-based systems is confirmation that the real time performance of the system is adequate to ensure the completion of protective actions within the critical time periods identified within Clause 4.10 of IEEE Std 603-1991. SRP BTP 7-21 provides supplemental guidance to evaluate the real-time performance of digital systems and architectures, and discusses the identification of bounding real-time performance specifications and the verification of these specifications to demonstrate real-time performance. The establishment of predictable performance and behavior for a platform supports the future evaluation of a safety system based on the platform.

3.4.1 Response Time GDCs 20, 21, 23, and 25 (of Appendix A to 10 CFR Part 50) constitute general requirements for a timely operation of the protection features. To support these requirements, SRP BTP 7-21 provides the following guidance:

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION The feasibility of design timing may be demonstrated by allocating a timing budget to components of the system architecture to ensure that an entire system meets its timing requirements.

Timing requirements should be met by design commitments.

Two regulations provide bases for this guidance, where the first is 10 CFR 50.55a(h) and its reference to IEEE Std 603-1991. The second is 10 CFR 50.36(c)(1)(ii)(A), which provides the basis for timing requirement commitments by requiring the inclusion of limiting safety system settings for nuclear reactors in the plant technical specifications that are so chosen that automatic protective action will correct the abnormal situation before a safety limit is exceeded.

The response time of an ALS v2 platform-based system is determined by its overall configuration. Therefore, each licensee must determine the ALS v2 platform response time characteristics which are suitable for its plant-specific application. The ALS platform response time performance characteristics are described in general terms within the ALS topical report, as amended by Reference 1 (see Reference 5, Section 2.7). These reports also identify the configuration settings that affect the response time performance (see Reference 5, Sections 2.2.2.1 and 2.3.1).

To meet a typical response time performance requirement, an ALS v2 platform-based system must acquire the input signal, perform logic processing associated with the safety function, and generate an output signal to initiate the safety function. These ALS v2 platform response time components do not include: (1) the earlier plant process delays through the sensor input to the platform and (2) the latter delays through a final actuating device to affect the plant process.

Therefore, the applicants or licensees plant-specific and application-specific safety function response time design bases should address these response time components separately from the response time performance requirements specified for the ALS v2 platform-based system.

The ALS topical report Figure 2.7-1, as amended by Reference 1, depicts the typical ALS v2 platform response time as a chain of high level delays that includes three board types (Input Board, Core Logic Board, and Output Board) where:

Any of the input boards, ALS-352, ALS-361, or ALS-371, may acquire an input signal and perform some initial signal conditioning/processing (see Reference 5, Figure 2.7-1, Input Delay);

The ALS-152 Core Logic Board performs plant-specific and application-specific logic processing functions on the inputs to control an output signal (see Reference 5, Figure 2.7-1, Logic Delay); and Any of the output boards, ALS-452 or ALS-471, may perform some final signal conditioning before generating the output signal (see Reference 5, Figure 2.7-1, Output Delay).

However, an ALS-651 Communications Board may also be used within a system to transfer digital data as part of the safety signal path in direct support of the response time performance requirements. When an ALS-651 Communications Board is used as part of the safety signal

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION path in direct support of the response time performance requirement, the chain of delays includes a minimum of six boards (Input Board, Core Logic Board, Communication Board #1, Communications Board #2, Core Logic Board #2, and Output Board) where additional component response time delays beyond those depicted in ALS topical report Figure 2.7-1, as amended by Reference 1, would exist.

Each ALS v2 platform input board has a defined propagation delay from the point in time when an input signal changes until the digital representation of the input signal reflects the new value and is available, via the RAB, for access by the ALS-152 Core Logic Board. Each ALS v2 platform output board has a similarly defined propagation delay from the point in time when the ALS-152 Core Logic Board provides a new digital representation for an output signal, via the RAB, until the output signal reflects 50 percent of the difference between the original value and the new value. In addition to these defined propagation delays, either an input or output board may apply to the configuration data to establish application-specific filtering, and this filtering can produce additional response time delays. Plant-specific and application-specific response time performance budgets should account for the input and output delays, including propagation delays and any additional application-specific digital filtering delays, as applicable.

The ALS-651 Communications Board also has a defined propagation delay from the point in time when the digital data reception successfully completes until the digital data is available, via the RAB, for access by the ALS-152 Core Logic Board. The ALS-651 Communications Board has another defined propagation delay from the point in time when the digital data is provided by the ALS-152 Core Logic Board, via the RAB, until the ALS-651 makes this digital data available for transmission. The plant-specific and application-specific configuration of the ALS-651 Communications Board establishes the interval between digital data transmissions and the worst-case transmission duration. Furthermore, consistent with DI&C-ISG-04, Staff Position 1, Point 20, the safety system response time calculations should assume a data error rate greater than or equal to a design basis error rate, which is supported by the error rates observed during the design and qualification testing (see Section 3.7.2.1.20). Plant-specific and application-specific response time performance budgets should account for the ALS-651 Communications Board digital data communications delays, as applicable. Furthermore, because the ALS-651 program does not incorporate logic to detect a communication timeout (i.e., failure to successfully received valid data), when an ALS v2 application must take action (e.g., go to a fail-safe state or initiate an alarm indication) based on lost communication or an excessive communication delay, a project-specific ALS v2 application specification must include an appropriate requirement to address this application-specific system behavior. The manufacturer identified this application-related restriction within an ALS application guidance document.

The ALS v2 platform does not establish a propagation delay from digital input to digital output for the ALS-152 Core Logic Board, because the logic for each ALS-152 Core Logic Board is both plant-specific and application-specific. In accordance with the ALS v2 Topical Report, each ALS-152 Core Logic Board controls the instrument frame time, which is the interval between accessing each specific board so that the information will have been read once from all application input boards and will have been written once to all application output boards. Plant-specific and application-specific logic within the ALS-152 Core Logic Board can produce additional response time delays which may be significant in comparison to the RAB transfer time and application-specific frame time. As a result, the plant-specific and application-specific

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION response time performance budgets should account for ALS-152 Core Logic Board processing delays.

The ALS v2 Platform Design Specification specifies a single crystal oscillator for use with each FPGA and performance requirements for the oscillator (see Reference 23, Section 3.3.8.1). For all ALS v2 platforms FPGA-based digital logic, the digital logic delays are fixed at the design time and the maximum digital delay is a function of the as-built logic and the frequency of the local oscillator. The FPGA logic of the ALS-152 Core Logic Board includes the logic that establishes the ALS v2 platform board access time, which is a fixed interval allocated to exchange data with an individual board using the RAB protocol, and the application-specific frame time, which is the interval between accessing each specific board so that the information will have been read once from all application input boards and will have been written once to all application output boards. The oscillator that establishes the board access time and the frame time also establishes the timing of the ALS-152 Core Logic Boards logic for control of the RAB as the bus master. Use of a single crystal local oscillator on the master ALS-152 Core Logic Board and one each slave ALS v2 platform standardized circuit board, allows the verification of the ALS-152 Core Logic Boards local oscillator as a method to bound the digital system response time of the FPGA logic, because the RAB protocol logic bounds the oscillator drift between boards.

Qualification testing of the ALS v2 platform will include exercising the RAB and monitoring for failed RAB transactions. The qualification test will include system performance requirements and the use of test equipment to monitor the unit under test for RAB transaction errors.

The ALS v2 platform provides features to monitor an ALS-152 Core Logic Boards application-specific frame time to address the potential for the oscillator drift to negatively affect the response time performance. An application should consider the inclusion of features to monitor the ALS-152 Core Logic Board oscillator drift. When the application specifications for the ALS-152 Core Logic Board includes features to monitor an ALS-152 Core Logic Boards application-specific frame time, the continued performance of its local oscillator can be independently verified. In turn, this independent clock verification can be extended to the indirect verification of the oscillators on each RAB slave standardized circuit board, because RAB protocol design features bound the oscillator logic drift between the master ALS-152 board and each slave board.

The NRC staff determined that periodic measurements of the ALS-152s oscillator performance may be used by the applicants or licensees to confirm that the application-specific instruments digital response time performance requirements continue to be met when the traceable independent clock verifications to the applicable National Institute of Standards and Technology standard bound the systems digital response time performance. The NRC staff further determined that the worst-case board access and frame times, which are application-specific, may be used by licensees when determining whether the ALS v2 platform response time characteristics are sufficient for the applicants or licensees plant-specific application.

The NRC staff also determined that the worst-case RAB digital data transaction time may be used by the applicants and licensees when determining whether the ALS v2 platform response time characteristics are sufficient for the applicants or licensees plant-specific application. The RAB protocol includes provisions to bound the oscillator logic drift between boards and provides operator notifications for a failed RAB transaction.

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION The NRC staff determined that the response time performance for each safety-related system, based on the ALS v2 platform, requires a PSAI to address the system timing requirements and the timing budget among system components. Specifically, the applicant and licensees referencing this SE should:

1. Establish application-specific design timing requirement(s) for the system,

2. Perform application-specific analysis to budget the timing requirement(s) to associated components of the system architecture,

3. Validate that the most restrictive timing requirement for each ALS v2 platform component used within the system architecture has been bounded by the qualified performance envelope for that ALS v2 platform component,

4. Perform verification testing that demonstrates that the integrated ALS v2 platform-based system meets each design timing requirement and performs as expected, and

5. Include appropriate technical specification surveillance requirements to confirm the equipments digital response time characteristics, as applicable.

These PSAIs should ensure that the ALS v2 platform-based system meets its requirements in direct support of the plant-specific and application-specific system response time design bases (see Section 4.2, Item 7).

In addition to confirming that each system-level design commitment timing requirement has been met, verification testing should also evaluate the test results against the expected minimum and maximum response times predicted for the equipments performance to validate the response time analyses.

3.4.2 Determinism The review guidance of SRP Chapter 7, Appendix 7.1-C, Section 6.1, Automatic Control, identifies the considerations that address digital computer-based systems for the evaluation of the automatic control capabilities of the safety system command features. This review guidance advises that the evaluation should confirm that the systems real time performance is deterministic and known. SRP BTP 7-21 discusses design practices for computer-based systems that should be avoided, and these practices include non-deterministic data communications, non-deterministic computations, interrupts, multitasking, dynamic scheduling, and event-driven design. SRP BTP 7-21 further states that the methods for controlling the associated risk to be acceptable real time performance should be described when such practices are employed.

Electric Power Research Institute (EPRI) TR-107330, as approved by NRC SE dated July 30, 1998 (ML12205A265), provides generic requirements specification for qualifying commercially available Programmable Logic Controllers (PLCs) for safety-related applications. Specifically, it provides specifications and guidance intended to achieve a deterministic execution cycle with deterministic behavior that ensures that an application and its constituent tasks will be completed within specified time limits. In particular, EPRI TR-107330, Section 4.4.1.3, Program

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION Flow Requirements, specifies that, where scanning of the inputs and application program execution are performed in parallel, methods should ensure that the input scan and application program execution are completed each cycle. EPRI TR-107330 (Reference 28) does not directly apply to the ALS v2 platform, because the ALS v2 platform is entirely FPGA-based and does not include a software executive or software programming. However, the EPRI report provides specifications and guidance that promote a continuous and essentially non-interruptible operating cycle as the preferred environment in which to execute safety functions, and this is applicable to the ALS v2 platform and architecture.

The following subsections describe the deterministic characteristics of the ALS v2 platform and architecture and evaluate these characteristics using criteria applicable to the FPGA technology.

3.4.2.1 Deterministic and Known Real Time Performance (Deterministic Computation)

The discussion and evaluation in Section 3.4.1 of this SE addresses the establishment and confirmation of the response time performance requirements for the ALS v2 platform-based systems so the real time performance is known. The application-specific analysis to budget real time requirement(s) to the response time performance of each component and data transaction is founded upon deterministic propagation delays, a deterministic board access time, and a deterministic frame time in accordance with the design of the ALS v2 platform and architecture.

The ALS topical report, as amended by Reference 1, describes the deterministic nature of the ALS v2 platform (see Reference 5, Sections 2.3 and 3.1). The ALS v2 platform and architecture provide design features to ensure that the ALS-152 Core Logic Board will perform its functions to completion within the board access time and frame time. The board access time is the fixed interval allocated to exchange data with an individual board using the RAB protocol. The frame time is the interval between accessing each specific board so information will have been read once from all application input boards and written once to all application output boards. Although the ALS v2 platform establishes a fixed board access time, other aspects, including the number of times a board is accessed per frame, the number of boards accessed per frame, the sequence of board accesses per frame, and the frame time itself, are determined during the application-specific design phase. All of these design aspects establish the fixed interval for each safety function performed. The ALS v2 platform RAB protocol ensures that each RAB transaction occurs within its timing budget, and each ALS v2 platform board that responds to RAB requests contains monitoring logic to ensure that it continues to be successfully accessed.

Therefore, the ALS v2 platform provides design features to alert operators to the systems condition when the RAB transaction time, board access time, or frame time is not met. The ALS v2 platform provides the capability to activate alarms when a failure to meet timing is detected. This capability can identify to operators when timing is not being met so operators can take corrective actions.

The NRC staff determined that the ALS v2 platform supports the deterministic and known real time performance through deterministic computation, because the discussions and evaluation in Section 3.4.1 of this SE demonstrate the allocation of time delays to the elements of the platform and architecture, and the ALS v2 platform provides the capability to activate alarms to notify the operators of failures to meet timing so that the operators can take corrective actions.

3.4.2.2 Deterministic Digital Communication for Safety Signals

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION The ALS v2 platform performs digital communications between the system components within each safety division through serial data transfers over the RAB: Reliable ALS Bus. Each divisional RAB provides a redundant digital data exchange, which forms part of the overall safety signal path. A second bus, TAB: Test ALS Bus, for each safety division is used for maintenance, diagnostics, and test data. The TAB cannot adversely affect the safety signal path because the communications needed to accomplish safety functions use the RAB and do not use the TAB. Each bus follows a master-slave protocol. An ALS-152 Core Logic Board is the bus master of the RAB. When connected, the Maintenance Workstation will act as the bus master of the TAB (see Reference 23, Section 5).

As part of the NRC staffs prior SE (Reference 5), the NRC staff reviewed the documentation that described the RAB and TAB protocols and determined that the communications independence within an ALS platform-based system is maintained between these two separately controlled buses.

The NRC staff previously concluded that communication independence exists because of the following:

1) the RAB segregates the operational safety signal path from the TAB that provides the maintenance and troubleshooting diagnostic signal path,

2) the independent digital logic circuits in the form of separate finite state machines implement the bus logic, and

3) operation of the TAB does not affect the operation of the RAB or other safety logic.

The ALS v2 platform retains the basic design features of the RAB and TAB buses. Though changes are made to the backplane connectors through which the RAB and TAB buses are connected, the bus configurations and operation remain unchanged from the original ALS platform design. Therefore, the above safety conclusions for the communication independence between the RAB and TAB buses remain valid for the ALS v2 platform design.

The ALS v2 platform boards are connected using a backplane in each instrumentation chassis.

The backplane contains copper signal traces that are the signal paths for the RAB and TAB.

These buses are based on the EIA-485 differential standard and each is half-duplex, which does not allow simultaneous data transmission and reception. Each half-duplex communication is controlled by its bus master to allow one and only one active bus transmitter at a given point in time. The serial communication protocol for each bus uses predefined messages of a fixed size to establish fixed and predictable bandwidth use and data transfer delays. The serial communication protocol for each bus also uses Cyclic Redundancy Checks (CRCs) to ensure the integrity of data transfers between boards. Each bus master (ALS-152 Core Logic Board or Maintenance Workstation) controls its serial data bus resource (RAB or TAB), which is shared among boards, so two boards cannot simultaneously access the same bus. Both RAB and TAB buses may be simultaneously active because they operate independently.

The NRC staff reviewed the ALS platform architecture and internal communication protocol and determined that the characteristics have not changed since the NRC staffs prior SE review in Reference 5. The prior SE determined that the ALS platform provides deterministic point-to-

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION point communications and error detection to preclude the use of invalid data in accordance with IEEE Std 7-4.3.2-2003.

The NRC staff determined that the ALS v2 platform does not include non-deterministic data communications. The ALS v2 platform communications remain consistent with the communications designs previously described and evaluated in Reference 1 and meet the NRC staffs SE criteria governing deterministic communications.

3.4.2.3 Exclusion of Software-based System Characteristics The ALS v2 platform uses independent FPGAs which contain digital logic in the form of separate finite state machines to implement individual functions. The ALS v2 platform neither implements a microprocessor nor embeds executable software. As such, the ALS v2 platform does not use operating system or software executive, and the design approach inherently precludes the ALS v2 platform from implementing software interrupts, multitasking, or dynamic scheduling.

The NRC staff determined that the ALS v2 platform does not include risks to real time performance that would otherwise be associated with the potential software programming practices of interrupts, multitasking, or dynamic scheduling. The operational characteristics that result from the ALS v2 platforms design approach inherently preclude the ALS v2 platform from implementing these programming practices.

3.4.2.4 Exclusion of an Event-Driven Design The ALS v2 platform design uses a cyclic sampling of inputs, processing, and refreshing of outputs. This logic processing sequence does not vary based on the context or timing of individual data transactions.

The NRC staff determined that the ALS v2 platform is not an event-driven design, because the sequence of processing logic is fixed, periodically repeats, and does not change as a result of either the context or the timing of individual data transactions. The NRC staff further determined that the ALS v2 platform is not an event-driven design, because the evaluation of the internal communications against the points under DI&C-ISG-04, Staff Position 1, Interdivisional Communications, as applicable to the ALS v2 platforms use of FPGA technology, confirmed that the data communication protocols are deterministic.

3.4.2.5 Summary Staff Determination for Determinism As discussed in the preceding subsections, the NRC staff determined that the ALS v2 platform supports meeting the criteria for deterministic performance contained within SRP Chapter 7, Appendix 7.1-C, Section 6.1; SRP BTP 7-21; and EPRI TR-107330, Section 4.4.1.3 when the plant-specific and application-specific logic conforms to the ALS v2 platform architecture described within the ALS topical report, as amended by Reference 1. The NRC staff also determined that the ALS v2 platform does not introduce non-deterministic computations or a non-deterministic digital data communication protocol, because the ALS v2 platform supports deterministic data communications and the FPGA logic does not implement a microprocessor or executable software.

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION Based on the preceding evaluation of the ALS v2 platform and the NRC staff determinations, the NRC staff has identified a PSAI to confirm that the application specifications identify the board access sequence, frame time, and design features that activate the alarms upon the detection of a failure to meet timing requirements. The PSAI should also verify that the application-specific logic does not introduce non-deterministic computations or non-deterministic digital data communications (see Section 4.2, Item 8).

3.4.3 Self-Diagnostics, Test, and Calibration Capabilities IEEE Std 603-1991, Clause 5.7, states that the safety system shall have the capability for test and calibration while retaining the capability to accomplish its safety functions. It further states that this capability shall be provided during a power operation, and shall duplicate, as closely as practicable, performance of the safety function. Exceptions to the testing and calibration during power operation are allowed where this capability cannot be provided without adversely affecting the safety or operability of the generating station. However, appropriate justification must be provided, acceptable reliability of the equipment operation must be demonstrated, and the capability shall be provided while the generating station is shut down.

IEEE Std 603-1991, Clause 5.7, references IEEE Std 338-1987, Criteria for the Periodic Surveillance Testing of Nuclear Power Generating Station Safety Systems, for the testing of Class 1E systems, and RG 1.118, Periodic Testing of Electric Power and Protection Systems, which endorses with exceptions IEEE Std 338-1987, as a method acceptable to the NRC staff for meeting the Commission's regulations with respect to periodic testing of electric power and protection systems. Furthermore, RG 1.22, Periodic Testing of Protection System Actuation Functions, describes a method that is acceptable to the NRC staff for the inclusion of actuation devices in the periodic tests of the protection system during reactor operation.

SRP, Chapter 7, Appendix 7.1-C, Section 5.7, Capability for Test and Calibration, provides acceptance criteria for IEEE Std 603-1991, Clause 5.7. Capability should be provided to permit testing during power operation and when this capability is achieved by overlapping tests, the test scheme must ensure that the tests do, in fact, overlap from one test segment to another.

Section 5.7 further states that the test procedures requiring the disconnection of wires, the installation of jumpers, or other similar modifications to the installed equipment are not acceptable test procedures for use during power operation. Section 5.7 further states, for digital computer based systems, that the test provisions should address the increased potential for subtle system failures such as data errors and computer lockup.

SRP BTP 7-17 states that automatic diagnostics and self-test features should preserve channel independence, maintain system integrity, and meet the single-failure criterion during testing.

Additionally, the benefits of diagnostics and self-test features should not be compromised by additional complexity that may result from the implementation of diagnostics and self-test features. In particular, the scope and the extent of interfaces between safety software and diagnostic software such as self-test routines should be designed to minimize the complexity of the integrated software. SRP BTP 7-17 only partially applies to the ALS v2 platform, because the ALS v2 platform is entirely FPGA-based and does not include a software executive or software programming. The ALS v2 platform diagnostic and self-test FPGA logic is separate and independent of the FPGA safety function logic, thus the programming of the safety function FPGA logic is not made more complex by the inclusion of the diagnostic and self-test FPGA

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION logic. Regardless, SRP BTP 7-17 provides other guidance directly applicable to the ALS v2 platform and architecture.

EPRI TR-107330 provides guidance and requirements applicable to PLC-based systems diagnostics and test capability to help ensure that the combination of self-diagnostics and surveillance testing will detect all failures that could prevent a PLC from performing its intended safety function. EPRI TR-107330 only partially applies to the ALS v2 platform because the ALS v2 platform is entirely FPGA-based and does not include a software executive or software programming. Regardless, the concepts provided through EPRI TR-107330s specifications and guidance to detect all failures that could prevent the performance of a safety function through the combination of self-diagnostics and surveillance testing are applicable to the ALS v2 platform and architecture.

The regulations at 10 CFR Part 50, Appendix A, GDC 21 require, in part, that the protection system be designed for in-service testability commensurate with the safety functions to be performed. It also requires a design that permits periodic testing of its functioning when the reactor is in operation, including the capability to test channels independently to determine failures and losses of redundancy that may have occurred.

The regulations at 10 CFR 50.36(c)(3), Surveillance requirements, state that surveillance requirements are requirements relating to test, calibration, or inspection to assure the necessary quality of systems and components is maintained, that facility operation will be within safety limits, and that the limiting conditions for operation will be met. RG 1.53, which endorses IEEE Std 379-2000, IEEE Standard Application of the Single-Failure Criterion to Nuclear Power Generating Station Safety Systems, states that the protection system must be capable of accomplishing the required protective function in the presence of any single detectable failure concurrent with all identifiable, but non-detectable, failures. Consequently, self-testing and periodic testing are important elements in the designs ability to meet the single-failure criterion.

SRP BTP 7-17 describes additional considerations in the evaluation of test provisions in digital computer-based systems.

The ALS topical report, as amended by Reference 1, describes the diagnostics and maintenance features provided by ALS v2 platform and addresses IEEE Std 603-1991, Clause 5.7 (see Reference 5, Sections 3 and 12.1.8). The ALS v2 platform supports the test and calibration from field input to instrument output without the lifting of leads or the installation of jumpers, because the design features for maintenance allow an individual instrument input or output channel to be disabled, placed into bypass, or placed into calibration.

Field terminations for the ALS v2 platform are now at the front of the individual ALS v2 boards instead of at the back of the chassis. The field terminal block design continues to allow the injection of test signals without lifting leads to field wiring and can still be used for the ALS v2 platform. With this approach, the test signal can be injected at the field terminal blocks and then the ALS v2 platform processes it using the actual safety signal path. This manually initiated test method excludes the sensor wiring to the terminal block and includes the instrument signal and data communication path from the terminal block throughout the remainder of the instrument.

The ALS v2 platform architecture and communication protocols include design features to verify continued logic processing and the correctness of data transfers so either lockup or data errors are detectable failures.

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION Additional periodic surveillances, which are beyond this SE scope, may be required to comply with IEEE Std 603-1991, Clause 5.7. Additional periodic surveillances should be provided when the ALS v2 platform injection point is not considered to be as close to the sensor as practical or when the ALS v2 platform output does not extend to the actuating device. These additional periodic surveillances could include the confirmation of other continuous or manually initiated tests that overlap with the ALS v2 platform self-diagnostics. Overlapping tests could include the verification of the integrity of sensor wiring and sensor itself or involve the system-level verification of actuations.

The ALS topical report, as amended by Reference 1, provides a high-level description of the ALS v2 platform approach to diagnostics and fault indications, and this description includes a generic depiction of the verification approach for the safety signal path within an ALS v2 platform-based instrument (see Reference 5, Section 3.1 and its Figure 3.1-1).

Some ALS v2 test capabilities, such as from a field input to an ALS v2 input board and from an ALS v2 output board to a field output, are determined by the specific application and interfacing equipment. When failures are detected, their effects will be mitigated and managed in accordance with the application specifications and some application-specific diagnostics may be required. Because application-specific surveillance testing requirements are determined during application development and technical specification changes are application-specific, these system design features are outside of the scope of the ALS v2 Topical Report.

The NRC staff reviewed the ALS Topical Report, as amended by Reference 1, ALS v2 Platform Requirements Specification, ALS v2 Platform Specification, and individual standardized circuit board specifications to evaluate the diagnostic, self-test and manually initiated test, and calibration capabilities provided in the ALS v2 platform. However, the NRC staffs review could neither evaluate whether the test and calibration approach duplicates, as closely as practicable, performance of the safety function nor whether the combination of the channel specific testing, standardized platform testing, and licensee specific surveillance requirements provides overlapping testing, because these considerations are application specific. The NRC staffs review could not address the application-specific considerations necessary to confirm that channel independence is preserved, system integrity is maintained, and the single-failure criterion continues to be met during testing, because these considerations are, in part, dependent on the application-specific functionality and channel, division, and voting logic arrangement. These limitations are consistent with the ALS topical report scope, which states that specific system-level failure modes, methods of detection, and system responses are expected to be documented as application-specific and notes that an Application Design Specification will be presented to the NRC staff to provide the DI&C-ISG-06 information content for the topics of System Integrity and Test & Calibration (Reference 5, Sections 12.1.6 and 12.7). The manufacturer provided no information in its ALS v2 submittal that would invalidate that related information in its ALS topical report.

Despite these limitations, the NRC staff determined that the ALS v2 platform supports meeting the applicable provisions of IEEE Std 603-1991, Clause 5.7, RG 1.22, and RG 1.118. This determination is based on the NRC staffs review of the information provided in the ALS Topical Report as amended by Reference 1, ALS v2 Platform Specification, and the individual standardized circuit board specifications, because the design features, as described, provide the following capabilities: (1) test and

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION calibration while retaining the equipments ability to accomplish its safety function, (2) support of compensatory actions, such as tripping or bypassing individual functions per channel, when technical specification limiting conditions for operation are not met, and (3) continuous indication of these compensatory actions in the control room.

In consideration of the preceding limitations, the NRC staff determined that PSAIs are required.

For each safety function, PSAIs should demonstrate the application-specific use of ALS v2 platform diagnostic, self-test, and manually initiated test and calibration features are sufficient to verify the operational integrity of all logic components (i.e., all relays and contacts, trip units, solid state logic elements, etc.) of a logic circuit, from as close to the sensor as practicable, up to but not including the actuated device, with sufficient overlap.

When an ALS v2 platform built-in self-test feature is the justification for eliminating an existing surveillance or surveillances, or performing a less frequent surveillance, then the applicant or licensee should demonstrate how the ALS v2 platform built-in self-test features test the components and safety functions and further demonstrate how the built-in self-testing provides equivalent assurance to the manual functional tests and related surveillances performed on the equipment being replaced.

Plant-specific actions should also confirm that the plants surveillance procedures will verify the built-in self-tests results and ensure that these built-in self-tests continue to operate, as referenced by surveillance requirements provided in the plants technical specifications and as applicable.

Plant-specific actions should also confirm that the plants installation does not exhibit unjustified intermediate errors without reported failures that could adversely affect a safety function.

Plant-specific actions should demonstrate that the application-specific diagnostic, self-test, and manually initiated test and calibration features identified within the plants maintenance and surveillance procedures will not adversely affect the channel independence, system integrity, or the systems ability to meet the single-failure criterion during testing, as permitted by the plants administrative controls and in consideration of the functionality per channel and the overall channel, division, and voting logic arrangement of the system.

Plant-specific actions should demonstrate the relationship between the application-specific diagnostic, self-test, and manually initiated test and calibration features provided by the ALS v2 platform and the conformance to the NRC staffs positions in RG 1.22 and RG 1.118 (see Section 4.2, Item 9).

3.5 Failure Mode and Effects Analysis RG 1.53 describes a method that is acceptable to the NRC staff for meeting the NRCs regulations as they apply to the single-failure criterion to the electrical power, instrumentation, and control portions of nuclear power plant safety systems. RG 1.53 endorses IEEE Std 379-2000, and IEEE Std 379-2000, Clause 5.5 identifies Failure Mode and Effects Analysis (FMEA) as a method to address common-cause failures when performing analysis to demonstrate that the single-failure criterion has been met. Although no specific regulatory guidance on the format, complexity, or conclusions of the FMEA exists, the FMEA should identify potential failure modes within a system to determine the effects of those failures on the system. The expectation is that

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION each potential failure mode should be identified, and its effects should be determined. The FMEA should demonstrate that single-failures, including those with the potential to cause a nonsafety system action (i.e., a control function) that results in a condition requiring protective action (i.e., a protection function), cannot also adversely affect the associated protection functions.

The ALS topical report, as amended by Reference 1, limits the scope of its FMEA to an FMEA that is individually applicable to each standardized circuit board, and that this scope does not represent a system to which the potential effects of failures can be analyzed. Therefore, in lieu of providing a system-level analysis, the ALS v2 platform FMEA documentation forms a portion of a boards hardware design specification. This ALS v2 platform documentation is identified with the ALS v2 platform document prefix of 6003 and the FMEA document suffix of xxx12 for each board-specific document as shown in Table 3.5-1 below. Within these documents, the manufacturer described the set of board-level analyses performed, to identify each boards functions and the failure paths associated with these functions. After postulating hardware failures to the board, the manufacturer also performed and described a board-level FMEA to document whether ALS v2 design features, including built-in self-test, would detect the hardware failure, whether the failure would affect the operability of the boards functions, and whether either the factory board-level acceptance testing or release testing would detect the hardware failure.

Table 3.5-1, ALS v2 Platform FMEA and Reliability Information Document ID Title 6003-35212 ALS-352 FMEA, Failure Path Analysis (FPA) and Reliability Analysis 6003-36112 ALS-361 FMEA, Failure Path Analysis (FPA) and Reliability Analysis*

6003-37112 ALS-371 FMEA, Failure Path Analysis (FPA) and Reliability Analysis 6003-45212 ALS-452 FMEA, Failure Path Analysis (FPA) and Reliability Analysis 6003-47112 ALS-471 FMEA, Failure Path Analysis (FPA) and Reliability Analysis 6003-65112 ALS-651 FMEA, Failure Path Analysis (FPA) and Reliability Analysis 6003-15212 ALS-152 FMEA, Failure Path Analysis (FPA) and Reliability Analysis

• NRC Staff Audited The ALS topical report, as amended by Reference 1, establishes that each application-specific ALS v2 platform-based system will have a system-level FMEA, because the set of individual board-level analyses is not equivalent to a system-level analysis. The ALS topical report, as amended by Reference 1, further states that the determination of the reliability of an ALS v2 platform-based safety system requires an application-specific system-level FMEA. As described in Sections 4.5.2.6 and 5.5.2.4 of Reference 8, the combination of the ALS v2 platform board-specific FMEAs and the system-level FMEA are required to demonstrate that there are neither any undetectable failures nor cascading failures that can contribute to a violation of the single failure criterion. Each ALS v2 platform board-specific FMEA should provide analyses of potential

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION hardware or programming failure modes applicable to the board level component, and as such, applicants and licensees may use this information to support an application-specific system-level FMEA (see Reference 5, Sections 7.1 and 12.1.1).

The NRC staff audited 6003-36112, identified in Table 3.5-1, in consideration of the limited scope of the ALS v2 platform FMEA, as described within the ALS topical report, as amended by Reference 1, and the reliance upon an application-specific system functionality and architecture as described within the ALS v2 Platform Specification. This document identifies each component failure that affects the principal functions of the board, some of which may not be detected and annunciated by ALS v2 platform self-diagnostic features.

The NRC staff determined that the manufacturer has performed a FMEA to support future evaluations against the single-failure criterion for ALS v2 platform-based systems, because the FMEAs identify board functions and the failure paths associated with these functions, postulate hardware failures, analyze the detectability of hardware failures, and further analyze the effect of hardware failures on the continued operability of the board and its functions. This NRC staffs determination is further based on the ability to design an application-specific ALS v2 platform-based system with sufficient diversity in redundant components to ensure the continued performance of safety functions as discussed in Section 3.8 of this SE.

In consideration of the preceding limitations, and the information presented by the manufacturer in Reference 1, the NRC staff determined that a PSAI continues to be required. A PSAI should include a system-level FMEA to demonstrate that the application-specific use of the ALS v2 platform identifies each potential failure mode and determines the effects of each. The FMEA should demonstrate that single-failures, including those with the potential to cause a nonsafety system action (i.e., a control function) that results in a condition requiring protective action (i.e.,

a protection function), cannot adversely affect the protection functions (see Section 4.2, Item 10).

3.6 Reliability and Availability Analysis IEEE Std 603-1991, Clause 4.9, requires that the identification of the methods to determine the reliability of the safety system design is appropriate for each such design, and the identification of the methods to verify that the reliability goals imposed on the system design have been met.

However, as discussed within RG 1.152 and DI&C-ISG-06, the NRCs acceptance of the reliability of digital I&C systems is based on deterministic criteria for both hardware and programming, and the NRC does not endorse the concept of quantitative reliability goals as a sole means of meeting its regulations for reliability of the digital computers used in the safety systems. Clause 5.15, IEEE Std 603-1991, further requires performance of an appropriate design analysis to confirm that the reliability goals have been achieved for each system with an established quantitative or qualitative reliability goal. IEEE Std 603-1991, Clause 6.7, requires that the safety system shall remain capable of accomplishing its safety function while continuing to meet the single-failure criterion when sense and command features are in maintenance bypass. Similarly, IEEE Std 603-1991, Clause 7.5, requires that the remaining redundant portions should provide acceptable reliability when one portion of a redundant safety systems execute features is placed into a maintenance bypass condition. DI&C-ISG-06 states that the reliability and availability analysis should justify that the degree of redundancy, diversity, testability, and quality provided in the safety system design is adequate to achieve functional

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION reliability commensurate with the safety functions to be performed with further consideration of the effect of possible failures and the design features provided, to prevent or limit their effects.

The ALS v2 Platform Requirements Specification (Reference 22) includes a reliability specification for Mean Time Between Failures (MTBF) for individual ALS v2 platform standardized circuit boards. The manufacturer also supports performance of its reliability predictions by an independent second party who uses data and a failure rate prediction tool from the Reliability Information Analysis Center, 217PLUSTM.

The NRC staff reviewed the reliability analysis summary, approach, and results provided in the Table 3.5-1 references and confirmed that these analyses identify an acceptable method of predicting the reliability of each of the ALS v2 boards. However, the NRC staff could not determine any compliance to IEEE Std 603-1991, Clauses 4.9, 5.15, 6.7, and 7.5, because these requirements are based on system-level reliability, which is established on a plant-specific and application-specific basis. The methods for determining if the ALS v2 system reliability meets the plant specific reliability requirements can be used to establish compliance with the IEEE 603 reliability criteria; however, such a determination is a plant-specific activity that must be performed for each plant-specific application of the ALS v2 platform.

Failure modes and the potential for failures, other than those associated with the hardware reliability of components, should be considered and addressed by the applicants and licensees.

To address this consideration, the ALS v2 Diversity Analysis includes a qualitative discussion of potential sources of faults introduced earlier in the life-cycle and identifies the methods for use throughout the life-cycle of an ALS v2 platform-based project to address the sources of potential unreliability (See Reference 18). ALS v2 platform methods address the development of its FPGA logic programs, including the reliance upon software-based tools, design specification and implementation activities, IV&V activities, and CM activities.

In consideration of the preceding limitations, the NRC staff determined that a PSAI is required and should include a deterministic system-level evaluation to determine that the degree of redundancy, diversity, testability, and quality provided in an ALS v2 platform-based safety system is commensurate with the safety functions that must be performed. This plant-specific action should consider the effect of possible failures, system-level design features provided to prevent or limit the failures effects, and any application-specific inclusion of a maintenance bypass to support plant operations. Plant-specific actions should confirm that a resultant ALS v2 platform-based system continues to meet any applicable reliability goals that the plant has established for the system (see Section 4.2, Item 11).

3.7 Digital Data Communication Independence and Isolation The NRC staffs positions within DI&C-ISG-04 establish a means to ensure independence among redundant safety channels while permitting some degree of interconnection and shared resources among independent channels. DI&C-ISG-04 is based on: (1) the 10 CFR 50.55a(h) inclusion of IEEE Std 603-1991 and (2) the endorsement of IEEE Std 7-4.3.2-2003 within RG 1.152. IEEE Std 603-1991 requires, among other things, independence among redundant safety channels and redundant safety systems to be independent of one another. RG 1.152 endorses IEEE Std 7-4.3.2-2003 as acceptable for meeting the NRCs regulations with respect to high functional reliability and design requirements for computers used in the safety systems

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION of nuclear power plants. Clause 5.6 of IEEE Std 7-4.3.2-2003 addresses digital communication independence for safety systems.

The following subsections evaluate the ability of the ALS v2 platform to meet safety system digital data communication evaluation criteria. The ALS topical report, as amended by Reference 1, identifies three methods that support the safety system digital data communication to differing degrees and these methods are:

1) ALS-152 Core Logic Board - two transmit-only interfaces (TxB1 and TxB2);

2) Test ALS Bus (TAB) - one bidirectional (transmit and receive) interface; and

3) ALS-651 Communication Board - eight unidirectional (transmit-only or receive-only) interfaces.

The following subsections contain the NRC staffs evaluation of each available method against the NRC staff positions and points within DI&C-ISG-04, with further consideration that the ALS topical report scope, as amended by Reference 1, does not propose to meet all staff positions and points via the ALS v2 platform components. For example, the ALS v2 platform components do not include the qualified isolation devices required between Class 1E and Non-Class 1E equipment and does not include the use of the ALS v2 platform within command prioritization applications. The exclusions to the staff positions and points are documented in the corresponding evaluations.

3.7.1 ALS v2 Platform Digital Data Communications The DI&C-ISG-04 evaluation criteria are the same for both safety-safety interdivisional communications and safety-nonsafety communications. The ALS topical report, as amended by Reference 1, targets its methods for digital data communication to different types of communications between safety and nonsafety equipment and among independent safety channels. The ALS-152 Core Logic Board and the TAB methods target communication with nonsafety equipment while the ALS-651 Communication Board targets interdivisional communication among redundant safety channels. The following subsections first provide an overview of these methods and then evaluate each method against applicable NRC staff positions and points within DI&C-ISG-04.

3.7.1.1 With Nonsafety Equipment The ALS-152 Core Logic Board method targets transmit-only communication to computing, display, and recording devices while the TAB method targets bidirectional communication with a maintenance workstation. The ALS topical report, as amended by Reference 1, establishes the interfacing equipment which may be nonsafety. The NRC staff evaluated these interfaces as the communication between a safety division and nonsafety equipment.

3.7.1.1.1 Via TxB1 and TxB2 on the ALS-152 Core Logic Board The ALS-152 Core Logic Board provides two transmit-only interfaces, which are referred to as TxB1 and TxB2. The FPGA device installed in the ALS-152 Core Logic Board will include the logic that performs safety functions and the logic that supports communication via TxB1 and

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION TxB2. Use of the ALS v2 platform requires application specifications for each system that enables either TxB1 or TxB2.

3.7.1.1.2 Via TAB and Instrument Backplane with Each Circuit Board Each ALS v2 standardized circuit board shares a bidirectional interface over the instrument backplane, which is referred to as the TAB. The FPGA device installed in each ALS v2 standardized circuit board will include the logic that performs safety functions and the logic that supports communication via the TAB. Available TAB interactions with each standardized circuit board are predefined except for the ALS-152 Core Logic Board, because only the ALS-152 Core Logic Board requires application-specific logic programming. Use of the ALS v2 platform requires application specifications for the ALS-152 Core Logic Boards installed FPGA

((

)) to identify its application-specific TAB interactions.

3.7.1.2 Among Safety Divisions or with Safety Equipment The ALS-651 Communication Board provides eight unidirectional interfaces that can be independently configured as transmit-only or receive-only. The FPGA device installed in the ALS-651 Communication Board will include separate logic resources to independently support the communication through each interface. The ALS topical report, as amended by Reference 1, describes the application of the ALS-651 Communication Board for interdivisional communications as being limited to a communication processor for sharing (i.e., transmitting and receiving) individual channel trip votes among redundant safety channels to support a coincidence voting application. In this application, the ALS-651 Communication Board provides vital communication to support the safety signal path, but its logic does not implement safety functions. Use of the ALS v2 platform for a coincidence voting application also requires an ALS-152 Core Logic Board to perform coincidence voting safety functions, which would be contained in the boards application-specific FPGA logic. Such use of the ALS v2 platform also requires application specifications for the ALS-152 Core Logic Boards FPGA to identify the digital data communication content and format for each enabled interface on the ALS-651 Communication Board, because the functionality of these interfaces is application specific. The NRC staff evaluated these interfaces as interdivisional.

3.7.2 NRC Staff Guidance in DI&C-ISG-04 DI&C-ISG-04 contains three NRC staff positions to address communication issues, which are:

(1) Interdivisional Communications, (2) Command Prioritization, and (3) Multidivisional Control and Display Stations. The ALS topical report, as amended by Reference 1, contains the manufacturers assessment of conformance to these points (see Reference 5, Sections 5 and 12.3).

Some of the points under the DI&C-ISG-04 NRC staff positions are implementation-specific and worded primarily with the consideration of microprocessor-based systems. Still other points are application-specific and cannot be fully evaluated within the scope of the ALS v2 Topical Report. The following subsections provide an evaluation of each ALS v2 platform communication method against the applicable points for the DI&C-ISG-04 positions. These evaluations address implementation-specific points in the consideration of the ALS v2 platforms FPGA-based logic processing to determine the degree that the platforms approach provides equivalent assurance that the digital data communications do not adversely affect the operability

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION of safety functions. For application-specific points, appropriate PSAIs are provided (see Section 4.2, Items 12, 13, 14, 15, and 16).

3.7.2.1 Staff Position 1, Points 1 through 20 - Interdivisional Communications DI&C-ISG-04, Staff Position 1, Interdivisional Communications, establishes criteria for communication interfaces between independent safety channels/divisions and between safety and nonsafety equipment. Meeting the criteria under this staff position provides reasonable assurance that these types of communications do not adversely affect the operability of the safety functions. The following subsections address each point of this staff position.

3.7.2.1.1 Point 1 Point 1 establishes that the accomplishment of a safety channels safety function should not depend on information or resources outside of the safety division while recognizing performance of voting logic requires the receipt of inputs from multiple safety divisions.

The ALS topical report, as amended by Reference 1, states that the ALS v2 inputs, conditioning, and outputs do not depend on data/information from any divisional input from outside its own division (see Reference 5, Table 5.4-1, DI&C-ISG-04 Item 1). Through this approach, the TxB1 and TxB2 interfaces on the ALS-152 Core Logic Board meet Point 1 because both are transmit-only interfaces. Therefore, neither of these interfaces can receive inputs from outside of the safety division and no dependency on the data from these interfaces can be established.

The TAB interface supports meeting Point 1 because the ALS v2 platform contains design features and provisions to establish and indicate that the equipment has been bypassed when this interface is active, whereby the bypassed equipment would no longer be relied upon to perform its safety function. Furthermore, the ALS topical report, as amended by Reference 1, describes an additional application-specific provision that allows the installation of a physical hardware disconnection of this interface when it is used with either a nonsafety or multidivisional maintenance workstation. This additional provision would not be necessary to meet Point 1 when this interface is used with a safety maintenance workstation that is contained within the same division and when the safety maintenance workstation is independent of resources outside of the safety division.

The ALS-651 Communication Board interfaces support meeting Point 1 because the ALS topical report, as amended by Reference 1, limits its intended use to vote sharing among multiple safety divisions when an ALS-651 communication interface is configured to receive data. In coincidence voting applications, the separate ALS-152 Core Logic Boards in each trip channel and in each coincidence voter, should have application-specific FPGA logic specifications to identify the digital data communication content and format that govern the interdivisional communications. When an application uses the ALS-651 Communication Board for interdivisional communications, its companion ALS-152 Core Logic Boards application specifications should demonstrate that Point 1 is met.

The NRC staff determined that the ALS v2 platform components support meeting Point 1 because the components can be arranged to preclude dependence on information or resources outside of the safety division. The NRC staff further determined that PSAIs are necessary to ensure that the ALS v2 platform components are applied to produce safety equipment that is

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION independent of information and resources outside of its safety division because each plant application defines the signal connections, data exchanges, and safety functions of the equipment (see Section 4.2, Items 13 and 14).

3.7.2.1.2 Point 2 Point 2 establishes that each safety channel should use internal safety resources to protect its safety functions from being adversely influenced by resources, signals, and information that originate from outside its own safety division.

The ALS topical report, as amended by Reference 1, states that there are no ALS v2 communication networks that transmit data between divisions, except for the final voting logic (see Reference 5, Table 5.4-1, DI&C-ISG-04 Item 2). The TxB1 and TxB2 are transmit-only interfaces. The ALS-152 Core Logic Board has been developed as safety-related and the FPGA logic on this board is application-specific. The TxB1 and TxB2 interfaces on the ALS-152 Core Logic Board support meeting Point 2 when the application-specific ALS-152 Core Logic Board FPGA logic is developed as safety-related and when qualified safety-related isolation devices are used.

The TAB interface supports meeting Point 2 under the following conditions:

When the application requires a qualified physical hardware disconnection (e.g., a Class 1E switch, disconnection of cable, etc.) of the TAB during system operability and When qualified safety-related isolation (i.e., a Class 1E isolating device that is part of the safety-related system) is used to isolate nonsafety or multidivisional maintenance workstations.

These two conditions are sufficient, because all ALS v2 standardized circuit boards have been developed as safety-related, and part of their standardized functionality establishes and indicates that the equipment has been bypassed when the TAB interface is active.

The TAB interface also supports meeting Point 2 without either employing a hardware disconnection of the TAB from the maintenance workstation or including isolation devices between the equipment and the maintenance workstation when the application uses a safety-related maintenance workstation that is contained within the same division. This provision is acceptable, because all division components will have been developed as safety-related, and further because the ALS v2 platform standardized functionality includes provisions to indicate that a division has been bypassed while its TAB interface remains active.

The ALS-651 Communication Board interfaces support meeting Point 2 when qualified safety-related isolation devices are used for interdivisional or safety to nonsafety communications, because the ALS-651 Communication Board has been developed as safety-related.

The NRC staff determined that the ALS v2 platform components support meeting Point 2 because the ALS v2 platform uses internal safety resources to protect safety functions from being adversely influenced by resources, signals, and information that originate from outside a safety division. The NRC staff further determined that PSAIs are necessary to ensure that the ALS v2 platform components are applied to prevent adverse influence by resources, signals,

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION and information that originate from outside any specific safety division by confirming the installation of the safety-related qualified devices for interdivisional and safety-nonsafety interfaces, and confirming that the standardized bypass detection and indication logic has been applied. This determination is based on the plant-specific application that defines the signal connections, interdivisional interfaces, safety-nonsafety interfaces, and safety functions are associated with each safety division (see Section 4.2, Items 1, 12, 13, and 14).

3.7.2.1.3 Point 3 Point 3 establishes that a safety channel should not receive any communication from outside its own safety division unless that communication supports or enhances the performance of the safety function. However, if receipt of information from outside the division exists, then the applicant should justify it. Furthermore, the applicant should justify the receipt of information and inclusion of functions that do not support or enhance safety functions. These justifications should demonstrate that the added system/programming complexity does not significantly increase the likelihood of program specifications or implementation errors and should also define and justify the term significantly within the demonstration.

The ALS topical report, as amended by Reference 1, states that the ALS v2 platform design is kept as simple as possible and that its uses will include only functions related to the safety functions (see Reference 5, Table 5.4-1, DI&C-ISG-04 Item 3). Through this approach, the ALS v2 Topical Report commits to only use TxB1 and TxB2 on the ALS-152 Core Logic Board, the TAB, and the ALS-651 Communication Board to support or enhance a safety function.

Application specifications can include and justify digital data communication to support or enhance the performance of a safety function. The ALS v2 platform supports these types of digital data communications, which, if required, would need to be justified in individual application specifications.

When FPGA programming implements individual specifications, the ALS v2 platform programming process generates individual logic circuits for each specification. The logical behavior of the resulting circuits is autonomous, and the functions performed by one logic circuit do not take resources away from any other logic circuit. This behavior differs from microprocessor-based programming where memory and processor resources are shared among individually developed software programs. Therefore, the NRC staff determined that the addition of communication functions should not significantly increase the likelihood of program specifications or implementation errors when the same high quality process is applied for all FPGA programming requirements included within the ALS v2 platform because FPGA programming results in autonomous logic circuits and the generation of specification or programming errors primarily results from process quality rather than the function being specified and programmed. Conformance to portions of Point 3 is plant-specific because the required safety functions to be enhanced or supported by communication features and data are application-specific and programmed into the ALS-152 Core Logic Boards installed FPGA

((

)) based on application specifications and development efforts.

The TxB1 and TxB2 interfaces on the ALS-152 Core Logic Board meet Point 3 with respect to receiving communication from outside a safety division, because both are transmit-only interfaces that do not require handshaking. Therefore, neither can be used to receive inputs from outside of the safety division. FPGA logic resources that support this interface do not take resources away from logic circuits that perform safety functions, and the inclusion of TxB1 and

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION TxB2 on the ALS-152 Core Logic Board allows this interface to be serviced without impacting the safety signal path provided via the RAB. A PSAI is necessary to ensure that the application specifications adequately justify the use of the TxB1 and TxB2 to meet Point 3s exclusion of nonsafety functions within safety components regarding any significant increase in errors that could result from increased complexity of the ALS-152 Core Logic Boards programming.

The safety FPGA in each standardized circuit board supports the safety functions and the TAB interface, and this interface supports the bidirectional safety-nonsafety communication that is application-specific and requires request/response handshaking. The TAB interface supports meeting Point 3 with respect to receiving communication from outside a safety division, because the ALS v2 platform includes provisions for a physical hardware disconnection. Standardized functionality indicates that equipment has been bypassed while this interface remains active.

This standardized functionality has been developed as safety-related. FPGA logic resources that support this interface do not take resources away from logic circuits that perform safety functions, and the inclusion of the TAB on each standardized circuit board allows this interface to be serviced without impacting the safety signal path provided via the RAB. A PSAI is necessary to ensure that the application specifications adequately justify the use of the TAB to meet Point 3s exclusion of nonsafety functions within safety components regarding any significant increase in errors that could result from an increased complexity of the standardized circuit boards installed FPGA ((

)) programming.

Uses of the ALS-651 Communication Board do not impact its programming complexity, rather these uses impact the programming of the application-specific FPGA in the ALS-152 Core Logic Board. The ALS-651 Communication Board interfaces support meeting Point 3 because the ALS v2 Topical Report limits the use of its data receivers to interdivisional vote sharing. This application of the ALS-651 Communication Board provides vital communication paths that directly support a safety function to perform coincidence voting. A plant-specific review is necessary to ensure that application specifications adequately justify the use of the ALS-651 Communication Board interfaces to meet Point 3s exclusion of nonsafety functions within the safety components regarding any significant increase in errors that could result from an increased complexity of the ALS-152 Core Logic Boards programming.

The NRC staff determined that the ALS v2 platform communication components support meeting Point 3 because the communication has been generally described in support or enhancement of the performance of the safety function. The NRC staff further determined that PSAIs are necessary to ensure that the application specifications adequately justify each use of these interfaces regarding their support or enhancement of the application-specific safety functions. PSAIs should also demonstrate that the inclusion of any functionality that does not support or enhance a safety function will not add complexity that significantly increases the likelihood of program specification or implementation errors (see Section 4.2, Items 1, 12, 13, 14, and 21).

3.7.2.1.4 Point 4 Point 4 establishes that communication processes to support interdivisional communications (i.e., the transfer of data and any associated handshaking between a safety function processor and another channel or nonsafety equipment) should be carried out by a safety-related communications processor that is separate from the processor that executes the safety function, so communications errors and malfunctions will not interfere with the successful execution of

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION safety functions. Point 4 provides amplifying information that describes an acceptable implementation method, and this method uses shared memory resource, such as dual-ported random access memory (RAM). Point 4 further identifies the demonstration of safety function determinism with respect to the data exchange between the safety processor and the communication processor. The demonstration of safety function determinism should show that the safety function will: (1) be performed within the timeframe established in the safety analysis and (2) complete successfully without data from the communication process, including either a complete lack of access or any delays in obtaining access to a resource shared between the safety processor and the communication processor.

As discussed in Point 3, the ALS v2 platform specifies, implements, verifies, validates, and tests the communications and safety functions using safety-related processes. The resultant FPGA device contains communication logic circuits that are separate and unique from other safety function logic circuits. An FPGA installed in the ALS-152 Core Logic Board supports application-specific safety functions and the TxB1 and TxB2 interfaces, and similarly the FPGA in each standardized circuit board supports application-specific safety functions and the TAB interface.

Within the ALS v2 platform architecture, only the ALS-651 Communication Board is dedicated to communication processing and supports bidirectional communication with either safety or nonsafety equipment. The ALS-651 Communication Boards FPGA also supports the TAB interface.

The ALS v2 platform proposes an alternative method to addressing shared memory between distinct processing devices. This alternative method does not provide communication processors and safety processors that reside in physically distinct processing devices using a separate shared memory resource. Instead, this alternative method provides communication processing logic that is separate from the safety processing logic but resides in a common physical device, (i.e., ((

))).

In lieu of a separate shared memory resource, this alternative method uses the ALS v2 platform development processes to create buffers within each FPGA device that provide access priority to safety logic functions in order to ensure a deterministic completion of each safety function.

As discussed in Point 3, all of the ALS v2 platform logic circuits have been developed as safety-related, which meets Point 4s guidance that the safety function processors, communications processors, the data exchange memory resource, supporting circuits, and programming be developed as safety-related. The ALS topical report, as amended by Reference 1, states that the communication logic circuits do not interact with the safety function logic circuits within an FPGA device. Instead, the communication logic circuits non-intrusively monitor safety function logic circuits so a failure of the communication logic processing cannot adversely affect the performance of the safety function processing (see Reference 5, Table 5.4-1, DI&C-ISG-04, Item 4, and Section 5.3.2).

The NRC staff determined that the ALS v2 platform alternative method, which produces:

(1) communication processing logic circuits that are separate from safety processing logic circuits but reside in a common physical FPGA device and (2) communication buffers that give access priority to safety logic functions within each device, is an acceptable alternative to the implementation method provided in Point 4. The alternative method supports a deterministic completion of each safety function without adverse effect from the communication processing.

The NRC staff also determined that the ALS v2 platform standardized circuit boards support meeting Point 4 using this alternative method, because each has been developed as safety-

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION related and can be used to ensure the deterministic behavior of the safety functions. The NRC staff further determined that PSAIs are necessary to ensure that: (1) application specifications document the safety analysis that applies to its safety function determinism and (2) the application-specific implementation, V&V, and testing efforts demonstrate that these safety functions will be performed within the established safety design bases timeframes, including any lack of access or delays related to the communication activities (see Section 4.2, Items 1, 8, 12, 13, and 14).

3.7.2.1.5 Point 5 Point 5 establishes that the cycle time for the safety function processor should be determined in consideration of the longest possible completion time for each access to the shared memory and that failure of the system to meet the limiting cycle time should be detected and initiate an alarm.

As discussed in Point 4, the ALS v2 platform provides an alternative approach to shared memory access, wherein communication logic circuits non-intrusively monitor safety function logic circuits and communication activities cannot delay or otherwise adversely affect the performance of the safety functions. Additionally, the ALS topical report, as amended by Reference 1, states that the failures of the system to meet timing requirements will activate an alarm so corrective actions can be taken (see Reference 5, Table 5.4-1, DI&C-ISG-04, Item 5).

The ALS v2 platform addresses application-specific response times during each application-specific development, which should provide an application specification for the ALS-152 Core Logic Board that includes response time specifications. The ALS v2 platform architecture and its standardized circuit boards ((

)) provides features to ensure determinism by establishing expected response time performance variances. Although the platform communication architecture does not implement a shared memory resource, the application-specific ALS-152 Core Logic Board logic should meet Point 5 with respect to cycle-time performance, because the ALS-152 Core Logic Board determines the cycle-time for TxB1, TxB2, and ALS-651 Communication Board communications.

The NRC staff determined that the ALS v2 platform communication components support meeting Point 5 because the ALS v2 platform supports the detection and alarm logic in response to a systems failure to meet its application-specific limiting cycle time. The NRC staff further determined that PSAIs are necessary to ensure that the application specifications meet Point 5 with respect to the detection of and initiation of an alarm for cycle time performance in excess of the limiting cycle time (see Section 4.2, Items 1, 7, 12, 13, and 14).

3.7.2.1.6 Point 6 Point 6 establishes that a safety function processor should perform no communication handshaking and should not accept interrupts from outside its own safety division.

As discussed in Point 4, the ALS v2 platform provides an FPGA approach that implements communication logic circuits that non-intrusively monitor safety function logic circuits so that communication activities cannot delay or otherwise adversely affect the performance of the safety functions. Additionally, the ALS topical report, as amended by Reference 1, states that communication functions do not perform communication handshaking and do not accept any

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION interrupts from any communication devices (see Reference 5, Table 5.4-1, DI&C-ISG-04, Item 6).

The TxB1 and TxB2 interfaces on the ALS-152 Core Logic Board meet Point 6 because the communication logic circuits that provide this transmit-only protocol do not include handshaking and do not interrupt the safety function logic circuits within the ALS-152 Core Logic Boards installed FPGA.

The TAB interface meets Point 6, because the communication logic circuits that provide this bidirectional protocol neither handshake with nor interrupt the safety function logic circuits within each FPGA device.

The ALS-651 Communication Board meets Point 6 because the communication logic circuits that it provides do not include handshaking or interrupts. Furthermore, the communication activities of the ALS-651 Communication Board do not handshake or interrupt the safety functions performed by the ALS-152 Core Logic Board.

The NRC staff determined that the ALS v2 platform communication components meet Point 6 because the safety function logic circuits perform no communication handshaking and do not accept interrupts.

3.7.2.1.7 Point 7 Point 7 establishes that only predefined data sets should be used by the receiving system. It also provides amplifying information that states that unrecognized messages and data should be identified and dispositioned by the receiving system in accordance with the pre-specified design requirements and that data from unrecognized messages must not be used within the safety logic executed by the safety function processor. The pre-specified design requirements should establish the message format, such that each message has the same field structure and sequence, including message identification, status information, data bits, etc., in the same locations. The pre-specified design requirements should establish the message protocol that ensures the deterministic system behavior by including every datum in every transmit cycle without regard to whether it has changed since the previous transmission.

As discussed in Point 4, the ALS v2 platform provides an FPGA approach that implements the communication logic circuits that are separate and independent from the safety function logic circuits without regard to whether the circuits reside in the same FPGA device. Section 3.1.4.6 of this SE describes two digital data communication protocols, Byte Mode and Packet Mode, and for each communication protocol, all ALS v2 data is sent to each transmission cycle without regard to whether it has changed since the previous transmission. Additionally, the ALS topical report, as amended by Reference 1, states that a receiving ALS v2 instrument will validate the data and will only accept and use data that conforms to a pre-defined communication protocol and message format (see Reference 5, Table 5.4-1, DI&C-ISG-04, Item 7).

Point 7 does not directly apply to the TxB1 and TxB2 interfaces on the ALS-152 Core Logic Board, because these interfaces provide a transmit-only protocol. Therefore, TxB1 and TxB2 cannot be used by an ALS v2 platform-based safety instrument to receive data. The NRC staff recognizes, however, that Point 7 could indirectly apply. The ALS-152 Core Logic Boards application-specific FPGA can be programmed in such a way that allows a receiving safety

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION system to meet Point 7. The scope of the ALS topical report, as amended by Reference 1, does not include application-specific message definitions or identify specific safety system-to-safety system interfaces. As applicable, the NRC staff determined that PSAIs are necessary to ensure that the application specification for the ALS-152 Core Logic Boards installed FPGA ((

)) requires pre-defined messages in accordance with Point 7 when either TxB1 or TxB2 provides data to another safety system.

The TAB interface supports meeting Point 7; however, not all of Point 7 applies to the TAB interface. The ALS v2 platform includes features to indicate that an ALS v2 platform-based instrument is bypassed whenever communication over this interface has been connected. The ALS v2 platform derives this indication from monitoring a switch contact associated with the physical connection of the maintenance workstation and the detection of TAB activity. However, the ALS-152 Core Logic Boards application-specific FPGA may need to be programmed to meet application-specific maintenance activities in addition to standardized activities that are accounted for by pre-defined TAB messages for each standardized circuit board. The NRC staff determined that PSAIs are necessary to ensure that the application specification for the ALS-152 Core Logic Boards installed FPGA ((

)) provides any application-specific pre-defined messages necessary to meet Point 7.

The ALS-651 Communication Board supports meeting Point 7; however, the ALS-152 Core Logic Boards application-specific FPGA must be programmed to meet application-specific messaging needs when these interfaces are used. Therefore, the NRC staff determined that PSAIs are necessary to ensure that the application specification for the ALS-152 Core Logic Boards installed FPGA ((

)) provides pre-defined messages and a transmission cycle to meet Point 7 when the ALS-651 Communication Board interface is used.

The NRC staff determined that the ALS v2 platform communication components support meeting Point 7 because the ALS v2 platform supports application-specific message formats, protocols, and transmission cycles that conform to Point 7. The NRC staff further determined that PSAIs are necessary to ensure that application specifications adequately define all message formats, protocols, and transmission cycles (as applicable) to each use of these interfaces (see Section 4.2, Items 1, 12, 13, and 14).

3.7.2.1.8 Point 8 Point 8 establishes that the data exchanged between redundant safety divisions or between safety and nonsafety divisions should be processed in a manner that does not adversely affect the safety function of the sending divisions, the receiving divisions, or any other independent divisions.

As discussed in Point 4, the ALS v2 platform provides an FPGA approach that implements the communication logic circuits that are separate and independent from safety function logic circuits without regard to whether the circuits reside in the same FPGA device. Therefore, the NRC staff determined that transmit-only communications cannot adversely affect a safety function regardless of its location. As such, the NRC staff determined that Point 8 does not apply to the TxB1 and TxB2 interfaces of the ALS-152 Core Logic Board but does apply to the TAB interface and the ALS-651 Communication Board interfaces.

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION As discussed in Point 7, the ALS v2 platform supports bidirectional communication between safety and nonsafety division via the TAB interface on all standardized circuit boards. However, activation of the TAB interface places an ALS v2 platform-based instrument into bypass where it is no longer relied upon to perform its safety function (see Reference 5, Table 5.4-1, DI&C-ISG-04, Item 8). The ALS v2 platform also supports bidirectional communication among redundant safety divisions via the ALS-651 Communication Board, and the intended application of this board does not extend to the bidirectional communication between safety and nonsafety divisions. Taken together, the TAB and the ALS-651 Communication Board support bidirectional communication among redundant safety divisions and between safety and nonsafety divisions.

However, the ALS topical report, as amended by Reference 1, scope neither includes the application-specific system-to-system communication architecture nor the application-specific messages to support this architecture. Therefore, a PSAI is necessary to ensure that the application specification for the ALS-152 Core Logic Boards installed FPGA ((

))

demonstrates that the data exchanges associated with these interfaces meet Point 8.

The NRC staff determined that the ALS v2 platform communication components support meeting Point 8 because the ALS v2 platform supports an application-specific communication architecture for data exchanges that conforms to Point 8. The NRC staff further determined that a PSAI should verify that Point 8 is met by ensuring that the application specifications define:

(1) the administrative controls and design features that govern the use of the TAB interface for data exchanges between safety and nonsafety divisions and (2) the use of the ALS-651 Communication Board to exchange data among redundant safety divisions (see Section 4.2, Items 1, 13, and 14).

3.7.2.1.9 Point 9 Point 9 establishes that incoming message data should be placed in fixed and predetermined locations of the communication processor shared memory and function processor memory, which both contain memory locations dedicated to store incoming message data. These memory locations should segregate input data from output data, such as through placement into separate memory devices or in separate pre-specified physical areas of a single memory device.

As discussed in Point 4, the FPGA-based ALS v2 platform provides an alternative method to the shared memory between distinct processing devices. This alternative method does not provide communication processors and safety processors that reside in physically distinct processing devices using a separate shared memory resource. Instead, this alternative method provides communication processing logic circuits that are separate from the safety processing logic circuits but resides in a common physical device, ((

]. In lieu of a separate shared memory resource, this alternative method uses the ALS v2 platform development processes to create buffers that provide dedicated pre-specified physical areas within each FPGA to store incoming message data and to segregate input data from output data (see Reference 5, Table 5.4-1, DI&C-ISG-04, Item 9).

The NRC staff determined that the ALS v2 platform alternative method to that associated with Point 4 is an acceptable alternative to the guidance in Point 9 because the ALS v2 platform alternative method provides separate buffers within each FPGA device to store and segregate message data. As such, the NRC staff determined that the ALS v2 platform meets the intent of Point 9, as applicable to FPGA technology.

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION 3.7.2.1.10 Point 10 Point 10 establishes that safety division programs should be protected from alteration while the safety division is in operation. In other words, the safety division programs should be protected when the equipment is on-line and being relied upon to perform a safety function. Point 10 identifies two acceptable implementation options to protect programming from alteration, and these two options are: (1) hardware interlocks and (2) physical disconnection of the maintenance workstation. Point 10 also establishes that maintenance workstations capable of altering addressable constants, setpoints, parameters, and other settings can only do so when either (1) an interposing communication processor provides a shared-memory resource to exchange incoming and outgoing messages with the safety function processor in accordance with the entirety of the DI&C-ISG-04s Interdivisional Communication guidance or (2) when the associated channel is inoperable. When such a maintenance workstation is provided, Point 10 further establishes that the maintenance activities should be physically restricted to making changes to only one redundant safety division at a time, and this restriction should be accomplished by means of the physical disconnection being capable of interrupting the communication signal path to all safety channels except for the one undergoing maintenance changes. Although Point 10 establishes that this restriction be implemented in hardware circuits, it does not preclude program monitoring of the hardware circuits for other purposes.

The ALS topical report, as amended by Reference 1, summarizes the ALS v2 platform approach to meet Point 10 (see Reference 5, Table 5.4-1, Item 10). The summary states that the installed safety FPGA logic programs can only be modified using special tools available to the manufacturer, unavailable to the licensees, and only upon board removal. Nevertheless, certain parameters, such as setpoints, can be adjusted by the licensees during plant operations when either the equipment is bypassed, or its safety function is no longer required to be operable based on the current operating mode and conditions. Either a qualified safety or a nonsafety maintenance workstation will be used to perform the allowable operational adjustments.

Communications with the maintenance workstation are activated by a key lock switch that will initiate alarms at the ALS v2 chassis and in the control room. These adjustments will be performed in accordance with the plant operating procedures that govern the parameters adjustment, including any that establish the minimum number of redundant safety channels that must remain operable for the current operating mode and conditions.

Once an ALS v2 platform-based instrument has been programmed and delivered to a nuclear power plant as an application-specific system, none of the available digital data communication interfaces supports the alteration of the FPGA logic circuits or configuration settings that have been set to fixed values in order to meet the application specifications. Therefore, the NRC staff determined that the safety division FPGA logic (i.e., programs) is protected from alteration at all times.

The ALS v2 platform provides options to support different maintenance workstation configurations. However, the scope of the ALS topical report, as amended by Reference 1, does not include the maintenance workstation. The two options that the ALS v2 platform supports are (1) a safety qualified maintenance workstation integral to each safety equipment channel/division and (2) an external nonsafety maintenance workstation not integral to any safety equipment channel/division (see Reference 5, Section 5.3.3 and Figure 5.3-1). The ALS v2 platform does not support a multidivisional maintenance workstation that is

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION simultaneously connected to more than one safety channel/division, because the maintenance activities require the use of the TAB interface, and the TAB is a point-to-point connection that does not support simultaneous communication with multiple divisions (see Reference 5, Section 5.4.1.1).

Only the TAB interface can be used to operationally adjust addressable constants, setpoints, or parameters. The ALS v2 platform supports the inclusion of a physical disconnection, such as a key lock switch, to physically interrupt the TAB interface communication signal path between the maintenance workstation and the safety channel/division. Additionally, the ALS v2 platform provides design features (monitoring and indication capabilities) to alert operators when a safety channel/division is bypassed. These design features independently detect the key switch position, detect TAB interface activity, and provide associated local and remote alarm indications. These alarm indications can be used to identify when a maintenance workstation is connected so that operators can consider the affected channel to be inoperable. Based on this evaluation, the NRC staff determined that the program can be protected against inadvertent adjustment to addressable constants, setpoints, or parameters. The methods to connect/disconnect the TAB communication signal path between the maintenance workstation and a safety channel/division and to initiate an alarm for a connected condition to operators is application-specific. Therefore, to meet Point 10, a PSAI is necessary to ensure that application specifications include methods to interrupt the TAB communication signal path between the maintenance workstation and the safety channel/division and to initiate an alarm for the condition of a connected maintenance workstation. This PSAI should also ensure that these methods have been implemented.

As discussed in Point 4 and Point 9, the NRC staff determined that the ALS v2 platform alternative method, which produces: (1) communication processing logic circuits that are separate from safety processing logic circuits but reside in a common physical FPGA device and (2) communication buffers that give access priority to safety logic functions within each device, is an acceptable alternative to the implementation methods provided in Point 4, which identifies an interposing communication processor and shared-memory resource to exchange incoming and outgoing messages with a safety function processor, and Point 9, which identifies fixed, predetermined, and segregated locations for incoming and outgoing data exchanges within a shared memory.

Point 10 does not apply when maintenance workstations have been developed to meet safety-related equipment criteria and an individual maintenance workstation is associated with each safety division, because the applicability of DI&C-ISG-04 is limited to the communication interfaces between independent safety channels/divisions and between safety and nonsafety equipment. The ALS v2 platform: (1) supports the inclusion of a physical disconnection that interrupts the communication signal path from the maintenance workstation to individual safety channels/divisions; (2) provides an acceptable alternative method to the interface implementation discussed in Points 4 and 9; (3) provides features to ensure that a safety channel/division is identified as inoperable whenever a maintenance workstation is connected; and (4) does not support simultaneous use of a multidivisional maintenance workstation with redundant safety channels/divisions.

The NRC staff determined that the ALS v2 platform supports meeting Point 10, because the ALS v2 platforms maintenance communication architecture can be configured to conform to Point 10. The NRC staff determined that Point 10s provisions to physically restrict making

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION changes to only one redundant safety division at a time are met by the design of the TAB interface, which does not support the simultaneous connection of redundant safety divisions to a multidivisional maintenance workstation. The NRC staff further determined that the PSAIs should verify whether application specifications identify administrative controls and include additional design features (i.e., a safety-qualified hardware switch and detection and indication of bypass) to govern the use of the TAB interface for data exchanges with a nonsafety maintenance workstation, if applicable (see Section 4.2, Items 1 and 13).

3.7.2.1.11 Point 11 Point 11 establishes that provisions for interdivisional communication should explicitly preclude the ability to send software instructions to a safety function processor unless all safety functions associated with that processor are either bypassed or otherwise out-of-service. These provisions should prevent the progress of a safety function processor through its instruction sequence from being affected by any message from outside its division.

The ALS v2 platform does not contain conventional software instructions with either subroutines or branches. Instead, the ALS v2 platform contains configured hardware logic circuits that are contained in the FPGA. As discussed in Point 10, once an ALS v2 platform-based instrument has been programmed and delivered to a nuclear power plant as an application-specific system, none of the available digital data communication interfaces supports the alteration of the configured FPGA logic circuits. Information or messages received through the TAB interface or the ALS-651 Communication Board cannot be used to control the execution of the safety division application program (see Reference 5, Table 5.4-1, DI&C-ISG-04, Item 11). As further discussed in Point 10, the ALS v2 platform provides design features (monitoring and indication capabilities) to alert the operators when a safety channel/division is bypassed, and these design features are intended to detect and indicate when the interface that supports the maintenance workstation is either enabled or active.

The NRC staff determined that the ALS v2 platforms provisions for interdivisional communication meet Point 11, because these provisions explicitly preclude any ability to change the safety division logic circuits, which is the FPGA equivalent to conventional processor software. Furthermore, the NRC staff determined that available ALS v2 platform features can be used to ensure that an ALS v2 platform-based instrument has been bypassed or is otherwise out-of-service when maintenance workstation activities are active. The NRC staff further determined that PSAIs should verify whether application specifications include these additional design features (i.e., a qualified hardware switch and detection and indication of bypass) to govern the use of the TAB interface, as applicable to application-specific safety functions (see Section 4.2, Items 1 and 13).

3.7.2.1.12 Point 12 Point 12 establishes that faults associated with interdivisional communications should not adversely affect the performance of required safety functions in any way.

As discussed in Point 4, the ALS v2 platform provides an FPGA approach that implements communication logic circuits that are separate and independent from safety function logic circuits without regard to whether the circuits reside in the same FPGA device. The ALS v2 platform communication protocol and implementation checks, detects, and annunciates

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION communication failures. The ALS-152 Core Logic Boards application-specific FPGA must be programmed to meet application-specific communications and to maintain the status of the communications needed to ensure the performance of required safety functions (see Reference 5, Table 5.4-1, DI&C-ISG-04, Item 12).

The TxB1 and TxB2 interfaces on the ALS-152 Core Logic Board meet Point 12, because these interfaces provide a transmit-only protocol and the interfaces are supported by communication logic circuits that are separate from the safety function logic circuits.

The TAB interface on each standardized circuit board supports meeting Point 12, because these interfaces are only intended to be enabled when a safety channel/division is not being relied upon to perform its safety functions. As discussed in Point 10, the ALS v2 platform provides design features (monitoring and indication capabilities) to alert operators when a safety channel/division is bypassed, and these design features are intended to detect and indicate when the interface that supports the maintenance workstation is either enabled or active. PSAIs should verify whether application specifications identify administrative controls and include additional design features (i.e., a safety-qualified hardware switch and detection and indication of bypass) to govern the use of the TAB interface with a nonsafety maintenance workstation, if applicable.

The ALS-651 Communication Board supports meeting Point 12 for vital communications.

However, the ALS-152 Core Logic Boards application-specific FPGA must be programmed to meet application-specific safety functions when these interfaces are vital communications and relied upon to perform a safety function. The number of redundant safety channels/divisions and the overall communication architecture are also application specific. Therefore, a PSAI is necessary to ensure that the application specification for the ALS-152 Core Logic Boards installed FPGA ((

)) and the overall communication architecture are sufficient to ensure that the interdivisional vital communication failures do not adversely affect the performance of the required safety functions. Application-specific equipment specifications should identify the number of redundant safety channels/divisions, the overall communication architecture, and any fail-safe actions taken in response to interdivisional communication failures to ensure that a safety function will be performed when required to do so.

The ALS-651 Communication Board also supports meeting Point 12 for nonvital communications with a multidivisional display and control station (see Reference 5, Sections 5.4.1 and 5.4.1.1). PSAIs should be performed to verify that the application specifications include administrative controls and additional design features (i.e., a safety-qualified hardware switch and detection and indication of bypass) to govern this use of the interface.

The NRC staff determined that the ALS v2 platform communication components support meeting Point 12 because the ALS v2 platform supports an application-specific communication architecture to respond to communication faults without adversely affecting the performance of the required safety functions. The NRC staff further determined that PSAIs should verify that Point 12 is met by ensuring the application specifications define: (1) the administrative controls and design features that govern the use of the TAB interface for data exchanges between safety and nonsafety divisions, (2) the number of redundant safety channels/divisions, the overall communication architecture, and responses to communication failures that govern the use of the ALS-651 Communication Board for vital communications to ensure that the

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION application-specific safety functions will be performed, and (3) the administrative controls and design features that govern the use of the ALS-651 Communication Board for use with a multidivisional display and control station, if applicable (see Section 4.2, Items 1, 13, and 14).

3.7.2.1.13 Point 13 Point 13 establishes that vital interdivisional communications, such as the sharing of channel trip decisions for the purpose of voting, should include provisions to ensure that any received messages are correct and are correctly understood. The effectiveness of these provisions should be demonstrated and verified by testing. Point 13 further establishes that vital interdivisional communications should include provisions to handle corrupt, invalid, untimely, or otherwise questionable data. Any error detection or error correction processing should not adversely affect the operation of the safety function processor.

As discussed in Point 4, the ALS v2 platform provides an FPGA approach that implements communication logic circuits that are separate and independent from safety function logic circuits, so communication processing logic circuits that perform error detection will not adversely affect the operation of the safety function logic circuits. The ALS v2 platform implements only point-to-point UART communication protocols and these protocols include error detection logic circuits to ensure that any received messages are correct and are correctly understood. However, the protocol does not include error-correcting features. Furthermore, the ALS topical report, as amended by Reference 1, only describes vital interdivisional communications as being supported by the ALS-651 Communication Board. Therefore, the evaluation against Point 13 is only performed for the interfaces provided on the ALS-651 Communication Board (see Reference 5, Table 5.4-1, DI&C-ISG-04, Items 12, 13, and 14).

The ALS v2 platform communication protocol validates messages and detected failures, including both bit and byte serial transfer overruns and underruns. Methods to detect data corruption during transmission include the use of parity bits and/or cyclical redundancy check (CRC) message checksums. The protocol includes a feature for encoding messages and this feature ensures that the originator of any received message is correct. Use of this feature applies to messaging protocols that include the CRC checksum, is directly supported by the ALS v2 platforms restriction to use of a point-to-point communication architecture for all interdivisional communications and will result in the complete rejection of a message originating from an unexpected source. The transmit interval for messages is fixed, so the ALS v2 platform communication protocol supports the detection of untimely messages (too early or too late). The communications logic circuits detect and handle communication errors. As discussed in Point 4, the ALS v2 platform communication protocol and implementation checks, detects, and annunciates communication failures. However, the ALS-152 Core Logic Boards application-specific FPGA must be programmed to meet application-specific communications and to maintain the status of the communications needed to ensure the performance of any required safety function that depends on vital interdivisional communications. The effectiveness of these provisions will be verified by testing and documented as part of the EQ process.

The NRC staff determined that the ALS-651 Communication Board supports meeting Point 13 for vital interdivisional communications, because the ALS v2 platform communication protocol includes error detection and handling provisions that have been demonstrated during EQ testing. The NRC staff further determined that PSAIs should verify that Point 13 is met by ensuring that the application specifications define the protocol configuration, the messages

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION transmit interval, and the responses to any communication failures that govern the use of the ALS-651 Communication Board for vital communications to ensure that the integrity of application-specific safety functions are preserved (see Section 4.2, Items 1 and 14).

3.7.2.1.14 Point 14 Point 14 establishes that vital interdivisional communications should be point-to-point over a dedicated medium without intervening nodes between the transmitter and the receiver. Point 14 further establishes that alternative methods, if proposed, should be justified and demonstrated as providing equivalent reliability.

As discussed in Point 13, the ALS v2 platform only implements point-to-point UART communication protocols and these protocols require a dedicated medium. Furthermore, the ALS topical report, as amended by Reference 1, only describes vital interdivisional communications as being supported by the ALS-651 Communication Board. Therefore, the evaluation against Point 14 is only performed for the interfaces provided on the ALS-651 Communication Board (see Reference 5, Table 5.4-1, DI&C-ISG-04, Item 14).

The NRC staff determined that the provisions for vital interdivisional communications meet Point 14 because only point-to-point communications over a dedicated medium is proposed for and supported by the ALS v2 platform. The NRC staff further determined that PSAIs should verify that Point 14 remains met by ensuring that the application specifications define a point-to-point communication architecture that excludes intervening nodes between any transmitter-receiver pair used for vital interdivisional communications (see Section 4.2, Items 1 and 14).

3.7.2.1.15 Point 15 Point 15 establishes that vital interdivisional communications for safety functions should provide a fixed dataset at regular intervals whether data values in the set have changed or not. This fixed dataset should reflect the equipment state in support of equipment safety functions.

As discussed in Point 13, the ALS v2 platform UART communication protocols support the transmission of a pre-defined fixed dataset at prescribed intervals (see Reference 5, Table 5.4-1, DI&C-ISG-04, Item 15). As discussed within Section 3.1.4.7 of this SE, the content and format of the digital data communications are to be included in the application specifications for each system that uses a digital data communication channel. Furthermore, the ALS topical report, as amended by Reference 1, only describes vital interdivisional communications as being supported by the ALS-651 Communication Board. Therefore, the evaluation against Point 15 is only performed for the interfaces provided on the ALS-651 Communication Board.

The NRC staff determined that the provisions for vital interdivisional communications support meet Point 15 because the protocol can be used to transmit pre-defined fixed dataset at prescribed intervals and without regard to the data values. The NRC staff further determined that PSAIs should verify that Point 15 is met by ensuring that the application specifications identify the datasets required for vital communications for safety functions and identify the fixed transmission interval for these datasets in such a way that the values are transmitted without regard to whether any value has changed (see Section 4.2, Items 1 and 14).

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION 3.7.2.1.16 Point 16 Point 16 establishes that network connectivity, liveness, and real-time properties that are essential to the safety application should be verified in the protocol.

Point 16 is application-specific, because meeting Point 16 is dependent upon the safety functions of the application and the installed communication architecture. As discussed in Point 13, the ALS v2 platform UART communication protocols support the transmission of a pre-defined fixed dataset at prescribed intervals using a point-to-point architecture, which further supports the detection of untimely messages that occur too early, too late, or not at all (see Reference 5, Table 5.4-1, DI&C-ISG-04, Item 16). The ALS v2 platform communication protocols do not support network connectivity. As discussed within Section 3.1.4.7 of this SE, the content and format of the digital data communications are to be included in application specifications for each system that uses a digital data communication channel. Furthermore, the ALS topical report, as amended by Reference 1, only describes vital interdivisional communications as being supported by the ALS-651 Communication Board. Therefore, the evaluation against Point 16 is only performed for the interfaces provided on the ALS-651 Communication Board.

The NRC staff determined that the provisions for vital interdivisional communications support meet Point 16 because the protocol can be used to ensure the connectivity, liveness, and real-time properties of vital communication processes. The NRC staff further determined that PSAIs should verify that Point 16 is met by ensuring that the application specifications identify provisions to detect untimely messages and provide an indication of this type of communication failure to operators when it occurs (see Section 4.2, Items 1 and 14).

3.7.2.1.17 Point 17 Point 17 establishes that the medium used for vital interdivisional communications should be qualified for the anticipated normal and post-accident environments associated with its installation.

Point 17 is dependent upon the plant installation and the safety application because meeting Point 17 is dependent upon the environmental conditions of the installation within which the application-specific safety functions are required to remain available. Although the ALS v2 platform supports both copper and fiber-optic mediums, the scope of the ALS topical report, as amended by Reference 1, excludes the medium used for interdivisional communication and identifies this to be application-specific (see Reference 5, Table 5.4-1, DI&C-ISG-04, Item 17).

The ALS topical report, as amended by Reference 1, only describes the vital interdivisional communications as being supported by the ALS-651 Communication Board. Therefore, the evaluation against Point 17 is only performed for the interfaces provided on the ALS-651 Communication Board, even though the medium equally applies to other ALS v2 platform communications interfaces.

Based on this evaluation, the NRC staff determined that the ALS v2 platform supports meeting Point 17 because the ALS v2 platform was qualified for use in a mild environment, the ALS v2 platform supports copper and fiber-optic mediums, and both copper and fiber-optic mediums that have been qualified for a mild environment are available and in-use at nuclear power plants. The NRC staff further determined that a PSAI should verify that Point 17 is met by

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION ensuring that the application-specific medium has been qualified for the normal and post-accident environments associated with its installation when the application-specific safety functions are required to be available. A PSAI is necessary to ensure that the ALS v2 platform EQ envelope bounds the environmental conditions for the plant-specific installation (see Section 4.2, Item 14).

3.7.2.1.18 Point 18 Point 18 establishes that the provisions for communications should be analyzed for hazards and performance deficits posed by unneeded functionality and complexity.

Point 18 is dependent upon the plant safety application because the plants application establishes that potential hazards and plant-specific needs establish the required performance, the needed functionality, and the interdivisional communication architecture to support the needed functionality. As discussed within Section 3.1.4.7 of this SE, the application specifications for each use of a digital data communication channel must be analyzed and designed to meet plant and system hazard and performance specifications. This analysis will occur as part of the application-specific development process. This analysis will assess unneeded functionality and complexity to ensure that no hazards or performance deficits are produced from the inclusion of unneeded functionality or increases in complexity that result from including these functions (see Reference 5, Table 5.4-1, DI&C-ISG-04, Item 18).

The ALS v2 platform integrity characteristics to address the response time and determinism are discussed within Sections 3.4.1 and 3.4.2 of this SE, respectively. The ALS v2 platform characteristics for diagnostics and self-test capabilities and failure mode and effects analysis are discussed within Sections 3.4.3 and 3.5 of this SE, respectively. These characteristics, as evaluated, support a plant-specific hazards analysis and a plant-specific performance analysis.

Based on the evaluations in Sections 3.4.1, 3.4.2, 3.4.3, and 3.5 of this SE, the NRC staff determined that the ALS v2 platform supports meeting Point 18, because the ALS v2 platform supports the performance of plant-specific hazard and performance analyses in consideration of an applications specified functionality and inherent level of complexity. The NRC staff further determined that PSAIs should verify that Point 18 is met by ensuring that an application-specific analysis has been performed to assess the unneeded functionality and complexity. The results of this analysis should demonstrate that any resultant hazards or performance deficits have been addressed (see Section 4.2, Items 1, 12, 13, and 14).

3.7.2.1.19 Point 19 Point 19 establishes that all vital interdivisional communication links and nodes should have sufficient capacity to support the safety functions. Point 19 further establishes that the true data rate (including overhead) should be identified and ensure that the communication bandwidth is sufficient for the proper performance of all safety functions. The safety systems sensitivity to potential communication throughput issues should be confirmed by testing to demonstrate that each specified minimum communications throughput threshold associated with a safety function performance is reliably met.

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION Point 19 is dependent upon the plant safety application, because the plants application establishes the minimum communications throughput threshold for each vital interdivisional communication link and node required to reliably meet each application-specific safety functions limiting performance requirement. As discussed within Section 3.1.4.7 of this SE, the application specifications for the ALS-152 Core Logic Board must be analyzed, designed, and configured to meet each plant performance requirement, including those dependent on any digital data communication channel. This analysis will occur as part of the application-specific development process. This analysis will result in specified transmission rates and message transmission intervals to meet all plant performance requirements.

Application-specific V&V, as well as factory and system acceptance testing, will demonstrate that the plant-specific performance requirements have been met (see Reference 5, Table 5.4-1, DI&C-ISG-04, Item 19).

As discussed in Points 14 and 15, the ALS v2 platform communication architecture is point-to-point over a dedicated medium, and the UART communication protocols support the transmission of a pre-defined fixed dataset at prescribed intervals. Additionally, the clock circuit, from which the communication transmission rate is derived, can be monitored for the correct frequency. These platform characteristics produce a consistent and predictable communication load, which simplifies the analysis and testing to demonstrate adequate communication throughput. The communication protocols and architecture can be applied to eliminate widely varying or excessive communication loads like those that could result from using either a shared medium or communications that are not point-to-point. Furthermore, the ALS v2 platform integrity characteristics to address response time and determinism are discussed within Sections 3.4.1 and 3.4.2 of this SE3.4.2, respectively, and these characteristics, as evaluated, also simplify the plant-specific analysis and testing to demonstrate adequate communication throughput.

The NRC staff determined that the ALS v2 platform supports meeting Point 19, because the ALS v2 platform supports the specification, V&V, and testing of data communication capacities and throughput thresholds required for the proper performance of plant-specific safety functions.

The NRC staff further determined that PSAIs should verify that Point 19 is met by ensuring that an application-specific analysis has been performed to specify transmission rates and intervals that will meet all plant performance requirements. These PSAIs should document the expected communication loading and address any variations to demonstrate that the adequacy of the transmission rates and intervals will remain above the minimum threshold required for proper safety function performance. These PSAIs should also ensure that the application-specific V&V and factory and system acceptance testing confirm all plant-specific performance requirements dependent on digital data communications are met (see Section 4.2, Items 1, 7, 8, 12, 14, and 23).

3.7.2.1.20 Point 20 Point 20 establishes that the safety system response time calculations should assume a data error rate greater than or equal to a design basis error rate, which is supported by error rates observed during design and qualification testing.

Point 20 is dependent upon the plant safety application, because the plants application establishes the safety system response time requirement. As discussed within Section 3.1.4.7 of this SE, the application specifications for each use of a digital data communication channel

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION must be analyzed and designed to meet plant response time performance specifications. This analysis, and related response time calculations, will occur as part of the application-specific development process. These application-specific response time calculations will document a design basis data error rate and its relationship to the application-specific digital data communications configuration and use (see Reference 5, Table 5.4-1, DI&C-ISG-04, Item 20).

The design basis data error rates applied in application-specific response time calculations will be demonstrated as equally or more conservative than the corresponding data error rates observed during design and qualification testing. Although the communication protocol allows for a maximum number of consecutive unsuccessful transmissions before identifying a failure, the qualification testing should bound potential intermittent serial communications delays, which could impact response time, to a maximum based on the transmission intervals and an allowance for a maximum number of consecutive errors without declaring a failure. Future safety system response time calculations should consider the potential delay when determining the design basis error rate that has been observed in the qualification testing, and further consider the impact of potential additional delays based on the maximum number consecutive unsuccessful transmissions that the application allows before declaring a failure.

The ALS v2 platform integrity characteristics to address the response time and determinism are discussed within Sections 3.4.1 and 3.4.2 of this SE, respectively. These characteristics, as evaluated, support plant-specific safety system response time calculations to demonstrate adequate performance when data error rates remain within the qualified design basis.

The NRC staff determined that the ALS v2 platform supports meeting Point 20, because the ALS v2 platform supports the specification, V&V, and testing of the response time performance in the consideration of the design basis data error rates. The NRC staff further determined that PSAIs should verify that Point 20 is met by ensuring that the application-specific response time calculations have been performed that: (1) document applicable design basis data error rates, (2) demonstrate each safety functions response time requirement dependent on digital data communications is met in the presence of the applicable design basis data error rate, and (3) demonstrate each design basis error rate is equally or more conservative than the corresponding data error rate that was observed during design and qualification testing (see Section 4.2, Items 7, 12, and 14).

3.7.2.2 Staff Position 2 - Command Prioritization DI&C-ISG-04, Staff Position 2, Command Prioritization, establishes guidance governing a priority module. A priority module is a shared resource that is capable of receiving device actuation commands from multiple sources which may originate from different safety divisions and/or from both safety and nonsafety divisions, but that responds by only sending the command having the highest priority to the actuating device. Priority modules should be developed as safety-related devices for use with safety-related actuators.

The ALS v2 platform does not include a priority module within its standardized circuit board set and does not include priority module-type functionality within its standardized circuit boards.

Therefore, the ALS v2 platform design has not been developed or tested to meet the criteria of DI&C-ISG-04, Staff Position 2, to serve as a priority module (see Reference 5, Section 5.4.1, Table 5.4-2s discussions of Non-safety stations controlling the operation of safety-related equipment and of Safety-related stations controlling the operation of equipment in other safety-

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION related divisions). The ALS topical report, as amended by Reference 1, states that Points 1 through 10 under Staff Position 2 would be demonstrated on an application-specific basis during the development of an ALS v2 platform-based safety system when the command prioritization is specified for use (see Reference 5, Section 12.3).

The NRC staff determined that the ALS topical report, as amended by Reference 1, has not requested an evaluation of the ALS v2 platform against Staff Position 2, Command Prioritization. Therefore, this SE does not include an evaluation of suitability of the ALS v2 platform components for use as a priority module. The NRC staff further determined that PSAIs should either confirm that the ALS v2 platform-based safety system does not specify the use of command prioritization or demonstrates that Points 1 through 10 under Staff Position 2, Command Prioritization, are met when the command prioritization is specified for use (see Section 4.2, Items 1 and 15).

3.7.2.3 Staff Position 3 - Multidivisional Control and Display Stations DI&C-ISG-04, Staff Position 3, Multidivisional Control and Display Stations, establishes the guidance governing operator workstations used for the control of plant equipment in more than one safety division and for the display of information from sources in more than one safety division. This guidance also applies to the workstations to program, modify, monitor, or maintain safety systems that are not in the same safety division as the workstation.

The ALS topical report scope, as amended by Reference 1, does not include control and display stations (see Reference 5, Section 1.2). Therefore, the ALS v2 platform does not include consideration of either nonsafety stations controlling the operation of safety-related equipment or safety-related stations controlling the operation of equipment in another safety-related division (see Reference 5, Section 5.4.1).

The NRC staff determined that the ALS topical report, as amended by Reference 1, has not requested an evaluation of the ALS v2 platform against Staff Position 3, Multidivisional Control and Display Stations. Therefore, this SE does not include an evaluation of the suitability of either a Qualified Display System or an ALS Service Unit as a multidivisional control or multidivisional display station. The NRC staff further determined that PSAIs should either confirm that the ALS v2 platform-based safety system does not specify the use of either a multidivisional control or a multidivisional display station or demonstrates that Staff Position 3, Multidivisional Control and Display Stations, is met when either a multidivisional control or a multidivisional display station is specified for use (see Section 4.2, Items 1 and 16).

3.8 Diversity and Defense-in-Depth This section describes and evaluates the methods available to build diversity into the ALS v2 platform component designs. It also describes and evaluates the designs and principles of the operation of the ALS v2 platform-based systems. However, a demonstration of adequate diversity and D3 requires the context of a specific nuclear power plants overall D3 analysis to address the mitigation of plant-specific vulnerabilities. Therefore, this evaluation is limited to the specific built-in diversity design features of the ALS v2 platform and principles of operation, while considering the ALS v2 platform design and process attributes that either preclude or limit certain types of common-cause failures (CCFs).

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION Clause 5.1 of IEEE Std 603-1991 requires, in part, that safety systems shall perform all safety functions required for a design basis event in the presence of any single detectable failure within the safety systems concurrent with all identifiable but non-detectable failures.

The NRC Staff Requirements Memorandum on SECY-93-087, dated July 21, 1993 (ML003708056), describes the NRC staffs position on D3 requirements to compensate for common-cause programming failures. This requires an applicant or licensee to assess the D3 of the proposed I&C system, and if a postulated common-cause failure could disable a safety function, then a diverse means, with a documented basis that the diverse means is unlikely to be subject to the same common-mode failure, shall be required to perform either the same function or a different function.

Guidance on the evaluation of D3 is provided in SRP BTP 7-19, Revision 8. In addition, NUREG/CR-6303, Method for Performing Diversity and Defense-in-Depth Analyses of Reactor Protection Systems, dated December 1994 (ML071790509), summarizes several D3 analyses performed after 1990 and presents a method for performing such analyses.

NUREG/CR-7007, Diversity Strategies for Nuclear Power Plant Instrumentation and Control Systems, dated February 2010 (ML100880143), builds upon NUREG/CR-6303 and provides guidance to the NRC staff and the nuclear industry for use after an applicant or licensee has performed a D3 assessment per NUREG/CR-6303 and determined that some diversity in a safety system is needed to mitigate the consequences of potential CCFs identified through a prior evaluation of the safety system design features. NUREG/CR-7007 evaluates the characteristics and efficacy of diversity strategies that can be used to provide a technical basis for resolving D3 assessment findings and establishing conformance with NRC regulations.

The ALS topical report, as amended by Reference 1, identifies the intended applications of the ALS v2 platform in various diversity configurations to support different nuclear power plant systems. One example application provided includes a digital reactor trip system (RTS) and the engineered safety features actuation system (ESFAS) (see Reference 5, Appendix A).

A BTP 7-19 D3 evaluation should demonstrate that the plant vulnerabilities to CCFs have been adequately addressed in the context of an overall suite of plant I&C systems. Furthermore, the four-point position within BTP 7-19 was developed in recognition that programming design errors are credible sources of CCFs that apply to nuclear power plants that incorporate digital protection systems. BTP 7-19 provides guidance for the evaluation of the applicants or licensees D3 assessment, including the design of manual controls and displays to ensure conformance with the NRC positions on D3.

The NRC staffs evaluation of the ALS topical report, as amended by Reference 1, partially addresses BTP 7-19 Point 3. BTP 7-19 Point 3 provides, in part, that if a postulated common-cause failure could disable a safety function, a diverse means, with a documented basis that the diverse means is unlikely to be subject to the same common-cause failure, should be required to perform either the same function as the safety system function that is vulnerable to common-cause failure or a different function that provides adequate protection. The diverse or different function may be performed by a nonsafety system if the system is of sufficient quality to perform the necessary function under the associated event conditions.

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION manufacturer, and thus aids the claim of a different logic version being used in the platform.

The ALS v2 platform possesses architectural differences for logic processing to address some sources of systematic errors that may arise during the design and implementation of systems.

The NRC staff determined that the ALS v2 platform approach supports logic processing equipment diversity (see NUREG/CR-7007, Section 2.2.3.3), but it is not a primary contributor to overall platform diversity.

4) Functional ALS v2 Diversity Analysis; Functional Diversity (see Reference 18, Section 3.2.3)

The ALS v2 platform equipment supports the implementation of the functional diversity strategy. However, any functional diversity provided by an ALS v2 platform-based system would be based on application specifications.

The NRC staff determined that the ALS v2 platform can support overall instrumentation architectures that include functional diversity that implements different underlying mechanisms, different purpose, function, control logic, or actuation means, and/or different response time scales (see NUREG/CR-7007, Section 2.2.3.4). The NRC staff also determined that the ALS v2 platform itself does not provide functional diversity, because functional diversity requires specifications of different functions, which is application-specific and is not provided at the platform level.

Therefore, this SE cannot make a determination regarding the adequacy of application-specific functional diversity.

5) Life-cycle (Human)

The ALS v2 platform development approach uses a common development life cycle process using the same personnel for the development of logic in all components of the platform.

ALS v2 Diversity Analysis; Human Diversity (see Reference 18, Section 3.2.4.

The NRC staff determined that the ALS v2 platform does not provide a significant contribution to life-cycle diversity that produces differences in the susceptibility to CCF sources, when compared to the ALS development process.

The ALS v2 platform supports a degree of life-cycle diversity that is provided by the use of different teams for design and verification activities that include the use of diverse tools for the specific FPGA implementation activities when embedded design diversity is applied for safety-significant systems. This SE cannot make an adequacy determination of application-specific life-cycle diversity because the choice to require embedded design diversity and the methods for applying these techniques are application-specific.

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION

6) Logic (Software)

ALS v2 Diversity Analysis; Software Diversity (see Reference 18, Section 3.2.6)

Both the Core Diversity and Embedded Design Diversity strategies support logic diversity. The ALS v2 platform equipment also supports the implementation of logic diversity strategies. However, the overall logic diversity provided by an ALS v2 platform-based system to include different algorithms requires application specifications to identify the different algorithms to produce further logic diversity.

The NRC staff determined that the ALS v2 platform provides a level of logic diversity and can support further logic diversity, because: (1) the ALS v2 platform provides Core Diversity that produces different logic arrangements with corresponding differences in timing although the logic is derived from the same requirements, specifications, and code implementation and (2) Embedded Design Diversity produces additional differences in how a given algorithm is implemented, via ((

)) different tools, even though both implementations are based on the same top-level requirements (see NUREG/CR-7007, Section 2.2.3.6). Nevertheless, this SE cannot make an overall determination regarding the adequacy of the application-specific logic diversity, because the choice to require Embedded Design Diversity or alternative algorithm requirement specifications is application-specific and is not provided at the platform level.

7) Signal ALS v2 Diversity Analysis; Signal Diversity (see Reference 18, Section 3.2.5)

The ALS v2 platform equipment supports the implementation of the signal diversity strategy. However, any signal diversity provided by an ALS v2 platform-based system would be based on application specifications.

The NRC staff determined that the ALS v2 platform can support overall instrumentation architectures that include signal diversity implementing different reactor or process parameters sensed by different physical effects, different reactor or process parameters sensed by the same physical effect, and/or the same reactor or process parameter sensed by a different redundant set of similar sensors (see NUREG/CR-7007, Section 2.2.3.7).

The NRC staff also determined that the ALS v2 platform itself does not provide signal diversity, because signal diversity requires the specification of different signal inputs, which is application-specific and is not provided at the platform level. Therefore, this SE cannot make a determination regarding the adequacy of application-specific signal diversity.

To summarize Table 3.8-1 for the ALS v2 platforms diversity strategies in comparison to NUREG/CR-7007, the ALS v2 platform provides a baseline of design diversity, equipment manufacturer diversity, and logic diversity. However, the degree to which these approaches will be implemented depends on plant-specific vulnerabilities and resulting requirements and specifications. Furthermore, the ALS v2 platform provides support for functional diversity and signal diversity, both of which are application-specific and are not provided at the platform level (see Reference 18, Sections 3.2.3 and 3.2.5).

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION BTP 7-19 notes that functional and signal diversity are considered to be particularly effective.

These forms of diversity are not explicitly included within the ALS v2 platform level (i.e., not at the system level). However, nothing in the ALS topical report, as amended by Reference 1, or this SE precludes a plant from specifying either functional or signal diversity requirements for a safety system design. Similarly, nothing precludes a plant from specifying other equipment in addition to ALS v2 platform-based systems to provide diversity beyond the ALS v2 platform, such as design, equipment manufacturer, and logic processing equipment diversities. The scope of this SE is limited to the diversity provided within the ALS v2 platform.

Programming of an FPGA requires the use of FPGA-specific tools, and the ALS-152 Core Logic Board installed FPGA ((

)) are required to be application-specific. Post-programming testing efforts of the application-specific system are necessary to demonstrate the as-built ALS-152 Core Logic Board FPGA ((

] meet the criteria of BTP 7-19. However, these efforts do not fall under the ALS v2 Topical Report scope.

The application-specific board configurations and application-specific logic within the ALS-152 Core Logic Boards FPGA ((

)) are beyond the scope of the ALS topical report, as amended by Reference 1. This application-specific information, in part, defines equipment fail-safe behavior in response to detectable failures. Fail-safe equipment behavior is one method of providing internal design features to mitigate vulnerabilities to potential common-cause programming errors. However, appropriate use of these design features is based on application-level specifications. Furthermore, the ALS topical report, as amended by Reference 1, has not included an analysis that demonstrates that the coverage provided through continuous self-test functionality overlaps the entire safety function path for any application-specific systems.

If continuous self-test functionality is included by specification, then a subsequent analysis could demonstrate that sufficient V&V of continuous self-testing has been performed and the set of continuous self-tests covers the entirety of each application-specific safety function path. This analysis could demonstrate the continued ability to perform the safety function when no faults have been annunciated, because the continuous self-tests themselves would have been developed based on unique and independent requirements from the application-specific safety functions and result in individual FPGA logic circuits that are separate from the FPGA safety function logic circuits. Such an approach would require operators to periodically perform appropriate surveillance tests, which would need to be included within each plants technical specifications, to verify that the continuous self-test functions remain operable.

Table 12.7-1 in the ALS topical report, as amended by Reference 1, includes a matrix that maps DI&C-ISG-06 information requirements between ALS platform documentation and license amendment requests. However, the sections within DI&C-ISG-06 have been revised in Revision 2 of the ISG. However, as the topical report revision does not identify any changes to this mapping, there is no equivalent mapping to the ALS v2 documentation. Specifically, Utility D3 Analysis is identified under the LAR column to address DI&C-ISG-06, Section D.6.2 information requirements. The NRC staff notes that the D3 analysis now maps to DI&C-ISG-06, Section D.2.6.2.4. An applicants or licensees D3 analysis that cites DI&C-ISG-06 and any reference to BTP 7-19 must ensure that the mapping to the relevant guidance is accurate.

OFFICIAL USE ONLY - PROPRIETARY INFORMATION OFFICIAL USE ONLY - PROPRIETARY INFORMATION diversity is specified to be applied, identify any additional diversity strategies that the applicant or licensee includes in its design basis for ALS v2 platform-based equipment, identify the specified use of any platform features (e.g., continuous self-tests, fail-safe behavior, surveillances, etc.) that provide mitigations against CCFs, and identify any other equipment that is diverse from the ALS v2 platform that supports continued availability of a safety function. The applicants or licensees D3 analysis should either: (1) demonstrate that adequate diversity exists to mitigate plant vulnerabilities without the need for a diverse actuation system or (2) determine the need for a diverse actuation system to provide adequate mitigation against plant vulnerabilities. Consistent with this determination, the NRC staff has created a PSAI (see Section 4.2, Item 19), because important diversity strategies depend on the application specifications and the plants overall I&C system architectures.

3.9 Compliance to IEEE Std 603-1991 Equipment based on ALS v2 platform components is intended for use in safety systems and other safety-related applications. Therefore, the platform topical report was evaluated against its ability to support the application-specific system provisions of IEEE Std 603-1991. The NRC staffs evaluation is based on the guidance contained in SRP Chapter 7, Appendix 7.1-C, which provides acceptance criteria for this standard.

The following subsections contain the NRC staffs evaluation of the ALS v2 platform against the clauses of IEEE Std 603-1991 with further consideration that the scope of the ALS topical report, as amended by Reference 1, does not propose to meet all clauses via its components.

Because the NRC staffs evaluation is largely limited to a determination regarding whether the ALS v2 platform supports meeting the various clauses of IEEE Std 603-1991, a single PSAI has been created to address full compliance to each IEEE Std 603-1991 clause, which applies to each plant-specific and application-specific use of the ALS v2 platform (see Section 4.2, Item 20).

3.9.1 IEEE Std 603 Section 4 - Safety System Designation Section 4 of IEEE Std 603-1991 states that a specific basis shall be established and documented for the design of each safety system of the nuclear power generating station. The individual clauses under Section 4 require identification and documentation of specific design basis information.

The determination and documentation of the design basis for a safety system continues to be an application-specific activity dependent on the plant design, and the ALS topical report, as amended by Reference 1, acknowledges this (see Reference 5, Section 12.1.1). Therefore, the NRC staff did not evaluate the ALS v2 platform components against the requirements of Section 4 and instead, performed a limited evaluation of the ALS v2 platforms ability to support plant-specific and application-specific evaluations against Section 4 design basis information. This evaluation was limited to Section 4 design basis information that the platform directly supports.

Table 3.9-1 provides a cross-reference between clauses of IEEE Std 603-1991, Section 4 and sections within this SE. Each SE section identified in Table 3.9-1 contains corresponding PSAIs to demonstrate that the plant and application-specific design basis for a safety system has been bounded within the scope of this SE. If the plant or application-specific design basis for a safety

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 100 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION system has not been adequately bounded, then additional evaluations should be performed as further plant-specific actions.

Table 3.9-1, Cross-reference of IEEE Std 603-1991, Section 4 and SE Sections IEEE Std 603-1991, Section 4 SE Section Clause 4.7 Section 3.3, Equipment Qualification Clause 4.9 Section 3.6, Reliability and Availability Analysis Clause 4.12 Section 3.8, Diversity and Defense-in-Depth 3.9.2 IEEE Std 603 Section 5 - Safety System Criteria Section 5 of IEEE Std 603-1991 contains fifteen clauses that apply to all safety system functions and features. Through these clauses, Section 5 of IEEE Std 603-1991 requires that safety systems maintain plant parameters, with precision and reliability, within acceptable limits established for each design basis event. The power, instrumentation, and control portions of each safety system must be comprised of more than one safety group and any single safety group must be able to accomplish the safety function. The establishment of safety groups to accomplish a given safety function is a plant-specific and application-specific activity and the topical report scope does not include specific applications. Therefore, the following evaluations against the requirements of IEEE Std 603-1991, Section 5 are limited to the capabilities and characteristics of the ALS v2 platform that are relevant to meet each requirement.

3.9.2.1 Clause 5.1 - Single Failure Criterion Clause 5.1 of IEEE Std 603-1991 requires that safety systems be able to perform all safety functions required for a design basis event in the presence of: (1) any single detectable failure within the safety systems concurrent with all identifiable, but non-detectable, failures; (2) all failures caused by the single failure; and (3) all failures and spurious system actions that cause or are caused by the design basis event requiring the safety functions. SRP Chapter 7, Appendix 7.1-C, Section 5.1, Single Failure Criterion, provides acceptance criteria for the single failure criterion. In addition, RG 1.53 endorses IEEE Std 379-2000 as providing an acceptable method for meeting this requirement.

As described in the ALS Topical Report, as amended by Reference 1, the manufacturer has indicated that applicants and licensees will implement a configuration of redundant and independent ALS v2 platform components to meet the single failure criterion for any ALS v2 platform-based safety system (see Reference 5, Section 12.1.2). Consequently, the evaluation for conformance to this portion of the acceptance criteria remains for the plant-specific review.

The NRC staffs evaluation of the capabilities and characteristics of the ALS v2 platform that are relevant to the single failure criterion are documented in Section 3.4.3, Self-Diagnostics, Test, and Calibration Capabilities, and Section 3.5, Failure Mode and Effects Analysis, of this SE.

The Section 3.4.3 evaluation identifies plant-specific actions to demonstrate that the application-specific use of the ALS v2 platform diagnostic, self-test, and manually initiated test and calibration features are sufficient to verify the operational integrity of safety functions in a manner that supports meeting the single failure criterion. The Section 3.5 evaluation describes the board-level approach to identify failure modes and effects in support of plant-specific and application-specific activities to be performed at the system level and should include an

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 101 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION assessment of the complete system design. Section 3.5 also includes plant-specific actions to perform a system-level FMEA to demonstrate that: (1) the application-specific use of the ALS v2 platform identifies each potential failure mode and determines the effects of each and (2) single-failures, including those with the potential to cause a nonsafety system action (i.e., a control function) that results in a condition requiring protective action (i.e., a protection function), cannot adversely affect the protection functions.

3.9.2.2 Clause 5.2 - Completion of Protective Action Clause 5.2 of IEEE Std 603-1991 states that the safety systems shall be designed so, once initiated automatically or manually, the intended sequence of protective actions of the execute features shall continue until completion and deliberate operator action shall be required to return the safety systems to normal. SRP Chapter 7, Appendix 7.1-C, Section 5.2, Completion of Protective Action, provides acceptance criteria for this requirement.

The ALS topical report, as amended by Reference 1, states that the requirement to complete a protective action requires verification on an application-specific basis (see Reference 5, Section 12.1.3). Consequently, the evaluation for conformance to this portion of the acceptance criteria remains for a plant-specific review.

Determination that protective actions of the execute features of a safety system continue to completion after initiation and require a deliberate operator action thereafter to restore to normal are plant-specific and application-specific activities, and the topical report scope does not include specific applications to implement execute features for a specific safety system.

Therefore, the evaluation against the requirements of IEEE Std 603-1991, Clause 5.2 is not addressed by this SE. Application-specific logic must be specified and programmed into the ALS-152 Core Logic Board and should be verified by plant-specific and application-specific activities (see Section 4.2, Item 20).

3.9.2.3 Clause 5.3 - Quality Clause 5.3 of IEEE Std 603-1991 states that the components and modules within the safety system must be of a quality that is consistent with minimum maintenance requirements and low failure rates, and that safety system equipment be designed, manufactured, inspected, installed, tested, operated, and maintained in accordance with a prescribed QA program. SRP Chapter 7, Appendix 7.1-C, Section 5.3, Quality, provides acceptance criteria for the quality requirement.

These acceptance criteria state that the QA provisions of 10 CFR Part 50, Appendix B, apply to a safety system.

The ALS v2 platform, which consists of standardized circuit boards and FPGA programs, was developed specifically for use in nuclear power plants. The platform development activities are performed in accordance with the WEC quality management system.

Section 3.2 of this SE provides the NRC staffs evaluation of the manufacturers development processes, wherein the NRC staff determined that the ALS v2 platforms hardware and FPGA logic program components will have been designed and developed with a sufficient quality process and in a manner suitable for use in safety-related applications at nuclear power plants, should the manufacturer follow the processes described in Reference 1 and evaluated in Section 3.2. Additionally, Subsection 3.10.2.3 of this SE provides additional NRC staff

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 102 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION evaluations that address aspects of IEEE Std 7-4.3.2-2003, Clause 5.3, Quality, as applicable to the ALS v2 platforms development and FPGA logic programs.

Based on the NRC staffs assessment that the WEC Quality Management System meets the requirements of Appendix B to 10 CFR Part 50, and the regulatory requirement that licensees remain responsible for the vendor quality through the performance of licensee audits for the ALS v2 platform-based systems, the NRC staff concludes that ALS v2 platform components should be treated as basic components produced by an Appendix B supplier. The NRC staff determined that the conformance with IEEE Std 603-1991, Clause 5.3 remains an application-specific activity that should take into consideration the applicants or licensees Appendix B program and the activities of inspection, installation, pre-operational testing, operation, and maintenance, because these activities are outside the scope of the ALS topical report, as amended by Reference 1, and would occur at a licensed facility.

3.9.2.4 Clause 5.4 - Equipment Qualification Clause 5.4 of IEEE Std 603-1991 states that the safety system equipment must be qualified by type test, previous operating experience, or analysis, or any combination of these three methods, to substantiate that it will be capable of meeting the performance requirements as specified in the design basis. SRP Chapter 7, Appendix 7.1-C, Section 5.4, Equipment Qualification, provides the acceptance criteria for IEEE Std 603-1991 Clause 5.4. These acceptance criteria state that an applicant or licensee should confirm that the safety system equipment is designed to meet the functional performance requirements over the range of normal environmental conditions for the area in which it is located. This clause of IEEE Std 603-1991 also states that the qualification of Class 1E equipment should be in accordance with the requirements of IEEE Std 323-1983 and IEEE Std 627-1980, IEEE Standard for Design Qualification of Safety Systems Equipment Used in Nuclear Power Generating Stations.

RG 1.209 endorses and provides the guidance for compliance with IEEE Std 323-2003 for the qualification of safety-related computer-based I&C systems installed in mild environment locations.

The NRC staffs evaluation of the ALS v2 platform EQ is documented in Section 3.3, Equipment Qualification of this SE. This evaluation identifies plant-specific actions to demonstrate that the ALS v2 platform performance, as bounded by its EQ, meets the requirements of the plant-specific installation environment for the plant-specific and application-specific safety functions in accordance with the ALS topical report, as amended by Reference 1, (see Reference 5, Section 12.1.5).

The NRC staffs evaluation provided in Section 3.3 of this SE determined that the ALS v2 platform EQ plans provide a type test and supporting analyses methodology that can be used to support the establishment of documented platform safety functions, a range of installation conditions, and installation limitations for the ALS v2 platform that are suitable for reference by applicants and licensees and to conform to RG 1.209s endorsement of IEEE Std 323-2003 for the qualification of safety-related computer-based I&C systems installed in mild environment locations.

The NRC staff further determined that the ALS v2 platform EQ meets IEEE Std 603-1991, Clause 5.4, for the plant-specific use of the seven standardized printed circuit cards, backplane, and chassis, which are included within the ALS v2 platform scope, after a referencing applicant

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 103 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION or licensee adequately addresses the plant-specific actions associated with confirming that the application and installation have been bounded by the ALS v2 platform EQ, including each boundary/interface condition, installation limitation, and related application guidance.

3.9.2.5 Clause 5.5 - System Integrity Clause 5.5 of IEEE Std 603-1991 states that each safety system design must remain capable of accomplishing its safety functions under the full range of the applicable conditions enumerated in the design basis. SRP Chapter 7, Appendix 7.1-C, Section 5.5, System Integrity, provides the acceptance criteria for system integrity. This guidance on acceptance criteria states that the NRC staff should confirm that tests have been conducted on safety system equipment components and the system racks and panels as a whole to demonstrate that the safety system performance is adequate to ensure the completion of protective actions over the range of transient and steady state conditions of both the energy supply and the environment.

Furthermore, the NRC staff should confirm that the tests show that if the system does fail, it fails in a safe state. Also, the NRC staff should verify that any failures detected by self-diagnostics are specified to place a protective function into a safe state. Finally, the confirmation that system real-time performance is adequate to ensure that the completion of protective actions within critical time frames is identified as a special concern for digital computer-based systems.

The ALS topical report, as amended by Reference 1, states that application-specific system level requirements are necessary to define a safe state and the conditions that are required to enter a fail-safe state. As described in the ALS v2 Topical Report, the manufacturer has indicated that applicants and licensees will identify specific system level failure modes, methods of detection, and system responses and document these characteristics in an application specific FMEA (see Reference 5, Section 12.1.6).

Therefore, the determination of the system integrity is an application-specific activity that requires an assessment of a full system design. A platform-level assessment can only address the integrity characteristics to support fulfillment of this requirement by a system design based on the platform. The platforms evaluation against this requirement is limited to the consideration of the integrity demonstrated by the platform and its features to allow a safe state to be reached in the presence of failures, because the ALS topical report, as amended by Reference 1, does not address a specific application or establish a definitive safety system design. Although the evaluation indicates the suitability of the platform to contribute to meeting this requirement, a plant-specific evaluation is necessary to establish full conformance with Clause 5.5.

As discussed in Section 3.3 of this SE, the ALS v2 platform will undergo equipment type testing to demonstrate the qualification for the installation in mild environment locations in nuclear power plants. Upon an applicants or licensees demonstration that the equipments boundary/interface conditions, installations limitations, and application guidance, as discussed in Section 3.3 and delineated in Section 4.2 of this SE, have been addressed, the ALS v2 platform qualification program will provide reasonable assurance that the safety systems based on the ALS v2 platform will be capable of performing safety functions over the full range of the environmental stressors defined by the qualification envelope for the ALS v2 platform.

Section 3.5 of this SE describes the steps taken thus far by the manufacturer to perform a FMEA for each of the seven ALS v2 platform standardized circuit boards. An assessment of the

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 104 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION application specifications for a full system design is necessary to demonstrate the fulfillment of the requirement to fail in a safe state, when applicable.

The evaluation of the response time and deterministic performance is discussed in Sections 3.4.1 and 3.4.2 of this SE. The ALS v2 platform demonstrates the credible response time characteristics and supports definition and demonstration of minimum and maximum response time performance to meet safety system performance and determinism requirements.

Therefore, the ALS v2 platforms response time and determinism meet the criteria of this clause at the platform level and are suitable to support safety applications. The actual response times for particular safety functions are application-specific, and the acceptable performance depends on the overall system design, architecture, and required plant safety functions. Therefore, a PSAI is identified to confirm the suitability of the response time characteristics of the ALS v2 platform for a particular safety function implementation and to demonstrate acceptable relevant response times. Consequently, the evaluation for full conformance against this portion of the acceptance criteria remains for a plant-specific review.

Based on the review items discussed above, the NRC staff concludes that the integrity characteristics (e.g., response time, deterministic performance, failure detection and response, fault tolerance, environmental withstand) of the ALS v2 platform, when appropriately implemented for a plant-specific application, are suitable for safety applications at nuclear power plants and meet Clause 5.5 at the platform level.

3.9.2.6 Clause 5.6 - Independence Clause 5.6 of IEEE Std 603-1991 requires, in part, the independence between: (1) redundant portions of a safety system, (2) safety systems and the effects of design basis events, and (3) safety systems and other systems. SRP Chapter 7, Appendix 7.1-C, Section 5.6, Independence, provides acceptance criteria for system integrity. These acceptance criteria state that the three aspects of independence, (1) physical independence, (2) electrical independence, and (3) communications independence, should be addressed for each of the previously listed cases. Guidance for the evaluation of physical and electrical independence is provided in RG 1.75, Revision 3, which endorses IEEE Std 384-1992, Criteria for Independence of Class 1E Equipment and Circuits. The safety system design should not have components that are common to the redundant portions of the safety system, such as common switches for actuation, reset, mode, or test; common sensing lines; or any other features that could compromise the independence of redundant portions of the safety system. The physical independence is attained by physical separation and physical barriers. The electrical independence should include the use of separate power sources. The transmission of signals between independent channels should be through isolation devices.

SRP Chapter 7, Appendix 7.1-C, Section 5.6, Independence, provides additional acceptance criteria for communications independence. Section 5.6 states that where data communication exists between different portions of a safety system, the analysis should confirm that a logical or software malfunction in one portion cannot affect the safety functions of the redundant portions, and if a digital computer system used in a safety system is connected to a digital computer system used in a nonsafety system, a logical or software malfunction of the nonsafety system must not be able to affect the functions of the safety system.

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 105 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION SRP Chapter 7, BTP 7-11, Guidance on Application and Qualification of Isolation Devices, provides guidelines for reviewing the use of electrical isolation devices to allow connections between redundant portions of safety systems or between safety and nonsafety systems.

The ALS topical report, as amended by Reference 1, states that the specific redundancy needed for an ALS v2-based system is intended to be defined at the system level during the actual plant implementation (see Reference 5, Section 12.1.7). Therefore, the determination of independence is an application-specific activity that requires an assessment of a full system design. A platform-level assessment can only address independence characteristics to support the fulfillment of this requirement by a system design based on the platform. The platforms evaluation against this requirement is limited to the consideration of the digital communications evaluated in Section 3.7 of this SE, because the ALS topical report, as amended by Reference 1, does not address a specific application or establish a definitive safety system design. Although the evaluation indicates the suitability of the platform to contribute to meeting this requirement, a plant-specific evaluation is necessary to establish full conformance with Clause 5.6.

Although the ALS v2 platform supports the use of unique components within different redundant portions of a safety system, application-specific activities should assess the full system design to ensure that different redundant portions of a safety system do not rely on a common component. This assessment should provide reasonable assurance that the safety system will retain the capability to accomplish the safety function due to the loss or failure of any common component.

Although the ALS v2 platform supports an installation that physically separates the redundant portions of the safety equipment from one another and that physically separates the safety system from other equipment, application-specific activities should assess the full system design and installation to ensure adequate separation and physical barriers exist between different redundant portions of a safety system and between the safety system and other equipment. This assessment should provide reasonable assurance that the safety system will retain the capability to accomplish the safety function in the presence of any single-failure and in the presence of each design basis event, including its environmental effects.

Although the ALS v2 platform supports an installation that provides separate and independent electrical power sources to redundant portions of the safety equipment, application-specific activities should assess the full system design and power distribution architecture to ensure that the independent electrical power sources are provided to the redundant portions of the safety equipment. This assessment should provide reasonable assurance that the safety system will retain the capability to accomplish the safety function in the presence of any single loss of an electrical power source.

The isolation provided on the ALS v2 platform circuit boards is limited to that which is required for electromagnetic compatibility and circuit reliability. However, the board level provisions are not intended to ensure that sufficient isolation exists between the ALS v2 platform-based Class 1E equipment and non-Class 1E equipment. The ALS topical report states that the demonstration that the isolation criterion is met will be performed as part of a plant-specific application and the qualified isolation devices will be used when required by the application (see Reference 5, Sections 2.5.7, 5, and 12.1.7.3). As such, a PSAI results from this exclusion (see Section 4.2, Item 21).

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 106 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION The NRC staff determined that the conformance with IEEE Std 603-1991, Clause 5.6 remains an application-specific activity that should take into consideration the full system design, any use of a shared component, the equipments installation, and the power distribution architecture.

When considering the use of a shared component or the power distribution architecture, the application-specific activities of the full system design should take into further consideration the digital communications evaluation in Section 3.7 of this SE, and the requirement to include isolation devices, because the isolation device requirement has been excluded from the scope of the ALS topical report, as amended by Reference 1.

3.9.2.6.1 Clause 5.6.1 - Independence between Redundant Portions of a Safety System The ALS topical report, as amended by Reference 1, states that the specific redundancy needed for an ALS v2 system is intended to be defined at the system level during the actual plant implementation to accomplish the safety function during and following any design basis event requiring that safety function. As described in the ALS topical report, as amended by Reference 1, the manufacturer has indicated that applicants and licensees will establish requirements for any communications between otherwise redundant portions of a safety system, any use of common components among redundant portions of a safety system, the maintenance of physical separation between redundant portions of safety systems and between the safety system and other equipment, and the maintenance of electrical independence between redundant portions of a safety system (see Reference 5, Sections 12.1.7 and 12.1.7.1).

Based on the use described for the ALS v2 platform and the design features provided by its standardized circuit boards, the NRC staff determined that the ALS v2 platform supports the use of unique components within different redundant portions of a safety system, so a safety system can be constructed with independent and physically separate redundant portions capable of accomplishing the safety function during plant-specific design basis events that require that safety function.

3.9.2.6.2 Clause 5.6.2 - Independence of Effects of Design Basis Event The ALS topical report, as amended by Reference 1, states that the ALS v2 platform is intended for installation in a mild environment (see Reference 5, Sections 4 and 12.1.7.2).

Section 50.49(c) of 10 CFR Part 50 defines a mild environment as one that would at no time be significantly more severe than the environment that would occur during normal plant operation, including anticipated operational occurrences. The ALS v2 platform will need to be qualified to an established bounding envelope for its installed operating environment, and this EQ is discussed and evaluated in Section 3.3 of this SE.

Based on the installation of the ALS v2 platform equipment in a mild environment that is bounded by the EQ discussed and evaluated in Section 3.3 of this SE, the NRC staff determined that the ALS v2 platform supports meeting IEEE Std 603-1991, Clause 5.6.2.

3.9.2.6.3 Clause 5.6.3 - Independence between Safety Systems and Other Systems Evaluation of this Clause requires the identification of credible failures in and consequential actions by other systems as documented in the applicants or licensees plant-specific design

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 107 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION basis. The ALS v2 platform provides digital communication design features to support the independence between an ALS v2-based safety system and other interfacing systems, which are discussed and evaluated in Section 3.7 of this SE. The ALS v2 platform also supports the classification of interconnected equipment. However, the demonstration that adequately qualified isolation devices have been used where required should be performed as part of the plant-specific application of the ALS v2 platform. Therefore, no additional NRC staff determinations are made for the ALS v2 platform to address IEEE Std 603-1991, Clause 5.6.3.

3.9.2.7 Clause 5.7 - Capability for Test and Calibration The ALS topical report, as amended by Reference 1, does not address a specific application or establish a definitive safety system design. The determination of the test and calibration requirements that must be fulfilled depends upon the plant-specific safety requirements (e.g.,

accuracy, response time, etc.) that apply. The establishment of the types of surveillance that is necessary for the safety system to ensure the detection of identifiable single failures only revealed through testing, is also an application-specific activity. For these reasons, this SE is limited to the consideration of the means provided within the platform to enable testing and calibration for a redundant portion of a safety system (i.e., a division). Section 3.4.3 of this SE discusses the ALS v2 platforms ability to support meeting IEEE Std 603-1991, Clause 5.7 and identifies plant-specific actions to ensure that IEEE Std 603-1991, Clause 5.7 will be met.

3.9.2.8 Clause 5.8 - Information Displays The following four subclauses of Clause 5.8 of IEEE Std 603-1991 apply to information displays associated with safety systems.

3.9.2.8.1 Clause 5.8.1 - Displays for Manually Controlled Actions Clause 5.8.1 of IEEE Std 603-1991 requires unambiguous display instrumentation to be part of the safety systems and to minimize the possibility of operator confusion wherever manually controlled actions are required for a safety system to accomplish its safety function and no automatic control is provided.

The ALS topical report, as amended by Reference 1, states that the display instrumentation provided for manually controlled safety actions is an application-specific system level requirement and that the ALS v2 platform does not include a display instrumentation for manually controlled actions. The ALS topical report provides a description of the ALS v2 standardized circuit board capabilities to receive manual demand signals, perform the required safety actions, and drive analog or digital displays associated with the manually controlled action (see Reference 5, Section 12.1.9.1).

The NRC staffs review of the design features provided by ALS v2 platform standardized circuit boards is addressed in Section 3.1 of this SE.

Although the ALS v2 platform does not include display instrumentation or directly display information beyond the discrete front panel status indicators, the NRC staff determined that the ALS v2 platform supports meeting IEEE Std 603-1991, Clause 5.8.1. This determination is based on the use described for the ALS v2 platform and the design features provided by its standardized circuit boards. Nevertheless, a plant-specific action is necessary when the ALS v2

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 108 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION platform supports the use of display instrumentation that is provided to support manually controlled safety actions necessary to accomplish a safety function for which no automatic control is provided. This plant-specific action should ensure that the supporting ALS v2 components and display instrumentation will be functional during plant conditions under which manual actions may be necessary.

3.9.2.8.2 Clause 5.8.2 - System Status Indication Clause 5.8.2 of IEEE Std 603-1991 requires unambiguous display instrumentation, which need not be part of the safety system, to minimize the possibility of operator confusion and to provide accurate, complete, and timely information pertinent to a safety systems status, including the indication and identification of protective actions.

The ALS topical report, as amended by Reference 1, states that the display instrumentation provided for the safety systems status is an application-specific system level requirement and that the ALS v2 platform does not include the remote display instrumentation for safety systems status. The ALS topical report also describes the ALS v2 platform standardized circuit board capabilities to perform the protective actions and to provide status both locally via discrete front panel indicators and remotely to display instrumentation (see Reference 5, Section 12.1.9.2).

The NRC staffs review of each ALS v2 platform standardized circuit boards design features is addressed in Section 3.1 of this SE.

Although the ALS v2 platform does not include display instrumentation or directly display information beyond the discrete front panel status indicators, the NRC staff determined that the ALS v2 platform supports meeting IEEE Std 603-1991, Clause 5.8.2. This determination is based on the use described for the ALS v2 platform and the design features provided by its standardized circuit boards. Nevertheless, a plant-specific action is necessary when the ALS v2 platform supports the use of the display instrumentation to provide the indication and identification of protective actions as part of a safety systems status. This plant-specific action should ensure that the supporting ALS v2 components and the display instrumentation provide unambiguous, accurate, complete, and timely status of the safety system protective actions.

3.9.2.8.3 Clause 5.8.3 - Indication of Bypasses Clause 5.8.3 of IEEE Std 603-1991 requires the display instrumentation in the control room, which need not be part of the safety system, to continue to indicate whether the protective actions of some part of a safety system have been bypassed or deliberately rendered inoperable (excluding an operating bypass) for each affected safety group. Indicated bypasses are required to be automatically actuated if the bypass or inoperable condition will occur more frequently than once a year and when the affected system is required to be operable. The control room shall provide the capability to manually activate the bypass indication.

The ALS topical report, as amended by Reference 1, states that the display instrumentation provided for safety systems status is an application-specific system level requirement and that the ALS v2 platform does not include a remote display instrumentation for safety systems status. The ALS topical report describes the ALS v2 platform standardized circuit board capabilities to provide an indication of a bypass for plant and application-specific protective actions and to provide an indication of a bypass both locally via the discrete front panel

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 109 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION indicators and remotely to display instrumentation. The ALS v2 platform supports the automatic actuation of the bypass or inoperable condition of a safety group when the maintenance workstation is actively communicating to it. Additionally, capabilities achieved through application-specific configurations allow for individual protective actions to be manually placed into a bypass, which can then activate the bypass indication (see Reference 5, Section 12.1.9.3). The ALS topical report (Reference 5) continues to describe the platforms maintenance features, which address the behavior of a bypass and the inoperable status indications (see Reference 5, Section 3).

The NRC staffs review of the design features provided by the ALS v2 platform standardized circuit boards is addressed in Section 3.1 of this SE. The NRC staff reviewed the features and intended operation in support of the safety system bypass and the inoperable status indications for conformance with the guidance of RG 1.47.

Although the ALS v2 platform does not include the display instrumentation or directly display the information beyond the discrete front panel status indicators, the NRC staff determined that the ALS v2 platform supports meeting the requirements in IEEE Std 603-1991, Clause 5.8.3. This determination is based on the use described for the ALS v2 platform and the design features provided by its standardized circuit boards. Nevertheless, a plant-specific action is necessary when the ALS v2 platform supports the use of the display instrumentation to provide the indication of bypassed or inoperable protective actions. This plant-specific action should ensure that the supporting ALS v2 components and the display instrumentation automatically actuate the bypass indication for bypassed or inoperable conditions, when required, and provide the capability to manually activate the bypass indication from within the control room.

3.9.2.8.4 Clause 5.8.4 - Location Clause 5.8.4 of IEEE Std 603-1991 requires information displays to be located accessible to the operator and visible from the location of the controls used to affect manually controlled protective actions.

The ALS topical report, as amended by Reference 1, states that the location of the displays is an application-specific system level requirement and that the ALS v2 platform does not include remote display instrumentation (see Reference 5, Section 12.1.9.4). The topical report also discusses the ALS v2 platform standardized circuit board capabilities to locally monitor protective action states via the discrete front panel indicators and initiate the manually controlled protective actions via the front panel toggle switches.

The NRC staffs review of the design features provided by the ALS v2 platform standardized circuit boards is addressed in Section 3.1 of this SE.

The NRC staff agrees that the evaluation of this clause is plant-specific and application-specific.

Therefore, no NRC staff determinations are made for the ALS v2 platform to address IEEE Std 603-1991, Clause 5.8.4. A plant-specific action is necessary to ensure that the information displays are located accessible to the operator and visible from the location of any controls used to affect a manually controlled protective action provided by the front panel controls of the ALS v2-based system.

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 110 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION 3.9.2.9 Clause 5.9 - Control of Access Clause 5.9 of IEEE Std 603-1991 requires the capability to administratively control access to the safety system equipment via supporting provisions within the safety systems and/or the generating station design.

The ALS topical report, as amended by Reference 1, does not address a specific application or establish a definitive safety system design and acknowledges that the location of the safety related equipment within the generating station is a plant-specific implementation issue.

Additionally, the ALS topical report, as amended by Reference 1, describes the provisions intended for any ALS v2-based safety system. Since no additional information related to this topic was provided by the manufacturer and since the ALS topical report states that the physical access to the ALS platform equipment can be controlled via locked cabinet doors that generate an alarm if opened (see Reference 5, Section 12.1.10), the NRC staff understands that no changes have been made to this provision. Although the ALS v2 platform excludes the cabinet from its scope, the ALS topical report describes a typical cabinet installation (see Reference 5, Sections 1.2 and 2.6.1). The typical cabinet installation would include integral key locks on the cabinet door handles to limit access to the cabinet internals and logic to initiate an alarm for an unlocked cabinet or any activated or active digital data communication access by a Maintenance Workstation. Furthermore, access to modify the ALS v2 platform FPGA logic is not available to the applicant or licensee and all changes to the FPGA logic are to be performed by WEC within its secure development environment and under the WEC QA program.

The NRC staffs review of the design features provided by the ALS v2 platform standardized circuit boards is addressed in Section 3.1 of this SE. These design features support the administrative controls of the access to an ALS v2-based safety system through mechanical key locks and alarms that are automatically generated when the equipment is accessed.

The location of the safety related equipment within the generating station is also a plant-specific implementation activity. However, the NRC staff determined that the ALS v2 platform supports meeting the requirements in IEEE Std 603-1991, Clause 5.9. This determination is based on the use described for the ALS v2 platform and the design features provided by its standardized circuit boards. A plant-specific action is still necessary when the ALS v2 platform is solely relied upon to meet the IEEE Std 603-1991, Clause 5.9 administrative controls. For safety system equipment, this plant-specific action should ensure that the application system V&V activities demonstrate the implementation of the integral key locks on the cabinet door handles and the alarms upon cabinet access via the cabinet door or upon any digital data communication access such as by the Maintenance Workstation.

3.9.2.10 Clause 5.10 - Repair Clause 5.10 of IEEE Std 603-1991 requires that the safety systems be designed to facilitate the timely recognition, location, replacement, repair, and adjustment of malfunctioning equipment.

The ALS topical report, as amended by Reference 1, describes the continuously performed ALS v2 platform diagnostics and application diagnostics, which are designed to facilitate a timely recognition and identification of malfunctioning equipment. However, the topical report does not address a specific application or its application diagnostics. Therefore, the scope of the topical report is limited to the troubleshooting and replacement of the standardized circuit

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 111 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION boards at the board level only (sees Reference 5, Section 12.1.11). The topical report also describes board features to remove and reinstall boards into the chassis without requiring the removal of power (see Reference 5, Sections 2.5.5, and 2.9), which directly supports timely repair.

The NRC staffs review of the ALS v2 platform self-diagnostics, test, and calibration capabilities is addressed in Section 3.4.3 of this SE.

Because the ALS v2 platform topical report and the additional documentation submitted in Reference 1 do not address a specific application or its application diagnostics, this SE does not assess the report against the regulatory positions contained in RG 1.22 or RG 1.118.

Furthermore, because the ALS v2 platform FMEA informs an application-specific system level FMEA, this SE addresses failures detected by the hardware, software, and surveillance testing to ensure that the board-level FMEAs are consistent with the assumed failure detection of an application-specific single-failure analysis and FMEA.

Although the ALS topical report, as amended by Reference 1, does not address a specific application or establish a definitive safety system design, the NRC staff determined that the ALS v2 platform supports meeting the requirements in IEEE Std 603-1991, Clause 5.10. This determination is based on the use described for the ALS v2 platform and the design features provided by its standardized circuit boards. Nevertheless, a plant-specific action is necessary to ensure that the IEEE Std 603-1991, Clause 5.10 is met. This PSAI (see Section 4.2, Item 9) should address the applicable provisions of RG 1.22 and RG 1.118, and ensure that the failures detected by the hardware, FPGA logic, and surveillance testing are consistent with the assumed failure detection of the applications single-failure analysis and FMEA.

3.9.2.11 Clause 5.11 - Identification Clause 5.11 of IEEE Std 603-1991 requires that the safety system equipment to be distinctly identified for each redundant portion of the safety system and this identification must be distinguishable from any other identifying markings placed on the equipment in a manner that does not require frequent use of reference material to identify the equipment and its divisional assignment.

The ALS topical report, as amended by Reference 1, states that when the ALS v2 platform is used in instrumentation retrofits, the safety group identification, which uses cabinet name plates and color-coded wiring, will not change from the existing approach in the plant. An ALS v2 platform cabinet will include unique cabinet/division identifying nameplates on each cabinets exterior as required by the generating station procedures. Within the cabinet, each ALS v2 chassis is labeled with a unique identification and each installed ALS v2 board provides a unique identification, including the board type, via its front panel plate (see Reference 5, Section 12.1.12). The ALS v2 Platform Requirements Specification includes the identification requirements for the ALS v2 platform components (see Reference 22, PR0440 and PR0590).

Because the ALS topical report states that the plant-specific labeling requirements are specified by the applicant or licensee, this SE does not include a full evaluation against IEEE Std 603-1991, Clause 5.11.

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 112 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION Although the ALS topical report cannot fully address the requirements in IEEE Std 603-1991, Clause 5.11, the NRC staff determined that the ALS v2 platform supports meeting IEEE Std 603-1991, Clause 5.11. This determination is based on the use described for the ALS v2 platform, the identification features provided by its standardized circuit boards, and the ability for the ALS v2 platform to accommodate the plant-specific labeling requirements. Nevertheless, a plant-specific action is necessary to ensure that IEEE Std 603-1991, Clause 5.11 is met.

3.9.2.12 Clause 5.12 - Auxiliary Features Clause 5.12 of IEEE Std 603-1991 requires that the auxiliary supporting features, which are systems or components that provide services (such as cooling, lubrication, and energy supply) required for the safety systems to accomplish their safety functions, meet all the requirements of the standard. Clause 5.12 of IEEE Std 603-1991 also requires that other auxiliary features that are not required for safety functions but are part of a safety system by association, be designed to meet the criteria necessary to ensure these components, equipment, and systems do not degrade the safety systems below an acceptable level.

The ALS topical report, as amended by Reference 1, does not address a specific application or establish a definitive safety system design for the ALS v2 platform to provide an auxiliary supporting feature or some other auxiliary feature that is part of the safety system by association (see Reference 5, Section 12.1.13).

Because the ALS topical report does not address a specific application or establish a definitive safety system design, but its components, equipment, and resultant ALS v2-based systems are intended to meet all the requirements of IEEE Std 603-1991, Clause 5.12, a unique requirement may arise for future evaluations of the ALS v2 platform. Regardless, the determination of whether an application of the ALS v2 platform is an auxiliary supporting feature or some other auxiliary feature that is part of the safety system by association, is a plant-specific activity.

Although the ALS topical report cannot fully address the requirements in IEEE Std 603-1991, Clause 5.12, the NRC staff determined that the ALS v2 platform supports meeting the requirements in IEEE Std 603-1991, Clause 5.12. This determination is based on the use described for the ALS v2 platform and the evaluation of the platform against all requirements of IEEE Std 603-1991. Nevertheless, a plant-specific action is necessary to ensure that IEEE Std 603-1991, Clause 5.12 is met based on the application of an ALS v2 platform component as an auxiliary supporting feature or some other auxiliary feature that is part of the safety system by association.

3.9.2.13 Clause 5.13 - Multi-Unit Stations Clause 5.13 of IEEE Std 603-1991 permits the sharing of structures, systems, and components between units at multi-unit generating stations, provided that the ability to simultaneously perform safety functions in all units is not impaired. Clause 5.13 of IEEE Std 603-1991 also provides guidance on the sharing of electrical power between units and the application of the single failure criterion to the shared systems.

The ALS topical report, as amended by Reference 1, states that the applicability of this clause will be evaluated on a plant-specific basis (see Reference 5, Section 12.1.14).

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 113 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION The NRC staff agrees that the evaluation of this clause is plant-specific and application-specific.

Therefore, no NRC staff determinations are appropriate for the ALS v2 platform to address IEEE Std 603-1991, Clause 5.13. Nevertheless, a plant-specific action is necessary to ensure that Clause 5.13 is met whenever an ALS v2-based system or an ALS v2 platform component is shared between units at a multi-unit generating station.

3.9.2.14 Clause 5.14 - Human Factors Considerations Clause 5.14 of IEEE Std 603-1991 requires human factors considerations at the initial stages and throughout the design process to ensure that any functions allocated in whole or in part to human operator(s) and maintainer(s) can be successfully accomplished to meet the safety system design goals.

The ALS topical report describes human factors considerations that were applied initially throughout the ALS platform development process. The ALS topical report states that the ALS platform design considerations indicate compliance with relevant human factors guidance (see Reference 5, Sections 2.9 and 12.1.15). As no changes were made in Human Factors considerations in the ALS v2 submittal (Reference 1), the conclusions drawn in the ALS SE remain valid.

The ALS topical report does not address a specific application or establish a definitive safety system. Furthermore, the safety system design goals are established on a plant and application-specific basis. As such, no specific safety functions have been allocated in whole or in part to human operator(s) and maintainer(s) at a specific generating station.

The NRC staffs review of the design features provided by the ALS v2 platform standardized circuit boards and their instrument chassis are addressed in Section 3.1 of this SE. The NRC staffs review of the ALS v2 platform self-diagnostics and test and calibration capabilities are addressed in Section 3.4.3 of this SE.

Although the ALS topical report does not fully address the requirements in IEEE Std 603-1991, Clause 5.14, the NRC staff determined that the ALS v2 platform supports meeting the requirements in IEEE Std 603-1991, Clause 5.14. This determination is based on the use described for the ALS v2 platform and the evaluation of the platforms design features.

Nevertheless, a plant-specific action is necessary to ensure that the requirements in IEEE Std 603-1991, Clause 5.14 are met based on the application of the ALS v2 platform and an evaluation of any functions allocated in whole or in part to human operator(s) and maintainer(s) to ensure that these functions can be successfully accomplished to meet the safety system design goals. This evaluation should be consistent with the applicants or licensees commitments documented in the plants safety analysis report, as updated.

3.9.2.15 Clause 5.15 - Reliability Clause 5.15 of IEEE Std 603-1991 requires that the appropriate analysis of system designs to confirm any established reliability goals, either quantitative or qualitative, have been met.

The NRC staffs evaluation of reliability establishes that the applicant or licensee should justify that the degree of redundancy, diversity, testability, and quality provided in the safety system design is adequate to achieve the functional reliability commensurate with the safety functions

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 114 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION to be performed. Furthermore, for computer systems this analysis should address both hardware and software reliability, as applicable.

The ALS topical report, as amended by Reference 1, relies on the individual board documents to provide the information for each individual standardized circuit board reliability calculation.

Each boards reliability analysis includes individual hardware component failures and excludes consideration of software failures because the FPGA-based ALS v2 platform standardized circuit boards do not contain traditional software. The ALS topical report, as amended by Reference 1, describes these reliability calculations as providing a Mean Time Between Failure (MTBF) prediction with the goal of not requiring surveillance tests at an interval more frequent than once every 92 days and with the objective of allowing a licensee to pursue a Technical Specifications change for less frequent surveillances after some period of an ALS or ALS v2-based systems operation that successfully demonstrates its sufficiently low failure rate (see Reference 5, Sections 7 and 12.1.16 for the ALS platform). The ALS v2 Platform Requirements Specification includes a calculated reliability specification of MTBF for individual standardized circuit boards (see Reference 22, PR1101).

The ALS topical report, and its ALS v2 descendent, do not provide specific configuration details for any application to establish a definitive safety system configuration. Furthermore, safety system reliability goals are established on a plant-specific and application-specific basis. As described in the reliability analyses, the predicted MTBF for a safety function depends on the application-specific logic and the number and arrangement of ALS v2 components, which includes its standardized circuit boards and other peripherals. Because the application-specific logic development and the number and arrangement of ALS v2 components will be plant and application-specific, the reliability of a plant safety function cannot be predicted based solely on the ALS v2 standardized circuit board reliability analyses. However, the reliability analyses of the standardized circuit boards support reliability predictions of the ALS v2-based safety systems.

The NRC staffs review of the ALS v2 platform reliability is addressed in Section 3.6 of this SE.

This review identifies a PSAI.

The NRC staff determined that the ALS topical report, as amended by Reference 1, cannot fully address IEEE Std 603-1991, Clause 5.15. However, the NRC staff determined that the ALS v2 platform supports meeting the requirements in IEEE Std 603-1991, Clause 5.15 based on the standardized circuit board reliability predictions and the adequate closure of the PSAI identified in Section 3.6 of this SE.

3.9.3 IEEE Std 603 Section 6 - Sense and Command Features - Functional and Design Requirements Section 6 of IEEE Std 603-1991 contains eight clauses that only apply to sense and command features of safety systems. In addition to the preceding evaluation of the ALS v2 platform against the requirements in Section 5 of IEEE Std 603-1991, the NRC staff evaluated the ALS v2 platform against the requirements of Section 6. Sense and command features are the electrical and mechanical components and interconnections involved in generating those signals associated directly or indirectly with the safety functions. The scope of the sense and command features extends from the measured process variables to the execute features input terminals thereby including the actuation device for the actuated equipment. The following

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 115 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION evaluations against the requirements of IEEE Std 603-1991, Section 6 are limited to the capabilities and characteristics of the ALS v2 platform relevant to meet each requirement.

3.9.3.1 Clause 6.1 - Automatic Control Clause 6.1 of IEEE Std 603-1991 requires that for each design basis event, all protective actions should automatically initiate without operator action, except as justified in Clause 4.5 of IEEE Std 603-1991. SRP Chapter 7, Appendix 7.1-C, Section 6.1, Automatic Controls, provides acceptance criteria for Clause 6.1. These acceptance criteria state that the automatic initiation should be precise and reliable, and the evaluation of the precision of the safety system should be addressed to the extent that setpoints, margins, errors, and response times are factored into the analysis. Section 6.1 also states that SRP BTP 7-12 discusses the considerations for the review of the process for establishing instrument setpoints. In part, these acceptance criteria contribute to the demonstration that a safety system meets Appendix A to 10 CFR Part 50, GDC 13 and RG 1.97, when applicable.

The ALS topical report, as amended by Reference 1, does not address a specific application or establish a definitive safety system, which is necessary to define the extent that setpoints, margins, errors, and response times are factored into a plants safety analysis or are associated with IEEE Std 603-1991, Clause 4.5 (see Reference 5, Sections 2.8 and 12.1.17). Per SRP Chapter 7, Appendix 7.1-C, Section 6.1, the applicant or licensee analyses should confirm that the safety system has been qualified to demonstrate that the performance requirements are met.

The NRC staffs review of the design features provided by the ALS v2 platform standardized circuit boards and their instrument chassis are summarized in Section 3.1 of this SE. The NRC staffs review of the ALS v2 platforms response time characteristics is addressed in Sections 3.4.1 and 3.4.2.1 of this SE. The NRC staffs review of self-diagnostics and test and calibration capabilities provided by the ALS v2 platform is addressed in Section 3.4.3 of this SE.

The NRC staffs review of the ALS v2 platform reliability is addressed in Section 3.6 of this SE.

The NRC staffs review of the approaches to build diversity into an ALS v2-based system is addressed in Section 3.8 of this SE. The NRC staffs evaluation of the precision of the safety system with regard to the degree that setpoints, margins, errors, and response times are factored into the analysis is addressed in Section 3.9.3.8 of this SE, which discusses setpoints.

Although the ALS topical report does not fully address IEEE Std 603-1991, Clause 6.1, the NRC staff determined that the ALS v2 platform supports meeting the requirements in IEEE Std 603-1991, Clause 6.1. This determination is based on the platform design features, deterministic performance characteristics, reliability calculations, methods to build-in diversity, and adequate closure of the associated PSAIs. Nevertheless, a plant-specific action is necessary when the ALS v2 platform provides safety system sense and command features that include automatic control. This plant-specific action should ensure that Clause 6.1 is met, and this action should include the applicant or licensee analyses to confirm that the safety system has been qualified to demonstrate that the specified performance requirements have been met.

3.9.3.2 Clause 6.2 - Manual Control Clause 6.2 of IEEE Std 603-1991 contains three subclauses related to the availability of the manual controls in the control room. Clause 6.2.1 requires that the control room provide a

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 116 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION means to manually initiate the protective actions at the division level of the automatically initiated protective actions, such that the number of discrete operator manipulations and operated equipment is minimized while the independence between the redundant portions of a safety system per IEEE Std 603-1991, Clause 5.6.1 is preserved. Clause 6.2.2 requires that the control room provide a means to manually initiate the protective actions that were not selected for automatic control along with the associated information displays. Clause 6.2.3 requires that the control room provide a means to perform manual actions necessary to maintain safe conditions after the protective actions are completed along with the associated information displays in sufficient quantities and locations to support the surveillance and action by the number of available qualified operators.

SRP Chapter 7, Appendix 7.1 C, Section 6.2, Manual Control, provides the acceptance criteria for IEEE Std 603-1991, Clause 6.2. These criteria state that the features for the manual initiation of protective action should conform to RG 1.62 and should be functional, accessible within the time constraints of the operator responses, and should be available during the plant conditions under which manual actions may be necessary.

The ALS topical report, as amended by Reference 1, does not address a specific application, establish a defined safety system, or locate manual controls and displays within a plant-specific control room. The scope of the report does not include information displays. It also states that manual control applies as an application specific system level requirement, which may also be a function of the architecture of any system being replaced by an ALS v2-based system. The ALS platform has previously been qualified for use in a mild environment that is consistent with installation in a control room, and the ALS v2 platform standardized circuit boards provide features that support the implementation of manual controls and connectivity to information displays (see Reference 5, Section 12.1.18).

The NRC staffs review of the design features provided by the ALS v2 platform standardized circuit boards and their instrument chassis are addressed in Section 3.1 of this SE. The NRC staffs review of the approaches to build diversity into an ALS v2-based system is addressed in Section 3.8 of this SE.

Although the ALS topical report, as amended by Reference 1, does not fully address IEEE Std 603-1991 Clause 6.2, the NRC staff determined that the ALS v2 platform supports meeting the requirements in IEEE Std 603-1991, Clause 6.2. This determination is based on the platform design features and methods to implement diversity features. Nevertheless, a plant-specific action is necessary when the ALS v2 platform provides safety system sense and command features that include manual control. This plant-specific action should ensure that Clause 6.2 is met and also addresses RG 1.62 and BTP 7-19, Point 4.

3.9.3.3 Clause 6.3 - Interaction Between the Sense and Command and Other Systems Clause 6.3 of IEEE Std 603-1991 contains two subclauses related to the diversity and D3 of the protective actions. Clause 6.3.1 of IEEE Std 603-1991 contains a requirement to mitigate the consequences of a credible event (and its direct and indirect consequences) that is an initiator of a nonsafety system action resulting in a condition requiring the protective action while concurrently preventing the protective actions from being performed by the channels designated as providing principal protection against the resulting condition. Two alternatives to fulfill the requirement are specified. The first alternative is that the channels not subject to a failure from

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 117 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION the same single credible event shall be provided to limit the consequences of this event to a value specified by the design basis using either one or a combination of both of the following options: (1) provide alternate channels that sense a set of different variables from the principal channels and/or (2) provide alternate channels that use equipment that is different from that of the principal channel to sense the same variable. The second alternative is equipment not subject to failure from the same single credible event shall be provided to detect the event and limit the consequences to a value specified by the design basis, where this equipment is not considered a part of the safety system. Clause 6.3.2 of IEEE Std 603-1991 requires and identifies three provisions that will allow Clause 6.3.1 to remain met during the maintenance bypass of a channel. These provisions are: (1) reducing the required coincidence, (2) defeating the nonsafety system signals taken from the redundant channels, or (3) initiating a protective action from the bypassed channel.

The ALS topical report, as amended by Reference 1, states that the ALS v2 platform has the capability to be configured in a manner that meets the requirements in IEEE Std 603-1991, Clause 6.3. However, the ALS topical report and the ALS v2 topical report do not address a specific application, establish a definitive safety system or protective action, or identify and analyze the impact of credible events along with their direct and indirect consequences. As such, the ALS topical report and the ALS v2 topical report (that provided that no changes had occurred to the information related to this clause) state that conformance to IEEE Std 603-1991, Clause 6.3 will be addressed during a plant-specific implementation (see Reference 5, Section 12.1.19).

Within the first alternative provided in Clause 6.3.1, the specified differences between the alternate channels and the principal channels correspond to diversity attributes discussed in Section 3.8 of this SE. The second alternative would provide an automatic diverse backup system to provide the diverse means discussed in BTP 7-19 Point 3. The NRC staffs review of the approaches to build diversity into an ALS v2-based system is addressed in Section 3.8 of this SE. The NRC staffs review of the design features provided by ALS v2 platform standardized circuit boards and their instrument chassis are addressed in Section 3.1 of this SE.

Although the ALS v2 topical report does not fully address IEEE Std 603-1991, Clause 6.3, the NRC staff determined that the ALS v2 platform supports meeting the requirements in IEEE Std 603-1991, Clause 6.3 through the implementation of either principal channels, alternate channels, or a diverse backup system. This determination is based on the ALS v2 diversity options, platform design features to implement coincidence logic, and maintenance features to either bypass or trip channels. A plant-specific action is necessary when the ALS v2 platform provides sense and command features for principal protection against the resulting condition of a nonsafety system action that has been caused by a single credible event, including its direct and indirect consequences. This plant-specific action should ensure that Clause 6.3 is met and also addresses BTP 7-19.

3.9.3.4 Clause 6.4 - Derivation of System Inputs Clause 6.4 of IEEE Std 603-1991 requires, to the extent practical, that sense and command feature inputs be derived from signals that are direct measures of the desired variables as specified in the design basis.

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 118 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION The ALS topical report, as amended by Reference 1, states that the applicability of this clause will be evaluated on a plant-specific basis, because it applies as a system level and application specific requirement. As described in the ALS topical report (Reference 5), the manufacturer indicated that the ALS platform directly supports a plants existing methods for the direct measurement of the desired variables, as specified in the plants design basis, so no changes to the plant transmitters or sensors will be required (see Reference 5, Section 12.1.20). As no changes to the information were provided by the manufacturer for this clause, as described in the ALS v2 topical report (Reference 9), the NRC staff understands that no changes to the acceptance criteria related to this clause have been implemented.

The NRC staff agrees that the evaluation of this clause is plant-specific and application-specific.

Therefore, no NRC staff determinations are made for the ALS v2 platform to address IEEE Std 603-1991, Clause 6.4. A plant-specific action is necessary to ensure that Clause 6.4 is met.

3.9.3.5 Clause 6.5 - Capability for Testing and Calibration Clause 6.5 of IEEE Std 603-1991 contains two subclauses related to assuring the availability of the sense and command feature input sensors. Clause 6.5.1 requires means to check, with a high degree of confidence, the operational availability of each sense and command feature input sensor required for a safety function during reactor operation. Clause 6.5.2 requires the means to assure the operational availability of each sense and command feature input sensor required during the post-accident period.

The ALS topical report, as amended by Reference 1, states that the applicability of this clause will be evaluated on a plant-specific basis. As described in the ALS topical report (Reference 5),

the manufacturer indicated that the ALS platform directly supports a plants existing methods to perform cross-checking between the redundant safety system channel sensors or between sensor channels that bear a known relationship to each other. As no changes in information were made to this clause in the ALS v2 platform report, based on the information contained in Reference 29, the manufacturer indicated that the ALS v2 platform will also support cross-checking through its design features, which will provide sufficiently precise readouts for the sensors as described in the ALS topical report (see Reference 5, Section 12.1.21).

The NRC staffs review of the design features provided by the ALS v2 platform standardized circuit boards is addressed in Section 3.1 of this SE. The NRC staffs review of self-diagnostics and test and calibration capabilities provided by the ALS v2 platform is addressed in Section 3.4.3 of this SE.

BTP 7-17 discusses issues that should be considered in the sensor check and surveillance test provisions where digital computer I&C systems are involved. In particular, when automatic test features, which would include any automatic sensor cross-check, are credited with performing a surveillance test function, then provisions should be made to confirm the continued execution of the automatic tests during plant operations. Additionally, the safety classification and quality of the hardware and software performing periodic tests should be equivalent to that of the tested system, and the design should maintain channel independence, maintain system integrity, and meet the single-failure criterion during testing.

Although the ALS topical report, as amended by Reference 1, cannot fully address IEEE Std 603-1991, Clause 6.5, the NRC staff determined that the ALS v2 platform supports meeting the

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 119 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION requirements in IEEE Std 603-1991, Clause 6.5. This determination is based on the following factors.

Platform design features support the implementation of application-specific diagnostic logic and confirmation of continued execution via the Maintenance Workstation.

The classification and quality of the hardware and FPGA logic performing diagnostic functions, as part of the tested system, are equivalent to the classification and quality of the safety function hardware and FPGA logic.

The proposed instrumentation architecture supports meeting channel independence, system integrity, the single failure criterion, and the use of a qualified display system as the Maintenance Workstation during test and calibration activities.

A plant-specific action is necessary to ensure that Clause 6.5 is met in further consideration of applicable portions of BTP 7-17, RG 1.118, and RG 1.47.

3.9.3.6 Clause 6.6 - Operating Bypasses Clause 6.6 of IEEE Std 603-1991 requires that a safety system either: (1) automatically prevent the activation of an operating bypass whenever the applicable permissive conditions are not met or (2) when the permissive conditions are not met, initiate the appropriate safety function(s) to be bypassed. This clause further requires that the safety system take one of three actions whenever the conditions change so that the permissive conditions are no longer met after an operating bypass had been established: (1) remove the appropriate operating bypass(es),

(2) restore plant conditions so that the permissive conditions once again exist, or (3) initiate the appropriate safety function(s).

The ALS topical report, as amended by Reference 1, states that the applicability of this clause will be evaluated on a plant-specific basis, because it applies as a system level and application specific requirement. As described in the ALS topical report (Reference 5), the manufacturer indicated that the ALS platform directly supports the implementation of operating bypasses within the application-specific logic of the ALS-102 Core Logic Board. As no changes in information were made to this clause in the ALS v2 platform report, based on the information contained in Reference 9, the manufacturer indicated that the ALS v2 platform will also support the implementation of operating bypasses for the ALS-152 Core Logic Board. The manufacturer indicated that the application-specific logic for the operating bypass will meet the requirements in IEEE Std 603-1991, Clause 6.6 through automatic actions that require neither operator intervention nor confirmation (see Reference 5, Section 12.1.22).

The NRC staffs review of the design features provided by the ALS v2 platform standardized circuit boards is addressed in Section 3.1 of this SE. The NRC staffs review of the ALS v2 platform response time characteristics is addressed Sections 3.4.1 and 3.4.2.1 of this SE. The NRC staffs review of the self-diagnostics and test and calibration capabilities provided by the ALS v2 platform is addressed in Section 3.4.3 of this SE.

Although the ALS topical report does not fully address IEEE Std 603-1991, Clause 6.6, the NRC staff determined that the ALS v2 platform supports meeting the requirements in IEEE Std 603-1991, Clause 6.6. This determination is based on the platform design features to implement

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 120 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION the application-specific logic. The NRC staff also agrees that the evaluation of this clause is plant-specific and application-specific. Therefore, no broader NRC staff determination is appropriate for the ALS v2 platform to address IEEE Std 603-1991, Clause 6.6. A plant-specific action is necessary to ensure that Clause 6.6 is met.

3.9.3.7 Clause 6.7 - Maintenance Bypass Clause 6.7 of IEEE Std 603-1991 requires that a safety system retain its ability to accomplish its safety function while the sense and command features equipment is in a maintenance bypass and that during the maintenance bypass both the single failure criterion of Clause 5.1 and the diversity and D3 of protective actions of Clause 6.3 continue to be met. An exception to continuing to meet Clauses 5.1 and 6.3 is provided for one-out-of-two portions of the sense and command features when one portion is rendered inoperable, provided that the acceptable reliability of the equipment operation has been demonstrated to show that the removal from service for the maintenance bypass is sufficiently short to have no significantly detrimental effect on overall sense and command features availability.

The ALS topical report, as amended by Reference 1, states that the applicability of this clause will be evaluated on a plant-specific basis, because it applies as a system level and application specific requirement that depends on the number of redundant safety channels. As described in the ALS topical report, the manufacturer indicated that the ALS platform directly supports the implementation of the maintenance bypasses in accordance with plant technical specifications (see Reference 5, Section 12.1.23). As no changes in information were made to this clause in the ALS v2 platform report, based on the information contained in Reference 9, the manufacturer indicated that the ALS v2 platform will also support the implementation of the maintenance bypasses in accordance with the Technical Specifications.

The NRC staffs review of the design features provided by the ALS v2 platform standardized circuit boards is addressed in Section 3.1 of this SE. The NRC staffs review of the self-diagnostics and test and calibration capabilities provided by the ALS v2 platform is addressed in Section 3.4.3 of this SE.

Although the ALS topical report and its ALS v2 descendent do not fully address IEEE Std 603-1991, Clause 6.7, the NRC staff determined that the ALS v2 platform supports meeting the requirements in IEEE Std 603-1991, Clause 6.7. This determination is based on the platform design features to implement the multiple redundant safety channels/divisions while maintaining independence between them and the ability to perform a maintenance bypass on an individual safety channel/division. An evaluation of this clause requires the review of plant and application-specific technical specification content. Therefore, the NRC staff also agrees that the evaluation of this clause is plant-specific and application-specific. As such, no broader NRC staff determination is appropriate for the ALS v2 platform to address IEEE Std 603-1991, Clause 6.7.

A plant-specific action is necessary to ensure that Clause 6.7 is met.

3.9.3.8 Clause 6.8 - Setpoints Clause 6.8 of IEEE Std 603-1991 contains two subclauses related to the determination of the sense and command feature setpoints. Clause 6.8.1 requires that the allowance for the uncertainties between a plants process analytical limit, which is documented in its design basis per Clause 4.4, and a safety system devices setpoint is to be determined using a documented

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 121 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION methodology. Clause 6.8.2 requires the design to provide a positive means of ensuring that the more restrictive setpoint is used when it is necessary to provide multiple setpoints for adequate protection for a particular mode of operation or set of operating conditions. Clause 6.8.2 additionally requires that the devices to prevent the improper use of less restrictive setpoints be part of the sense and command features of the safety system.

The ALS topical report, as amended by Reference 1, does not address a specific application or establish a definitive safety system, which is necessary to demonstrate the adequacy of setpoints associated with IEEE Std 603-1991, Clause 4.4. However, the manufacturer has indicated that protection system setpoints will be calculated in accordance with a well-established methodology that accounts for all measurement and signal processing inaccuracies, as well as time and temperature effects (see Reference 5, Section 12.1.24). Per SRP Chapter 7, Appendix 7.1-C, Section 6.8, an applicants or licensees analyses should confirm that an adequate margin exists between operating limits and setpoints, such that there is a low probability for inadvertent actuation of the system. The applicants or licensees analyses should also confirm that an adequate margin remains between the setpoints and safety limits, such that the system initiates protective actions before safety limits are exceeded.

RG 1.105, Revision 4, Setpoints for Safety-Related Instrumentation, and SRP BTP 7-12 provide guidance on the establishment of instrument setpoints.

Although the ALS topical report excludes the process of establishing instrument setpoints, it does describe the operational concept by which an automatic control would be implemented using the platform and provides a high-level description of the ALS system accuracy. The ALS topical report and its ALS v2 descendent do not provide board level accuracy calculations, accuracy requirements in terms of plant process variables, or the supporting statistical basis for board-level accuracy error terms in support of a plant-specific setpoint methodology or an application-specific setpoint calculation. As described in the ALS topical report, the manufacturer indicated that the ALS board accuracy supports a safety system accuracy that is the same or better than the system being replaced, so the setpoints will not change and a plants operating margin will be preserved (see Reference 5, Sections 2.8 and 12.1.17). Since no changes were made to the method to determine the board accuracies that support the safety system accuracy in the ALS v2 topical report (Reference 9), the conclusion that the plants operating margin will be preserved is reasonable.

The ALS topical report further states that the determination of actual setpoints will be made on a plant-specific basis and that the accuracy and response time performance of the plant-specific application of the ALS v2 platform will become part of the plants setpoint methodology program, which will follow current setpoint guidance and requirements (see Reference 6, Section 12.1.24).

The NRC staffs review of the design features provided by the ALS v2 platform standardized circuit boards is addressed in Section 3.1 of this SE. The NRC staffs review of the self-diagnostics and test and calibration capabilities provided by the ALS v2 platform is addressed in Section 3.4.3 of this SE.

Although the ALS topical report and its ALS v2 descendent do not fully address IEEE Std 603-1991, Clause 6.8, the NRC staff determined that the ALS v2 platform supports meeting the requirements in IEEE Std 603-1991, Clause 6.8. This determination is based on the platforms deterministic processing characteristics, equipment accuracy specifications, plant-specific and

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 122 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION application-specific logic within the ALS-152 Core Logic Board, and the equipment calibration and test operational concepts. Nevertheless, the evaluation of this clause requires the review of an applicants or licensees plant-specific setpoint methodology and application-specific instrument error terms. The NRC staff agrees that the evaluation of this clause is plant-specific and application-specific. As such, no broader NRC staff determination is appropriate for the ALS v2 platform to address IEEE Std 603-1991, Clause 6.8. A plant-specific action is necessary to ensure that Clause 6.8 is met, and this should include applicant or licensee analyses to provide information related to the applicants or licensees setpoint methodology, calculations, and technical basis for the associated ALS v2 platform error terms in consideration of RG 1.105 and SRP BTP 7-12.

3.9.4 IEEE Std 603 Section 7 - Execute Features - Functional and Design Requirements Section 7 of IEEE Std 603-1991 contains five clauses that only apply to execute features of safety systems.

For each of these five clauses, the ALS topical report, as amended by Reference 1, states that the associated requirements apply on an application-specific basis (see Reference 5, Sections 12.1.25 through 12.1.29). Furthermore, the set of examples of the ALS v2 platform applications do not implement the actuated equipment associated with the execute features of the safety systems and instead primarily address the sense and command features of the safety systems (see Reference 5, Appendices A through C). As such, the NRC staff agrees that no review of the ALS v2 platform against Section 7 of IEEE Std 603-1991 is necessary. However, the NRC staffs review of Section 5 and Section 6 of IEEE 603-1991 provides an adequate evaluation of the ALS v2 platforms potential use within the execute features.

Although the ALS topical report, as amended by Reference 1, does not fully address IEEE Std 603-1991, Section 7, the NRC staff determined that the ALS v2 platform supports meeting the requirements in IEEE Std 603-1991, Section 7. This determination is based on the platform design features to implement the application-specific logic on the ALS-152 Core Logic Board, to implement multiple redundant safety channels/divisions while maintaining independence between them, and to implement and indicate the compliant bypasses on an individual safety channel/division. This is because the ALS v2 topical report states that no changes to the information occurred for Section 7, as described in Reference 9. However, the evaluation of this clause requires plant-specific action. Therefore, the NRC staff agrees that the evaluation of this clause is plant-specific and application-specific. As such, no broader NRC staff determination is appropriate for the ALS v2 platform to address IEEE Std 603-1991, Section 7. A plant-specific action is necessary to ensure that Section 7 is met for the ALS v2 platform applications of a safety system execute feature.

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 123 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION 3.9.5 IEEE Std 603 Section 8 - Power Source Requirements Section 8 of IEEE Std 603-1991 contains three clauses related to power sources for safety systems. Clause 8.1 requires that any portion of the Class 1E power system required to provide electrical power to the safety system shall be considered part of the safety systems and shall be governed by the criteria of IEEE Std 603-1991. Clause 8.2 requires that non-electrical power sources (e.g., control-air, bottled-gas, hydraulic accumulator, etc.) required to provide motive power to the safety system components shall be considered part of the safety systems and shall provide power consistent with the requirements of IEEE Std 603-1991. Clause 8.3 requires that the safety systems retain their ability to accomplish their safety functions while power sources are in maintenance bypass similar to the maintenance bypass provisions for the sense and command features and the execute features.

When addressing IEEE Std 603-1991, Section 8, the ALS topical report, as amended by Reference 1, states that each ALS v2-based safety system cabinet can be supplied with two qualified, auctioneered power supplies, where each power supply will be capable of independently providing full-power for an ALS v2 chassis if one of its power supplies fails or is removed from service (see Reference 5, Section 12.1.30). This redundant power supply approach can be used to address local power supplies within an instrument cabinet in support of the single failure criterion. However, in both the ALS and ALS v2 platform topical reports, these power supplies are considered to be peripheral devices and are not within the ALS v2 platform scope (see Reference 5, Section 1.2 and Reference 9, Section 1.2).

The NRC staff agrees that no review of the ALS v2 platform against Section 8 of IEEE Std 603-1991 is necessary. Nevertheless, the NRC staffs review of Sections 4, 5, and 6 of IEEE Std 603-1991 provides an adequate evaluation of the ALS v2 platforms potential use within the overall Class 1E electrical power system.

Although the ALS topical report, as amended by Reference 1, does not fully address IEEE Std 603-1991, Section 8, the NRC staff determined that the ALS v2 platform supports meeting the requirements in IEEE Std 603-1991, Section 8. This determination is based on the platform design features to implement the application-specific logic on the ALS-152 Core Logic Board and to implement multiple redundant safety channels/divisions while maintaining independence between them. Nevertheless, the evaluation of this clause requires plant-specific action.

Therefore, the NRC staff agrees that the evaluation of this clause is plant-specific and application-specific. As such, a plant-specific action is necessary to ensure that Section 8 is met for the ALS v2 platform applications of a safety system power source features.

3.10 Conformance with IEEE Std 7-4.3.2-2003 Equipment based on the ALS v2 platform components is intended for use in the safety systems and other safety-related applications. Therefore, the platform topical report was evaluated against its ability to support the application-specific system provisions of IEEE Std 7-4.3.2-2003.

RG 1.152, Revision 3, states that conformance with the requirements of IEEE Std 7-4.3.2-2003 is a method that the NRC staff has deemed acceptable for meeting the NRCs regulations with respect to high functional reliability and design requirements for computers used in the safety systems of nuclear power plants. The NRC staffs evaluation is based on the guidance contained in SRP Chapter 7, Appendix 7.1-D, which provides acceptance criteria for this standard.

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 124 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION With the consideration that the ALS topical report, as amended by Reference 1, scope does not propose to meet all clauses of IEEE Std 7-4.3.2-2003 via its components, the NRC staffs evaluation of each clause has a limited scope that does not evaluate all of the criteria within that standard.

Because the NRC staffs evaluation is largely limited to the determination of the degree that the ALS v2 platform and its FPGA development processes support meeting the various clauses of IEEE Std 7-4.3.2-2003, as applicable to an FPGA-based platform, a single general PSAI has been created to address full compliance to each IEEE Std 7-4.3.2-2003 clause, which applies to each plant-specific and application-specific use of the ALS v2 platform (see Section 4.2, Item 22).

3.10.1 IEEE Std 7-4.3.2, Section 4 - Safety System Design Basis Section 4 of IEEE Std 7-4.3.2-2003 states that no requirements beyond those found in Section 4 of IEEE Std 603 are necessary. The NRC staffs review of the ALS v2 platform against the requirements found in Section 4 of IEEE Std 603-1991 is addressed in Section 3.9.1 of this SE.

3.10.2 IEEE Std 7-4.3.2, Section 5 - Safety System Criteria Section 5 of IEEE Std 7-4.3.2-2003 contains fifteen clauses that apply to all safety system functions and features. Some of the clauses in Section 5 of IEEE Std 603-1991 are supplemented by IEEE Std 7-4.3.2-2003 to address technology specific issues related to the use of digital computers in safety systems. The following evaluations against IEEE Std 7-4.3.2-2003, Section 5 are limited to capabilities and characteristics of the ALS v2 platform relevant to meeting each requirement.

3.10.2.1 IEEE Std 7-4.3.2, Clause 5.1 - Single Failure Criterion Clause 5.1 of IEEE Std 7-4.3.2-2003 states that no requirements beyond those found in Clause 5.1 of IEEE Std 603 are necessary. The NRC staffs review of the ALS v2 platform against the requirements found in Clause 5.1 of IEEE Std 603-1991 is addressed in Section 3.9.2.1 of this SE.

3.10.2.2 IEEE Std 7-4.3.2, Clause 5.2 - Completion of Protective Action Clause 5.2 of IEEE Std 7-4.3.2-2003 states that no requirements beyond those found in Clause 5.2 of IEEE Std 603 are necessary. The NRC staffs review of the ALS v2 platform against the requirements found in Clause 5.2 of IEEE Std 603-1991 is addressed in Section 3.9.2.2 of this SE.

3.10.2.3 IEEE Std 7-4.3.2, Clause 5.3 - Quality Clause 5.3 of IEEE Std 7-4.3.2-2003 states that the hardware quality is addressed in IEEE Std 603-1991 and that the software quality is addressed in IEEE/EIA Standard 12207.0-1996 and supporting standards. Clause 5.3 further requires that the digital computer development process include the development activities for both computer hardware and software, the integration of the hardware and software, and the integration of the computer with the safety system.

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 125 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION Clause 5.3 includes six subclauses to identify activities beyond the requirements of IEEE Std 603-1991 necessary to meet the quality criteria for a digital computer-based system, including its software. Each subclause under Clause 5.3 addresses one of these six activities.

The ALS topical report, as amended by Reference 1, describes the QA program as a 10 CFR Part 50, Appendix B program and describes the ALS v2 platform life-cycle management process (see Reference 5, Sections 6, 10, and 12.2.4).

For the ALS v2 platform, the manufacturer has maintained a QA program based on 10 CFR Part 50, Appendix B and its QA program has since been subjected to further NRC staff, supplier, and licensee audit activities. Section 3.9.2.3 of this SE provides the NRC staffs evaluation for quality against IEEE Std 603-1991, Clause 5.3. The next six subsections of this SE address the six subclauses of IEEE Std 7-4.3.2-2003, Clause 5.3, which identify activities beyond the requirements of IEEE Std 603-1991 that are necessary to meet the quality criterion for a digital computer-based system, including its software.

3.10.2.3.1 IEEE Std 7-4.3.2, Clause 5.3.1 - Software Development Clause 5.3.1 of IEEE Std 7-4.3.2-2003 states that the computer software shall be developed, modified, or accepted in accordance with an approved software QA plan that is consistent with the requirements of IEEE/EIA 12207.0-1996. Clause 5.3.1 further states that the software QA plan shall address all software resident on the computer at run time (i.e., application software, network software, interfaces, operating systems, and diagnostics) and provides reference guidance for developing software QA plans.

The ALS topical report, as amended by Reference 1, states that the ALS v2 platform has no resident software at run time and describes its overall approach to providing an Appendix B compliant QA program (see Reference 5, Sections 12.2.5 and 10).

Based on the continuity of the Quality Assurance Plan and the manufacturers position as an Appendix B supplier throughout the ALS v2 platform development, the NRC staff determined that all FPGA programming residents in the ALS v2 platform is developed, modified, and accepted in accordance with a QA plan that is appropriate for the FPGA technology and for use in safety-related systems of nuclear power plants.

3.10.2.3.1.1 IEEE Std 7-4.3.2, Clause 5.3.1.1 - Software Quality Metrics Clause 5.3.1.1 of IEEE Std 7-4.3.2-2003 states that the use of software quality metrics shall be considered throughout the software lifecycle to assess whether software quality requirements are being met. Clause 5.3.1.1 also identifies life-cycle phase characteristics that should be considered when software quality metrics are used and states that the basis for the selected metrics should be included in the software documentation.

The ALS topical report, as amended by Reference 1, states that the ALS v2 platform is FPGA-based and does not use software in a traditional sense. However, the ALS platform includes and the ALS v2 platform development lifecycle continues to include the consideration of methods to assess satisfactory implementation of FPGA programming quality (see Reference 5, Sections 12.2.6 and 6). Although the ALS topical report, and its descendent described in Reference 1, do not identify specific FPGA programming quality metrics to identify explicit

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 126 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION measurement indicators or the basis for the selected metrics, the ALS v2 V&V Plan does address correctness and completeness of requirements during the requirements phase, compliance with requirements as part of the design phase, compliance with design as part of the implementation phase, and functional compliance with requirements as part of the test and integration phase. Because the scope of the ALS v2 topical report excludes a specific system design and its subsequent installation and use, the ALS v2 V&V Plan (Reference 21) addresses on-site functional compliance with requirements as part of the installation and checkout phase and assess any new platform requirements and their application to the V&V Plan as part of the operation and maintenance phase (see Reference 21, Section 4, IV&V Processes).

As part of the life-cycle activities of the ALS v2 platform development, the manufacturer documents error reports and tracks associated records and corrective actions for the ALS v2 platform.

The NRC staff determined that the manufacturer did not establish or use specific FPGA program quality metrics for the ALS or the ALS v2 platform. Therefore, software quality metrics, as defined in IEEE Std 7-4.3.2-2003, Clause 5.3.1.1, were not applied for the ALS v2 platform FPGA program development efforts. Therefore, the NRC staff concludes that the manufacturer does not intend to use quality inferences from FPGA program quality metric measurements to demonstrate that the quality requirements of 10 CFR Appendix B have been met. The NRC staffs evaluation of quality, which is addressed in Sections 3.9.2.3 and 3.10.2.3 of this SE, does not include software quality metrics.

3.10.2.3.2 IEEE Std 7-4.3.2, Clause 5.3.2 - Software Tools Clause 5.3.2 of IEEE Std 7-4.3.2-2003 states that the software tools to support the software development processes and V&V processes shall be controlled under CM. Clause 5.3.2 also identifies two methods whereby software tools may be confirmed as suitable for use, where one or both methods shall be used. These confirmation methods are: (1) a test tool validation program to provide confidence that the necessary features of the software tool function as required and (2) the use of the software tool so defects not detected by the software tool will be detected by V&V activities. Additionally, Clause 5.3.2 allows for the use of the operating experience to provide additional confidence in the suitability of a tool, particularly when evaluating the potential for undetected defects.

The design and development of the ALS v2 platforms FPGAs rely on several commercially available software-based tools, which the ALS v2 platform applicant has placed under its CM program for control and maintenance. These software-based tools are subjected to an assessment and tool qualification to ensure that each tool is capable of performing its design or verification functions in accordance with an ALS v2 Design Tools document. The software tools have not been developed as safety-related products. Therefore, the manufacturer performs a tool assessment and qualification to ensure adequate quality and the suitability for each software-based tools intended use in a design development activity. This document identifies how the V&V assessments are performed on tool outputs to verify that a tool correctly performed its functions. The tool outputs for each design development activity are also subject to project CM. To provide additional confidence in the suitability for intended use, the design tools document also discusses the ALS v2 manufacturers experience with the software-based tools along with broader industry use. Furthermore, following each in-process V&V activity,

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 127 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION which includes the tool output assessments, V&V testing is performed on the programmed FPGA to confirm correct device operation, and this testing represents a verification of the final software-based tools output. The ALS topical report states that the tool assessment and qualification process meets the intent of IEEE Std 7-4.3.2, Section 5.3.2, Software Tools (see Reference 5, Section 12.2.7). As no modifications to the tools or the quality program were made in the ALS v2 submittal (Reference 1), the ALS v2 platform continues to be subject to this claim.

The NRC staff reviewed the ALS v2 V&V Plan (Reference 21) and confirmed that the processes include activities to verify third party software tool versions and to review tool outputs to ensure that the tools perform as expected for the intended use in the design activity. Additionally, as described in the ALS v2 Diversity Analysis (Reference 18), IV&V activities use test and analysis tools that are different than those used in design activities to verify proper operability. This approach provides tool diversity as mitigation against the introduction of an undetected program flaw through either a tool error or incorrect tool operation.

Although the commercially available software tools are not qualified as safety-related due to the lack of full V&V information for the tools and their development, the NRC staff determined that the tool assessment and qualification described within ALS v2 Design Tools satisfies IEEE Std 7-4.3.2-2003, Clause 5.3.2, because the ALS v2 platform manufacturer controls software tools under a CM program, the ALS v2 platform manufacturer implemented a tool validation program to provide confidence that the necessary features of software tools function as required, the ALS v2 platform manufacturer has incorporated methods to detect defects by the software tool within its design and V&V activities, and the ALS v2 platform manufacturer will provide additional confidence in the suitability of tools through operating experience, as applicable to the platforms development.

3.10.2.3.3 IEEE Std 7-4.3.2, Clause 5.3.3 - Verification and Validation Clause 5.3.3 of IEEE Std 7-4.3.2-2003 adopts the terminology of process, activity, and task from IEEE Std 1012-1998, in which software V&V processes are subdivided into activities, which are further subdivided into tasks. Clause 5.3.3 also states that the V&V processes shall address the computer hardware and software, integration of the digital system components, and the interaction of the resulting computer system with the nuclear power plant. The V&V activities and tasks shall include system testing of the final integrated hardware, software, firmware, and interfaces. Clause 5.3.3 requires the software V&V effort to be performed in accordance with IEEE Std 1012-1998, where the V&V requirements for the highest integrity level apply to systems developed using IEEE Std 7-4.3.2-2003.

RG 1.168, Revision 2, endorses IEEE Std 1012-2004, with exceptions, to describe a method acceptable to the NRC staff for complying with the NRCs regulations as they apply to the V&V of safety system software.

The ALS topical report, as amended by Reference 1, states that the V&V process is an integral part of each ALS v2 platform lifecycle (see Reference 5, Sections 12.2.8 and 6). The ALS v2 V&V Plan (Reference 21) defines the techniques, procedures, and methodologies that provide IV&V for ALS v2 projects to meet the requirements defined by IEEE Std 1012-2004 for a Software V&V Plan. The ALS v2 V&V Plan provides a mapping of IEEE Std 1012-2004 V&V activities and tasks to the ALS v2 project efforts (see Reference 21, Table B-1). Additionally, an

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 128 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION ALS v2 Platform FPGA V&V Test Plan is used to define the techniques, procedures, and methodologies that provide IV&V of the ALS v2 platform FPGA logic programs.

Certain IEEE Std 1012-2004 tasks are excluded from this NRC staff evaluation, because the IV&V tasks are beyond the scope of the ALS topical report. The hazard analysis task cannot be fulfilled within the ALS v2 platform scope, because the task is project specific. Other tasks cannot be fulfilled within the ALS v2 platform topical report scope, because the task is not performed on a platform component, such as plant-specific risk analysis, system integration test, system acceptance test, installation, operation, maintenance, and training tasks. In these and similar cases, the ALS v2 V&V Plan defers the IEEE Std 1012-2004 tasks to an applicants or licensees use of the ALS v2 platform.

Given the scope of the ALS v2 Topical Report, the NRC staff determined that the manufacturer will perform V&V for the ALS v2 platform standardized circuit boards and their intended use within a safety-related system in a nuclear power plant as part of its V&V Program.

The evaluation in this SE against IEEE Std 7-4.3.2-2003, Clause 5.3.3 excludes the V&V tasks deferred to plant-specific applications that reference this SE and provides an appropriate plant-specific action to address the deferrals. Applicants and licensees referencing this SE should demonstrate that they have fulfilled the IEEE Std 1012-2004 tasks that have been deferred, as identified in the ALS v2 V&V Plan (see Reference 21, Section 2.2 and Table B-1). Applicants and licensees referencing this SE should ensure that the appropriate activities are included in their project-specific V&V plan and the performance of each activity is acceptably independent.

The project-specific V&V plan should identify any alternative method(s) to IEEE Std 1012-2004 for any IV&V task and demonstrate that the alternative method(s) provides equivalent assurance (see Section 4.2, Item 23).

Based on the NRC staffs evaluation of the ALS v2 platforms V&V tasks, its confirmation against the criteria applicable to the seven standardized circuit boards and associated FPGA programs, and fulfillment of the plant-specific action, the NRC staff concludes that the ALS v2 platform V&V activities and tasks support meeting the criteria of IEEE Std 7-4.3.2-2003, Clause 5.3.3, as applicable to the platforms development.

3.10.2.3.4 IEEE Std 7-4.3.2, Clause 5.3.4 - Independent V&V (IV&V) Requirements Clause 5.3.4 of IEEE Std 7-4.3.2-2003 defines the levels of independence required for the V&V effort covered by Clause 5.3.3 in terms of technical independence, managerial independence, and financial independence. Clause 5.3.4 requires that the individuals or groups that verify and validate the development activities and tests exclude original design developers but possess the appropriate technical competence. Clause 5.3.4 also requires an organization that is separate from the development and program management organizations to be vested with the oversight of IV&V activities and that this IV&V effort include the selection of the following three items: (1) the segments of the software and system to be analyzed and tested, (2) the V&V techniques to be used, and (3) the technical issues and problems upon which to act. Lastly, Clause 5.3.4 requires the IV&V effort to be allocated resources that are independent of the development resources.

RG 1.168, Revision 2, endorses IEEE Std 1012-2004, with exceptions, to describe a method acceptable to the NRC staff for complying with the NRCs regulations as they apply to IV&V.

Specifically, RG 1.168 states that the method described in IEEE Std 1012-2004 is acceptable

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 129 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION for performing IV&V, with the noted exceptions in Section C, Staff Review Guidance of the RG.

For nuclear power plant safety systems, RG 1.168 provides guidance to apply IEEE Std 1012-1998, Annex C, Classical IV&V, from the development for each IV&V task, because RG 1.168 states that the nuclear power plant safety system programming should be assigned an integrity level 4 or equivalent. RG 1.168 goes on to state that the extent of independence between the organization responsible for design and the organization responsible for verification and checking of the design must be verified by the applicant or licensee to meet the NRC requirements contained in Appendix B.

The ALS topical report, as amended by Reference 1, states that the ALS v2 platform V&V process meets V&V technical, managerial, and financial independence from development (see Reference 5, Section 12.2.9 for the ALS platform). The ALS v2 Development Process Topical Report discusses the projects organization and shows that the projects IV&V team is managed independently from the design team (see Reference 8, Section 2). The ALS v2 Development Process Topical Report states that the required training for specific job functions along with associated training records are administered under the WEC QMS (see Reference 27 and Reference 8, Section 7.15).

The ALS v2 V&V Plan (Reference 21) similarly defines the IV&V organization in terms of technical, managerial, and financial independence from development, provides a more detailed explanation of each independence characteristic, and describes that the IV&V teams interface through CM and anomaly reporting to the development effort. The ALS v2 V&V Plan states that the ALS v2 IV&V organization most closely matches the definition of Modified IV&V as defined within IEEE Std 1012-2004, to ensure that the V&V process is not compromised by schedule or resource demands placed on the design process (see Reference 21, Section 3.1, Organization).

The NRC staff reviewed and evaluated the ALS v2 platform documentation governing the independence of V&V from development. The NRC staff confirmed that the ALS v2 platform V&V, as discussed in Section 3.10.2.3.3 of this SE, was technically, managerially, and financially independent from the design and development activities. The NRC staff also confirmed that the ALS v2 platform V&V responsibilities included defining the portions of the FPGA program and ALS v2 platform to analyze and test, establishing the V&V techniques to apply, and deciding upon the technical issues and problems upon which to act. Additionally, the NRC staff confirmed that personnel not involved in the design development and possessing appropriate technical competence, performed the V&V activities, and the V&V resources were sufficiently independent from the development resources for protection and important to safety classified systems (as defined in Table A-1 of Reference 21).

Based on the NRC staffs evaluation of the ALS v2 platforms V&V independence and confirmation of the independence criteria, the NRC staff concludes that the ALS v2 platform V&V activities meet the criteria of IEEE Std 7-4.3.2-2003, Clause 5.3.4, as applicable to the platforms development.

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 130 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION 3.10.2.3.5 IEEE Std 7-4.3.2, Clause 5.3.5 - Software Configuration Management Clause 5.3.5 of IEEE Std 7-4.3.2-2003 requires software CM (SCM) to be performed in accordance with IEEE Std 1042-1987. Clause 5.3.5 also lists nine activities required to be addressed by SCM. These activities specify items that must be identified and controlled, address the control of software design changes, software documentation, software application development activities, and the retrieval of qualification information for software designs and code, and also include software configuration audits and status accounting. Clause 5.3.5 requires the SCM plan to describe the division of responsibility whenever some of its activities are performed or controlled by other QA activities. Clause 5.3.5 also requires software baselines to be established at appropriate points in the software life-cycle process to synchronize engineering and documentation activities and requires approved changes to the baseline.

Clause 5.3.5 further requires the unique identification of each software configuration item and the revision and/or date time stamps for each configuration item. Lastly, Clause 5.3.5 requires that the formal documentation and approval of changes to software/firmware is consistent with the SCM plan. This documentation is required to include the reason for the change, identification of the affected software/firmware, and the impact of the change on the system.

RG 1.169 endorses IEEE Std 828-2005 as it provides an approach that the NRC staff considers to be acceptable for satisfying the agencys regulatory requirements with respect to CM plans for the safety system software, with the exceptions and additions listed in the regulatory positions of the RG.

The ALS topical report, as amended by Reference 1, states that the CM for the ALS v2 platform is addressed in the QA plan and performed throughout the lifecycle (see Reference 8, Sections 7 and 8). The ALS v2 CM Plan defines the change control mechanisms for the ALS v2 platform.

The ALS v2 Development Process Topical Report describes that the IV&V team will evaluate the project deliverables within the ALS v2 topical report scope and states a detailed list of all project deliverables. The administrative controls applied to the FPGA configuration items, including those items released for testing, will be defined in the Configuration Status Accounting documents, also known as the CM Release Records, where there will be a Configuration Status Accounting document that provides platform configuration items and board level configuration items.

The ALS Configuration Management Plan (Reference 25) identifies that the configuration items to be placed under CM, provides CM process and control requirements, identifies individual responsibilities for the change process, and defines the baselining process.

Reference 25 also includes requirements for the identification of documentation, tools, hardware, FPGA logic programs, and standardized circuit board NVM configuration and includes provisions for releasing, archiving, and retrieving configuration items. Furthermore, the CM processes address issue reporting, tracking, and corrective action as they affect configuration items. Lastly, the CM processes and controls are subject to QA activities to ensure the effectiveness of CM activities along with the completeness and correctness of the specified configuration items.

For this ALS v2 platform SE, the Configuration Status Accounting documents will be used to identify configuration controlled items for each ALS v2 board, and an ALS v2 Platform Status Accounting document is used to identify configuration controlled items for the platform. When produced, each ALS v2 boards CM Summary Report should provide a summary of established

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 131 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION configuration-controlled project milestone baselines, identify the boards primary configuration items, identify and explain the corresponding Configuration Status Accounting documentation, and identify unresolved developmental product defects that are part of the ALS v2 project scope. Additionally, a Platform CM Summary Report will be produced and be used to provide an overall configuration status summary for the entire ALS v2 platform.

The NRC staff reviewed and evaluated the ALS Configuration Management Plan (Reference 25). Through these efforts, the NRC staff confirmed that the applicable ALS v2 platform CM activities have been identified and will be controlled. The NRC staff confirmed that the ALS v2 platform CM activities address the control of the FPGA program design changes, FPGA program documentation and development activities, and the retrieval of qualification information for the FPGA program designs and code. Additionally, the NRC staff confirmed that the CM activities include configuration audits and status accounting.

Per Reference 25, the issuance of CM baselines will establish and document specific FPGA program baselines within the development lifecycle. The NRC staff determined that the changes to any configuration-controlled item and the established baseline requires a formal organizational approval that includes the reason for change. The NRC staff also determined that the manufacturers processes include an assessment of the impact of the change and regression testing. Via a review of Reference 25, the NRC staff confirmed that a unique identification should exist for each configuration item along with revision information.

Based on the NRC staffs evaluation of the CM plan documentation related to the ALS v2 platform and planned related CM activities, the NRC staff concludes that the ALS v2 platform FPGA CM activities support meeting the applicable criteria of IEEE Std 7-4.3.2-2003, Clause 5.3.5.

3.10.2.3.6 IEEE Std 7-4.3.2, Clause 5.3.6 - Software Project Risk Management Clause 5.3.6 of IEEE Std 7-4.3.2-2003 requires risk management to be performed at all levels of a digital system project to provide adequate coverage for each potential problem area. Software project risk management should ensure that technical, schedule, or resource-related risks do not compromise software quality goals, and thereby affect the ability of the safety computer system to perform safety related functions. Clause 5.3.6 also lists seven high-level steps that should be included in risk management.

The ALS topical report, as amended by Reference 1, states that the risk management for the ALS v2 platform is described in WCAP-18780-P, ALS v2 Development Process Topical Report. Section 7.16 of the ALS v2 development process topical report describes the risk management approach used for the platform. It states that risks are managed and discussed during regular project meetings and maintained by the project manager.

The mapping of DI&C-ISG-06 provides the information for software project risk management and identifies an Application Management Plan to fully address the topic (refer to Section D.4 of Reference 24). The ALS v2 Development Process Topical Report (Reference 8) states that the project management plan and the WEC QMS (ML20118C995) conducts risk assessments and risk management activities throughout the development process.

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 132 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION As discussed in Section 3.1 of this SE, the ALS v2 platform is FPGA-based and does not contain executable software. Instead, the ALS v2 platform contains devices that are programmable (FPGAs and NVM). The characteristics of the ALS v2 platform necessitate an appropriate tailoring of IEEE 7-4.3.2, Software Risk Management, for applicability to the platform, and this tailoring includes licensee-specific risk management activities, because an Application Management Plan is required by each applicant or licensee referencing this SE.

The ALS v2 V&V Plan contains provisions for management of FPGA development risks, including risk and hazard analysis activities performed during each phase of development and risk reports during project meetings. The risk and hazard analysis activities are designed to reduce the risks associated with undetected flaws introduced during development activities.

Risk mitigating activities will need to be defined within the plans and procedures that govern the ALS v2 platform design and development.

Although the ALS topical report, as amended by Reference 1, does not fully address IEEE Std 7-4.3.2-2003, Clause 5.3.6, the NRC staff determined that the ALS v2 platform supports meeting the requirements of IEEE Std 7-4.3.2-2003, Clause 5.3.6. This determination is based on the inclusion of specified reviews and testing activities within the Electronics Development Procedure and the FPGA Development Procedure, which were reviewed as documented in the original ALS platform SE (Reference 5). Meetings to regularly address risk and the risk mitigation techniques are also described within the ALS v2 V&V Plan. Nevertheless, a plant-specific action is necessary when the ALS v2 platform is used for a safety system. This plant-specific action should ensure that Clause 5.3.6 is met, and this should include an applicant or licensee analysis that confirms that the Application Management Plan adequately addresses the list of steps identified within IEEE Std 7-4.3.2-2003, Clause 5.3.6.

3.10.2.4 IEEE Std 7-4.3.2, Clause 5.4 - Equipment Qualification Clause 5.4 of IEEE Std 7-4.3.2-2003 contains two subclauses necessary to qualify digital computers for use in safety systems. These subclauses are in addition to the EQ criteria provided in IEEE Std 603.

3.10.2.4.1 IEEE Std 7-4.3.2, Clause 5.4.1 - Computer System Testing Clause 5.4.1 of IEEE Std 7-4.3.2-2003 requires that computer system qualification testing be performed with the computer functioning with software and diagnostics that are representative of those used in actual operation. Clause 5.4.1 also requires that all portions of the computer necessary to accomplish safety functions, or those portions whose operation or failure could impair safety functions, be exercised during testing. This testing is required to demonstrate that the performance requirements related to the safety functions have been met.

As discussed in Section 3.1 of this SE, the ALS v2 platform is FPGA-based and does not contain executable software. Therefore, there is no ALS v2 platform software to run during system testing. The ALS-152 Core Logic Boards installed FPGA ((

)) requires application-specific programming in order to represent the final operational configuration.

Nevertheless, the ALS v2 platforms FPGAs are programmed in a manner similar to a conventional microprocessor-based software program development, which provides similar versatility and potential weaknesses. Because of these similarities, the NRC staff determined

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 133 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION that to meet IEEE Std 7-4.3.2-2003, Clause 5.4.1, the qualification testing needs to include type-testing with FPGA and an NVM programming representative of an operational configuration.

The manufacturer will perform EQ testing using the type testing approach, which used a representative set of FPGA logic on each standardized circuit board. The qualification testing will demonstrate the ALS v2 platform performance for a range of normal and anticipated worst case mild environment conditions and established limitations and conditions for use of the ALS v2 platform. Limitations and conditions identified during the qualification testing will include plant-specific actions to ensure that an applicants or licensees installation environment has been sufficiently bounded by EQ tests and that the acceptance criteria used during the ALS v2 platform type testing is sufficient to identify portions of the ALS v2 platform that could operate or fail in a way that would impair a plant-specific safety systems safety function.

To support the extension of platform EQ to plant-specific applications, as discussed in the original ALS topical report submittal (Reference 1), the manufacturer will perform an ALS v2 Platform Qualification Evaluation. The ALS v2 Platform Qualification Evaluation is intended to address the potential for gaps between the ALS v2 platform capabilities and those that may be considered satisfactorily qualified through a representative type test because the ALS v2 platform has capabilities for a variety of configurations and options, but the type test only provides a representative configuration. The ALS v2 Platform Qualification Evaluation is also intended to identify exclusions, constraints on ALS v2 platform interfaces, restrictions on use, and plant-specific evaluations which the applicants should address for it to be considered covered by the EQ tests.

The NRC staff did not review the EQ test processes and could not confirm that the test methods will include a notional safety system application on the ALS-152 board and did not exercise the diagnostics representative of those intended for actual operations. However, as those activities occurred during the original ALS Topical Report submittal (see Reference 5) and no changes were made to the EQ program based on a review of the docketed ALS v2 Platform documents (see Reference 1), it is reasonable to conclude that the EQ program for the ALS v2 platform will be carried out in a similar manner as its predecessor. For the EQ type testing, the manufacturer should identify that the ALS v2 platform functions are considered necessary to accomplish the safety functions. The EUT should be monitored during tests for diagnostic failures. Test activities should also include baseline tests to confirm its continued operability of the ALS v2 platform functions identified as necessary to accomplish the safety functions.

Section 3.3 of this SE addresses the EQ plan for the ALS v2 platform and identifies plant-specific actions associated with establishing platform EQ levels and extending the EQs for specific applications.

Based on the NRC staffs evaluation documented in Section 3.3 of this SE, fulfillment of its associated plant-specific actions, and confirmation that type tested components exercised diagnostics representative of those intended for actual operations, the NRC staff concludes that the ALS v2 platform system supports the construction of a safety system to meet the criteria of IEEE Std 7-4.3.2-2003, Clause 5.4.1.

3.10.2.4.2 IEEE Std 7-4.3.2, Clause 5.4.2 - Qualification of Existing Commercial Computers

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 134 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION Clause 5.4.2 of IEEE Std 7-4.3.2-2003 requires that the qualification process for existing commercial computers be accomplished by evaluating the hardware and software design using the criteria of this standard. Clause 5.4.2 also requires the acceptance to be based on evidence that the digital system or component, including hardware, software, firmware, and interfaces, can perform its required functions where the acceptance and its basis shall be documented and maintained with the qualification documentation. Clause 5.4.2 and its several subclauses go on to describe the commercial grade dedication process and specify requirements for that process.

The ALS v2 platform manufacturer dedicated some commercial suppliers as a service under its Appendix B program (e.g., for the manufacture of bare PCBs, etc.). Regardless, as discussed in Sections 3.1 and 3.9.2.3 of this SE, the ALS v2 platform was developed under a 10 CFR Part 50, Appendix B, program specifically for the nuclear power industry and is, therefore, not considered commercial grade digital equipment. Accordingly, this requirement is not applicable to the review of the ALS v2 platform.

3.10.2.5 IEEE Std 7-4.3.2, Clause 5.5 - System Integrity Clause 5.5 of IEEE Std 7-4.3.2-2003 contains three subclauses necessary to achieve system integrity in digital equipment for use in safety systems. These subclauses are in addition to the system integrity criteria provided in IEEE Std 603.

3.10.2.5.1 IEEE Std 7-4.3.2, Clause 5.5.1 - Design for Computer Integrity Clause 5.5.1 of IEEE Std 7-4.3.2-2003 requires that the computer be designed to perform its safety function when subjected to conditions, external or internal, that have significant potential for defeating the safety function. Clause 5.5.1 further requires the ability to place the safety system in its preferred failure mode in the presence of a computer failure. Lastly, Clause 5.5.1 requires the retention of the safety systems ability to perform its safety functions when a computer system restart operation occurs.

The manufacturer is designing the ALS v2 platform to handle anticipated external and internal conditions, and the ALS v2 platform should contain design features and capabilities to ensure that a safety system maintains full integrity when subjected to these conditions. The manufacturer described its modes and states for the ALS platform and the classification of failures and the effect of failures on the system. The manufacturer also described digital communication design that contains provisions to address conditions with the potential to defeat a safety function (see Reference 5, Section 12.2.13.1). During the ALS review, the NRC staff reviewed these descriptions along with supporting requirement and specification documents.

Based on a review of the material placed on the docket for the ALS v2 platform, the same process will be used for its implementation and testing.

Unlike microprocessor-based computer systems, to which Clause 5.5.1 of IEEE Std 7-4.3.2-2003 typically applies, the ALS v2 platform does not contain general use computer hardware. It is expected that the ALS v2 platform restart operation should occur much faster than a microprocessor-based computing system because the ALS v2 platform FPGA logic does not load either an operating system, software drivers for peripheral devices, or an executable software program. However, it should be noted that it is possible that with the use of

] the restart sequence for the ALS v2 platform may not be as rapid as that of its ALS counterpart. Additionally, the ALS v2 platform FPGA logic self-

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 135 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION diagnostics that run on restart should complete much faster than a typical microprocessor-based computers startup diagnostics.

Although the ALS v2 platform scope does not provide a specific safety system with a preferred failure mode, the NRC staff determined that the ALS v2 platform includes design features to establish a preferred failure mode through plant-specific configuration data and in response to established internal and external conditions. Through its requirements and specifications, the ALS v2 platform contains provisions to enter a fail-safe state defined by the plant-specific configuration and to force a channels output to a defined state using the maintenance workstation. The ALS v2 platform also supports plant-specific safety system configurations that provide redundancy, so no single failure has the potential to defeat the safety function. The ALS v2 platform scope excludes the use of a multi-divisional workstation and contains provisions to ensure that no nonsafety equipment can provide data to a safety channel unless the channel indicates it is in an inoperable state (e.g., indicating failure, in bypass, undergoing calibration, etc.). Additionally, plant-specific programming of the ALS-152 board allows the further establishment of conditions for entry into a fail-safe state that is conservative with respect to a systems safety function. To further address external conditions, the ALS v2 platform hardware and representative FPGA logic are subjected to the EQ discussed in Section 3.3 of this SE.

In the original ALS Topical Report SE, the NRC staff confirmed that the manufacturers processes incorporated requirements and specifications for computer integrity features, including identification of internal and external conditions, fail-safe states, and support for redundancy, which are traced through requirements and to IV&V activities. As no changes were made to these processes in the ALS v2 submittal (Reference 1), the NRC staff concludes that the same processes should prove to be sufficient.

Based on the NRC staffs determinations and confirmations in this section, the NRC staff concludes that the ALS v2 platform system supports the construction of a safety system to meet the criteria of IEEE Std 7-4.3.2-2003, Clause 5.5.1 because the ALS v2 platform contains design features and capabilities to ensure that a safety system can maintain its full integrity when subjected to the internal and external conditions, including an environmental envelope to be established during platform environmental testing.

3.10.2.5.2 IEEE Std 7-4.3.2, Clause 5.5.2 - Design for Test and Calibration With the exclusion of an appropriate bypass of one redundant channel being in place, Clause 5.5.2 of IEEE Std 7-4.3.2-2003 prohibits test and calibration functions from creating any adverse effects on the ability of the computer to perform its safety function. Clause 5.5.2 also requires verification that the test and calibration functions do not affect the computer functions that were not included in a calibration change. When the sole verification of test and calibration data is provided on a separate computer, Clause 5.5.2 requires V&V, CM, and QA for the test and calibration functions of the separate computer. Likewise, Clause 5.5.2 requires V&V, CM, and QA when the test and calibration function is built into the safety system computer. In other words, the only case where V&V, CM, and QA for test and calibration functions would not be required would be when these functions reside on a separate computer and do not provide the sole verification of the test and calibration data for the safety system computer.

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 136 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION The ALS v2 platform scope does not include a separate computer to provide the verification of test and calibration data. Additionally, the ALS v2 platform scope does not establish whether a licensee might solely rely on a separate computer to provide the verification of test and calibration data for a future ALS v2-based safety system. Therefore, this SE excludes these aspects of Clause 5.5.2 of IEEE Std 7-4.3.2-2003.

For each standardized circuit board, test and calibrations features are discussed in the specifications for that board. The ALS v2 platform incorporates the test and calibration features to provide a means to bypass channels during surveillance testing, setpoint changes, and calibration. The ALS v2 platform also incorporates features to provide a means to force a channels output to a defined state. Furthermore, the ALS v2 platform allows a maintenance workstation to access configuration data, which includes setpoint and calibration data, when a channel is bypassed. Sections 3.2 through 3.6 of the ALS topical report, as amended by Reference 1, discuss the capabilities of the test and calibration for an overall system. The manufacturer designed these test and calibration functions so that the functions do not impede the safety functions of a system. Furthermore, the manufacturer incorporated the test and calibration functions within the initial product specifications and subsequently developed the associated FPGA programming following its safety-related development process (see Reference 5, Sections 3 and 12.2.13.2). The manufacturer also included the test and calibration functions within its type testing of the ALS v2 platform standardized circuit boards during EQ.

Section 3.3 of this SE provides the NRC staffs evaluation of the ALS v2 platform EQ.

Unlike microprocessor-based computer systems, to which Clause 5.5.2 of IEEE Std 7-4.3.2-2003 typically applies, the ALS v2 platform does not contain executable software that uses shared processing resources (e.g., processor, processing registers, cache memory, etc.).

Instead, an ALS v2 platform standardized circuit board performs individual functions supported through distinct FPGA logic, and each individual function does not share its FPGA logic resources with other functions. Within the ALS v2 platform, test and calibration function logic neither uses the safety signal paths Reliable ALS Bus nor competes with safety function logic for FPGA logic resources.

The NRC staff confirmed that the manufacturers processes include the incorporation of requirements and specifications for test and calibration functions, which are traced through requirements and to IV&V activities.

The NRC staff determined that the ALS v2 platform test and calibration will not impede the safety function of an ALS v2-based safety system, because the self-diagnostic functions do not compete with safety functions for the safety signal path or FPGA programming resources, the platform provides features to limit test and calibration functions to bypassed or inoperable channels, and EQ activities verified the continued operability of the ALS v2 platforms safety functions and the safety signal path for FPGA logic that included the test and calibration functions. The NRC staff also confirmed that the manufacturer follows fundamentally the same design, development, and IV&V processes for the test and calibration functions as for all other ALS v2 platform functions. Based on these NRC staff determinations and confirmations, the NRC staff concludes that the ALS v2 platform meets the applicable criterion in IEEE Std 7-4.3.2-2003, Clause 5.5.2. Nevertheless, any licensee who relies on a separate computer for the sole verification of test and calibration data should ensure adequate V&V, CM, and QA for the test and calibration functions of the separate computer.

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 137 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION 3.10.2.5.3 IEEE Std 7-4.3.2, Clause 5.5.3 - Fault detection and Self-diagnostics Clause 5.5.3 of IEEE Std 7-4.3.2-2003 provides reliability requirements for a safety system to determine the need and scope of self-diagnostics. Clause 5.5.3 does not require self-diagnostics for systems in which failures can be detected by alternative means in a timely manner. When self-diagnostics are built into the safety system, then Clause 5.5.3 requires these functions to be subject to the same V&V processes as the safety system functions. If reliability requirements warrant self-diagnostics, then Clause 5.5.3 requires the computer programs to incorporate functions to detect and report the computer system faults and failures in a timely manner. Clause 5.5.3 also prohibits self-diagnostic functions from adversely affecting the ability of the computer system to perform its safety function or causing spurious actuations of the safety function. Lastly, whenever self-diagnostics are applied, Clause 5.5.3 requires the system design to address: (1) self-diagnostics performed during system startup, (2) self-diagnostics performed periodically while the computer system is operating, and (3) failure reporting of the self-diagnostic results.

Based on a review of the original ALS Topical Report (Reference 5) and Reference 1, which states that no changes were made to how the diagnostics would be implemented, the NRC staff determined that the ALS v2 platform will continue to incorporate self-diagnostic features to provide a means to detect and alert any failure within the ALS v2 platform in a similar fashion to the original ALS Platform. For each standardized circuit board, these self-diagnostic features are discussed in Reference 5 (and allowing for the board number changes) and in the specifications for that board. These specifications include startup tests, periodic tests, and reporting of test results. Section 2 of the ALS topical report, as amended by Reference 1, discusses the capabilities of fault detection and self-diagnostics for an overall system. The manufacturer designed these self-diagnostic functions so that the functions do not impede the safety functions of a system. Furthermore, the manufacturer incorporated self-diagnostic functions within the initial product specifications and subsequently developed the associated FPGA programming following its safety-related development process (see Reference 5, Section 12.2.13.3). The manufacturer also includes the self-diagnostic functions within its type testing of the ALS v2 platform standardized circuit boards during EQ. Section 3.3 of this SE provides the NRC staffs evaluation of the EQ.

The manufacturer predicted the reliability for each standardized circuit board and analyzed the ability of self-diagnostics to detect failures. Section 3.6 of this SE provides the NRC staffs evaluation of ALS v2 platform reliability and availability, and Section 3.4.3 of this SE provides the NRC staffs evaluation of ALS v2 platform self-diagnostic capabilities. However, the reliability and failure detection analyses are not based on a specific safety system. Therefore, the manufacturer did not establish the need and scope of the self-diagnostics based on reliability requirements of a specific safety system. Instead, the manufacturer established ALS v2 platform requirements and specifications for reliability and self-diagnostics in general terms.

As discussed within Section 3.6 of this SE, plant-specific actions are necessary to confirm that the plant-specific configuration of an ALS v2-based safety system produces adequate safety system reliability.

Unlike microprocessor-based computer systems, to which Clause 5.5.3 of IEEE Std 7-4.3.2-2003 typically applies, the ALS v2 platform does not contain executable software that uses shared processing resources (e.g., processor, processing registers, cache memory, etc.).

Instead, an ALS v2 platform standardized circuit board performs individual functions supported

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 138 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION through distinct FPGA logic, and each individual function does not share its FPGA logic resources with other functions. Within the ALS v2 platform, self-diagnostic function logic does not compete with the safety function logic for FPGA logic resources.

The NRC staff confirmed that the manufacturers processes incorporated requirements and specifications for self-diagnostic functions, which are traced through requirements and to IV&V activities.

The NRC staff determined previously that the ALS platform self-diagnostics will not impede the safety function of the system, because the self-diagnostic functions do not compete with the safety functions for FPGA programming resources and EQ will demonstrate continued operability of the platforms safety functions and safety signal path while the self-diagnostics are operable. In the original SE, the NRC staff confirmed that the manufacturer included the specifications for the self-diagnostic functions at power-up and periodically, along with failure result reporting capabilities. The NRC staff also confirmed that the manufacturer followed fundamentally the same design, development, and IV&V processes for self-diagnostic functions as for all other ALS-based platform functions. As no changes were made to how the diagnostics for the ALS v2 platform will be developed and based on information in Table 5-1 of Reference 9, the NRC staff conclusions of the original ALS SE as they relate to diagnostics remain valid. Based on these NRC staff determinations, the NRC staff concludes that the ALS v2 platform meets the criterion in IEEE Std 7-4.3.2-2003, Clause 5.5.3 with the exception of using reliability requirements of the safety system to establish the need and scope of self-diagnostics. Nevertheless, the NRC staff further concludes that plant-specific actions provided in Section 3.6 of this SE will be sufficient to provide an equivalent assurance that the entirety of IEEE Std 7-4.3.2-2003, Clause 5.5.3 can be met for an ALS v2-based safety system.

3.10.2.6 IEEE Std 7-4.3.2, Clause 5.6 - Independence Clause 5.6 of IEEE Std 7-4.3.2-2003 prohibits data communication between safety channels or between safety and nonsafety systems from inhibiting the performance of the safety function.

Clause 5.6 also recognizes that the software directly associated with the performance of a safety function and other nonsafety software may reside on the same computer or use common resources. In order to ensure that the nonsafety software does not adversely affect the safety software, Clause 5.6 identifies two approaches to address the issue: (1) inclusion of barrier requirements to provide adequate confidence that the nonsafety functions cannot interfere with the performance of the safety functions of the software or firmware, where the barriers shall be designed in accordance with the requirements of the standard while the nonsafety software is not required to meet these requirements and (2) if barriers between the safety software and nonsafety software are not implemented, then the nonsafety software functions are required to be developed in accordance with the requirements of this standard.

SRP Chapter 7, Appendix 7.1-D, Section 5.6, Independence, provides acceptance criteria for safety and nonsafety software and communications independence. This section points out that 10 CFR Part 50, Appendix A, GDC 24, states that the protection systems must be separated from the control systems to the extent that failure of any single control system component or channel, or failure or removal from service of any single protection system component or channel that is common to the control system, leaves intact a system meeting all reliability, redundancy, and independence requirements of the protection system, and interconnection of the protection and control systems shall be limited so as to assure that safety is not significantly

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 139 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION impaired. SRP Chapter 7, Appendix 7.1-D, Section 5.6, Independence also provides acceptance criteria for nonsafety software and equipment development where barriers do not exist between safety and nonsafety software or equipment.

DI&C-ISG-04, Task Working Group #4: Highly-Integrated Control Rooms - Communications Issues (HICRc), Revision 1, describes the methods acceptable to the NRC staff to prevent adverse interactions among safety divisions and between safety-related equipment and equipment that is not safety-related. This guidance directly addresses most of IEEE Std 7-4.3.2-2003, Clause 5.6.

Unlike microprocessor-based computer systems, to which Clause 5.6 of IEEE Std 7-4.3.2-2003 typically applies, the ALS v2 platform does not contain executable software that uses shared processing resources (e.g., processor, processing registers, cache memory, etc.). Instead, an ALS v2 platform standardized circuit board performs the individual functions supported through distinct FPGA logic, and each individual function does not share its FPGA logic resources with other functions. The scope of the ALS topical report, as amended by Reference 1, does not include electrical isolation requirements between safety and nonsafety equipment. Therefore, this SE does not address meeting the electrical isolation requirements beyond the creation of a PSAI. The ALS topical report, as amended by Reference 1, addresses Clause 5.6 of IEEE Std 7-4.3.2-2003 within Reference 5, Section 12.2.14.

Section 3.7 of this SE addresses Section 5 of the ALS topical report, as amended by Reference 1, using the guidance within DI&C-ISG-04. Section 3.9.2.6 of this SE addresses ALS topical report Section 12.1.7 for compliance to IEEE Std 603-1991, Clause 5.6, Independence.

Both evaluations include plant-specific actions. This is because the prohibition against data communication between safety channels or between safety and nonsafety systems from inhibiting the performance of the safety function must be addressed based on each plant-specific application of the ALS v2 platform.

Sections 3.7 and 3.9.2.6 of this SE address IEEE Std 7-4.3.2-2003, Clause 5.6 with the exception of its contingency for nonsafety software functions to be developed in accordance with safety function requirements when no barrier exists. However, the manufacturer has developed all FPGA programming within the scope of the ALS topical report, as amended by Reference 1, using the same safety-related development process without regard to whether the function is safety or nonsafety.

The NRC staff determined that the ALS v2 platform supports meeting IEEE Std 7-4.3.2-2003, Clause 5.6 based on the evaluations and fulfillment of the PSAIs provided within Sections 3.7 and 3.9.2.6 of this SE, and because the ALS v2 platform design applies the same safety-related development processes to all FPGA programming, which includes programming that does not perform a safety function.

3.10.2.7 IEEE Std 7-4.3.2, Clause 5.7 - Capability for Test and Calibration Clause 5.7 of IEEE Std 7-4.3.2-2003 states that no requirements beyond those found in Clause 5.7 of IEEE Std 603 are necessary. The NRC staffs review of the ALS v2 platform against the requirements found in Clause 5.7 of IEEE Std 603-1991 is addressed in Section 3.9.2.7 of this SE.

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 141 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION application-specific system (see Reference 5, Sections 2.1.5.2 and 2.5.2). These attributes address the first portion of IEEE Std 7-4.3.2-2003, Clause 5.11.

The ALS v2 platform contains features that include FPGA and NVM version identifiers, which may be viewed using maintenance equipment to confirm the configuration of the installed equipment. This information is stored in a section of the NVM device that is configured by the manufacturer and non-modifiable by the end user (see Reference 5, Section 2.1.5.2, Table 2.1-2). The system and board information provides details about the configuration of an ALS v2 system. This information includes board FPGA programming, board build information, and the boards configuration (see Reference 5, Section 2.6.3). These features address the second portion of IEEE Std 7-4.3.2-2003, Clause 5.11.

Section 3.9.2.11 of this SE addresses compliance to IEEE Std 603 general physical identification requirements for hardware, which includes digital hardware. Therefore, no further NRC staff evaluation is required to address the third portion of IEEE Std 7-4.3.2-2003, Clause 5.11.

The NRC staff evaluated the ALS v2 platform design features against each portion of Clause 5.11 of IEEE Std 7-4.3.2-2003 and the acceptance criteria described in SRP Chapter 7, Appendix 7.1-D, Section 5.11. Based on this evaluation, the NRC staff determined that the ALS v2 platform design features support meeting the requirements in Clause 5.11 of IEEE Std 7-4.3.2-2003.

3.10.2.12 IEEE Std 7-4.3.2, Clause 5.12 - Auxiliary Features Clause 5.12 of IEEE Std 7-4.3.2-2003 states that no requirements beyond those found in Clause 5.12 of IEEE Std 603 are necessary. The NRC staffs review of the ALS v2 platform against the requirements found in Clause 5.12 of IEEE Std 603-1991 is addressed in Section 3.9.2.12 of this SE.

3.10.2.13 IEEE Std 7-4.3.2, Clause 5.13 - Multi-Unit Stations Clause 5.13 of IEEE Std 7-4.3.2-2003 states that no requirements beyond those found in Clause 5.13 of IEEE Std 603 are necessary. The NRC staffs review of the ALS v2 platform against the requirements found in Clause 5.13 of IEEE Std 603-1991 is addressed in Section 3.9.2.13 of this SE.

3.10.2.14 IEEE Std 7-4.3.2, Clause 5.14 - Human Factors Considerations Clause 5.14 of IEEE Std 7-4.3.2-2003 states that no requirements beyond those found in Clause 5.14 of IEEE Std 603 are necessary. The NRC staffs review of the ALS v2 platform against the requirements found in Clause 5.14 of IEEE Std 603-1991 is addressed in Section 3.10.2.14 of this SE.

3.10.2.15 IEEE Std 7-4.3.2, Clause 5.15 - Reliability When IEEE Std 603 reliability goals are identified, Clause 5.15 of IEEE Std 7-4.3.2-2003 requires proof that the goals are met, including software. Clause 5.15 also identifies two potential methods that may be used for determining reliability which are: (1) combinations of

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 142 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION analysis, field experience, or testing and (2) software error recording and trending in combination with analysis, field experience, or testing.

The manufacturer treats its FPGA programs as hardware for reliability purposes. Furthermore, the manufacturer relies on the adequacy of the overall set of V&V activities in conjunction with its development processes to provide sufficient reliability (see Reference 5, Section 12.2.23).

The manufacturers FPGA development procedures include regression testing of FPGA programs along with evaluations of any future FPGA program change to ensure that the change does not adversely affect the previously established reliability through EQ testing.

The ALS topical report, as amended by Reference 1, does not fully address Clause 5.15 of IEEE Std 7-4.3.2-2003, because the IEEE Std 603 reliability goals are both plant and application-specific. Nevertheless, the NRC staff evaluated the ALS v2 platform for its ability to meet this clause.

Unlike microprocessor-based computer systems, to which Clause 5.15 of IEEE Std 7-4.3.2-2003 typically applies, the NRC staff agrees that the ALS v2 platform does not contain separate and distinct executable software. Although the ALS v2 platform does not provide separate and distinct executable software, the manufacturer will subject the functions and circuits associated with the FPGA logic to a reliability analysis (see Section 3.6 of this SE).

Furthermore, per Reference 9 and Reference 8, the manufacturer will perform simulation testing and other IV&V activities on each FPGA program along with EQ testing on a representative set of FPGA programs. During these activities, error recording and corrective actions associated with error reporting will be maintained and tracked without unique treatment of the FPGA programs.

The ALS v2 platform contains identification features that will include project-specific FPGA version and NVM configuration version identifiers in addition to the standardized circuit board

((

)) hardware revision identifiers. The FPGA and NVM version identifiers may be viewed using maintenance equipment (see Section 3.10.2.11 of this SE), and the set of version identifiers support error recording, tracking, and trending for fielded equipment.

Although the ALS topical report, as amended by Reference 1, does not fully address Clause 5.15 of IEEE Std 7-4.3.2-2003, the NRC staff determined that the ALS v2 platform supports meeting the requirements in Clause 5.15 of IEEE Std 7-4.3.2-2003. This determination is based on the platform development activities, which include reliability analyses along with error recording and tracking, and platform design features, which include FPGA, NVM, and hardware version identification. Nevertheless, evaluation of this clause requires plant-specific action. Therefore, the NRC staff also agrees that the evaluation of this clause is plant-specific and application-specific. As such, no broader NRC staff determination is appropriate for the ALS v2 platform to address Clause 5.15 of IEEE Std 7-4.3.2-2003, and a plant-specific action is necessary to ensure that Clause 5.15 is met for each future ALS v2 platform application of a safety system. Furthermore, to ensure adequate error reporting, tracking, and trending for fielded equipment, licensee purchase orders should specify 10 CFR Part 21 reporting requirements and should ensure that the licensee Appendix B supplier requirements for safety-related uses of the ALS v2 platform promulgate to sub-suppliers, because the manufacturer has indicated that it will act as an Appendix B supplier (see Section 3.9.2.3 of this SE).

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 143 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION 3.10.3 IEEE Std 7-4.3.2, Section 6 - Sense and Command Features Functional and Design Requirements Section 6 of IEEE Std 7-4.3.2-2003 states that no requirements beyond those found in Section 6 of IEEE Std 603 are necessary. The NRC staffs review of the ALS v2 platform against the requirements found in Section 6 of IEEE Std 603-1991 is addressed in Section 3.9.3 of this SE.

3.10.4 IEEE Std 7-4.3.2, Section 7 - Execute Features - Functional and Design Requirements Section 7 of IEEE Std 7-4.3.2-2003 states that no requirements beyond those found in Section 7 of IEEE Std 603 are necessary. The NRC staffs review of the ALS v2 platform against the requirements found in Section 7 of IEEE Std 603-1991 is addressed in Section 3.9.4 of this SE.

3.10.5 IEEE Std 7-4.3.2, Section 8 - Power Source Requirements Section 8 of IEEE Std 7-4.3.2-2003 states that no requirements beyond those found in Section 8 of IEEE Std 603 are necessary. The NRC staffs review of the ALS v2 platform against the requirements found in Section 8 of IEEE Std 603-1991 is addressed in Section 3.9.5 of this SE.

3.11 Platform Generic Change Process Section 6 of the ALS v2 Platform Topical Report (Reference 9) states that the quality procedure controlling configuration control describes methods that will be used to screen and evaluate changes made to the ALS v2 platform components, logic, or processes. This process is intended to ensure that all safety conclusions made by the NRC staff remain valid when changes are made to the ALS v2 platform.

These generic change processes describe methods used by WEC to screen and evaluate proposed changes to the digital I&C platform components, logic, or processes defined within the platform topical reports, subsequent to the NRC staffs review and approval. These processes define criteria to be used for the determination of whether the safety conclusions of the NRC SE remain valid following any proposed changes or if the changes will require a submittal to the NRC staff for evaluation and approval prior to any implementation (i.e., if the proposed changes invalidate any conclusions made, a submittal to the NRC staff would be required).

The Common Q platform generic change process is included as a reference within this SE (i.e.,

Reference 30) as the Common Q platform generic change process was used as an input for managing some ALS platform changes and provided restrictions for the original platform. In this case, using the reference provides future reviewers of ALS v2 applications that reference this SE with analogous information discussing the methods that may be used by WEC to evaluate and document changes to platform components, logic, and processes defined within the ALS v2 platform and Development Process topical reports (Reference 1). It is also beneficial for reviewers of ALS v2 applications to have access to the WEC generic change process in order to interpret the information provided in the documentation to support platform changes and will be managed via a PSAI (see Section 4.2, Item 24).

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 144 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION 4.0 LIMITATIONS AND CONDITIONS For each generic open item and plant-specific action item that applies to the applicants or licensees use of the ALS v2 platform, applicants and licensees referencing this SE should demonstrate that they have satisfactorily addressed the applicable items. The set of applicable items provide limitations and conditions for the ALS v2 platforms use, as reviewed by the NRC staff and documented within this SE.

Applicant or licensee information requirements in consideration of SRP Chapter 7, Table 7.1, Regulatory Requirements, Acceptance Criteria, and Guidelines for Instrumentation and Control Systems Important to Safety, will need to be considered during licensing evaluations of systems using the ALS v2 platform.

4.1 Generic Open Items The NRC staff identified the following generic open items to be addressed by an applicant or licensee referencing this SE for the installation of a safety-related system based on the ALS v2 platform.

1. Platform EQ Testing - Because platform EQ testing, including component testing, was not completed at the time of this SE, the use of the ALS v2 platform equipment is contingent upon the completion of the equipment testing (e.g., Environmental, Seismic, EMC, and isolation testing) in accordance with the EQ test plan (Reference 10) in addition to PSAI 6 below.

2. Category 3 and 5 Enhancements - The ALS platform changes for the ALS v2 are comprised of six categories of enhancements. The scope of the ALS v2 topical report (Reference 1) includes only Categories 1, 2, 4, and 6, as they support digital I&C upgrades for current operating nuclear power plants. Categories 3 and 5 enhancements have a later development lifecycle and are not included for evaluation by the NRC staff in this SE. The NRC staffs review and approval of these Categories 3 and 5 ALS v2 changes must therefore be performed at a future time, prior to the implementation of these enhancements in nuclear safety-related applications.

3. Configuration Management Summary Report - Because the CM Summary Reports for the platform and the seven board types were not available at the time of this SE, the use of the ALS v2 platform equipment is contingent upon the report providing documentary evidence that proper configuration controls, in accordance with the manufacturers CM Plan, have been applied during development.

4. V&V Program - The commitment by the manufacturer to comply with IEEE 1012-2004 could not be verified at the time of this SE, because limited documentation was presented to the NRC staff to verify the conformance to IEE 1012-2004. Thus, the use of the ALS v2 platform equipment is contingent upon the evaluation of the V&V reports (e.g., V&V Phase Summary Reports) providing documentary evidence that proper V&V programmatic controls were in place during platform development in accordance with the manufacturers V&V Program.

4.2 Plant-Specific Action Items

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 145 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION The following plant-specific actions should be performed by an applicant or licensee referencing this SE for a safety-related system based on the ALS v2 platform.

1. Application-specific ALS-152 Requirements Specification(s) - An applicant or licensee referencing this SE should demonstrate that it has provided the application specification(s) to govern each unique ALS-152 FPGA logic programs development.

2. Application Conformance to ALS v2 Platform Development Process - An applicant or licensee referencing this SE should demonstrate that the development of its application-specific ALS-152 FPGA logic programs followed a development process equivalent to the one described and evaluated in Section 3.2.2 of this SE.

3. Application Conformance to Embedded Design Diversity Development Process -

When an applicant or licensee referencing this SE specifies Embedded Design Diversity, the applicant or licensee should demonstrate that the development of its application-specific ALS-152 FPGA logic programs followed the equivalent development processes to those described and evaluated in Section 3.2.1.4. of this SE. This demonstration should include the production and configuration control of the related life-cycle development products.

4. ALS v2 Platform Boundary/Interface Conditions and Installation Limitations - An applicant or licensee referencing this SE should address its conformance to or deviations from any manufacturer identified boundary/interface conditions and installation limitations established by an ALS v2 Platform EQ Summary Report. An applicant or licensee referencing this SE should identify the applicability of each condition and limitation. For each applicable condition or limitation, the applicant or licensee should either demonstrate its conformance or provide justification for any deviation. For a deviation, an applicant or licensee should demonstrate that the deviation does not invalidate the ALS v2 platform qualification in a manner adverse to the reliable performance of a safety function. Such demonstrations that deviations are justified should consider the performance of supplemental testing, supplemental analysis, or both.

5. ALS v2 Platform Application Restrictions ALS v2 Platform Application Restrictions - An applicant or licensee referencing this SE should address its adherence to the manufacturer identified application restrictions within a platform application guidance document for the ALS v2 Application Guidance and verify restrictions against those in the original platform application restriction document that still apply (see Reference 20). An applicant or licensee referencing this SE should identify the applicability of each restriction. For each applicable restriction, the applicant or licensee should either demonstrate its adherence or provide the justification for excluding the restriction. For any exclusion, an applicant or licensee should also demonstrate that the exclusion does not invalidate the ALS v2 platform qualification in a manner adverse to the reliable performance of a safety function.

Such demonstrations should consider the performance of supplemental testing, supplemental analysis, or both.

6. Demonstration of Equipment Qualification - An applicant or licensee referencing this SE should demonstrate that the platform component EQ testing shows that the equipment is qualified for operation at the specific plant installation environment. Otherwise, additional plant-specific EQ efforts should be performed, which may include analyses and/or tests. If an applicant or licensee cannot demonstrate that the ALS EQ is valid and bounding, then the applicant or licensee should demonstrate that the plant-specific qualification efforts are

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 146 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION bounding. The demonstration should identify that the NVM Configuration for each ALS v2 standardized circuit board it uses and the EQ that shows the circuit boards performance has been bounded for each application-specific configuration.

7. Response Time Performance - As discussed within Section 3.4.1 of this SE, an applicant or licensee referencing this SE should: (1) establish application-specific design timing requirement(s) for the system; (2) perform application-specific analysis to budget the timing requirement(s) to the associated components of the system architecture; (3) validate that the most restrictive timing requirement for each ALS v2 platform component used within the system architecture has been bounded by the qualified performance envelope for that ALS v2 platform component; (4) perform verification testing that demonstrates that the integrated ALS v2 platform-based system meets each design timing requirement and performs as expected; and (5) include appropriate technical specifications surveillance requirements to confirm the equipments digital response time characteristics, as applicable.

8. Deterministic Performance - As discussed within Section 3.4.2 of this SE, an applicant or licensee referencing this SE should confirm that the application specifications identify the board access sequence, frame time, and implementation of the design features to activate the system alarms upon the detection of a failure to meet the timing requirements, so an operator can take corrective action. An applicant or licensee referencing this SE should also verify that the application-specific logic does not introduce a non-deterministic computation or non-deterministic digital data communications.

9. Self-Diagnostics, Test, and Calibration Capabilities - As discussed within Section 3.4.3 of this SE, an applicant or licensee referencing this SE should demonstrate the adequacy of the application-specific use of the ALS v2 platform diagnostic, self-test, and manually initiated test and calibration features. The following should be considered:

a. Test Coverage - The applicant or licensee should demonstrate that the ALS v2 platform diagnostic, self-test, and manually initiated test and calibration features are sufficient to verify the operational integrity of all logic components (e.g., all relays and contacts, trip units, solid state logic elements, etc.) of a logic circuit, from as close to the sensor as practicable up to but not including the actuated device for each safety function and with sufficient overlap.

b. Relationship to Existing Surveillances - If a licensee proposes to use the ALS v2 platform built-in self-test features to justify the elimination of existing surveillances or less frequent performance of existing surveillances, then the licensee should also demonstrate that the built-in self-testing provides equivalent assurance to the surveillances performed on the equipment being replaced.

c. Reliance upon Automatic Testing - If an applicant or licensee relies upon the continued performance of diagnostic or self-test features that an ALS v2 platform-based system has been designed to automatically perform, then the surveillance procedures that the plants technical specifications reference through the surveillance requirements should verify the built-in self-tests results and ensure that these tests continue to acceptably operate. This activity should confirm that the plants installation does not exhibit unjustified Intermediate errors without reported failures that could adversely affect a safety function.

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 147 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

d. No Adverse Impact on the Reliability of Safety Functions - The applicant or licensee should demonstrate that the application-specific diagnostic, self-test, and manually initiated test and calibration features will not adversely affect the channel independence, system integrity, or the systems ability to meet the single failure criterion.

e. Administrative Controls to Prevent Limiting Conditions for Operation - For manual calibration or surveillance activities, the applicant or licensee should demonstrate adequate administrative controls to ensure that a limiting condition for operation is not routinely entered. This demonstration should consider the functionality per channel and the overall channel, division, and voting logic arrangement of the system.

f. Conformance to RGs - The applicant or licensee should demonstrate the relationship between: (1) the application-specific diagnostic, self test, and manually initiated test and calibration features provided by the ALS v2 platform and (2) the conformance to the NRC staff positions in RGs 1.22 and 1.118.

10. Failure Mode and Effects Analysis - As discussed within Section 3.5 of this SE, an applicant or licensee referencing this SE should perform a system-level FMEA to demonstrate that the application-specific use of the ALS v2 platform identifies each potential failure mode and determines the effects of each. The FMEA should demonstrate that single failures, including those with the potential to cause a nonsafety system action (i.e., a control function) resulting in a condition requiring protective action (i.e., a protection function),

cannot adversely affect the protection functions, as applicable.

11. Reliability and Availability Analysis - As discussed within Section 3.6 of this SE, an applicant or licensee referencing this SE should perform a deterministic system-level evaluation to determine that the degree of redundancy, diversity, testability, and quality provided in an ALS v2 platform-based safety system is commensurate with the safety functions that must be performed. An applicant or licensee should confirm that a resultant ALS v2 platform-based system meets any applicable reliability goals that the plant has established for the system. This plant-specific action should consider the effect of possible failures, system-level design features provided to prevent or limit the failures effects, and any application-specific inclusion of a maintenance bypass to support plant operations. An applicant or licensee should demonstrate that the ALS v2 platform reliability analysis method provides an equivalent level of assurance to the applicants or licensees reliability analysis method.

12. Application-specific ALS-152 Digital Communications - As discussed within Section 3.7.2.1 of this SE, an applicant or licensee referencing this SE and using either TxB1 or TxB2 digital data communication interface of the ALS-152 Core Logic Board should produce the application specification(s) that govern the interface and demonstrate conformance of its application to DI&C-ISG-04 points 2, 3, 4, 5, 7, 18, 19, and 20 under the NRC staffs position for interdivisional communications, which includes data communications between different safety divisions and data communications between a safety division and equipment that is not safety-related.

13. Application-specific TAB Communications - As discussed within Section 3.7.2.1 of this SE, an applicant or licensee referencing this SE and using the TAB digital data

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 148 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION communication interface, which is provided by each ALS v2 platform standardized circuit board, should produce the application specification(s) that govern the interface and demonstrate conformance of its application to DI&C-ISG-04 points 1, 2, 3, 4, 5, 7, 8, 10, 11, 12, and 18 under the NRC staffs position for interdivisional communications, which includes data communications between different safety divisions and data communications between a safety division and equipment that is not safety-related.

14. Application-specific ALS-651 Digital Communications - As discussed within Section 3.7.2.1 of this SE, an applicant or licensee referencing this SE and using the ALS-651 Communication Board should produce the application specification(s) that govern each communication channel and demonstrate conformance of its application to DI&C-ISG-04 points 1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 15, 16, 17, 18, 19, and 20 under the NRC staffs position for interdivisional communications.

15. Application-specific Command Prioritization - As discussed within Section 3.7.2.2 of this SE, an applicant or licensee referencing this SE and implementing command prioritization with the ALS v2 platform components should produce the application specification(s) that govern each priority module application and demonstrate conformance of each application to DI&C-ISG-04 points 1 through 10 under the NRC staffs position for command prioritization.

16. Application-specific Multidivisional Control and Display Stations - As discussed within Section 3.7.2.3 of this SE, an applicant or licensee referencing this SE and implementing a multidivisional control or a multidivisional display station should produce the application specification(s) that govern each multidivisional control or multidivisional display station application and demonstrate conformance of each application to DI&C-ISG-04 Staff Position 3 for multidivisional control and display stations.

17. Secure Development Environment for Applications - As discussed within Section 3.2.6.10 of this SE, an applicant or licensee referencing this SE for a safety-related plant-specific application should ensure that the development environment for its plant-specific application continues to meet the applicable regulatory evaluation criteria of RG 1.152.

18. Secure Operational Environment - As discussed within Section 3.2.6.10 of this SE, an applicant or licensee referencing this SE for a plant-specific application should ensure that the operational environment for its safety-related plant-specific applications meets the applicable regulatory evaluation criteria of RG 1.152.

19. Demonstration of Adequate Diversity - As discussed within Section 3.8 of this SE, an applicant or licensee referencing this ALS topical report, as amended by Reference 1, should identify the approaches specified to provide diversity and mitigations against CCFs within its application of the ALS v2 platform. The following should be considered:

a. Embedded Design Diversity - The ALS v2 application specifications should designate whether Embedded Design Diversity is required in addition to Core Diversity for each safety function performed by that application. When Embedded Design Diversity is required, the specifications should also identify the required arrangement of the FPGA design variants among channels, trains, and electrical separation groups.

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 149 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

b. Application-specific Core Diversity Comparison Checks - Specifications should identify any application-specific ALS-152 logic signals that need to be subject to the Core Diversity comparison checks.

c. Fail-Safe Behavior - Specifications should identify application-specific fail-safe behavior that should result from any comparison check mismatch.

d. Additional Diversity Measures - Specifications should identify any additional diversity measures, such as functional, signal, or additional logic diversity, that are included in the safety system in the context of maintaining plant safety.

e. Extent of Diversity - The applicant or licensee should describe the extent that it relies upon the techniques and processes that provide levels of defense against programming CCFs, which are described in Section 3.3 of the ALS v2 Diversity Analysis (Reference 18), for its use of the ALS v2 platform and its application-specific ALS-152 logic. Using this information, the applicant or licensee should demonstrate that the application adequately addresses potential plant vulnerabilities to common-cause programming failures in consideration of BTP 7-19, as applicable.

f. Identification of Echelons of Defense - Applicant or licensee D3 Analysis should identify the echelon(s) of defense (i.e., control, RTS, ESFAS, and monitoring and display) within the plant that each ALS v2 platform-based I&C function is assigned.

g. Diverse Manual Control Features - When manual controls are not provided as discrete hardwired components connected to the safety equipment at a point downstream of the plant's digital I&C safety system outputs, the applicant or licensee D3 Analysis should demonstrate that simple (e.g., component function can be completely demonstrated by test), dedicated, and diverse program-based digital equipment performs required coordinated system-level actuation logic.

20. IEEE Std 603-1991 Compliance - As discussed within Section 3.9 of this SE, although the NRC staff determined that the ALS v2 platform supports meeting various sections and clauses of IEEE Std 603-1991, an applicant or licensee referencing this SE should identify the approach taken to meet each applicable clause of IEEE Std 603-1991. The applicant or licensee should consider its plant-specific design basis because the scope of the ALS topical report, as amended by Reference 1, is limited. This SE does not address a specific application, establish a definitive safety system or protective action, or identify and analyze the impact of credible events along with their direct and indirect consequences. Therefore, an applicant or licensee should identify its plant-specific design basis for its safety system application and the applicability of each IEEE Std 603-1991 clause to its application-specific ALS v2-based safety system or component. As described within Section 3.9 of this SE, the applicant or licensee should demonstrate that the plant-specific and application-specific use of the ALS v2 platform meets the applicable IEEE Std 603-1991 clauses in accordance with the plant-specific design basis and safety system application.

21. Demonstration of Sufficient Isolation - An applicant or licensee referencing this SE should identify all safety/nonsafety interfaces and interdivisional interfaces, and for each interface, the applicant or licensee should demonstrate that sufficient isolation has been

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 150 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION provided by a qualified isolation device to meet IEEE Std 603, Clause 5.6.3.1(2), IEEE Std 384-1992, as endorsed by RG 1.75 and in accordance with BTP 7-11, and DI&C-ISG-04, as applicable. The application-specific information should identify the maximum credible voltage associated with each plant-specific use of each interface and demonstrate that each qualified isolation device applied to each interface is compatible with its maximum credible voltage and sufficient to prevent damage to the ALS v2 platform safety-related components covered by this SE.

22. IEEE Std 7-4.3.2-2003 Compliance - As discussed within Section 3.10 of this SE, although the NRC staff determined that the ALS v2 platform supports meeting various sections and clauses of IEEE Std 7-4.3.2-2003, an applicant or licensee referencing this SE should identify the approach taken to meet each applicable clause of IEEE Std 7-4.3.2-2003. The applicant or licensee should consider its plant-specific design basis because the scope of the ALS topical report, as amended by Reference 1, is limited. This SE does not address a specific application, establish a definitive safety system or protective action, or identify and analyze the impact of credible events along with their direct and indirect consequences.

Therefore, an applicant or licensee should identify its plant-specific design basis for its safety system application and the applicability of each IEEE Std 7-4.3.2-2003 clause to its application-specific ALS v2-based safety system or component. As described within Section 3.10 of this SE, the applicant or licensee should demonstrate that the plant-specific and application-specific use of the ALS v2 platform meets the applicable IEEE Std 7-4.3.2-2003 clauses in accordance with the plant-specific design basis and safety system application.

23. IEEE Std 1012-2004 Compliance - As discussed within Section 3.10 of this SE, although the NRC staff determined that the ALS v2 platform IV&V processes support various sections and clauses of IEEE Std 1012-2004, an applicant or licensee referencing this SE should demonstrate that it has fulfilled the tasks that have been deferred to an applicants or licensees use of the ALS v2 platform. Some IEEE Std 1012-2004 tasks cannot be fulfilled within the ALS v2 platform topical report scope, because the task is project-specific, such as hazard analysis and risk analysis. Other IEEE Std 1012-2004 tasks cannot be fulfilled within the ALS v2 platform topical report scope, because the task is not performed on a platform component, such as system integration test, system acceptance test, installation, operation, and maintenance tasks. An applicant or licensee referencing this SE should ensure that appropriate activities are included in its project-specific V&V plan and that the performance of each activity is acceptably independent. The project-specific V&V plan should identify any alternative method(s) to IEEE Std 1012-2004 for any IV&V task and demonstrate that the alternative method(s) provides equivalent assurance.

24. Review of Changes - A licensee implementing an application based upon the ALS v2 should perform a review of any change documents to assess the validity of previously derived safety conclusions if changes have been made to the ALS v2 platform hardware, software, or processes defined in the ALS v2 topical report.

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 151 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

5.0 REFERENCES

1. Submittal of the Westinghouse Advanced Logic System (ALS) v2 Topical Reports (WCAP-18762-P/NP and WCAP-18780-P-NP), dated December 21, 2022 (ML22355A230).

2. Completeness Determination for ALSv2 Platform Topical Report, dated February 3, 2023 (ML23024A227).

3. Completeness Determination for ALS2 Development Process Topical Report, dated March 3, 2023 (Package ML23061A157).

4. Submittal of Supporting Document for Review of Westinghouse Advanced Logic System (ALS) v2 Topical Report (WCAP-18762) - 6003-00031, Revision 0, ALS v2 Diversity Analysis, dated January 23, 2023 (ML23023A131; ML23023A134 (Proprietary)).

5. Approved version of ALS Platform Topical Report, dated October 17, 2013 (ML13298A092).

6. Wolf Creek Generating Station - Issuance of Amendment Re: Modification of the Main Steam and Feedwater Isolation System Controls (TAC No. MD4839), dated March 31, 2009 (ML090610317).

7. Wolf Creek Nuclear Operating Corporation, MSFIS D3 Assessment, Revision 2, dated January 9, 2009 (ML090270825).

8. WCAP-18780-P/NP, Advanced Logic System v2 Development Process Topical Report, dated December 21, 2022 (ML22355A237 (Proprietary); ML22355A238 (Non-Proprietary)).

9. WCAP-18762-P/NP, Revision 0, Advanced Logic System v2 Platform Topical Report, dated December 21, 2022 (ML22355A235 (Proprietary); ML22355A236 (Non-Proprietary)).

10. 6003-00004, ALS v2 Equipment Qualification Plan, Revision 2, dated December 31, 2022 (ML22355A248 (Proprietary)).

11. LAR Enclosure 10 - 6003-35206, ALS-352 FPGA Requirements Specification, Revision 0, dated November 30, 2022 (ML22355A242).

12. LAR Enclosure 11 - 6003-36106, ALS-361 FPGA Requirements Specification, Revision 0, dated November 30, 2022 (ML22355A243).

13. LAR Enclosure 12 - 6003-37106, ALS-371 FPGA Requirements Specification, Revision 0, dated November 30, 2022 (ML22355A244).

14. LAR Enclosure 13 - 6003-45206, ALS-452 FPGA Requirements Specification, Revision 0, dated November 30, 2022 (ML22355A245).

15. LAR Enclosure 14 - 6003-47106, ALS-471 FPGA Requirements Specification, Revision 0, dated November 30, 2022 (ML22355A246).

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 152 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

16. LAR Enclosure 15 - 6003-65106, ALS-651 FPGA Requirements Specification, Revision 0, dated November 30, 2022 (ML22355A247).

17. LAR Enclosure 9 - 6003-15206, ALS-152 FPGA Requirements Specification, Revision 1, dated November 30, 2022 (ML22355A241).

18. 6003-00031, ALS v2 Diversity Analysis, Revision 0, dated January 2023 (ML23023A134 (Proprietary)).

19. Regulatory Audit Plan for ALS V2 SE, dated September 20, 2023 (ML23244A650).

20. 6002-00008, ALS Application Guidance, Revision 4, dated February 2013 (ML13060A266 (Proprietary)).

21. License Amendment Request, Enclosure 17, ALS v2 Software Verification and Validation Plan. WNA-PV-00129-GEN, dated December 31, 2022 (ML22355A249).

22. 6003-00010, ALS v2 Platform Requirements Specification, Revision 1, dated April 30, 2022 (ML22355A240 (Proprietary)).

23. 6003-00011, ALS v2 Platform Design Specification, Revision 1, dated May 31, 2022 (ML22355A239 (Proprietary)).

24. NRC, Digital Instrumentation and Controls Interim Staff Guidance - 06 (DI&C-ISG-06),

Licensing Process, Revision 2, dated December 2018 (ML18269A259).

25. 6002-00002, ALS Configuration Management Plan, Revision 10, dated June 2014 (ML14191A108 (Proprietary)).

26. 6003-00006, ALS v2 Security Plan, Revision 1, dated February 28, 2023 (ML23023A133 (Proprietary)).

27. Westinghouse Electric Company Quality Management System, Revision 6 (TAC No. ME5256), dated February 24, 2011 (ML110310088).

28. Safety Evaluation by the Office of Nuclear Reactor Regulation Electric Power Research Institute (EPRI) Topical Report, TR-107330, Final Report, Generic Requirements Specification for Qualifying a Commercially Available PLC For Safety-Related Applications in Nuclear Power Plants, dated July 30, 1998 (ML12205A265).

29. Regulatory Audit Report of CS Innovations/Westinghouse, November 26-30, 2012, at Scottsdale, Arizona and Warrendale, Pennsylvania Facilities for the Advanced Logic System Topical Report (TAC No. ME4454), dated February 4, 2013 (ML12355A134).

30. WCAP-17266-P/NP, Revision 0, Common Q Platform Generic Change Process, dated August 2010 (ML102290177 (Proprietary); ML102290176 (Non-Proprietary)).

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

- 153 -

OFFICIAL USE ONLY - PROPRIETARY INFORMATION

6.0 CONCLUSION

The NRC staff determined that the ALS v2 FPGA based platform, as defined by its standardized circuit boards, design features, and development processes, supports meeting the applicable regulatory requirements for plant-specific use within safety-related I&C systems when conditions delineated in Section 4.0 of this SE are satisfied. The NRC staff determined that the ALS v2 platform can be used in safety-related systems to provide reasonable assurance of adequate protection of public health, safety, and security based on the evaluation in Section 3.0 of this SE, which applies to current and applicable regulatory evaluation criteria identified in Section 2.0 of this SE. On this basis, the NRC staff concludes that the ALS v2 platform is acceptable for use in safety-related I&C systems.

Principal Contributors:

Calvin Cheung William Roggenbrodt Richard Stattel