program name: cooperative development of …nuclear protection and control (nupac) digital safety...

No.: Rev: Page: Date:

NuPAC_ED610000-047-P B i of 204 01/19/2012

Copyright © 2011 Lockheed Martin Corporation and State Nuclear Power Automation System Engineering Company

PROGRAM NAME: Cooperative Development of Safety Platform for Reactor Protection System and Reactor Protection System

DOCUMENT TYPE: Licensing Topical Report (LTR)

DOCUMENT TITLE: Generic Qualification of the NuPAC Platform for Safety-related Applications (Proprietary)

REFERENCE NUMBER(S):

Project Number 780

RELEASE DATE: January 19, 2012 PUBLIC RELEASE APPROVED VIA: PIRA DAL201306007


NuPAC_ED610000-047-P B ii of 204 01/19/2012


This page intentionally left blank.


NuPAC_ED610000-047-P B iii of 204 01/19/2012


USNRC REQUEST FOR ADDITIONAL INFORMATION (RAI) AND

SAFETY EVALUATION REPORT (SER)

Reserved


NuPAC_ED610000-047-P B iv of 204 01/19/2012


ACKNOWLEDGEMENTS

This report was submitted by:

Lockheed Martin Global, Inc. 459 Kennedy Drive Archbald, PA 18403-1598, USA

Under a cooperative development project between Lockheed Martin Global, Inc. and the State Nuclear Power Automation System Engineering Company:

State Nuclear Power Automation System Engineering Company No. 41 Hongcao Road Shanghai, 200233, PRC

With technical assistance provided by:

MPR Associates, Inc. 320 King Street Alexandria, VA 22314-3230, USA


NuPAC_ED610000-047-P B v of 204 01/19/2012


ABSTRACT

This Licensing Topical Report (LTR) presents design, performance, and qualification information for the Nuclear Protection and Control (NuPAC) digital safety instrumentation and control (I&C) platform cooperatively developed by Lockheed Martin Global, Inc. (LMGI) and the State Nuclear Power Automation System (SNPAS) Engineering Company. The NuPAC system is a generic digital safety I&C platform devoted to the implementation of Class 1E safety-related applications in United States (US) nuclear power plants (NPPs).

This LTR is the summary licensing document for the NuPAC digital safety I&C platform and is organized as follows:

Section 1.0, Introduction Section 2.0, Design Criteria Section 3.0, Description of the NuPAC Digital Safety I&C Platform Section 4.0, Development Process for the NuPAC Platform Section 5.0, Software Development Process for NuPAC Programmable Logic Section 6.0, Equipment Qualification Section 7.0, Diversity and Defense-in-depth (D3) Section 8.0, Compliance with Standards and Interim Staff Guidance (ISG) Section 9.0, Secure Development and Operational Environment Appendix A, NuPAC Platform Application Guide Appendix B, IEEE Standard 603–1991 Compliance Matrix Appendix C, IEEE Standard 7-4.3.2-2003 Compliance Matrix Appendix D, DI&C-ISG-04 Compliance Matrix Appendix E, DI&C-ISG-06 Compliance Matrix Appendix F, Documentation Cross-Reference Matrix

Keywords

Instrumentation and Control System Digital Systems Safety Systems Control Systems Field Programmable Gate Array


NuPAC_ED610000-047-P B vi of 204 01/19/2012


REVISION HISTORY

Revision information for this LTR is listed below. This table will contain a listing and description of changed paragraphs for each succeeding revision.

Revision Date Paragraph Description of Change

- 06/28/2011 All Initial Release RELEASE AUTH: ER.2011.04266

A 01/19/2012 All RELEASE AUTH: ER.2012.00273 Throughout Editorials 3.1.x; Removed erroneous line in Figure 3.1.2-1 Removed erroneous lines in Figure 3.1.3-1 Re-sized power connector for consistency with

one another in Figure 3.1.3-2 Paragraph modifications and clarification on

programmable logic design architecture intent 3.2.x; Paragraph modifications, clarification on

programmable logic design architecture intent and clarification on power supply intent

3.3.x; Naming convention update in Figure 3.3-1 Naming convention update in Figure 3.3.2-1 Paragraph modifications, clarification on

programmable logic design architecture intent and clarification on power supply intent

3.4.x; Paragraph modifications and clarification on programmable logic design architecture intent

4.2.x; Paragraph modifications and naming convention clarification of Field Programmable Logic V&V plan


4.5; Updated reference 4-29 to identify the System Safety Plan as Revision B


5.2; Paragraph modifications adding the word “Independent”


5.4; Updated reference 5-13 to identify the System Safety Plan as Revision B

6.2; Paragraph modifications and naming convention clarification of surge withstand

6.3; Paragraph modifications and clarification of failure modes and effects analysis


NuPAC_ED610000-047-P B vii of 204 01/19/2012



Appendix A Paragraphs Throughout

Editorials

Appendix A Paragraph 2.1.x Paragraph modifications and clarification of power supplies characteristics

Appendix A Paragraph 2.2.x Paragraph modifications and clarifications for connection to the plant instrumentation and control

Appendix A Paragraph 2.3.x Paragraph modifications and clarifications for the system configured communication architecture

Appendix A Paragraph 2.4.x Paragraph modifications and clarifications for the chassis configured communication architecture

Appendix A Paragraph 2.5.x Paragraph modifications and clarifications for the external communication architecture

Appendix A Paragraph 2.6.x Paragraph modifications and clarifications on the operator interface

Appendix A Paragraph 2.8.x Paragraph modifications and clarifications on self-test and surveillance

Appendix A Paragraph 3.0 Paragraph modifications and clarifications on diversity

Appendix A Paragraph 5.1.x Paragraph modifications and clarifications on mounting

Appendix A Paragraph 5.6.x Paragraph modifications and clarifications on electro-magnetic compatibility

Appendix A Paragraph 7.1.x Paragraph modifications and clarifications on guidance for application programming

Appendix A Paragraph 8.3.x Paragraph modifications and clarifications on corrective maintenance

Appendix A Paragraph 8.4.x Paragraph modifications and clarifications on preventative maintenance

B 08/07/13 All Abstract Page V of 204 Editorial Revision (Deletion of superceded text) Throughout Established Public Version IAW PIRA

DAL201306007


NuPAC_ED610000-047-P B viii of 204 01/19/2012




NuPAC_ED610000-047-P B ix of 204 01/19/2012




NuPAC_ED610000-047-P B x of 204 01/19/2012


CONTENTS

USNRC REQUEST FOR ADDITIONAL INFORMATION (RAI) AND SAFETY

EVALUATION REPORT (SER) ................................................................................................ iii

ACKNOWLEDGEMENTS .......................................................................................................... iv

ABSTRACT .................................................................................................................................... v

REVISION HISTORY .................................................................................................................. vi

CONTENTS .................................................................................................................................... x

LIST OF APPENDICES ............................................................................................................... xi

LIST OF FIGURES ..................................................................................................................... xii

LIST OF TABLES ...................................................................................................................... xiii

GLOSSARY OF ACRONYMS AND ABBREVIATIONS ...................................................... xiv

1.0 INTRODUCTION .......................................................................................................................... 1 1.1 Purpose ....................................................................................................................................... 1 1.2 Licensing Topical Report Organization ..................................................................................... 2 1.3 Supporting Licensing Documents .............................................................................................. 3 1.4 Quality Assurance Program ....................................................................................................... 3 1.5 References .................................................................................................................................. 4

2.0 DESIGN CRITERIA ...................................................................................................................... 7

3.0 DESCRIPTION OF THE NUPAC DIGITAL SAFETY I&C PLATFORM .......................... 14 3.1 Overview .................................................................................................................................. 14 3.2 Hardware .................................................................................................................................. 21 3.3 Programmable Logic Architecture ........................................................................................... 40 3.4 Data Communication ............................................................................................................... 47 3.5 References ................................................................................................................................ 62

4.0 DEVELOPMENT PROCESS FOR THE NUPAC PLATFORM ............................................ 64 4.1 Overview .................................................................................................................................. 64 4.2 Process Description .................................................................................................................. 65 4.3 Planning Documentation .......................................................................................................... 77 4.4 Organizational Relationships ................................................................................................... 82 4.5 References ................................................................................................................................ 84

5.0 SOFTWARE DEVELOPMENT PROCESS FOR NUPAC PROGRAMMABLE LOGIC .. 86 5.1 Programmable Logic Life Cycle Description .......................................................................... 90 5.2 Programmable Logic Verification and Validation ................................................................... 91 5.3 Programmable Logic Planning Documentation ....................................................................... 91 5.4 References ................................................................................................................................ 94

6.0 EQUIPMENT QUALIFICATION ............................................................................................. 98 6.1 Description of Test Specimen and Test Equipment ................................................................. 98 6.2 Qualification Test Program .................................................................................................... 102


NuPAC_ED610000-047-P B xi of 204 01/19/2012


6.3 Supporting Data for Analyses ................................................................................................ 105 6.4 Limited Life Components ...................................................................................................... 108 6.5 Software Tool Evaluation ...................................................................................................... 108 6.6 References .............................................................................................................................. 109

7.0 DIVERSITY AND DEFENSE-IN-DEPTH (D3) ..................................................................... 111 7.1 Overview ................................................................................................................................ 111 7.2 Background ............................................................................................................................ 111 7.3 NuPAC Platform Diversity Approach ................................................................................... 113 7.4 Examples of Diversity Applications ...................................................................................... 124 7.5 References .............................................................................................................................. 129

8.0 COMPLIANCE WITH STANDARDS AND INTERIM STAFF GUIDANCE .................... 132 8.1 Compliance with IEEE Standard 603-1991 ........................................................................... 132 8.2 Compliance with IEEE Standard 7-4.3.2-2003 ...................................................................... 132 8.3 DI&C-ISG-02, Rev. 2 ............................................................................................................ 132 8.4 DI&C-ISG-04, Rev. 1 ............................................................................................................ 132 8.5 DI&C-ISG-06, Rev. 1 ............................................................................................................ 133 8.6 References .............................................................................................................................. 133

9.0 SECURE DEVELOPMENT AND OPERATIONAL ENVIRONMENT ............................. 134 9.1 Vulnerability Assessment ...................................................................................................... 134 9.2 Secure Development and Operational Environment Controls ............................................... 134 9.3 References .............................................................................................................................. 134

LIST OF APPENDICES

APPENDIX A NuPAC Platform Application Guide ............................................................................ 136 APPENDIX B IEEE Standard 603–1991 Compliance Matrix ............................................................ 168 APPENDIX C IEEE Standard 7-4.3.2-2003 Compliance Matrix ....................................................... 177 APPENDIX D DI&C-ISG-04 Compliance Matrix ............................................................................... 188 APPENDIX E DI&C-ISG-06 Compliance Matrix ............................................................................... 202 APPENDIX F Documentation Cross-Reference Matrix ...................................................................... 210


NuPAC_ED610000-047-P B xii of 204 01/19/2012


LIST OF FIGURES

Figure 3.1.2-1. NuPAC Context ................................................................................................................. 15 Figure 3.1.3-1. Generic Logic Module Configuration ................................................................................ 16 Figure 3.1.3-2. Chassis ............................................................................................................................... 17 Figure 3.1.3-3. Chassis Installed GLMs and RTMs ................................................................................... 18 Figure 3.1.3-4. GLM/Backplane/RTM Configuration ............................................................................... 19 Figure 3.2.1-1. GLM Components and Assembly ...................................................................................... 21 Figure 3.2.1-2. GLM Block Diagram ......................................................................................................... 22 Figure 3.2.1.1-1. Carrier Card .................................................................................................................... 23 Figure 3.2.1.2-1. Typical I/O Mezzanine ................................................................................................... 25 Figure 3.2.1.3-1. Logic Mezzanine............................................................................................................. 32 Figure 3.2.2-1. Rear Transition Module ..................................................................................................... 34 Figure 3.2.3-1. Chassis ............................................................................................................................... 35 Figure 3.3-1. Programmable Logic Configuration Items ........................................................................... 38 Figure 3.3.1-1. Core PLCI Block Diagram ................................................................................................ 39 Figure 3.3.2-1. AS PLCI Programmable Logic Block Diagram ................................................................ 42 Figure 3.4.1.2-1. Dual Mesh/Star LVDS Point-to-Point Serial Data Communication Paths ..................... 46 Figure 3.4.1.2.3-1. Message Routing Example .......................................................................................... 49 Figure 3.4.1.3-1. RS-422/485 Mezzanine Serial Data Communication ..................................................... 50 Figure 3.4.2.2-1. Intra-divisional Communication ..................................................................................... 54 Figure 3.4.2.3-1. Inter-divisional Communication ..................................................................................... 56 Figure 3.4.2.4-1. Non-safety System Data Communication ....................................................................... 58 Figure 4.1-1. Technical and Support Processes (TSP) ............................................................................... 61 Figure 4.2.1-1. TSP Program Execution Processes .................................................................................... 62 Figure 4.2.2-1. TSP Technical Processes ................................................................................................... 64 Figure 4.2.3-1. TSP Support Processes ...................................................................................................... 67 Figure 4.2.4-1. TSP I-V&V Processes ....................................................................................................... 71 Figure 4.4-1. NuPAC Program Organizational Relationships .................................................................... 77 Figure 5.0-1. Programmable Logic Development Process ......................................................................... 83 Figure 6.1.1-1. TSC Block Diagram .......................................................................................................... 94 Figure 6.1.2-1. Test System ........................................................................................................................ 95 Figure 6.1.2-2. TSC Test Setup Block Diagram ......................................................................................... 96 Figure 7.3.1-1. Diverse Logic Mezzanines............................................................................................... 109 Figure 7.3.1-2. Diverse Generic Logic Modules ...................................................................................... 110 Figure 7.3.2.2-1. Life Cycle (Human) Diversity ...................................................................................... 112 Figure 7.4.1-1. NuPAC Platform with Diverse Actuation System ........................................................... 118 Figure 7.4.2-1. NuPAC Platform Diversity Schemes ............................................................................... 119 Figure 7.4.2.1-1. NuPAC Platform with Inter-divisional Diversity ......................................................... 120 Figure 7.4.2.2-1. NuPAC Platform with Intra-divisional Diversity ......................................................... 121


NuPAC_ED610000-047-P B xiii of 204 01/19/2012


LIST OF TABLES

Table 2.0-1. Design Criteria Applied ........................................................................................................... 7 Table 3.1.4-1. Qualified Components ........................................................................................................ 19 Table 3.4.1.2.1-1. LVDS Backplane Message Structure ............................................................................ 47 Table 4.3-1. Generic NuPAC Platform Planning Documentation .............................................................. 73 Table 5.3-1. Generic NuPAC Platform PL Planning Documentation ........................................................ 86 Table 6.2-1. Qualification Testing .............................................................................................................. 97 Table 7.3.3.1-1. Diversity Rating for the NuPAC Platform1 .................................................................... 116


NuPAC_ED610000-047-P B xiv of 204 01/19/2012


GLOSSARY OF ACRONYMS AND ABBREVIATIONS

ΔΣ delta-sigma A – B

ac alternating current ADC analog-to-digital converter ALWR Advanced Light-Water Reactor AP assurance plan ANSI American National Standards

Institute ASME American Society of Mechanical

Engineers ASPLD Application-Specific Programmable

Logic Device ATWS Anticipated Transient Without Scram BIT built-in testing;

built-in test BGA ball grid array BTP Branch Technical Position BWNT Babcock & Wilcox Nuclear

Technology C

C Centigrade CAB Corrective Action Board CCA circuit card assembly CCF common cause failure CDR critical design review CFR Code of Federal Regulation CGDP Commercial Grade Dedication Plan CI configuration item CJC cold junction compensation CM configuration management CMP configuration management plan Core PLD Core Programmable Logic Device CRC cyclic redundancy check CSA configuration status accounting CTIC communications and test interface

connector D

D3 Diversity and Defense-in-Depth DAC digital-to-analog converter DAE Diversity Attribute Effectiveness DAS Diverse Actuation System dc direct current

DCE Diversity Criterion Effectiveness DRS design requirements specification

E ECC error correction code EEPROM electrically erasable programmable

read-only memory EFT electrical fast transient EMI electromagnetic interference EPRI Electric Power Research Institute ESD electrostatic discharge ESFAS Engineered Safety Features

Actuation System F

F Fahrenheit FCA functional configuration audit FMC FPGA Mezzanine Card FMEA failure modes and effects analysis FPGA field programmable gate array FPL field programmable logic FRACAS failure reporting, analysis and

corrective action system FVVP field programmable logic verification

and validation plan G – H

GDC General Design Criterion; General Design Criteria

GLM Generic Logic Module HDL hardware description language HDP hardware development plan HW hardware

I I/F interface I/O input/output I&C instrumentation and control I-V&V independent verification and

validation IAW in accordance with ICD interface control document IDD interface design document IEC International Electrotechnical

Commission IEEE Institute of Electrical and Electronics

Engineers


NuPAC_ED610000-047-P B xv of 204 01/19/2012


ILS integrated logistics support IMP integrated master plan IMS integrated master schedule INH inherent use INT intentional use IP industry pack IPT integrated product team IRS interface requirements specification ISG Interim Staff Guidance ISO International Standards

Organization J – K – L

JTAG Joint Test Action Group kb kilobits kbps kilobits per second KC key characteristic kHz kilohertz LAR License Amendment Request LED light emitting diode LMGI Lockheed Martin Global, Inc. LPE lead program engineer LTR Licensing Topical Report LVDS low-voltage differential signaling

M – N Mb megabits Mbps megabits per second MHz megahertz MICTOR Matched Impedance ConnecTOR MOFSET metal-oxide semiconductor field-

effect transistor MR mission review MSFIS Main Steam and Feedwater

Isolation System MTP master test plan N Newtons NPP nuclear power plant NQA Nuclear Quality Assurance NuPAC Nuclear Protection and Control

O – P OCD operational concept document P/CR problem/change request P/N part number PCA physical configuration audit PDR preliminary design review PGA programmable gain amplifier

PiV&V product integration, verification, and validation

PL programmable logic PLC programmable logic controller PLCI programmable logic configuration

item PLCMP programmable logic configuration

management plan PLD Programmable Logic Device PLDP programmable logic development

plan PLIP programmable logic integration plan PLM priority logic module PLPMP programmable logic project

management plan PLRS programmable logic requirements

specification PLTP programmable logic test plan PMP program management plan POST power-on self test PPMC program planning, monitoring, and

control PM program manager PMP program management plan PRI program repository index PSM program start meeting PSR program startup review

Q – R QA quality assurance QAP quality assurance plan RAM random access memory RG Regulatory Guide ROMP risk and opportunity management

plan RPP reliability program plan RPS Reactor Protection System RTD Resistance Temperature Detector RTM requirements traceability matrix

Rear Transition Module RTS Reactor Trip System Rx receiver

S SD system design SDR system design review SECY Secretary of the Commission Office

of the (NRC)


NuPAC_ED610000-047-P B xvi of 204 01/19/2012


SEMP systems engineering management plan

SER safety evaluation report SiO2 silicon dioxide SME subject matter expert SMP subcontract management plan SNPAS State Nuclear Power Automation

System Engineering Company SOW statement of work SP support plan SPI serial peripheral interface SQT system qualification/acceptance test SRA system requirements analysis SRAM static RAM SRR system requirements review SSP system security plan SSPP system safety plan SSR solid state relay;

solid state resistor SRAM static random access memory SSRAM static synchronous random access

memory Std. standard

T – U TEDP test equipment development plan TESDP test equipment software

development plan TRR test readiness review TSC test specimen configuration TSP technical support process Tx transmitter UART Universal Asynchronous Receiver-

Transmitter US United States USNRC United States Nuclear Regulatory

Commission V – W – X – Y – Z

V volt V&V verification and validation VA volt amperes VAC volts alternating current VDC volts direct current VDU visual display unit VHDL VHSIC (Very High-Speed Integrated

Circuit) Hardware Description Language

VRCM verification cross-reference matrix


NuPAC_ED610000-047-P B xvii of 204 01/19/2012




NuPAC_ED610000-047-P B 1 of 204 01/19/2012


1.0 INTRODUCTION

1.1 Purpose

Lockheed Martin Global, Inc. (LMGI) is submitting this Licensing Topical Report (LTR) to the United States Nuclear Regulatory Commission (USNRC) for review and approval of the Nuclear Protection and Control (NuPAC) platform design. The NuPAC platform will be used as a digital control system platform in safety-related applications in nuclear power plants (NPPs) in the United States (US). It is designed to replace existing analog and CPU-based instrumentation and control (I&C) systems currently used in US NPP applications and to be installed as original equipment for new NPP facilities. USNRC approval for the NuPAC platform will be provided in a Safety Evaluation Report (SER).

The NuPAC platform is functionally and physically similar to commercially available programmable logic controllers (PLCs). Its platform capabilities include input processing, customizable logic solving, and output processing. The NuPAC platform continuously monitors system status through signals that are received from peripheral sensors. It performs computations (e.g., solves logic) to calculate control commands. It also converts control commands to output signals that are applied to peripheral actuators. The NuPAC platform offers modularity and scalability, similar to a PLC, via the configuration of chassis installed logic solving modules.

The NuPAC platform is a state-of-the-art digital control system platform specifically designed for safety-related control and protection systems in NPP applications. Its design facilitates the development of highly safe and reliable digital I&C systems. The platform features a modular decentralized (distributed) field programmable gate array (FPGA)-based architecture. It is functionally similar to legacy analog measurement and trip modules, but takes advantage of the benefits of digital technology. The FPGA-based architecture facilitates implementation of redundancy, independence, determinacy, and diversity and defense-in-depth. In addition, the FPGA-based architecture allows simple programmable logic, avoiding unfavorable software-like behavior and integration of software operating systems and executables. NuPAC operational scenarios (typical NuPAC platform roles and applications) include, but are not limited to, the Reactor Trip System (RTS) and Engineered Safety Features Actuation System (ESFAS).

The NuPAC platform design is based on requirements of USNRC Regulatory Guides (RGs) and Institute of Electrical and Electronics Engineers (IEEE) standards applicable to NPP safety-related applications. The primary reference is Title 10 of the Code of Federal Regulation Section 50.55a(h) (Reference 1-1) and RG 1.153 (Reference 1-2), which endorses IEEE Standard 603-1991 (Reference 1-3). Since the NuPAC platform is a digital device, LMGI/SNPAS also applied RG 1.152 (Reference 1-4) and IEEE Standard 7-4.3.2-2003 (Reference 1-5). The development process considered all guidance provided in RGs 1.168, 1.169, 1.170, 1.171, 1.172, and 1.173 (References 1-6 through 1-11), as well as the Digital Instrumentation and Control Interim Staff Guidance (DI&C-ISG) associated with NPP digital I&C.

Generic qualification of the NuPAC platform includes both hardware components and the programmable logic used, which are detailed in Sections 3.2 and 3.3. The NuPAC platform provides the functionality that is typically required for safety-related control and protection systems in NPP applications. The qualification process involves technical evaluations and qualification tests. The qualification test program is based on the Electric Power Research Institute (EPRI) Technical Report TR-107330 (Reference 1-12). Electromagnetic compatibility qualification is based on RG 1.180 Revision 1 (Reference 1-13). A revision to this topical report; i.e., Phase 2 data submittal, will summarize qualification results and will provide reference to additional documents containing confirmatory data.

LMGI/SNPAS drafted this LTR in accordance with DI&C-ISG-06. Furthermore, it is patterned after the sample License Amendment Request (LAR) and safety evaluation provided in DI&C-ISG-06. This LTR describes the NuPAC platform, development processes, and equipment qualification. Detailed compliance matrices,


NuPAC_ED610000-047-P B 2 of 204 01/19/2012


included as appendices to this LTR, document how the NuPAC platform complies with each requirement specified in IEEE Standard 603-1991, IEEE Standard 7-4.3.2 2003, DI&C-ISG-04 (Reference 1-14), and DI&C-ISG-06 (Reference 1-15).

LMGI/SNPAS will use the platform defined in this LTR as a basis to provide plant-specific systems to utilities and other users. Plant-specific systems will be documented and submitted to the USNRC by the appropriate licensees, using the appropriate processes, for review and approval for installations in US NPPs.

1.2 Licensing Topical Report Organization

This report is organized as follows:

Section 1.0, Introduction: An overview of the LTR and identification of the supporting documents submitted for USNRC review. This Section also provides an overview of the quality assurance program.

Section 2.0, Design Criteria: Lists regulatory requirements, design criteria, and guidelines applicable to the NuPAC platform.

Section 3.0, Description of the NuPAC Digital Safety I&C Platform: Describes how the NuPAC platform works and how it is intended to be applied in NPP safety-related applications. Identifies NuPAC platform hardware components and programmable logic, explains how they function, and discusses how they are interrelated. In addition, addresses aspects of data communication, specifically identifying methodologies for the NuPAC platform to support compliance with DI&C-ISG-04 (Reference 1-14).

Section 4.0, Development Process for the NuPAC Platform: Describes the design process, organizational structure, and project control methods used during NuPAC platform development.

Section 5.0, Software Development Process for NuPAC Programmable Logic: Explains software-based life cycle processes used to develop NuPAC programmable logic.

Section 6, Equipment Qualification: Summarizes NuPAC platform qualification test plans. In addition, identifies the methodologies for the NuPAC platform to support plant-specific system-level analyses, including aspects of failure analysis, reliability/availability analysis, response time analysis, setpoint value analysis, and limited life component analysis.

Section 7.0, Diversity and Defense-in-Depth (D3): Addresses D3 elements, specifically methodologies for the NuPAC platform to support compliance with DI&C-ISG-02 (Reference 1-16).

Section 8.0, Compliance with Standards and Interim Staff Guidance (ISG): Explains how the NuPAC platform complies with IEEE Standard 603-1991 (Reference 1-3), IEEE Standard 7-4.3.2-2003 (Reference 1-5), DI&C-ISG-02 (Reference 1-16), DI&C-ISG-04 (Reference 1-14), and DI&C-ISG-06 (Reference 1-15).

Section 9.0, Secure Development and Operational Environment: Explains the NuPAC platform vulnerability assessment and identifies the associated methodology to apply secure development and operational environment controls per Draft Final RG 1.152 Revision 3 (Reference 1-17).

Appendix A, NuPAC Platform Application Guide: Provides plant-specific system design guidance, including recommended practices and any restrictions for use of the NuPAC platform.

Appendix B, IEEE Standard 603 Compliance Matrix: Provides an IEEE Standard 603-1991 (Reference 1-3) compliance matrix, with the requirement listed; NuPAC platform compliance to each requirement defined; and references to confirmatory information.

Appendix C, IEEE Standard 7-4.3.2 Compliance Matrix: Includes an IEEE Standard 7-4.3.2-2003 (Reference 1-5) compliance matrix, with the requirement listed, NuPAC platform compliance to each requirement defined, as well as references to the confirmatory information.


NuPAC_ED610000-047-P B 3 of 204 01/19/2012


Appendix D, DI&C-ISG-04 Compliance Matrix: Provides a DI&C-ISG-04 (Reference 1-14) compliance matrix, with the requirement listed, NuPAC platform compliance to each requirement defined, as well as references to the confirmatory information.

Appendix E, DI&C-ISG-06 Compliance Matrix: Contains a DI&C-ISG-06 (Reference 1-15) compliance matrix, with the requirement listed, NuPAC platform compliance to each requirement defined, as well as references to the confirmatory information.

Appendix F, Documentation Cross-Reference Matrix: Includes a life cycle documentation cross-reference, which maps the NuPAC documentation to the list of documentation provided in Enclosure B of DI&C-ISG-06 (Reference 1-15).

1.3 Supporting Licensing Documents

LMGI/SNPAS will provide the following additional documentation to support the application for USNRC approval of the NuPAC digital safety I&C platform:

Phase 1 Submittal for Tier 3 Review

– System description – Hardware design reports – Software architecture description – Software development specification – Equipment qualification test plan – Software quality assurance plan – Commercial grade dedication plan – Software life cycle planning documentation – Software tool evaluation plan – Vulnerability assessment and system security plan

Phase 2 Submittal for Tier 3 Review

– Verification and validation reports – Test procedures – Summary test reports/results – Requirements traceability matrix – Analysis reports (safety, failure modes and effects, reliability, response time, setpoint) – Software tool evaluation report – Commercial grade dedication reports.

Note, the software documentation is associated with the software-based life cycle processes used to develop FPGA programmable logic.

As mentioned previously, Appendix F provides a cross-reference matrix, which maps the NuPAC documentation to the list of documentation provided in Enclosure B of DI&C-ISG-06 (Reference 1-15).

1.4 Quality Assurance Program

LMGI/SNPAS activities are performed under a Title 10 of the Code of Federal Regulations Part 50 (10 CFR 50) Appendix B-compliant quality program documented in the LMGI “Nuclear Quality Assurance Manual,” NQA 2000 (Reference 1-18). Our 10 CFR 50 Appendix B QA program complies with Nuclear Quality Assurance (NQA)-1-1994 (Reference 1-19), USNRC RG 1.28 (Reference 1-20), ANSI N45.2-1977 (Reference 1-21), and associated daughter standards for basic components. Our quality assurance (QA) program has been audited and


NuPAC_ED610000-047-P B 4 of 204 01/19/2012


accepted by at least one organization with a long-standing Appendix B QA program. Furthermore, all LMGI/SNPAS nuclear activities are subject to the policies and procedures described in NQA 2000.

In addition, LMGI facilities in Archbald, Pennsylvania, maintain a quality management system, documented in the LMGI “Quality and Environmental Integrated Management System Manual,” IMS 2000 (Reference 1-22). The facilities are certified to ISO 9001:2008 (Reference 1-23) and SAE AS9100C (Reference 1-24) requirements. All LMGI/SNPAS activities are subject to the policies and procedures described in IMS 2000.

LMGI’s QA organization is responsible for all quality assurance functions. Its primary tasks are to verify that documentation, fabrication, tests, shipments, and deliveries are complete and comply with all program requirements and company policies. Accordingly, LMGI QA performs ongoing evaluations to ensure quality objectives are accomplished per 10 CFR 50 Appendix B-compliant quality assurance program and program requirements.

Software quality plans and other software life cycle plans are addressed in Section 5 of this LTR.

1.5 References

1-1 10 CFR 50.55a(h), “Codes and Standards, paragraph (h), Protection and safety systems”

1-2 USNRC RG 1.153, Rev. 1, “Criteria for Safety Systems,” June 1996

1-3 IEEE Standard 603-1991, “IEEE Standard Criteria for Safety Systems for Nuclear Power Generating Stations,” Institute of Electrical and Electronics Engineers

1-4 USNRC RG 1.152, Rev. 2, “Criteria for Digital Computers in Safety Systems of Nuclear Power Plants,” January 2006

1-5 IEEE Standard 7-4.3.2-2003, “IEEE Standard Criteria for Digital Computers in Safety Systems for Nuclear Power Generating Stations,” Institute of Electrical and Electronics Engineers

1-6 USNRC RG 1.168, Rev. 1, “Verification, Validation, Reviews, and Audits for Digital Computer Software Used in Safety Systems of Nuclear Power Plants,” February 2004

1-7 USNRC RG 1.169, “Configuration Management Plans for Digital Computer Software Used in Safety Systems of Nuclear Power Plants,” September 1997

1-8 USNRC RG 1.170, “Software Test Documentation for Digital Computer Software Used in Safety Systems of Nuclear Power Plants,” September 1997

1-9 USNRC RG 1.171, “Software Unit Testing for Digital Computer Software Used in Safety Systems of Nuclear Power Plants,” September 1997

1-10 USNRC RG 1.172, “Software Requirements Specifications for Digital Computer Software Used in Safety Systems of Nuclear Power Plants,” September 1997

1-11 USNRC RG 1.173, “Developing Software Life Cycle Processes for Digital Computer Software Used in Safety Systems of Nuclear Power Plants,” September 1997


NuPAC_ED610000-047-P B 5 of 204 01/19/2012


1-12 EPRI TR-107330, “Generic Requirements Specification for Qualifying a Commercially Available PLC for Safety-Related Applications in Nuclear Power Plants,” Electric Power Research Institute, December 1996

1-13 USNRC RG 1.180, Rev. 1, “Guidelines for Evaluating Electromagnetic and Radio-Frequency Interference in Safety-Related Instrumentation and Control Systems,” October 2003

1-14 DI&C-ISG-04, Rev. 1, “Highly-Integrated Control Rooms – Digital Communication Issues,” US Nuclear Regulatory Commission, March 2009

1-15 DI&C-ISG-06, Rev. 1, “Licensing Process,” US Nuclear Regulatory Commission, January 2011

1-16 DI&C-ISG-02, Rev. 2, “Diversity and Defense-in-Depth Issues,” US Nuclear Regulatory Commission, June 2009

1-17 Draft Final RG 1.152, Rev. 3, “Criteria for Digital Computers in Safety Systems of Nuclear Power Plants,” January 2011

1-18 LMGI Document No. NQA 2000, Rev. C, “Nuclear Quality Assurance Manual,” Lockheed Martin Global, Inc., November 2010

1-19 ASME NQA-1-1994, “Quality Assurance Program Requirements for Nuclear Facilities,” American Society of Mechanical Engineers

1-20 USNRC RG 1.28, Rev. 4, “Quality Assurance Program Criteria (Design and Construction),” June 2010

1-21 ANSI N45.2-1977, “Quality Assurance Program Requirements for Nuclear Facilities,” American National Standards Institute

1-22 LMGI Document No. IMS 2000, Rev. C, “Quality & Environmental Integrated Management System Manual,” Lockheed Martin Global, Inc., November 2010

1-23 ISO 9001:2008, “Quality management systems – Requirements,” International Organization for Standardization

1-24 SAE AS9100C, “Quality Management Systems – Requirements for Aviation, Space and Defense Organizations,” SAE International


NuPAC_ED610000-047-P B 6 of 204 01/19/2012




NuPAC_ED610000-047-P B 7 of 204 01/19/2012


2.0 DESIGN CRITERIA

This section identifies the applicable regulatory requirements that constitute design criteria for the NuPAC platform. Furthermore, it provides a brief introduction to compliance, including details in subsequent sections and the referenced appendices.

The suitability of a NuPAC platform for use in NPP safety-related systems depends on the quality of its components, quality of its design process, and system implementation aspects, such as real time performance, independence, and online testing.

The NuPAC platform was developed and is being supplied as 10 CFR 50 Appendix B qualified equipment. The NuPAC platform was developed based on the guidance provided in Regulatory Guides (RGs), endorsed industry standards, Branch Technical Positions (BTPs), and Interim Staff Guidance (ISG). By conforming to the acceptable methods set forth in that guidance, the NuPAC platform satisfies the applied design criteria (Table 2.0-1).

Table 2.0-1. Design Criteria Applied

Identifier Title Bases for RG 1.22, Rev. 0 Periodic Testing of Protection System Actuation

Functions GDC 21 IEEE Std. 603-1991

(ANSI/IEEE Std. 279-1971) RG 1.29, Rev. 4 Seismic Design Classification GDC 2 RG 1.47, Rev. 1 Bypassed and Inoperable Status Indication for

Nuclear Power Plant Safety System GDC 21 IEEE Std. 603-1991

(ANSI/IEEE Std. 279-1971) RG 1.53, Rev. 2 Application of the Single-Failure Criterion to

Nuclear Power Plant Protection Systems GDC 21 IEEE Std. 603-1991

(ANSI/IEEE Std. 279-1971) ANSI/IEEE Std. 379-2000

RG 1.62, Rev. 1 Manual Initiation of Protection Actions IEEE Std. 603-1991 (ANSI/IEEE Std. 279-1971)

RG 1.75, Rev. 3 Physical Independence of Electric Systems GDC 21 IEEE Std. 603-1991

(ANSI/IEEE Std. 279-1971) RG 1.89, Rev. 1 Environmental Qualification of Certain Electric

Equipment Important to Safety for Nuclear Power Plants

10 CFR 50.49 10 CFR 50 App B, Criteria 3

RG 1.100, Rev. 3 Seismic Qualification of Electric and Mechanical Equipment for Nuclear Power Plants

GDC 1 GDC 2 10 CFR 50 App B, Criteria 3, 11, 17 10 CFR 50 App S

RG 1.105, Rev. 3 Instrument Spans and Setpoints GDC 13 IEEE Std. 603-1991

(ANSI/IEEE Std. 279-1971) RG 1.118, Rev. 3 Periodic Testing of Electric Power and Protection

Systems GDC 21 IEEE Std. 603-1991

(ANSI/IEEE Std. 279-1971) RG 1.151, Rev. 1 Instrument Sensing Lines GDC 13


NuPAC_ED610000-047-P B 8 of 204 01/19/2012


Identifier Title Bases for RG 1.152, Rev. 2 Digital Computers in Safety Systems of Nuclear

Power Plants GDC 2 GDC 4 GDC 13 GDC 20 GDC 21 GDC 22 GDC 23 GDC 24 GDC 29

Note RG 1.152 only credits GDC 21; however, since IEEE Std. 7-4.3.2-2003 (endorsed by RG 1.152) defines how to implement IEEE Std. 603-1991 for digital equipment, all of the GDCs that apply to IEEE Std. 603-1991 also apply.

RG 1.153, Rev. 1 Power Instrumentation and Control Portions of Safety Systems

10 CFR 50.55a(h) GDC 2 GDC 4 GDC 13 GDC 20 GDC 21 GDC 22 GDC 23 GDC 24 GDC 29

RG 1.168, Rev. 1 Verification, Validation, Reviews and Audits for Digital Computer Software Used in Safety Systems of Nuclear Power Plants

10 CFR 50.55a(a)(1) 10 CFR 50.55a(h) GDC 1 10 CFR 50 App B, Criteria 1, 2, 3, 11,

and 18 RG 1.169, Rev. -- Configuration Management Plans for Digital

Computer Software Used in Safety Systems of Nuclear Power Plants

10 CFR 50.55a(a)(1) 10 CFR 50.55a(h) GDC 1 10 CFR 50 App B, Criteria 3

RG 1.170, Rev. -- Software Test Documentation for Digital Computer Software Used in Safety Systems of Nuclear Power Plants

10 CFR 50.55a(h) GDC 1 GDC 21 10 CFR 50 App B, Criteria 1, 3, 4, 6, 11,

and 17 RG 1.171, Rev. -- Software Unit Testing for Digital Computer

Software Used in Safety Systems of Nuclear Power Plants

10 CFR 50.55a(h) GDC 1 GDC 21 10 CFR 50 App A, Criterion 1 10 CFR 50 App B, Criteria 1, 2, 3, 5, 6,

11, and 17


NuPAC_ED610000-047-P B 9 of 204 01/19/2012


Identifier Title Bases for RG 1.172, Rev. -- Software Requirements Specifications for Digital

Computer Software Used in Safety Systems of Nuclear Power Plants

10 CFR 50.55a(h) GDC 1 10 CFR 50 App A, Criteria 12, 13, 19,

20, 22, 23, 24, 25, and 28 10 CFR 50 App B, Criterion 3

RG 1.173, Rev. -- Developing Software Life Cycle Processes for Digital Computer Software Used in Safety Systems of Nuclear Power Plants

10 CFR 50.55a(h) GDC 1 10 CFR 50 App B, Criteria 1, 2, 3, 6, 15,

and 17 RG 1.180, Rev. 1 Guidelines for Evaluating Electromagnetic and

Radio- Frequency Interference in Safety-Related Instrumentation and Control Systems

10 CFR 50.55a(a)(1) 10 CFR 50.55a(h) GDC 1 GDC 2 GDC 4 10 CFR 50 App B, Criteria 3, 11

RG 1.204, Rev. -- Guidelines for Lightning Protection of Nuclear Power Plants

10 CFR 50.55a 10 CFR 50.55a(h) GDC 2

RG 1.209, Rev. -- Guidelines for Environmental Qualification of Safety-Related Computer-Based Instrumentation and Control Systems in Nuclear Power Plants

GDC 1 GDC 2 GDC 4 GDC 13 GDC 21 GDC 22 GDC 23 10 CFR 50 App B, Criteria 3, 11, 17 IEEE Std. 603-1991

(ANSI/IEEE Std. 279-1971) BTP 7-8, Rev. 5 Guidance on Application of Regulatory Guide

1.22 Note relative guidance for RG 1.22.

BTP 7-11, Rev. 5 Guidance on Application and Qualification of Isolation Devices

Note relative guidance for RG 1.75.

BTP 7-12, Rev. 5 Guidance on Establishing and Maintaining Instrument Setpoints


BTP 7-14, Rev. 5 Guidance on Software Reviews for Digital Computer-Based Instrumentation and Control Systems

10 CFR 50.55a(a)(1) 10 CFR 50.55a(h) GDC 1 GDC 21 10 CFR 50 App B, Criteria 3, 5, 6, 7, 11

BTP 7-17, Rev. 5 Guidance on Self-Test and Surveillance Test Provisions


BTP 7-19, Rev. 5 Guidance on Evaluation of Defense in-Depth and Diversity in Digital Computer-Based Instrumentation and Control Systems

SRM to SECY-93-087 II.Q


NuPAC_ED610000-047-P B 10 of 204 01/19/2012


Identifier Title Bases for BTP 7-21, Rev. 5 Guidance on Digital Computer Real-Time

Performance 10 CFR 50.55a(h) GDC 10 GDC 12 GDC 13 GDC 19 GDC 20 GDC 21 GDC 23 GDC 25 GDC 28 GDC 29

IEEE Std. 323-1974 IEEE Standard for Qualifying Class 1E Equipment for Nuclear Power Generating Stations

RG 1.89


RG 1.209

ANSI/IEEE Std. 379-2000

Standard Application of the Single-Failure Criterion to Nuclear Power Generating Station Safety Systems

RG 1.53

IEEE Std. 384-1992 IEEE Standard Criteria for Independence of Class 1E Equipment and Circuits

RG 1.75

ISA S67.04-1994 Part 1 Setpoints for Nuclear Safety-Related Instrumentation"

RG 1.105

IEEE Std. 338-1987 Standard Criteria for the Periodic Surveillance Testing of Nuclear Power Generating Station Safety Systems

RG 1.118

IEEE Std. 7-4.3.2-2003 IEEE Standard Criteria for Digital Computers in Safety Systems of Nuclear Power Generating Stations

RG 1.152

IEEE Std. 603-1991 IEEE Standard Criteria for Safety Systems for Nuclear Power Generating Stations

RG 1.153

IEEE Std. 1012-1998 IEEE Standard for Software Verification and Validation

RG 1.168

IEEE Std. 1028-1997 IEEE Standard for Software Reviews and Audits RG 1.168 IEEE Std. 828-1990 IEEE Standard for Software Configuration

Management Plans RG 1.169

IEEE Std. 1042-1987 IEEE Guide to Software Configuration Management

RG 1.169

IEEE Std. 829-1983 IEEE Standard for Software Test Documentation RG 1.170 IEEE Std. 1008-1987 IEEE Standard for Software Unit Testing RG 1.171 IEEE Std. 830-1993 IEEE - Recommended Practice for Software

Requirements Specifications RG 1.172

IEEE Std. 1074-1995 IEEE Standard for Developing Software Life Cycle Processes

RG 1.173

IEEE Std. 730-1998 IEEE Standard for Software Quality Assurance Plans

Invoked by IEEE Std. 7-4.3.2-2003 Invoked by IEEE Std. 1074-1995

IEEE Std. 1016-1987 IEEE Recommended Practice for Software Design Descriptions

Invoked by IEEE Std. 1074-1995


NuPAC_ED610000-047-P B 11 of 204 01/19/2012


Identifier Title Bases for IEEE Std. 1540-2001 IEEE Standard for Life Cycle Processes - Risk

Management Invoked by IEEE Std. 7-4.3.2-2003

IEEE Std. 1050-1996 IEEE Guide for Instrumentation and Control Equipment Grounding in Generating Stations

RG 1.180 RG 1.204

MIL-STD-461E-1999 Requirements for the Control of Electromagnetic Interference Characteristics of Subsystems and Equipment

RG 1.180

IEEE Std. C62.41-1991 IEEE Recommended Practice on Surge Voltages in Low-Voltage AC Power Circuits

RG 1.180

IEEE Std. C62.45-1992 IEEE Guide on Surge Testing for Equipment Connected to Low-Voltage AC Power Circuits

RG 1.180

EPRI TR-107330, December 1996

Generic Requirements Specification for Qualifying a Commercially Available PLC for Safety-Related Application in Nuclear Power Plants

RG 1.209 Note the EMC requirements of RG 1.180 Revision 1 have been utilized in lieu of the older EMC requirements of EPRI TR-107300 and EPRI TR-102323.

IEEE Std. 344-2004 Recommended Practice for Seismic Qualification of Class 1E Equipment for Nuclear Power Generating Stations

RG 1.100

EPRI TR-102323, Revision 2

Guidelines for Electromagnetic Interference Testing in Power Plant Equipment

Invoked by EPRI TR-107330 Note the EMC requirements of RG 1.180 Revision 1 have been utilized in lieu of the older EMC requirements of EPRI TR-107300 and EPRI TR-10232.

IEEE Std. 627-1980 IEEE Standard for Design Qualification of Safety Systems Equipment Used in Nuclear Power Generating Stations




IEEE Std. 420-1982 IEEE Standard for the Design and Qualification of Class 1E Control Boards, Panels, and Racks Used in Nuclear Power Generating Stations


IEEE Std. 494-1974 (R1990)

IEEE Standard Method for Identification of Documents Related to Class 1E Equipment and Systems for Nuclear Power Generating Stations


IEEE Std. 1023-1988 IEEE Guide for the Application of Human Factors Engineering to Systems, Equipment, and Facilities of Nuclear Power Generating Stations


IEEE Std. 352-1987 IEEE Guide for General Principles of Reliability Analysis of Nuclear Power Generating Station Safety Systems

Invoked by IEEE Std. 603-1991 Invoked by IEEE Std. 7-4.3.2-2003

IEEE Std. 577-2004 IEEE Standard Requirements for Reliability Analysis in the Design and Operation of Safety Systems for Nuclear Facilities


DI&C-ISG-02, Rev. 2 Diversity and Defense-in-Depth Issues BTP 7-19 DI&C-ISG-04, Rev. 1 Highly-Integrated Control Rooms –

Communication Issues 10 CFR 50.55a(h) GDC 24 RG 1.152

DI&C-ISG-06, Rev. 1 Licensing Process BTP 7-14 and others


NuPAC_ED610000-047-P B 12 of 204 01/19/2012



NuPAC_ED610000-047-P B 13 of 204 01/19/2012




NuPAC_ED610000-047-P B 14 of 204 01/19/2012


3.0 DESCRIPTION OF THE NuPAC DIGITAL SAFETY I&C PLATFORM

3.1 Overview

3.1.1 Nuclear Power Plant Context

NPPs rely on I&C systems for monitoring, control, and protection. These I&C systems are grouped generally into three types—plant monitoring and display systems, plant control systems, and plant protection and mitigation systems. Additionally, I&C systems fall into two subcategories referred to within the nuclear industry as "non-safety" and "safety.”

Operators use non-safety systems to monitor and control the normal operation of the plant, including startup and shutdown, and to mitigate and prevent plant operational transients. These non-safety systems are backed up by a set of independent (non-interacting), redundant safety systems that are designed to take automatic action to prevent and mitigate accident conditions if the operators and the non-safety systems fail to maintain the plant within normal operating conditions.

The NuPAC platform functions as the control element for safety-critical applications; therefore, the focus of this document is on the safety subset of NPP protection and mitigation systems.

3.1.2 Control System Context

NPP protection and mitigation I&C safety systems are composed of sensors, controllers (control electronics), and actuators.

Sensors are located throughout the power plant. Sensors interface real-world parameters to the controllers. Sensors monitor important plant characteristics, such as the temperature of core cooling water, the pressure of the steam generator, and the neutron flux activity of the core. These measured parameters are converted into usable signals. Sensors convert a temperature variation into a measureable resistance or voltage. They convert pressure deflection or mechanical motion to a measureable voltage. They convert neutron flux to a measureable current. Resistance, voltage, and current are applied to and manipulated by the controllers. Furthermore, sensors are hardwired to controllers.

Data from sensors is sampled by controllers. Specific instructions are executed by the controllers repetitively on updated sensor data. Combinations of sensor data result in a coordinated control of the conditions within the reactor. Control decisions determined by the controllers are executed by the actuators. Actuators are hardwired to controllers.

Actuators are also located throughout the power plant. They respond to the control commands generated by the controllers. General types of actuators include electromechanical, hydraulic, and pneumatic. These actuators allow a pump motor to spin, a pressure valve to rotate, and a control rod to move. The actuator function results in changes to plant operating conditions, which continue to be monitored by the sensors. The constant cycle of measurement, control, and adjustment continues as the reactor operates.

The NuPAC platform is a control system platform specifically designed to serve as the controller (control electronics) for NPP safety-critical plant protection and mitigation systems (Figure 3.1.2-1).


NuPAC_ED610000-047-P B 15 of 204 01/19/2012


Figure 3.1.2-1. NuPAC Context

3.1.3 Architecture

The NuPAC platform is functionally and physically similar to commercially available programmable logic controllers (PLCs). However, the decentralized NuPAC FPGA-based architecture provides a unique paradigm akin to legacy NPP hardware-based solutions (e.g., analog measurement and trip modules).

An early development trade study, concluded to avoid use of microprocessors and software in the NuPAC platform in favor of a true hardware-based solution. The physical size of a true hardware-based solution resulted in a solution in which FPGA devices were used to realize hardware structures. Although the NuPAC platform is a FPGA-based product, the development process for the FPGA programmable logic follows accepted software development guidance, as described in Section 5.0.

The complexity and capability of FPGA products have made it possible to build, or to embed, whole microprocessor cores into an FPGA. This advance in programmable logic devices (PLDs) has resulted in a blurring of the lines between what was traditionally considered a software product and a programmable logic (PL) product. The cooperative development stayed true to the original intent of using PL as a method of producing hardware. Microprocessor-based structures are avoided in favor of discrete hardware based solutions.

The NuPAC platform contains no embedded software. Its design replaces the main operating loop (MOL) of a typical microprocessor-based platform by making use of dedicated independent state machines. The use of PL-based state machines is inherently safer than a reliance on microprocessors. The use of dedicated state machines also results in a distributed architecture that greatly improves processing throughput while simplifying verification and validation activities. In general, complex instruction sets, and the attendant risk of miss-operation that these instruction sets introduce, are avoided in the NuPAC platform design.

The architecture of the NuPAC platform is centered about a configurable electronic module called the Generic Logic Module (GLM). The GLM is a circuit card assembly consisting of a Carrier Card, a Logic Mezzanine, and up to eight I/O mezzanines (Figure 3.1.3-1). Each GLM provides the capability to accomplish input/output processing, customizable control logic, diagnostics, and data communication.

The Carrier Card interfaces up to eight I/O mezzanines to the Logic Mezzanine. The eight I/O mezzanine slots provide the flexibility to mix and match a variety of I/O functions on a single GLM.


NuPAC_ED610000-047-P B 16 of 204 01/19/2012


The I/O mezzanines read and write field input and output signals, including serial communication signals. The I/O mezzanines interface to the Logic Mezzanine via the Carrier Card. There are six variants of I/O mezzanines, which include:

1) Analog Input Mezzanine 2) Discrete/Pulse Input Mezzanine 3) Temperature Input Mezzanine

4) RS-422/485 Mezzanine 5) Analog Output Mezzanine 6) Solid State Relay (SSR) Mezzanine.

Figure 3.1.3-1. Generic Logic Module Configuration

The Logic Mezzanine provides a logic solving capability implemented using two FPGAs. The Logic Mezzanine hosts a non-configurable FPGA and a configurable FPGA. The non-configurable FPGA, known as the Core FPGA or Core PLD, is utilized for general infrastructure-like logic. The Core PLD is reusable logic which does not change from plant application to plant application. The configurable FPGA, known as the Application Specific FPGA or Application Specific PLD (ASPLD), is utilized for implementing plant-specific designs capable of executing plant-specific logic and algorithms.

The GLMs are chassis installed. The GLMs are front-loaded and interface to a backplane (more accurately a mid-plane) within the chassis.

The chassis also supports Rear Transition Modules (RTMs), which plug into the back (rear) of the chassis (Figures 3.1.3-2 and -3) in slot locations that match the front-loaded GLMs. The RTMs and GLMs are interconnected through connectors on the backplane (Figure 3.1.3-4). The RTM interfaces field input and output


NuPAC_ED610000-047-P B 17 of 204 01/19/2012


signals, including serial communication signals, to the GLM by busing those signals from card-top connectors on the RTM through the corresponding backplane connector, to the GLM carrier card, and on to the GLM I/O mezzanines.

Up to 18 GLM/RTM pairs may be installed within a single chassis. Scalability is realized by cascading multiple GLMs together within a chassis, with additional scalability realized by cascading multiple chassis of GLMs together. Modularity and scalability permit functional arrangements (both I/O and logic solving).

Additional architecture details may be found in the NuPAC System Description Report (Reference 3-1).

Figure 3.1.3-2. Chassis


NuPAC_ED610000-047-P B 18 of 204 01/19/2012


Figure 3.1.3-3. Chassis Installed GLMs and RTMs


NuPAC_ED610000-047-P B 19 of 204 01/19/2012


Figure 3.1.3-4. GLM/Backplane/RTM Configuration


NuPAC_ED610000-047-P B 20 of 204 01/19/2012


3.1.4 Qualified Components

Table 3.1.4-1 summarizes the qualified hardware components and the programmable logic configuration items to be provided in the NuPAC Verification and Validation Summary Report (Reference 3-2).

Table 3.1.4-1. Qualified Components Part Number Description

610100 Chassis 610120 Rear Transition Module (RTM) 610310 Carrier Card, Generic Logic Module (GLM) 610320 Logic Mezzanine, GLM 610330 Analog Input Mezzanine, GLM 610340 Discrete/Pulse Input Mezzanine, GLM 610350 Temperature Input Mezzanine, GLM 610360 RS-422/485 Mezzanine, GLM 610370 Analog Output Mezzanine, GLM 610380 SSR Mezzanine, GLM 610400 Core FPGA Logic 610405* Common Application-Specific FPGA Interface Logic

*If common interface logic is defined within the ASPLD logic architecture, this common interface logic shall be developed separately from plant-specific logic as a reusable common application logic interface configuration item, part number 610405. A future intent is to identify this architecture through the development of the Test Specimen Configuration (TSC) and future plant-specific application needs.


NuPAC_ED610000-047-P B 21 of 204 01/19/2012


3.2 Hardware

From its inception, the NuPAC platform has been designed to be used in NPP I&C safety systems. The NuPAC platform utilized EPRI TR-107330 (Reference 3-3) as a basis for functional and performance requirements. In addition, the NuPAC platform has been designed specifically to satisfy environmental withstand requirements of EPRI TR-107330 and electromagnetic compatibility requirements of USNRC RG 1.180 Revision 1 (Reference 3-4). The NuPAC platform is suitably rugged for NPP design basis events and long service life. With respect to reliability, electrical components used on the circuit card assemblies have been de-rated in terms of maximum electrical stress applied under worst-case conditions, including a 60ºC continuous operating environment. The resultant reliability, combined with the NuPAC platform’s extensive self-test features, yields a highly available and safe system.

3.2.1 Generic Logic Modules

The Generic Logic Module (GLM) is a circuit card assembly (shown previously in Figure 3.1.2-1) which consists of a Carrier Card, a Logic Mezzanine, and up to eight I/O mezzanines of which there are six variants. Each GLM offers the capability to accomplish input/output processing, control logic, diagnostics, and data communication. Figure 3.2.1-1 shows GLM components and assembly; Figure 3.2.1-2 shows a basic block diagram of the GLM.

Figure 3.2.1-1. GLM Components and Assembly


NuPAC_ED610000-047-P B 22 of 204 01/19/2012


Figure 3.2.1-2. GLM Block Diagram


NuPAC_ED610000-047-P B 23 of 204 01/19/2012


The Carrier Card accommodates mezzanine circuit card assemblies (I/O mezzanines and the Logic Mezzanine). The Carrier Card provides local power management. The Carrier Card constitutes the base of a GLM. It mechanically and electrically interfaces the Logic Mezzanine with the I/O mezzanines, while providing connectors to other peripheral interfaces via the chassis backplane. The capabilities of the Carrier Card are explained further in Section 3.2.1.1.

Each GLM supports up to eight I/O mezzanines. The I/O mezzanines provide access to a single field data item, such as an analog or discrete input or output, or a serial communication port. I/O mezzanine capabilities are detailed in Section 3.2.1.2.

The Logic Mezzanine provides a logic solving capability implemented using two FPGAs. The Logic Mezzanine features a configurable FPGA for implementing plant-specific designs. Capabilities of the Logic Mezzanine are discussed in Section 3.2.1.3.

As shown previously in Figure 3.1.3-3, the GLMs are installed from the front of the chassis. Each GLM plugs into three backplane connectors that connect each GLM to power—hardwired low-voltage differential signaling (LVDS) communication within the chassis via the backplane—and field input and output signals—including discrete, analog, and serial communication signals—via the Rear Transition Modules (RTMs).

3.2.1.1 Carrier Card, P/N 610310

The 610310 Carrier Card is a 360mm high and 340mm deep 9U size D Eurocard format circuit card assembly. The Carrier Card mechanical format and the backplane connector layout are defined in IEEE Standard 1101.1, “IEEE Standard for Mechanical Core Specifications for Microcomputers Using IEC 60603-2 Connectors” (Reference 3-5).

The Carrier Card (Figure 3.2.1.1-1) is a circuit card providing nine mezzanine interfaces—one Logic Mezzanine and eight I/O mezzanine interfaces. The Carrier Card mechanically and electrically interfaces the Logic Mezzanine with the I/O mezzanine, while providing connectors to other peripheral interfaces via the chassis backplane. The Carrier Card facilitates a modular approach to system assembly because each Carrier Card is populated with one Logic Mezzanine and any combination of I/O mezzanine (up to eight). The integration of a Logic Mezzanine and I/O mezzanines forms an intelligent single-board system, the GLM.


NuPAC_ED610000-047-P B 24 of 204 01/19/2012


Figure 3.2.1.1-1. Carrier Card

The power interface is via backplane connectors. Onboard the Carrier Card, redundant input power is fused and diode auctioneered. Hot-swapping is employed to allow a GLM to be installed in or removed from a powered chassis. From the auctioneered input power, power supplies develop the required power for the local circuitry. In addition, power-sequencing circuitry controls the power up of I/O mezzanines to manage inrush currents.

As part of built-in testing (BIT), an analog-to-digital converter (ADC) is employed to monitor redundant input power and auctioneered power, as well as to verify onboard derived power supply voltages. In addition, fuse


NuPAC_ED610000-047-P B 25 of 204 01/19/2012


monitoring is provided for both redundant input power sources. Temperature sensing is also provided to monitor forced air fan cooling effectiveness.

The Carrier Card provides an interface between the Logic Mezzanine and the circuitry of the I/O mezzanines and the Carrier Card itself. The interface is via four board-to-board receptacle connectors. Likewise, the Carrier Card provides interfaces between the eight I/O mezzanines and the circuitry of the Logic Mezzanine and the Carrier Card itself. These interfaces are via 16 board-to-board receptacle connectors (two per I/O mezzanine). The Carrier Card provides an interface to the backplane via three backplane connectors.

The backplane interface allows point-to-point serial data communication among GLMs within a chassis. Standard universal asynchronous receiver/transmitter (UART) data links to/from the Core Programmable Logic Device (PLD) on the Logic Mezzanine are passed to the Carrier Card through the board-to-board connectors. Onboard the Carrier Card, the UART signals are converted to/from LVDS. The GLM-to-GLM LVDS serial data link interface is via the backplane. Onboard the Carrier Card, eight transceivers provide eight transmit ports. Likewise, eight receivers provide eight receive ports.

As part of BIT, the integrity of LVDS-transmitted data is verified by loop-back data transmission validation. Utilizing the receiver portion of the transmit ports’ transceivers to loop back the transmitted data for verification accomplishes this.

The backplane interface also links field input and output signals to the Carrier Card. Field input and output signals, including serial communication signals, are linked to the Carrier Card through the backplane connectors which interface with the RTM, which in-turn mate with the field connections (RTM card-top connectors). Onboard the Carrier Card, the field input and output signals are routed to the respective I/O mezzanines. The input and output signals interface to the I/O mezzanines through the respective board-to-board connectors.

The backplane interface also passes dedicated chassis/backplane signals to the Carrier Card. The signals include slot identification, chassis identification, memory protect, and four system monitors. The signals interface via the backplane connector.

The Carrier Card provides a communications and test interface connector (CTIC), which is a cable-to-board shielded connector. The CTIC provides an interface to the external test systems and programming devices. The CTIC is not accessible when the GLM is installed into a chassis.

The CTIC is provided to configure the non-volatile memory content and access the test functions provided on the Logic Mezzanine. The CTIC allows point-to-point serial data communication between an external test system and a GLM. Standard UART data links to/from the Core PLD on the Logic Mezzanine are passed to the Carrier Card through the board-to-board connectors. Onboard the Carrier Card, the UART signals are converted to/from RS-422. The serial data link interface is through the CTIC via a cable to the external test system. Onboard the Carrier Card, a single isolated full-duplex transceiver provides one transmit port and one receive port.

The CTIC is also provided to configure the FPGAs on the Logic Mezzanine. The CTIC includes a Joint Test Action Group (JTAG) interface associated with the Core Programmable Logic Device (Core PLD) and a JTAG interface associated with the Application Specific PLD (ASPLD). The CTIC is not accessible when the GLM is in its installed position; thus, FPGA configuration changes cannot occur while the NuPAC platform is performing its safety functions.

The Carrier Card provides LED type indicators that are visible from the GLM front panel (card-top). The LED indicators display the GLM health status, including BIT pass, BIT fail, and operational mode (e.g., GLM running). The LED indicators also display I/O status associated with the eight I/O mezzanines. The I/O status LED indicators illuminate when the respective input/output is active for bistables or when transmitting/receiving


NuPAC_ED610000-047-P B 26 of 204 01/19/2012


data for serial communication. In addition, four user-defined LED indicators are provided to support plant-specific application requirements.

The LED indicators are controlled by the Core PLD on the Logic Mezzanine. LED control signals are output from the Core PLD and passed to the Carrier Card through the board-to-board connectors. Onboard the Carrier Card, buffer circuits drive the LEDs.

Additional design details are included in the GLM Design Report (Reference 3-6).

3.2.1.2 I/O Mezzanines

The I/O mezzanines are modular circuit card assemblies physically based on a modified version of an industry standard form factor, the Industry Pack (IP) Module specification per ANSI/VITA 4-1995 (Reference 3-7). The modification replaced the standard IP connectors on each end of the circuit card with two 64-pin IEEE Standard 1386-type connectors. The I/O mezzanines are 3 inches wide by more than 2 inches high. The connectors are installed parallel to the short side, almost at each end of the printed circuit boards. Figure 3.2.1.2-1 shows a typical I/O mezzanine.

Figure 3.2.1.2-1. Typical I/O Mezzanine

The GLM design supports up to eight input, output, or serial communication I/O mezzanines. There are six variants of I/O mezzanines. Each input mezzanine provides a single input, whether analog, pulse, or discrete. Each output mezzanine provides a single output, whether analog or discrete. The serial communication mezzanine


NuPAC_ED610000-047-P B 27 of 204 01/19/2012


provides one receiver and one transmitter. The I/O mezzanines interface with the Core PLD and by extension the ASPLD, which both reside on the Logic Mezzanine.

Each I/O mezzanine communicates with the Core PLD, located on the Logic Mezzanine, through up to three point-to-point serial peripheral interfaces (SPIs) which connect to devoted SPI drivers in the Core PLD logic. These SPI links provide a means for the Core PLD to read/write data from/to the I/O mezzanines’ circuitry. The Core PLD acts as master device and controls the data exchange with the I/O mezzanines, with a data request from the master to the slave followed by a response from the slave to the master.

Each I/O mezzanine includes an identification code, stored in a serial EEPROM. To preclude inadvertent changes to the content of the EEPROM, a hardware write protect capability is provided which disables any writes to the EEPROM. The EEPROM is only programmable at the factory. A dedicated SPI link provides the Core PLD with the ability to read and identify the I/O mezzanine type from this EEPROM. The SPI link is always associated with the identification EEPROM, and is not electrically isolated since there are no field connections.

The logic of the Core PLD, located on the Logic Mezzanine, includes identification of the expected I/O mezzanines. The logic reads the identification response from each I/O mezzanine during the power-on self test (POST), and will not start if incorrect or unresponsive I/O mezzanines are installed.

The other two SPI links are electrically isolated, if the link is used, and provide access to the standard registers provided in the design of each of the integrated circuits provided on the I/O mezzanines. As an example, the Texas Instruments ADS1247 analog-to-digital converter data sheets provides detailed descriptions of the 16 registers provided in that device.

Each I/O mezzanine provides electrical isolation in accordance with the requirements for class 1E to non-Class 1E isolation. This isolation provides at least 600V peak (more than 424 VAC RMS) for 30 seconds, and 250 VDC for 30 seconds.

I/O mezzanines are connected to the Carrier Card power planes. Each I/O mezzanine has onboard power management circuitry to isolate the mezzanine power from the Carrier Card power and provide the required regulated power for its respective circuitry. As part of BIT, an ADC monitors the onboard power supplies to verify onboard power supply operation.

All field inputs and outputs on the I/O mezzanines are isolated electrically. Each I/O mezzanine has an isolated common, which is wired appropriately through the backplane connectors and RTM to field wiring.

3.2.1.2.1 Analog Input Mezzanine, P/N 610330

The 610330 Analog Input Mezzanine is a circuit card with the capability to monitor a single differential analog input. The Analog Input Mezzanine is capable of accepting either an analog input voltage or an analog input current, but not both at the same time. Two analog input voltage ranges are provided, 0 to 5 VDC and 0 to 10 VDC. Two analog input current ranges are provided, 4 to 20 mA and 10 to 50 mA.

The power interface is via the Carrier Card through the board-to-board connectors. Onboard the mezzanine, isolated power supplies develop the required power for the local circuitry. Galvanic isolation isolates the mezzanine’s circuitry from the Carrier Card power and from all other GLM inputs and outputs. As part of BIT, to verify onboard power supply operation, an ADC monitors the onboard power supplies.

The field I/O interface is via the Carrier Card through the board-to-board connectors. The analog inputs are scaled such that their input ranges are compatible with those of the ADC. A 24-bit ADC monitors the voltages developed by the current sense and voltage divider circuitry.


NuPAC_ED610000-047-P B 28 of 204 01/19/2012


The ADC features an onboard, low-noise, programmable gain amplifier (PGA), a precision delta-sigma (ΔΣ) ADC with a single-cycle settling digital filter, and an internal oscillator. The ADC contains an input multiplexer capable of selecting one of four differential inputs (e.g., current inputs, voltage inputs, and BIT inputs). The low -noise PGA provides selectable gains of 1 to 128. The ΔΣ modulator and adjustable digital filter settle in only one cycle. The ADC is capable of supporting data sampling rates up to 2,000 samples per second.

As part of BIT, the ADC input ranges are designed such that under and over voltage and current conditions can be detected and reported. To verify ADC measurement accuracy, the ADC monitors a known independent reference voltage.

The ADC provides a standard SPI data link to the Core PLD on the Logic Mezzanine. The SPI data link interface is via the Carrier Card through the board-to-board connectors. Onboard the mezzanine, the SPI data link interface is isolated through a high-speed digital isolator. The isolator has logic input and output buffers separated by a silicon dioxide (SiO2) isolation barrier. Used in conjunction with isolated power supplies, the isolator blocks high voltage, isolates grounds, and prevents noise currents from entering the local ground and interfering with or damaging sensitive circuitry.


3.2.1.2.2 Discrete/Pulse Input Mezzanine, P/N 610340

The 610340 Discrete/Pulse Input Mezzanine is a circuit card with the capability to monitor a single discrete or pulse input. The Discrete/Pulse Input Mezzanine is capable of accepting either a discrete AC input voltage, or a DC input voltage, or digital input pulses, but not all at the same time (i.e., mutually exclusive). The Discrete/Pulse Input Mezzanine is capable of interfacing to any one of the following input voltage ranges:

0 to 24 VAC 0 to 120 VAC 0 to 12 VDC 0 to 15 VDC

0 to 24 VDC 0 to 48 VDC 0 to 125 VDC.

A pulse input range of 2.5 to 28 volts is provided (e.g., pulses whose magnitudes are below 2.5 volts are considered a logic low), with an operating frequency range of 20 Hz to 100 KHz.

The power interface is via the Carrier Card through the board-to-board connectors. Onboard the mezzanine, isolated power supplies develop the required power for the local circuitry. Galvanic isolation isolates the mezzanine’s circuitry from the Carrier Card power and from all other GLM inputs and outputs.

The field I/O interface is via the Carrier Card through the board-to-board connectors.

For a discrete input, the discrete inputs are conditioned and scaled such that their input ranges are compatible with those of the ADC. A 24-bit ADC monitors the voltages developed by the conditioning and voltage divider circuitry.

The ADC features an onboard, low-noise, programmable gain amplifier (PGA), a precision delta-sigma (ΔΣ) ADC with a single-cycle settling digital filter, and an internal oscillator. The ADC contains an input multiplexer capable of selecting one of four differential inputs (e.g., voltage inputs, and BIT inputs). The low noise PGA provides selectable gains of 1 to 128. The ΔΣ modulator and adjustable digital filter settle in only one cycle. The ADC is capable of supporting data sampling rates up to 2,000 samples per second.


NuPAC_ED610000-047-P B 29 of 204 01/19/2012


As part of BIT, the ADC input ranges are designed such that under and over voltage and current conditions can be detected and reported. To verify ADC measurement accuracy, the ADC monitors a known independent reference voltage.

The ADC provides a standard SPI data link to the Core PLD on the Logic Mezzanine. The SPI data link interface is via the Carrier Card through the board-to-board connectors. Onboard the mezzanine, the SPI data link interface is isolated through a high-speed digital isolator. The isolator has logic input and output buffers separated by an SiO2 isolation barrier. Used in conjunction with isolated power supplies, the isolator blocks high voltage, isolates grounds, and prevents noise currents from entering the local ground and interfering with or damaging sensitive circuitry.

For a pulse input, the inputs are conditioned and applied to a comparator. The comparator compares the voltage developed by the conditioning circuitry against a threshold to detect the presence of a pulse. The comparator provides the corresponding bistable (pulse present or pulse not present) to the Core PLD on the Logic Mezzanine. Onboard the mezzanine, the bistable is isolated through a high-speed digital isolator, similar to the ADC’s SPI data link.


3.2.1.2.3 Temperature Input Mezzanine, P/N 610350

The 610350 Temperature Input Mezzanine is a circuit card with the capability to monitor a single temperature input. The Temperature Input Mezzanine is capable of accepting either a resistance temperature detector (RTD) or a thermocouple input, but not both at the same time. The Temperature Input Mezzanine is capable of interfacing to any one of the following thermocouple types:

Type ‘E’, temperature range 0 to 1,000°C (32 to 1,832°F) Type ‘J’, temperature range 0 to 1,200°C (32 to 2,192°F) Type ‘K’, temperature range 0 to 1,300°C (32 to 2,372°F) Type ‘B’, temperature range 0 to 1,800°C (32 to 3,272°F) Type ‘N’, temperature range 0 to 1,250°C (32 to 2,282°F) Type ‘R’, temperature range 0 to 1,700°C (32 to 3,092°F) Type ‘S’, temperature range 0 to 1,700°C (32 to 3,092°F) Type ‘T’, temperature range 0 to 400°C (32 to 752°F).

The Temperature Input Mezzanine is capable of interfacing to European standard and American standard RTDs of the, following two-, three-, or four-wire types:

100 ohm, temperature range 0 to 800°C (32 to 1,472°F) 200 ohm, temperature range 0 to 800°C (32 to 1,472°F).


The field I/O interface is via the Carrier Card through the board-to-board connectors. A 24-bit ADC monitors the voltages developed across a thermocouple or RTD. For a RTD input, excitation current is provided from a single or two matched current sources, depending on the RTD type.

For linearization of a thermocouple input, the measured value from the ADC is adjusted based upon the cold junction compensation (CJC) value and the gain/offset calibration, then refers to the appropriate lookup table for


NuPAC_ED610000-047-P B 30 of 204 01/19/2012


that particular thermocouple type. A RTD input implemented onboard the same GLM may be utilized to sample the CJC value. The linearization calculation is performed by the Core PLD on the Logic Mezzanine.

For linearization of a RTD, the measured value from the ADC is adjusted based upon the gain/offset calibration, then refers to the appropriate lookup table for that particular RTD type. The linearization calculation is performed by the Core PLD on the Logic Mezzanine.

The ADC features an onboard, low-noise, programmable gain amplifier (PGA), a precision delta-sigma (ΔΣ) ADC with a single-cycle settling digital filter, and an internal oscillator. The ADC contains an input multiplexer capable of selecting one of four differential inputs (e.g., thermocouple/RTD inputs, and BIT inputs). The low noise PGA provides selectable gains of 1 to 128. The ΔΣ modulator and adjustable digital filter settle in only one cycle. The ADC is capable of supporting data sampling rates up to 2,000 samples per second.

As part of BIT, sensor burnout (malfunction) detection is provided, including thermocouple open circuit, RTD open circuit, and RTD short circuit failure modes. To verify ADC measurement accuracy, the ADC monitors a known independent reference voltage.



3.2.1.2.4 RS-422/485 Mezzanine, P/N 610360

The 610360 RS-422/485 Mezzanine is a circuit card with the capability to provide a serial data interface. The RS-422/485 Mezzanine provides one transmit port and one receive port. The ports are galvanically isolated from each other. The maximum port data rate is 5 Mbps.

The power interface is via the Carrier Card through the board-to-board connectors. Onboard the mezzanine, isolated power supplies develop the required power for the local circuitry. Galvanic isolation isolates the mezzanine’s circuitry from the Carrier Card power and from all other GLM inputs and outputs.

The field I/O interface is via the Carrier Card through the board-to-board connectors. A transceiver provides an isolated transmit port. Likewise, a second transceiver provides an isolated receive port.

At the maximum data rate of 5Mbps, the transmit port provides the drive capability to permit communication over twisted pair wire up to a recommended maximum length of 30 feet. For distances greater than 30 feet, an external device (repeater or fiber optic converter) is suggested. The differential driver outputs are protected from short circuits.

As part of BIT, the integrity of the transmitted data is verified by loop-back data transmission validation. This is accomplished by utilizing the receiver portion of the transmit port’s transceiver to loop-back the transmitted data for verification.

The transceivers convert RS-422/485 signals to/from logic level UART data links, which are routed to the Core PLD on the Logic Mezzanine. The UART data link interfaces are via the Carrier Card through the board-to-board connectors. Onboard the RS-422/485 Mezzanine, the UART data link interfaces are isolated within the transceivers themselves. Used in conjunction with isolated power supplies, the transceivers block high voltage,


NuPAC_ED610000-047-P B 31 of 204 01/19/2012


isolate grounds, and prevent noise currents from entering the local ground and interfering with or damaging sensitive circuitry.


3.2.1.2.5 Analog Output Mezzanine, P/N 610370

The 610370 Analog Output Mezzanine is a circuit card with the capability of outputting a single differential analog output. The Analog Output Mezzanine is capable of providing either an analog output voltage or a loop-powered analog output current, but not both at the same time. Two analog output voltage ranges are provided, 0 to 5 VDC and 0 to 10 VDC. One analog output current range is provided, 4 to 20mA.


The field I/O interface is via the Carrier Card through the board-to-board connectors. The scaled analog outputs are developed from the output of a digital-to-analog converter (DAC).

For a voltage output, the output of a 16-bit DAC is applied to signal conditioning circuitry, differential amplifier, and buffer amplifiers, to provide a scaled voltage output. The voltage output circuit is capable of outputting up to 10mA of current into a minimum load of 1Kohm. Short circuit protection is provided.

As part of BIT for the voltage output, an ADC monitors the analog voltage output. In addition, an ADC also monitors a high accuracy current shunt to detect the loss of output current when the analog output voltage is present.

For a current output, the output of a 16-bit DAC is applied to a two-wire current transmitter, which transmits 4-20 mA signals over an industry-standard current loop. An external loop power supply (not included in this LTR) is required, 24 VDC nominal, 32 VDC recommend maximum. Like the field I/O, the loop power interface is via the Carrier Card through the board-to-board connectors. Circuitry limits the output current to approximately 32mA to protect the transmitter and loop power/measurement circuitry.

As part of BIT for the current output, an ADC monitors the presence of external loop power. In addition, an ADC also samples a current shunt to monitor the 4-20 mA loop current.

The DAC features an internal reference, is monotonic, provides very good linearity, and minimizes undesired code-to-code transient voltages. The DAC incorporates a power-on-reset circuit that ensures its outputs power up at zero-scale until a valid code is written to it.

The DAC provides a standard SPI data link to the Core PLD on the Logic Mezzanine. The SPI data link interface is via the Carrier Card through the board-to-board connectors. Onboard the mezzanine, the SPI data link interface is isolated through a high-speed digital isolator. The isolator has logic input and output buffers separated by an SiO2 isolation barrier. Used in conjunction with isolated power supplies, the isolator blocks high voltage, isolates grounds, and prevents noise currents from entering the local ground and interfering with or damaging sensitive circuitry.

The ADC provides a standard SPI data link to the Core PLD on the Logic Mezzanine. The SPI data link interface is via the Carrier Card through the board-to-board connectors. Onboard the mezzanine, the SPI data link interface is isolated through a high-speed digital isolator. The isolator has logic input and output buffers separated by an SiO2 isolation barrier. Used in conjunction with isolated power supplies, the isolator blocks high voltage,


NuPAC_ED610000-047-P B 32 of 204 01/19/2012


isolates grounds, and prevents noise currents from entering the local ground and interfering with or damaging sensitive circuitry.


3.2.1.2.6 SSR Mezzanine, P/N 610380

The 610380 SSR Mezzanine is a circuit card with the capability of controlling either an AC- or DC-powered load. The SSR Mezzanine utilizes a MOSFET type solid state relay (SSR) to accomplish the output switching action. For AC-powered loads, the SSR is capable of switching 24 to 120 VAC and is rated for continuous load currents in the range of 50 mA to 500 mA. For DC-powered loads, the SSR is capable of switching 12 to 125 VDC and is rated for continuous load currents in the range of 50 mA to 1.0A. The SSR’s surge current rating exceeds the minimum 2.0A and 4.0A ratings for AC and DC applications, respectively. The SSR may be wired in series and parallel configurations. External surge protection (not included in this LTR) should be considered when driving an inductive load.


The field I/O interface is via the Carrier Card through the board-to-board connectors. The SSR is an optically isolated DC and bi-directional output relay. The SSR provides the capability to switch AC or DC power. The SSR is utilized in a series-connected MOSFET configuration for AC switching. Alternately, the SSR is utilized in a single MOSFET configuration for DC switching. Circuitry provides over current protection by turning off the SSR when the load current exceeds the design limit.

As part of BIT, the voltage at the AC and DC SSR outputs is scaled down and is monitored by an ADC. The ADC measured voltage is utilized to determine if the field voltage applied to the SSR is within its normal operating range. The ADC also monitors the SSR load current, via a Hall-effect current sensor, to determine if it is within its normal operating range. In addition, the SSR can be implemented such that broken wires can be detected.

The circuitry of the SSR Mezzanine utilizes a simple digital I/O interface to the Core PLD on the Logic Mezzanine. The interface is via the Carrier Card through the board-to-board connectors. Onboard the mezzanine, the digital I/O interface is isolated through high-speed digital isolators. The isolators have logic input and output buffers separated by an SiO2 isolation barrier. Used in conjunction with isolated power supplies, the isolators block high voltage, isolate grounds, and prevent noise currents from entering the local ground and interfering with or damaging sensitive circuitry.



3.2.1.3 Logic Mezzanine, P/N 610320

The 610320 Logic Mezzanine is a modular circuit card assembly physically based on a modified version of an industry standard form factor, the FPGA Mezzanine Card (FMC) specification per ANSI/VITA 57.1


NuPAC_ED610000-047-P B 33 of 204 01/19/2012


(Reference 3-8). The modification replaced the two standard BGA connectors on the circuit card with four 64-pin IEEE Standard 1386 type connectors. In addition, the modification eliminated the bezels and provides mounting studs in their place. The Logic Mezzanine is shown in Figure 3.2.1.3-1.

Figure 3.2.1.3-1. Logic Mezzanine

The GLM design supports a single Logic Mezzanine. The Logic Mezzanine contains all programmable logic devices and their supporting circuitry. The programmable logic devices include two FPGAs, which are designated the Core PLD and the Application Specific PLD (ASPLD). Supporting circuitry includes volatile and non-volatile memory storage, local power management, reset circuitry, and clock generation.

The power interface is via the Carrier Card through the board-to-board connectors. The mezzanine has onboard power management circuitry to provide the required regulated power for its respective circuitry. Power sequencing and power monitoring circuits are provided to ensure the FPGAs are initialized/re-initialized to a known state.

The Logic Mezzanine provides an interface to the circuitry of the Carrier Card, and by extension, the circuitry of the I/O mezzanines. The interface is via four board-to-board receptacle connectors.


NuPAC_ED610000-047-P B 34 of 204 01/19/2012


A 50 MHz crystal oscillator provides the primary clock to the Core PLD. A second crystal oscillator of a different frequency provides a reference clock to the Core PLD. As part of BIT, the relationship between clock frequencies is monitored to verify the operation of the primary oscillator.

Core PLD and ASPLD are non-volatile flash-based FPGAs that are live at power-up and retain their programmed functionality when powered-off. Each FPGA provides 3,000,000 system gates, 504K bits of true dual-port SRAM, and 341 inputs/outputs configured as eight input/output banks.

The Core PLD contains the following functional logic:

I/O Mezzanine Controller (8) Diagnostic/Maintenance (D/M) Controller ASPLD Interface Controller NVSRAM Controller.

Backplane Interface Controller (8) Data Handler (2)

The ASPLD contains the following functional logic:

Plant-Specific Application Logic Diagnostic/Maintenance D/M Controller ASPLD Interface Controller.

SRAM Controller

Programmable logic architecture is discussed in Section 3.3.

The Logic Mezzanine provides an electrically erasable programmable read-only memory (EEPROM) with error correction code (ECC) logic and hardware write-protection. The EEPROM stores parameters and constants, such as plant-specific setpoint values, scaling/calibration constants, lookup tables, and configuration data required to support the GLM’s I/O capacity and basic functionality. The EEPROM is organized as 128K × 8-bits. The EEPROM data retention is greater than 40 years and supports a minimum of 1,000,000 write cycles. The EEPROM interfaces with the Core PLD by a high-speed SPI interface. The Core PLD controls the transfer of data to/from the EEPROM. An active low (failsafe) write-protect input signal is applied to the EEPROM to control whether the memory is write-protected.

The Logic Mezzanine also provides a static RAM (SRAM), with a non-volatile element in each memory cell. This non-volatile SRAM (NVSRAM) is utilized to temporarily store data, such as values for variables, calculations, and lookup tables. Furthermore, the NVSRAM retains temporary data through a power cycle (e.g., error codes or a fault stack). The NVSRAM is organized as 512K × 8-bits. The SRAM provides infinite read and write cycles. Independent non-volatile data retention is greater than 20 years and supports a minimum of 1,000,000 store cycles. Data transfers from the SRAM to the non-volatile elements takes place automatically at power down. On power up, data is restored to the SRAM from the non-volatile memory. The NVSRAM interfaces with the Core PLD via an 8-bit parallel bus. The Core PLD controls the transfer of data to/from the NVSRAM.

The Logic Mezzanine also provides a Static Synchronous RAM (SSRAM) with error correction code (ECC) logic. The SSRAM is provided to support plant-specific application logic and, as such, is defined by plant application requirement specifications. It can be utilized to temporarily store data, such as values for variables, calculations, and build/parse serial data messages. The SSRAM can be thought of as an extension of the ASPLD’s SRAM. The SSRAM is organized as 512K × 32-bits. The SSRAM supports unlimited true back-to-back read/write operations with no wait state insertion. The SSRAM interfaces with the ASPLD via a 36-bit parallel bus. The ASPLD controls the transfer of data to/from the SSRAM.

Several connectors are provided to support the design and development portions of the lifecycle, to facilitate testing, verification, and validation. These connectors are not intended to be used by nuclear facilities. These


NuPAC_ED610000-047-P B 35 of 204 01/19/2012


connectors are not required for hardware to be delivered to end users. Included in these are the JTAG and Matched Impedance ConnecTOR (MICTOR) interfaces to each of the FPGAs on the Logic Mezzanine. The JTAG connectors interface to FPGA programming devices and tools. The MICTOR connectors provide access to internal FPGA signals, suitable for acquisition and display on a 32-bit logic analyzer.

The JTAG and MICTOR connectors are not accessible when the GLM is in its installed position (e.g., plugged into the chassis); thus, changes cannot occur while the NuPAC platform is performing its safety functions. These connectors will not be installed on production hardware to be delivered to end users. The connectors will be installed on developmental hardware only.


3.2.2 Rear Transition Module, P/N 610120

The 610120 RTM is a 360mm high and 80mm deep 9U size D Eurocard format circuit card assembly. The RTM mechanical format and backplane connector layout are defined in IEEE Standard 1101.1, “IEEE Standard for Mechanical Core Specifications for Microcomputers Using IEC 60603-2 Connectors” (Reference 3-5). It is shown in Figure 3.2.2-1.


NuPAC_ED610000-047-P B 36 of 204 01/19/2012


Figure 3.2.2-1. Rear Transition Module

RTMs are installed from the rear of the chassis. A RTM plugs into the backplane in a slot location corresponding to each respective GLM, and thus the RTM is paired electrically with its corresponding GLM. RTMs provide a means of connecting the external field wiring to the inputs, outputs, and communication paths for each GLM.

The RTMs attach to the backplane via three backplane connectors, explained in Section 3.1.3. The RTM is designed with trace width and clearance based on the guidance of IPC-2221A (Reference 3-9), and satisfies the overall 600 volt peak isolation requirement. The contacts of RTM filed wiring connectors (card-top connectors) support isolation voltages up to 1,000 volts RMS. The RTM to backplane connectors meet the requirement by not populating certain connector contacts between signals.


NuPAC_ED610000-047-P B 37 of 204 01/19/2012


The upper field wiring connector (card-top connector) on the RTM provides the low voltage and low current signals for input, output, and communication to GLM I/O mezzanine slots 1 through 4. The middle field wiring connector on the RTM provides the low voltage and low current signals for input, output, and communication to GLM I/O mezzanine slots 5 through 8. The lower field wiring connector on the RTM provides the high-voltage and high-current signals associated with SSR outputs for GLM I/O mezzanine slots 1 through 8.

Additional RTM design details are included in the Chassis/RTM Design Report (Reference 3-10).

3.2.3 Chassis, P/N 610100

The chassis, shown Figure 3.2.3-1, provides a structured, standards-based means to mount the NuPAC platform equipment in a standard 19-inch rack mount cabinet. The chassis format is defined in International Electrotechnical Commission (IEC) Standard 60297-3-100, “Mechanical structures for electronic equipment - Dimensions of mechanical structures of the 482,6 mm (19 in) series - Part 3-100: Basic dimensions of front panels, subracks, chassis, racks and cabinets” (Reference 3-11). The chassis is designed to provide a secure seismic structure. The chassis provides electromagnetic shielding.

Figure 3.2.3-1. Chassis

The chassis provides a structured means to mount up to 18 GLMs and their paired RTMs to the backplane (mid-plane) that runs vertically from side to side within the chassis, as shown in Figures 3.1.3-3 and 3.1.3-4.

The chassis provides slots with guides for mounting 18 GLMs, defined as A1 through A18. The chassis provides slots with guides for mounting 18 RTMs, defined as B1 through B18. The chassis provides additional slots for mounting redundant modular power supplies. Note that the modular power supplies are not part of this LTR, and power is provided by external power supplies. All wiring to the NuPAC platform is attached to the rear of the chassis. Field inputs, outputs, and external communication ports interface by way of connectors on the


NuPAC_ED610000-047-P B 38 of 204 01/19/2012


RTMs. Redundant external power interfaces via two connectors integral to the chassis assembly itself. Miscellaneous chassis inputs and outputs interface via a third connector integral to the chassis assembly itself.

The chassis provides forced air fan cooling and air filtration for the GLMs and RTMs. The integrated assembly provides fan speed monitoring to provide remote alarms when fan failures occur. Multiple fans are provided, and one fan failure can be tolerated in worst-case environmental conditions. While additional fan failures could be tolerated in best-case environmental conditions, operating for extended periods with failed fans is discouraged. The effectiveness of the fans at controlling temperature is measured by temperature monitoring on each GLM.

The chassis is built in an industry-standard 9U format. The GLM, RTM, and chassis format as well as the backplane connector layout are defined in IEEE Standard 1101.1, “IEEE Standard for Mechanical Core Specifications for Microcomputers Using IEC 60603-2 Connectors” (Reference 3-5). The chassis supports GLMs that are 360mm high and 340mm deep, with seismic attachments for GLMs to the chassis. The chassis provides terminations for field inputs, outputs, and communications on RTMs that are 360mm high and 80mm deep, with seismic attachments for RTMs to the chassis.

The cooperative development worked with a vendor to modify the basic design of a commercial chassis for increased seismic rigidity and electromagnetic shielding, resulting in a design specific to the NuPAC platform. After this modification, a vendor will make this modified design for LMGI/SNPAS as a commercial item, and LMGI/SNPAS will perform the appropriate commercial grade dedication activities, in accordance with the Commercial Grade Dedication Plan (Reference 3-11), to accept the chassis.

Additional chassis design details are included in the Chassis/RTM Design Report (Reference 3-10).

3.2.3.1 Backplane

The backplane is a passive mid-plane, which is installed vertically within the chassis. The backplane allows installation of GLMs from the front of the chassis and RTMs from the rear. Each GLM is keyed to only one chassis and slot location. Within the chassis, the backplane is wired to the redundant external power supplies and miscellaneous chassis I/O connectors. The backplane electrically connects a GLM in the front to the power supplies, the GLM’s paired RTM in the rear, and other GLMs installed within the chassis.

While slots are available in the chassis and on the backplane to support modular power supplies mounted in the chassis, this LTR submission does not include those power supplies.

GLMs are plugged into three connectors in each backplane slot, as shown previously in Figure 3.1.3-4. The connectors provide the redundant +12 VDC power supply connections, electrical communication interconnections between the GLMs, and the write protection and miscellaneous chassis input/output connections. The connectors provide electrical interconnections between the RTM and the GLM for interconnecting field input/output/communication signals with GLM I/O mezzanine slots.

The backplane connects the redundant regulated DC power and ground planes to the 18 GLMs. The backplane and its connectors provide sufficient current carrying capacity to provide 20 watts of power to each GLM.

The backplane provides built-in communication paths to interface GLMs within a chassis. The backplane communication is discussed in Section 3.4.1.

The backplane provides for distribution of the non-volatile memory lock signal (write protect input) to all GLMs within the chassis. The write protect input inhibits any write to the safety critical non-volatile memory when write protect is active.


NuPAC_ED610000-047-P B 39 of 204 01/19/2012


The backplane provides each of the 18 GLM slots with a 5-bit binary module address, which each GLM uses to verify, via Core PLD logic that it is installed in the correct slot. These slot identifications are incorporated as copper connections on the upper connector of each backplane slot. Valid GLM addresses start at 1 and end at 18.

The backplane also provides a 7-bit binary chassis address, which each GLM uses to verify that it is installed in the correct chassis. The chassis address is configured via a connector located on the rear of the chassis (referring to Figure 3.2.3-1, rear view, the circular connector is located on the right side in the middle). All possible values are valid.

The cooperative development team worked with a vendor to modify the basic design of a commercial backplane for increased seismic rigidity by adding vertical stiffeners, and to provide the input/output, communications, and power connections required for the NuPAC platform. After this modification, a vendor will make this modified design for LMGI/SNPAS as a commercial item, and LMGI/SNPAS will perform the appropriate commercial grade dedication activities, in accordance with the Commercial Grade Dedication Plan (Reference 3-12), to accept the backplane.

Additional chassis design details are included in the Chassis/RTM Design Report (Reference 3-10).

3.2.4 Power Supplies

The NuPAC platform chassis design provides provisions for redundant +12 VDC power supply inputs; the mounting can be chassis external or chassis internal. Internal power supplies are not part of this LTR. In support of the NuPAC platform design, a candidate +12 VDC external power supply shall be selected to support NuPAC platform qualification testing.

For the NuPAC platform qualification, each chassis will be powered by two independent supplies. Each power supply providing a +12 VDC output that shall be capable of providing the full power requirements for the chassis. Under normal conditions, power may be drawn from one power supply. If that power supply or its supporting power source fails, the other power supply will support the full power requirements of the chassis. This power supply selection will support electromagnetic and surge withstand qualification testing; the LMGI/SNPAS intent is to provide an acceptable supply characterization for future NuPAC platform considerations.

As part of BIT, an ADC on each Carrier Card monitors the redundant input power, the auctioneered power, as well as onboard derived power supply voltages. In addition, fuse monitoring is provided for each redundant input power sources.


NuPAC_ED610000-047-P B 40 of 204 01/19/2012


3.3 Programmable Logic Architecture

The Logic Mezzanine consists of two FPGA processing elements—the Core Programmable Logic Device (PLD) and the Application Specific PLD (ASPLD). Each PLD hosts a programmable logic configuration item (PLCI). The PLCI consists of the Core PLCI and Application Specific PLCI (AS PLCI) that reside in the Core PLD and ASPLD, respectively. Figure 3.3-1 shows that major functions of each PLCI.

Figure 3.3-1. Programmable Logic Configuration Items

The Core PLCI is the board support package that provides an I/O interface to the ASPLD. It handles all serial communications, input sampling, output driving, and presents this data to the ASPLD interface in a consistent manner regardless of the plant-specific I/O configuration (installed I/O mezzanines). This allows the AS PLCI designer to concentrate on the plant-specific application instead of the infrastructure-like details such as parity, baud rate, routing, and BIT of I/O. The Core PLCI is sufficiently generalized such that it can be fully verified and validated independent of the AS PLCI. That effort will not need to be repeated because only the design for the AS PLCI is changed from GLM to GLM implementing plant-specific application functionality.

The AS PLCI is the logic that provides the plant-specific application functionality from GLM to GLM that implements plant-specific application requirements. The AS PLCI receives input measurements and backplane serial messages from the Core PLD, performs logical or mathematical computations based on those inputs and determines a course of action. The course of action is plant-specific and takes the form of commands sent to the Core PLD for an output to be altered, activated, deactivated, or transmitted, or for a serial backplane message to be forwarded to another GLM.


NuPAC_ED610000-047-P B 41 of 204 01/19/2012


3.3.1 Core Programmable Logic Configuration Item

The following subsections provide a high-level summary of the Core PLCI architecture. Figure 3.3.1-1 provides a basic block diagram of the Core PLCI. The architecture is presented in terms of functional modules within the Core PLD. Additional Core PLCI architecture details are included in the Core PLCI Development Specification (Reference 3-13).

Figure 3.3.1-1. Core PLCI Block Diagram

3.3.1.1 Core PLD Module

The Core PLD Module represents the programmable physical pins of the FPGA; the Core PLD Module instantiates the Core Logic Module and I/O Ring Module.

3.3.1.1.1 I/O Ring Module

The I/O Ring Module provides FPGA-specific functions including active high/low signal conversion, input signal synchronization, tri-state conversion, and data type conversion between the physical interface of the FPGA and the logical interface of the Core Logic Module.


NuPAC_ED610000-047-P B 42 of 204 01/19/2012


3.3.1.1.2 Core Logic Module

The Core Logic Module instantiates the following functional modules that perform the logic functions of the Core PLCI:

1) I/O Mezzanine Controller (eight instances) 2) ASPLD Interface Controller 3) Data Handler (two instances) 4) Backplane Interface Controller (eight instances) 5) Diagnostic/Maintenance (D/M) Controller 6) NVSRAM Controller.

3.3.1.1.2.1 I/O Mezzanine Controllers

The Core Logic Module instantiates eight I/O Mezzanine Controllers, one for each I/O mezzanine slot. Each I/O Mezzanine Controller manages the interface with any of following six types of I/O mezzanines:

1) Analog Input Mezzanine, P/N 610330 2) Discrete/Pulse Input Mezzanine, P/N 610340 3) Temperature Input Mezzanine, P/N 610350 4) RS-422/485 Mezzanine, P/N 610360 5) Analog Output Mezzanine, P/N 610370 6) SSR Mezzanine, P/N 610380.

Each I/O Mezzanine Controller is responsible for the following functions for the attached I/O mezzanine:

1) I/O mezzanine type verification. 2) I/O mezzanine configuration for its intended function. 3) Input signal processing, including (as required)

a. Calibration b. Digital filtering c. Compensation (e.g., thermocouple cold junction compensation) d. Linearization/conversion via table look-up e. Scaling f. Limit checking g. Conversion to discrete on/off value h. De-bouncing i. Serial to parallel data conversion.

4) Output signal processing, including (as required) a. Calibration b. Slew rate control c. Parallel to serial data conversion.

5) I/O mezzanine BIT functions. 6) Formatting input data and status messages for the ASPLD Interface Controller. 7) Parsing output data messages from the ASPLD Interface Controller.

Each function above is enabled and/or configured by parameters located in the external parameter memory.


NuPAC_ED610000-047-P B 43 of 204 01/19/2012


3.3.1.1.2.2 ASPLD Interface Controller

The Core Logic Module instantiates an ASPLD Interface Controller, which manages all communications between the Core PLD and the ASPLD via the ASPLD interface. The controller sends the following types of information to the ASPLD from the appropriate Core PLD sources:

1) Core PLD status 2) I/O mezzanine input data and status 3) Backplane communications interface messages (if addressed to the ASPLD) 4) D/M requests to the ASPLD 5) D/M responses to the ASPLD.

The ASPLD Interface Controller accepts the following types of information from the ASPLD, and directs the data to the appropriate Core PLD destination:

1) ASPLD status 2) I/O mezzanine output data 3) Backplane communications interface messages from ASPLD 4) D/M responses from the ASPLD 5) D/M requests from the ASPLD.

The ASPLD Interface Controller also performs BIT functions to verify the operation and data integrity of the interface.

3.3.1.1.2.3 Data Handlers

The Core Logic Module instantiates two Data Handlers, the Data Handlers are responsible for forwarding messages between Backplane Interface Controllers and the ASPLD Interface Controller.

One Core PLCI Data Handler controls message forwarding associated with the four Backplane Interface Controllers grouped in the Alpha Mesh/Star Network, while the other controls message forwarding associated with the four Backplane Interface Controllers group in the Bravo Mesh/Star Network.

Backplane communication is detailed in Section 3.4.1.

3.3.1.1.2.4 Backplane Interface Controllers

The Core Logic Module instantiates eight Backplane Interface Controllers, the Backplane Interface Controllers are responsible for managing full duplex transmission and reception of UART-type serial data on the backplane serial interfaces. The controllers also convert serial data to/from parallel format for the Data Handlers.

3.3.1.1.2.5 Diagnostic/Maintenance Controller

The Core Logic Module instantiates a D/M Controller, which provides overall control, status, and diagnostic functions for the Core PLD including the following:

1) Operational mode control 2) Initialization control 3) Non-volatile parameter memory control 4) Clock signal monitoring 5) System monitoring 6) Front panel (card-top) LED control 7) MICTOR diagnostic interface control 8) Diagnostic request handling.


NuPAC_ED610000-047-P B 44 of 204 01/19/2012


The D/M Controller accepts and responds to diagnostic/maintenance request messages from either the Communications and Test Interface Connector (CTIC) or the ASPLD for read/write access to configuration parameters and Core PLD status and control registers. The D/M Controller also brokers diagnostic/maintenance requests and responses for ASPLD resources between the CTIC and ASPLD interfaces.

3.3.1.1.2.6 Non-Volatile Static RAM (NVSRAM) Controller

The Core Logic Module instantiates an NVSRAM Controller, which manages Core PLD access to the NVSRAM memory. The controller performs error correction code (ECC) processing to detect and correct data errors on all NVSRAM accesses. The controller also performs periodic scrubbing operations to verify and maintain the integrity of data stored in NVSRAM.

3.3.2 Application Specific Programmable Logic Configuration Item

The following subsections provide a high-level summary of the AS PLCI architecture. Figure 3.3.2-1 provides a basic block diagram of the AS PLCI. The architecture is presented in terms of functional modules within the ASPLD.

Figure 3.3.2-1. AS PLCI Programmable Logic Block Diagram

3.3.2.1 ASPLD Module

The ASPLD Module represents the programmable physical pins of the FPGA. The ASPLD Module provides FPGA-specific functions including active high/low signal conversion and data type conversion between the physical interface of the FPGA and the logical interfaces of the lower-level modules. The ASPLD Module implements plant-specific application logic and instantiates the following functional modules that perform common logic interface functions of the AS PLCI:

1) ASPLD Interface Controller 2) Diagnostic/Maintenance (D/M) Controller 3) SRAM Controller.


NuPAC_ED610000-047-P B 45 of 204 01/19/2012


If developed as such, this common interface logic will be defined separately from plant-specific logic as a reusable common application logic interface configuration item. A future intent is to identify this architecture through the development of the Test Specimen Configuration (TSC) and future plant-specific application needs.

3.3.2.1.1 ASPLD Interface Controller

The AS Logic Module instantiates an ASPLD Interface Controller that manages all communications between the Core PLD and the ASPLD via the ASPLD interface. The controller sends the following types of information to the Core PLD from the appropriate ASPLD sources:

1) ASPLD status 2) I/O mezzanine output data 3) Backplane communications interface messages 4) D/M responses to the Core PLD 5) D/M requests to the Core PLD.

The ASPLD Interface Controller accepts the following types of information from the Core PLD, and directs the data to the appropriate ASPLD destination:

1) Core PLD status 2) I/O mezzanine input data and status 3) Backplane communications interface messages (if addressed to the ASPLD) 4) D/M responses from the Core PLD 5) D/M requests from the Core PLD.

The ASPLD Interface Controller also performs BIT functions to verify the operation and data integrity of the interface.

3.3.2.1.2 Diagnostic/Maintenance Controller

The AS Logic Module instantiates a D/M Controller, which provides overall control, status, and diagnostics functions for the ASPLD including:

1) Operational mode control 2) Initialization control 3) MICTOR diagnostic interface control 4) Diagnostic request handling.

The D/M Controller accepts and responds to diagnostic/maintenance request messages from the ASPLD Interface Controller, for read/write access to SRAM contents and ASPLD status and control registers. The D/M Controller also brokers diagnostic/maintenance requests and responses for ASPLD resources between Core PLD logic and ASPLD logic.

3.3.2.1.3 SRAM Controller

The AS Logic Module instantiates a SRAM Controller, which manages ASPLD access to the external SRAM. The controller provides error detection and correction on all SRAM data accesses, and periodically scrubs SRAM contents to detect and correct SRAM data errors. The SRAM data interface consists of 36 bits of parallel data per word. Consecutively addressed word pairs are cached within the SRAM Controller, providing 64 bits of data and 8 bits of error correction code (ECC) encoding.


NuPAC_ED610000-047-P B 46 of 204 01/19/2012


3.3.2.1.4 Plant-Specific Application Logic

The AS Logic Module implements the plant-specific application logic, which is responsible for the unique application specific processing in the ASPLD.

In general, the plant-specific application logic processes input data from backplane serial messages and/or I/O mezzanine inputs, and then provides outputs in the form of backplane serial messages and/or I/O mezzanine output commands. Examples of this processing include the following:

Gathering input data from multiple I/O mezzanines, validating each one via range-checking against plant-specific limits, analyzing the validated data, and formatting the results into a backplane serial message to another GLM in the same chassis

Accumulating messages from other GLMs within the same chassis, formatting an aggregate message and sending it to a RS-422/485 Mezzanine that is connected to a GLM in a different chassis

Receiving an aggregated message from another chassis via an RS-422/485 Mezzanine, separating it into individual messages, and sending them to other GLMs in the same chassis

Receiving a backplane serial message from another GLM in the same chassis, validating the source and content, and formatting the data into an output command to an I/O mezzanine.

Many possible plant-specific application logic designs can be developed to comply with IEEE Standard 603-1991 (Reference 3-14) and IEEE Standard 7-4.3.2-2003 (Reference 3-15).


NuPAC_ED610000-047-P B 47 of 204 01/19/2012


3.4 Data Communication

This section provides a general description of the NuPAC platform data communication capabilities and how they are applied to realize intra-divisional and inter-divisional digital communications within a safety I&C system and how they accomplish unidirectional digital communication between the safety I&C system and non-safety systems. Aspects of electrical isolation, functional isolation, separation, and independence, especially including data independence are addressed.

3.4.1 Data Communication Capabilities

3.4.1.1 Overview

All data communication implemented in the NuPAC platform uses point-to-point serial data links. The following two methods of communication are offered:

1) Low-voltage differential signaling (LVDS) serial communication across the chassis backplane 2) RS-422/485 serial communication via I/O mezzanines.

The LVDS serial communication via the chassis backplane is utilized for intra-chassis GLM-to-GLM communication. In addition, RS-422/485 Mezzanines can also be added to any GLM, providing RS-422/485 capability to link any GLM to any other GLM or to external system via external cabling.

Data communication is implemented in the plant-specific application logic. All communications will be designed as broadcast messages, with no requirements for handshaking or acknowledgement. The messages will be of predefined content and fixed size. The processing of messages will result in data being provided to the plant-specific application logic in specific predefined locations (e.g., registers within the programmable logic). The plant-specific application logic will be designed to expect to receive data from applicable sources at a pre-determined interval, and will flag failures to receive valid messages as errors.

The following subsections provide a summary of the LVDS backplane serial data communication and the RS-422/485 Mezzanine serial communication.

3.4.1.2 LVDS Backplane Serial Data Communication

The GLMs are designed so that each can operate independently. There is predefined communication through the backplane to other GLMs, as necessary, to implement plant-specific functions. LVDS serial communication via the chassis backplane is utilized for intra-chassis GLM-to-GLM communication. Copper traces embedded in the backplane are used as the GLM-to-GLM communication paths. The backplane is discussed previously in Section 3.2.3.1. The predefined communication paths in the backplane do not support connections to external systems.

The LVDS backplane message processing and message protocol are implemented in the plant-specific application logic in accordance with a predefined message structure, including a maximum data length. The LVDS backplane message structure is discussed in Section 3.4.1.2.1. Messages will always be created with fixed content and fixed lengths. These messages are passed to/from the Core PLD, which routes the data to/from applicable destinations and sources.

On each GLM standard UART data links to/from the Core PLD on the Logic Mezzanine are passed to the Carrier Card through the board-to-board connectors. Onboard the Carrier Card, UART signals are converted to/from LVDS. Onboard the Carrier Card, eight transceivers provide eight transmit ports. Likewise, eight receivers provide eight receive ports. The GLM-to-GLM LVDS serial data link interface is via the backplane.

The backplane provides built-in predefined communication paths, via copper traces, to interface GLMs within a chassis. Dual mesh/star LVDS point-to-point serial data communication paths are provided, as shown in


NuPAC_ED610000-047-P B 48 of 204 01/19/2012


Figure 3.4.1.2-1. Regarding Figure 3.4.1.2-1, the dual-nature is shown by parsing the paths into two topologies designated as alpha and bravo. The boxes labeled A1-A18 represent GLMs installed in respective chassis/backplane slots. The numbers within the boxes represent the LVDS transmitter/receiver pairs. The lines between the boxes represent the backplane communication paths (copper traces) for full duplex LVDS serial data links. The color-coding is provided to facilitate the recognition of the logical grouping of GLMs, which is further explained in Section 3.4.1.2.2.

Figure 3.4.1.2-1. Dual Mesh/Star LVDS Point-to-Point Serial Data Communication Paths

A physically separate communication processor is not required for the LVDS backplane communications, since logically separate communication processing is supplied for each of the eight transmit and receive ports. In addition, electrical isolation is not provided or required since there are no field connections.

Data throughput for these LVDS links will be calculated, verified, and validated during design, development, review, and test activities. Estimates of data throughput can be performed based on evaluation of the data items to be passed, communication protocol used, and processing times of both the sending and the receiving systems.

The propagation and processing delays associated with communication are part of the overall delay through a NuPAC-based system. The methods for calculating delay from input to output are provided in Section 6.3.3. Means are provided to calculate the maximum data delay associated with each GLM, which can then be totaled into the data delay through the system. Since the data delay is directly proportional to the amount of data sent, and since the baud rate for each message path is predefined as part of the plant-specific application design, each


NuPAC_ED610000-047-P B 49 of 204 01/19/2012


application for an individual system design will require calculation of the maximum delay due to data transmission. This analysis will be part of the system’s total delay analysis, which will include assumptions concerning additional delays associated with faults and failures in communicated messages.

Redundant message processing can be implemented in safety-critical applications to ensure that the single failure of an LVDS backplane serial link does not result in the failure of the safety function. The guidance of DI&C-ISG-04 (Reference 3-16) and IEC 61784-3 (Reference 3-17) shall be considered in the implementation of both plant-specific application message processing logic and the logic associated with messaging faults and failures.

3.4.1.2.1 LVDS Backplane Message Structure

A defined message structure is provided for the LVDS backplane communication. This message structure consists of several message fields of defined length and a message content that must contain at least 1 byte.

Table 3.4.1.2.1-1. LVDS Backplane Message Structure Start of Message

Code 1 fixed format byte A fixed-field containing the value 0x8F hex, indicating the start of a

message. Message Length 2 bytes Provides a count of all bytes in the message following the message

length bytes (i.e., excluding a start of message code and message length). Each byte is encoded as 5 bits of data and 4 bits of error correcting code (ECC). The first byte transferred is the least significant five bits, with the second byte as the most significant 5 bits.

Destination Port Identifiers

1 byte per destination port Provides a list of 1 or more bytes, each of which contains the destination LVDS port on the GLM from which the message is to be sent, or the ASPLD interface on the current GLM.

Embedded Message Content

1 or more bytes of data Contains the data payload. The data (message) format is created and consumed by the appropriate plant-specific ASPLD logic. The maximum length of the message is 256 bytes, which restricts the message by the start of message code, message length, variable routing bytes (destination port identifiers and source port identifiers), and the end of message code.

End of Message Code

1 fixed format byte A fixed field containing the value 0xEC hex, marking the end of a message.

Source Port Identifiers

1 byte per source port Initially, has no content. As each message is passed from a GLM, the destination port used on that GLM is removed from the destination port identifiers list and the source port on which the message arrived is added to the end of the source port identifiers list. Thus, when the message reaches the end of the destination port Identifiers list and is processed, there is a list of ports, which can be used to generate a list of destination ports to return a message.

3.4.1.2.2 Implementation of LVDS Backplane Serial Data Communication

With respect to plant-specific applications, if more capabilities are required than what can be implemented with the eight inputs and/or outputs of a single GLM, additional GLMs can be applied. LMGI/SNPAS concludes that any normal Engineered Safety Features Actuation System (ESFAS) subsystem can be implemented with 32 inputs and/or outputs, which leads to the requirement for four GLMs to have extensive intercommunication capabilities.


NuPAC_ED610000-047-P B 50 of 204 01/19/2012


As shown in Figure 3.4.1.2-1, the backplane provides four groups of four adjacent GLMs with very tight coupling within each group, allowing each of the four GLMs within a group to work cooperatively and tightly, with minimal message routing. Within this group of four GLMs, capabilities exist for 32 inputs and/or outputs. The backplane groups GLMs into four groups of four GLMs in slots A1 through A16, which are intended for use as inputs, control logic, and outputs. Slots A17 and A18 are designated as communications aggregators for the information input, computed, and output by the GLMs in slots A1 through A16. However, inputs, outputs, and communications capabilities are supported in any mix on all GLMs in any of the 18 slots.

To support this grouping of GLMs, the backplane provides eight predefined communication paths between each GLM and the other GLMs in the chassis, as shown in Figure 3.4.1.2-1, on predefined copper interconnects designed into the backplane. Each path uses LVDS. Each communication path provides separate high-speed transmit and receive paths. The transmitter is monitored and checked by looping the transmitted signal back to a receiver and validating the data being transmitted.

The scheme supports larger groupings of GLMs, to provide capabilities beyond what can be implemented within the group of four GLMs. The left-hand two groups of four GLMs (GLMs A1 through A8) or the right-hand two groups of four GLMs (GLMs A9 through A16) can be grouped into a larger pair of groups of eight GLMs. As shown in Figure 3.4.1.2-1, four communication paths are provided between each of the groups of four. For the left-hand group, redundant communication is provided between GLMs A3 and A7 as well as between GLMs A4 and A8. For the right-hand group, redundant communication is provided between GLMs A11 and A15 as well as between GLMs A12 and A16.

In addition, provisions exist for direct linkage of the left-hand group of eight GLMs (GLMs A1 through A8) to the right-hand group of eight GLMs (GLMs A9 through A16). Communication is provided between GLMs A3 and A15 as well as between GLMs A4 and A16. Likewise, communication is provided between GLMs A7 and A11, as well as between GLMs A8 and A12.

3.4.1.2.3 Message Routing of LVDS Backplane Serial Data Communication

The Core PLD provides message-forwarding capabilities. Two Data Handlers (functional logic modules) embedded in the Core PLD logic are responsible for forwarding LVDS backplane messages between adjacent LVDS transmit/receive ports and the ASPLD. One Data Handler controls message forwarding associated with the four LVDS transmitter/receiver pairs grouped in the alpha topology (ports 1-4, as shown previously in Figure 3.4.1.2-1), while the other controls message forwarding associated with the four LVDS transmitter/receiver ports group in the bravo topology (ports 5-8).

To forward a message (packet), the Data Handlers perform the following operations on valid messages:

Read the first 4 bytes of the packet (Start of Message Code, Message Length, and the first Destination Port Identifier)

Write the Start of Message Code to the transmit buffer identified by the first Destination Port Identifier Copy the Message Length to the transmit buffer Copy the remainder of the message (except the first Destination Port Identifier) to the transmit buffer Write a Source Port Identifier indicating which port the Data Handler received the message from, to the

transmit buffer.


NuPAC_ED610000-047-P B 51 of 204 01/19/2012


An example is shown in Figure 3.4.1.2.3-1.

Figure 3.4.1.2.3-1. Message Routing Example


NuPAC_ED610000-047-P B 52 of 204 01/19/2012


3.4.1.3 RS-422/485 Mezzanine Serial Data Communication

RS-422/485 Mezzanines can be added to any GLM, providing the capability to link any GLM to any other GLM or external system via external RS-422/485 serial data links. Discrete shielded, twisted pair copper cabling connected at the respective RTMs is used to implement the external communication paths. The RS-422/485 Mezzanine is discussed in Section 3.2.1.2 above.

Figure 3.4.1.3-1. RS-422/485 Mezzanine Serial Data Communication

The messages associated with RS-422/485 Mezzanines, including communications between two NuPAC–based systems and external systems, are not routed and do not have to use the message format and protections documented in the previous section.

The RS-422/485 Mezzanine messages require additional plant-specific application logic to implement the message and message protocol. Messages will always be created with fixed content and thus fixed lengths. Since the messages do not have the data length limitations that routed messages do, more data can be placed inside these messages than into a routed message. Each message still has fixed/defined message content. However, if the message lengths are excessive, then multiple messages will be sent, each with fixed/defined message content.

A physically separate communication processor is not required for the RS-422/485 communication, since logically separate communication processing is supplied for each of the eight possible RS-422/485 Mezzanines installed on a GLM. However, it may be desirable to implement this communication processing using an aggregator scheme within a chassis.

For this LTR, the individual systems within a larger plant system like the ESFAS are not considered as separated systems, but as subsystems within a larger system.


NuPAC_ED610000-047-P B 53 of 204 01/19/2012



NuPAC_ED610000-047-P B 54 of 204 01/19/2012


Examples of external systems or devices include:

Bi- or unidirectional communication between safety systems, such as a neutron monitoring system sending data to a reactor trip system

Bi- or unidirectional communications between a safety system and safety-related displays in the control room

Unidirectional communications from a safety system to a non-safety system, such as a reactor trip system sending data to a plant computing system for data display, alarming, cross-channel comparisons and alarming.

Messages on these point-to-point links to/from external systems will be formatted as required by the communications interface with the external system. The communication protocol will be defined based on the needs of the communication link between the NuPAC-based system and the external system.

In order to keep the plant-specific application logic as simple as possible, predefined message formats will be used, with fixed data content. NuPAC platform GLMs will be configured as communication processors for communication with an external system. This method would be used to send data one-way to an external non-safety system through a RS-422/485 Mezzanine.

The electrical isolation provided on a RS-422/485 Mezzanine provides safety to non-safety isolation. The GLMs that serve as communication processors provide functional and data isolation. Data isolation will be provided by administrative restrictions within the NuPAC Platform Application Guide (see Appendix A).

Data throughput for these RS-422/485 Mezzanine links will be calculated, verified, and validated during design, development, review, and test activities. Estimates of data throughput can be performed based on evaluation of the data items to be passed, communication protocol used, and processing times of both the sending and the receiving systems.

The propagation and processing delays associated with communication are part of the overall delay through a NuPAC-based system. The methods for calculating delay from input to output are provided in Section 6.3.3. Means are provided to calculate the maximum data delay associated with each GLM, which can then be totaled into the data delay through the system. Since the data delay is directly proportional to the amount of data sent and the baud rate for each message path is predefined as part of the plant-specific application design, each application for an individual system design will require calculation of the maximum delay due to data transmission. This analysis will be part of the system’s total delay analysis, which will include assumptions concerning additional delays associated with faults and failures in communicated messages.


NuPAC_ED610000-047-P B 55 of 204 01/19/2012


3.4.2 Application to Nuclear Power Plant Instrumentation and Control

Digital I&C systems must be robust against propagation of errors between individual channels and other channels or divisions. This section provides the data communication methodology of NuPAC-based systems, which limits a failed channel adversely impacting other channels or divisions. Systems designed with the NuPAC platform shall conform to the requirements and expectations in IEEE Standard 603-1991 (Reference 3-14), IEEE Standard 7-4.3.2-2003 (Reference 3-15), and DI&C-ISG-04 (Reference 3-16).

As discussed in this LTR, channels compare the readings from plant process sensors associated with that channel only—including temperature, pressure, and flow—against preset setpoint values. Channels also generate a logical decision for each sensor or set of sensors to determine if action is required. The logical decisions from all channels are combined in each division to verify if enough of the channels have voted to perform the protective action to actuate the equipment associated with that action. Some nuclear power plant (NPP) designs separate the voting equipment from the actuation equipment, with the voting occurring in divisions and the actuation occurring in trains. A division is based on separation by the safety-related source of electrical power. Trains are normally separated based on the safety-related mechanical equipment. For most NPPs, mechanical trains and electrical divisions provide common equipment boundaries, where one electrical division provides power only to one mechanical train.

For example, most power reactors measure pressure within the reactor vessel and stop the fission reaction if pressure is excessive. For a modern plant design, four independent sets of pressure transmitters are compared to four sets of setpoint values in four independent decisions to request a reactor trip based on the individual value read from the transmitter associated with the logic making the decision. All four of these decisions are provided to multiple divisions of voters. If two or more out of the four possible logical decisions are to trip the plant, possibly with the outputs of the individual divisions also processed through voters, the divisions actuate the scram system and insert the control rods back into the core.

3.4.2.1 Intra-divisional Data Communication: NuPAC-to-NuPAC

This section addresses communication among NuPAC-based safety-related equipment/systems within a single division. Intra-divisional communication includes communication within a single channel and between a single channel and its division. Section 3.4.2.2 addresses the intra-divisional communication between NuPAC-based safety-related equipment/systems and other non-NuPAC-based safety-related equipment, such as neutron monitoring systems. This section does not apply to communication across electrical division boundaries or communication to non-safety systems.

The NuPAC platform architecture is centered on the configurable GLM. GLMs provide the capability to accomplish input/output (I/O) processing, control logic, diagnostics, and data communication. The safety system functionality is decomposed to the divisional and channel-levels, and then systematically allocated to GLMs. The safety system is realized via the configuration of the GLM I/O mezzanines and the ASPLD designs. Channel functions and division functions should not be combined on the same GLM.

For Section 3.4.2.1 of this LTR, all GLMs are assumed to be within the same division. If capabilities require more than what can be implemented with eight inputs and/or outputs, additional GLMs can be applied within the same chassis. Up to 18 GLMs may be installed within a single chassis. If capabilities require more than what can be implemented within a single chassis of GLMs, additional chassis of GLMs can be applied. This expansion would be required to distribute inputs, logic processing, and outputs physically within a plant, or for those functions that are very complex, and require more inputs, outputs, or plant-specific application logic than can be implemented in 18 GLMs.


NuPAC_ED610000-047-P B 56 of 204 01/19/2012


NuPAC-based safety systems can be designed to interface multiple GLMs within the same division via serial communication links. The point-to-point LVDS serial communication via the chassis backplane is the preferred method for intra-chassis GLM-to-GLM communication. The addition of RS-422/485 mezzanines provides serial communication capability to link a GLM in one chassis to a GLM in another chassis via external cabling.

3.4.2.1.1 Intra-chassis Data Communication

NuPAC-based safety systems can be designed to aggregate channel-level and divisional-level data within a GLM and provide that data to the other GLMs within the same chassis. This intra-divisional communication supports the implementation of safety functions at the channel-level and divisional-level. To ensure that data independence is maintained, channels shall not receive any communication from another channel that is not necessary for supporting or enhancing the performance of the safety function, which may include communication of bypass information. Furthermore, the safety system shall be designed to be failsafe. As such, the correct operation of the intra-divisional communication is only necessary to prevent a spurious trip.

All intra-chassis communications between GLMs should be constructed with the point-to-point LVDS serial communication via the chassis backplane. Please note, intra-chassis backplane serial data communication is the topic of Section 3.4.1.2. To enhance reliability, redundant intra-chassis communication paths could be implemented with two separate routed messages utilizing alternate backplane communication paths.

3.4.2.1.2 Inter-chassis Data Communication

NuPAC-based safety systems can be designed to aggregate channel and divisional level data within a chassis and provide that data to other chassis within the same division. This intra-divisional communication, shown in Figure 3.4.2.2-1, supports the implementation of safety functions at the channel and divisional-level. To ensure that data independence is maintained, channels shall not receive any communication from another channel that is not necessary for supporting or enhancing the performance of the safety function, which may include communication of bypass information. Furthermore, the safety system shall be designed to be failsafe. As such, the correct operation of the intra-divisional communication is only necessary to prevent a spurious trip.

This functionality will be allocated to devoted GLMs, which will only be used to implement inter-chassis communication. These GLMs will perform no other safety functions, and will buffer other GLMs performing other safety functions (e.g., other channels) from communication errors.

All inter-chassis communications shall be constructed with RS-422/485 mezzanines. The RS-422/485 mezzanine’s transmitter port in the originating chassis will be wired to the RS-422/485 mezzanine’s receiver port in receiving chassis. In this configuration, the safety-related application logic in the originating chassis shall prepare the communication to transmit, while the safety-related application logic in the receiving chassis shall process the communication received. Communication protocols will be implemented, as required, in the ASPLDs.

For this approach, the inter-chassis communication will be performed by GLMs that are not performing any other safety functions, which simplifies the evaluation of failure mechanisms and consequences. Since failure of the GLMs performing the inter-chassis communication would be localized to those GLMs, there can be no adverse effects on the other safety functions being performed in the remainder of the safety-related system. The GLMs serving as the inter-chassis communication interface provide functional and data isolation. Although not required, electrical isolation provided on the RS-422/48 mezzanines provides safety to non-safety electrical isolation. To enhance reliability, redundant inter-chassis communication paths could be provided with two separate GLMs and, thus, two separate communication paths. In addition, to extend the range (distance) of serial data links, including between chassis, external media converters may be incorporated to convert the RS-422/485 to fiber optic communication paths (not included in this topical report).


NuPAC_ED610000-047-P B 57 of 204 01/19/2012


3.4.2.2 Intra-divisional Data Communication: NuPAC-to-Other Safety Systems

This section addresses the intra-divisional communication between NuPAC-based safety-related equipment/systems and other non-NuPAC-based safety-related equipment within the same division. Examples include neutron monitoring systems or safety-related video display systems. This discussion does not cover communication across electrical division boundaries or communication to non-safety systems.

NuPAC-based safety systems can be designed to interface with other non-NuPAC-based safety systems within the same division via serial communication links. This intra-divisional communication, shown in Figure 3.4.2.2-1, supports implementation of safety functions at the channel-level and divisional-level. To ensure data independence is maintained, channels shall not receive any communication from another channel that is not necessary for supporting or enhancing performance of the safety function, which may include communication of bypass information. Furthermore, the safety system shall be designed to be failsafe. As such, the correct operation of the intra-divisional communication is only necessary to prevent a spurious trip. This functionality increases the complexity of both the sending and receiving portions of the safety system. However, LMGI/SNPAS concluded use of common data, rather than re-sampling data in each portion of the system, increases the reliability and availability of the overall safety system, even though the safety system is more complex.

Figure 3.4.2.2-1. Intra-divisional Communication

This intra-divisional communication functionality will be allocated to devoted GLMs, which will only be used to implement intra-divisional communications between NuPAC-based safety systems and non-NuPAC-based safety systems. These GLMs will perform no other safety functions, and will buffer other GLMs performing other safety functions (e.g., other channels) from communication errors.

All intra-divisional communications between NuPAC-based safety systems and non-NuPAC-based safety systems shall be constructed with RS-422/485 mezzanines. To receive data, the RS-422/485 mezzanine’s RS-receiver port will be wired to a transmitter in the non-NuPAC-based safety system. In this configuration, the safety-related application-specific logic in the NuPAC-based system shall process the communication received. The safety-related application-specific logic in the NuPAC-based system shall include appropriate protections to


NuPAC_ED610000-047-P B 58 of 204 01/19/2012


ensure the safety system is protected from faults and failures in the non-NuPAC-based safety system. To transmit data, the RS-422/485 mezzanine’s transmitter port will be wired to a receiver in the non-NuPAC-based safety system. In this configuration, the safety-related application-specific logic in the NuPAC-based system shall prepare the communication to transmit. Communication protocols will be implemented, as required, in the Application Specific PLD (ASPLD).

For this approach, the communications will be performed by GLMs that are not performing any other safety functions, which simplifies evaluation of failure mechanisms and consequences. Since failure of the GLMs performing the intra-divisional communication would be localized to those GLMs, there can be no adverse effects on the other safety functions being performed in the remainder of the safety-related system. The GLMs serving as the intra-divisional communication interface provide functional and data isolation. Although not required, electrical isolation provided on the RS-422/485 mezzanines provides safety to non-safety electrical isolation. To enhance reliability, redundant intra-divisional communication paths could be provided with two separate GLMs and, thus, two separate communication paths.

3.4.2.3 Inter-divisional Data Communication

This section addresses communication from NuPAC-based safety-related equipment/systems in one division to NuPAC-based safety-related equipment/systems in another division. NuPAC inter-divisional communication is shown in Figure 3.4.2.3-1.

NuPAC-based safety systems can be designed to aggregate channel trip status within a division and provide that data to the other divisions. This inter-divisional communication supports implementation of two-out-of-four voting of the individual channel trips. No division shall depend on correct operation of another division or on inter-divisional communication, except as required to implement two-out-of-four voting of the individual channel trips. To ensure data independence is maintained, divisions shall not receive any communication from another division that is not necessary for supporting or enhancing the performance of the safety function, which may include communication of trip conditions, trip condition status, and bypass status information. Furthermore, the safety system shall be designed to be failsafe. As such, correct operation of inter-divisional communication is only necessary to prevent a spurious trip. While this functionality increases the complexity of both the sending and receiving portions of the safety system, LMGI/SNPAS concludes the use of common data, rather than re-sampling the data in each portion of the system, increases the reliability and availability of the overall safety system, even though the safety system is more complex.

This inter-divisional communication functionality will be allocated to devoted GLMs, which will only be used to implement inter-divisional communication. These GLMs will perform no other safety functions and will buffer other GLMs performing other safety functions from communication errors.


NuPAC_ED610000-047-P B 59 of 204 01/19/2012


Figure 3.4.2.3-1. Inter-divisional Communication

All inter-divisional communications between NuPAC-based safety systems shall be constructed with RS-422/485 mezzanines. The RS-422/485 mezzanines’ transmitter ports in the originating division will be wired to a RS-422/485 mezzanine’s receiver port in each of the other divisions. Furthermore, the safety-related application-specific logic in the transmitting division will ignore any communication received on the transmitting RS-422/485 mezzanines.

For this approach, the communications will be performed by GLMs that are not performing any other safety functions, simplifying the evaluation of failure mechanisms and consequences. Since failure of the GLMs performing inter-divisional communication would be localized to those GLMs, there can be no adverse effects on the other safety functions being performed in the remainder of the safety-related system. The GLMs that serve as


NuPAC_ED610000-047-P B 60 of 204 01/19/2012


the unidirectional inter-divisional communication interface provide functional and data isolation. Electrical isolation provided on the RS-422/485 mezzanines provides safety to non-safety electrical isolation. Furthermore, to facilitate separation, external media converters may be incorporated to convert the RS-422/485 to fiber optic communication paths (not a topic of this LTR). The separation distance between a division’s and redundant divisions’ circuits and cables shall be in accordance with IEEE Standard 384-1992 (Reference 3-18), with fiber optic cable separation in accordance with IEEE Standard 384-2008 (Reference 3-19). To enhance reliability, redundant inter-divisional communication paths could be provided with two separate GLMs and thus two separate unidirectional communication paths.

Requirements shall be imposed on the receiving end to verify the data being used meets the requirements of DI&C-ISG-04 (Reference 3-16), especially with regard to liveness and other critical aspects of ensuring the data transferred is correct. Communication protocols will be implemented, as required, in the ASPLD.

3.4.2.4 Non-safety System Data Communication

This section addresses communication from NuPAC-based safety-related equipment/systems to non-safety equipment/systems (Figure 3.4.2.4-1).

NuPAC-based safety systems can be designed to aggregate channel and divisional engineering unit data, logical data, and status and provide that data to external non-safety systems. LMGI/SNPAS concludes this functionality, increases the reliability and availability of the overall safety system, even though the safety system is more complex.

This safety to non-safety communication functionality will be allocated to devoted GLMs, which will only be used to implement communication to non-safety systems. These GLMs will perform no safety functions and will buffer other GLMs performing safety functions from communication errors.

All communications between NuPAC-based safety systems and non-safety systems shall be constructed with RS-422/485 mezzanines. The RS-422/485 mezzanine’s transmitter port will be wired to a receiver in the non-safety system, with no wiring back from a transmitter in the non-safety system to a receiver in the NuPAC-based safety system. Furthermore, the safety-related application-specific logic in the NuPAC-based system will ignore any communication received on the RS-422/485 mezzanine’s ports. For the purpose of interfacing with component priority modules, reception of non-safety system data may be considered as part of the plant architecture.

For this approach, the communications will be performed by GLMs that are not performing any safety functions, simplifying the evaluation of failure mechanisms and consequences. Since failure of the GLMs performing the safety to non-safety communication would be localized to those GLMs, there can be no adverse effects on the other safety functions being performed in the remainder of the safety-related system. The GLMs acting as the safety-to-non-safety communication interface provide functional and data isolation. Electrical isolation provided on the RS-422/485 mezzanines provides safety-to-non-safety electrical isolation. Furthermore, to facilitate separation, external media converters may be incorporated to convert the RS-422/485 to fiber optic communication paths (not a topic of this LTR). The separation distance between a division’s and redundant divisions’ circuits and cables shall be in accordance with IEEE Standard 384-1992 (Reference 3-18), with fiber optic cable separation in accordance with IEEE Standard 384-2008 (Reference 3-19). To enhance reliability, redundant communication paths to the non-safety system could be provided with two separate GLMs and thus two separate communication paths.


NuPAC_ED610000-047-P B 61 of 204 01/19/2012


Figure 3.4.2.4-1. Non-safety System Data Communication


NuPAC_ED610000-047-P B 62 of 204 01/19/2012


3.5 References

3-1 NuPAC Document No. NuPAC_SYS610000-001, Rev. A, “NuPAC System Description,” LMGI/SNPAS

3-2 NuPAC Document No. NuPAC_TR610000-100, Rev. -, “NuPAC Product Integration Verification and Validation (PiV&V) Summary Report,” LMGI/SNPAS



3-5 IEEE Standard 1101.1, “IEEE Standard for Mechanical Core Specifications for Microcomputers Using IEC 60603-2 Connectors,” Institute of Electrical and Electronics Engineers

3-6 NuPAC Document No. NuPAC_ED610300-011, Rev. -, “NuPAC Generic Logic Module (GLM) DAR,” LMGI/SNPAS

3-7 ANSI/VITA 4-1995, “American National Standards for IP Modules,” American National Standards Institute/VMEbus International Trade Association

3-8 ANSI/VITA 57.1-2008, “American National Standard for FPGA Mezzanine Card (FMC) Standard,” American National Standards Institute/VMEbus International Trade Association

3-9 IPC-2221A, “Generic Standard on Printed Board Design,” IPC, May 2003

3-10 NuPAC Document No. NuPAC_ED610100-003, Rev. -, “Chassis/Rear Transition Module (RTM) Design Report,” LMGI/SNPAS

3-11 IEC 60297-3-100, Edition 1.0, “Mechanical structures for electronic equipment – Dimensions of mechanical structures of the 482,6 mm (19 in) series – Part 3-100: Basic dimensions of front panels, subracks, chassis, racks and cabinets,” International Electrotechnical Commission, November 2008

3-12 NuPAC Document No. NuPAC_CGDP610000-001, Rev. A, “NuPAC Commercial-Grade Item/Service Dedication Plan,” LMGI/SNPAS

3-13 NuPAC Document No. NuPAC_PLDS610400-001, Rev. -, “NuPAC Programmable Logic Development Specification – Core PLCI,” LMGI/SNPAS



NuPAC_ED610000-047-P B 63 of 204 01/19/2012



3-16 DI&C-ISG-04, Rev. 1, “Highly-Integrated Control Rooms – Digital Communication Issues,” US Nuclear Regulatory Commission, March 2009

3-17 IEC 61784-3, Edition 2.0, “Industrial communication networks – Profiles – Part 3: Functional safety fieldbuses – General rules and profile definitions,” International Electrotechnical Commission, June 2010

3-18 IEEE Standard 384-1992, “IEEE Standard Criteria for Independence of Class 1E Equipment and Circuits,” Institute of Electrical and Electronics Engineers

3-19 IEEE Standard 384-2008, “IEEE Standard Criteria for Independence of Class 1E Equipment and Circuits,” Institute of Electrical and Electronics Engineers


NuPAC_ED610000-047-P B 64 of 204 01/19/2012


4.0 DEVELOPMENT PROCESS FOR THE NuPAC PLATFORM

4.1 Overview

The development process for the NuPAC program consists of three elements. The first is the technical and support process (TSP), shown in Figure 4.1-1. It defines what needs to be accomplished, both technically and programmatically, to ensure the NuPAC platform and future NuPAC-based applications meet specific operational, safety, quality, and performance requirements as finished solutions within their intended operational environments. (See Section 4.2 for a complete discussion.) The second element is a set of work product outputs from the TSP that define specifically how the process will be implemented for a specific program (i.e., project or application). (See Section 4.3 for details of these work products.) The third element is the organization that will execute or perform the work to accomplish what is described in the TSP and work product outputs. (See Section 4.4 for a complete discussion.)

Hereafter, references to the development of the NuPAC platform and future NuPAC-based applications are referred to commonly as the NuPAC program.

Figure 4.1-1. Technical and Support Processes (TSP)


NuPAC_ED610000-047-P B 65 of 204 01/19/2012


4.2 Process Description

The TSP consists of four groups of processes—program execution processes, technical processes, support processes, and Independent Verification and Validation (I-V&V) processes. Program execution processes establish the infrastructure and systematic approach for the NuPAC program. In Figure 4.1-1, these processes are contained in the Program Planning, Monitoring, and Control (PPMC) box. Technical processes establish the development methodology for the development life cycle of the NuPAC program. Support processes establish technical management support and product assurance throughout the development life cycle of the NuPAC program. Finally, I-V&V processes establish verification and validation methods, activities, and governance for the NuPAC program by the Assurance organization, which is both technically and managerially independent from the Development organization.

4.2.1 Program Execution Processes

Program execution processes (Figure 4.2.1-1) establish the infrastructure and systematic approach for the control of the NuPAC program; these processes are contained in the “Program Planning, Monitoring and Control” aspect of the TSP.

Figure 4.2.1-1. TSP Program Execution Processes

4.2.1.1 Program Planning, Monitoring, and Control (PPMC)

PPMC defines how the NuPAC program is estimated and planned, how the NuPAC program is tracked against its plans, and how corrective actions are taken to resolve differences between planned and actual performance. The planning documentation ties together the three other process groups (technical processes, support processes, and I-V&V processes), including their time phasing. Reviews defined during PPMC are the program startup review and various program reviews. Reviews are conducted prior to the release of each work product.

PPMC includes three sub-processes spanning the life cycle of the program; these processes (as described below) are program preparation, program startup, and program execution.

4.2.1.1.1 Program Preparation

The program preparation sub-process addresses the preparation associated with the start of the NuPAC program. It requires preparation of many of the program and technical work plans.

Using a scope of work and accompanying work breakdown structure, the following set of initial program work products can be generated:

Program Repository Index (PRI) Program Management Plan (PMP) Integrated Master Plan (IMP) Integrated Master Schedule (IMS) Systems Engineering Management Plan (SEMP).


NuPAC_ED610000-047-P B 66 of 204 01/19/2012


4.2.1.1.2 Program Startup

This sub-process addresses activities that occur immediately following initial program preparation and focuses on establishing a resourced program organization and adjusting program requirements (as needed). During this process, much of the initial planning is matured and refined.

By using the outputs from the program preparation as inputs to this process, a set of program plans as work products can be generated. They include:

Assurance Plan (AP) Commercial Grade Dedication Plan (CGDP) Configuration Management Plan (CMP) Failure Reporting, Analysis and Corrective Action System (FRACAS) Plan Hardware Development Plan (HDP) Integrated Logistics Support Plan (SP) Master Test Plan (MTP) Product Integration, Verification, and Validation Plan (PiV&V) Programmable Logic Planning Documentation (see Section 4.3.21) Quality Assurance Plan (QAP) Reliability Program Plan (RPP) Risk and Opportunity Management Plan (ROMP) Subcontract Management Plan (SMP) System Safety Plan (SSPP) System Security Plan (SSP) Test Equipment Development Plan (TEDP) Test Equipment Software Development Plan (TESDP).

4.2.1.1.3 Program Execution

The program execution sub-process addresses the technical, cost, and schedule program activities associated with execution of the program. Its focus is on monitoring and controlling (making adjustments) to achieve the program’s objectives. Program plans are executed and adjusted as necessary during this phase.

The inputs to this process are the IMS and program plans. Work products include:

Technical review records Action items (recorded in an action item database).


NuPAC_ED610000-047-P B 67 of 204 01/19/2012


4.2.2 Technical Processes

The development life cycle for the NuPAC program is illustrated under the technical processes of the TSP in Figure 4.1-1. For clarity, it is shown in Figure 4.2.2-1.

Figure 4.2.2-1. TSP Technical Processes

The technical processes consist of five sub-processes —mission analysis, system requirements analysis, system design, configuration item (CI) development, and PiV&V. The detail description for each sub-process is described below.

4.2.2.1 Mission Analysis

The purpose of the mission analysis process is determining needs of the user and customer, understanding how the product will be used, and evaluating system effectiveness.

The following tasks are performed by the NuPAC program Integrated Product Team (IPT):

The IPT will identify and analyze regulatory requirements/constraints, industry specifications and requirements applicable to the NuPAC program, including but not limited to system-level performance parameters.

The IPT will develop an operational concept document (OCD) that describes the mission of the system, its operational and support environments, and the functions and characteristics of the system within an overall operational environment.

The IPT will perform trade studies and develop analysis reports to evaluate potential solutions, such as input and output (I/O) offerings, communication alternatives, and programmable logic devices, including available technologies and sizing.

The IPT will develop preliminary system requirements by using the OCD and the results of any trade studies and analysis reports.

The IPT will conduct a mission review (MR).


NuPAC_ED610000-047-P B 68 of 204 01/19/2012


Work products include:

OCD Trade studies and analysis reports

System Requirements Specification (SRS) MR record.

The detail description of this process and its implementation for the generic NuPAC platform is documented in the NuPAC platform SEMP (Reference 4-1).

4.2.2.2 System Requirements Analysis (SRA)

The purpose of the SRA process is to further mature the preliminary system requirements from mission analysis into an agreed-upon set of clearly stated baseline system requirements.

The following tasks are performed by the NuPAC program IPT:

The IPT will develop a functional architecture, which describes the system in terms of functions, and/or discrete actions. The functional architecture will arrange the functions and their sub-functions and interfaces (internal and external) that define execution sequencing, conditions for control or data flow, and the performance requirements to satisfy the system requirements.

The IPT will establish a requirements database. The database will include requirements traceability and safety impact information.

The IPT will perform trade studies and analysis to refine system requirements. The IPT will identify safety and key critical characteristics and document them in the requirements

database. The IPT will identify external system interfaces and document them in the requirements database. The IPT will conduct a system requirements review (SRR).


Functional architecture document Requirements in the requirements database Trade studies and analysis reports

System requirements (baselined) SRR records.


4.2.2.3 System Design

The purpose of the system design process is to define candidate architectures and evaluate these alternatives to select the best system design. The design of the system must meet all the requirements of the system specification.

The NuPAC program IPT performs the following tasks:

The IPT will review the existing program requirements baseline; from this baseline, a prioritized and time-phased list of required analyses and trade studies will be developed.

The IPT will develop and evaluate possible design alternatives using quantitative selection criteria. The IPT will develop the physical architecture using the functional architecture and the system

requirements; map the system requirements to the physical architecture. The IPT will develop the software architecture using the functional architecture and the system

requirements. The IPT will develop the top-level system block diagram to include all of the major interfaces.


NuPAC_ED610000-047-P B 69 of 204 01/19/2012


The IPT will identify CIs and allocate system requirements to the CI(s); develop preliminary CI requirements.

The IPT will develop the interface control document (ICD) including all interface requirements within the system.

The IPT will perform additional trade studies to facilitate selection of components that meet all of the allocated and derived requirements.


ICD Trade studies and analysis reports Physical architecture

System block diagram CI requirements System design review records.

The system design process continues through the completion of the PiV&V process, which provides a means to refine the system design and/or to ensure the implementation and the verification and validation (V&V) activities meet the design intent.


4.2.2.4 Configuration Item (CI) Development

The purpose of the CI development process is to design, implement, build, integrate, and test CIs, based on the allocated requirements developed during system design process. The preliminary design review (PDR) and the critical design review (CDR) are two major reviews that occur concurrently with CI development process.

The CI development process continues through completion of the PiV&V process, providing a means to refine the implementation and/or to ensure V&V activities cover the implementation in its entirety.

CI development process consists of separate sub-processes based on the CI type—hardware or programmable logic.

4.2.2.4.1 Hardware CI Development

The hardware CI development process is appropriate for the design of hardware items required by the program. If a CI has sub-elements such as circuit card assemblies (CCAs), this process is applied recursively to each sub-element. A sub-element is a design that has its own hardware design requirements document. When this process is executed for a sub-element, the term CI applies to the sub-element.


The IPT will analyze the requirements provided in the hardware CI requirements specification and allocate those requirements to functions, and decompose the requirements to a level that is implementable.

The IPT will prepare the design concept that shows how interface and technical requirements will be met and verified.

The IPT will design, document, and verify the hardware CI. The IPT will fabricate the hardware CI articles and perform integration and test.


Hardware CI design concept Hardware CI test plan Hardware CI preliminary and detailed designs

Hardware CI parts list Hardware CI test report.


NuPAC_ED610000-047-P B 70 of 204 01/19/2012


The detail description of this process and its implementation for the generic NuPAC platform is documented in the NuPAC platform HDP (Reference 4-2).

4.2.2.4.2 Programmable Logic CI Development

The programmable logic CI development process is described in Section 5.0 of this LTR.

4.2.2.5 PiV&V

The purpose of the PiV&V process is to integrate all system elements, to verify the system is built according to the system specification, and to validate that the system functions as intended. The integration process assembles the lower-level CIs into an overall system that will satisfy all end-user needs in its intended environments.


The IPT will analyze the system requirements and determine how best to integrate the system elements and to perform verification and validation.

The IPT will analyze the CI requirements and determine how best to integrate each of the CIs into the system.

The IPT will determine how to perform verification and validation on each CI.


MTP Test readiness review (TRR) Trade study reports

PiV&V procedures Test reports Problem and change requests.

The PiV&V process is initiated early in the program life cycle to ensure the requirements, design, and implementation are testable and verifiable.

The detail description of this process and its implementation for the generic NuPAC platform is documented in the NuPAC platform PiV&V Plan (Reference 4-3). In addition, the detail description of the processes to develop associated test equipment is described in the TEDP (Reference 4-4) and the Test Equipment Software Development Plan (TESDP) (Reference 4-5).

4.2.3 Support Processes

The support processes of the TSP are shown in Figure 4.2.3-1. The eight processes spanning the life cycle of the NuPAC program are:

1) Risk and opportunity management 2) Configuration management 3) Quality assurance 4) Trade studies

5) Measurement and analysis 6) Reviews 7) Supplier agreement management 8) Corrective and preventive action management.


NuPAC_ED610000-047-P B 71 of 204 01/19/2012


Figure 4.2.3-1. TSP Support Processes

4.2.3.1 Risk and Opportunity Management

The purpose of risk and opportunity management process is to address program risks and opportunities throughout the program life cycle. The process consists of the following activities or phases:

Planning and implementing risk/opportunity management Performing risk/opportunity analysis and managing the risk/opportunity profile (identify/assess) Performing necessary actions (handling) Assessing the overall risk/opportunity management process (monitoring).

This process is intended to govern all program risk and opportunity management activities, which include design, test, programmable logic development, hardware manufacturing, and any sub-contractor effort.


Risk/opportunity register Risk/opportunity assessment reports Risk/opportunity handling plans

Risk/opportunity management board meeting minutes.

The detail description of this process and its implementation for the generic NuPAC platform is documented in the NuPAC platform ROMP (Reference 4-6).

4.2.3.2 Configuration Management (CM)

The purpose of the CM process is to establish and implement means to ensure the configuration of products, the data integrity, and the ability to manage them.

The CM process provides a means of controlling changes to the functional and physical characteristics (which define the CI during its life cycle), and provides information on the status of the changes.

CM processes establish:

Configuration baseline identification procedures Document review, approval, and control procedures Procedures for tracking and implementing changes to internal and formal baselines Status accounting procedures to track baseline(s) and associated changes through implementation History of the evolution of baselines throughout the product life cycle.


Functional configuration audit (FCA) checklist and record Physical configuration audit (PCA) checklist and record Configuration Control Board (CCB) meeting records Problem and change request records Configuration control records Configuration management plan (CMP).

The detail description of this process and its implementation for the generic NuPAC platform is documented in the NuPAC platform CMP (Reference 4-7).


NuPAC_ED610000-047-P B 72 of 204 01/19/2012


4.2.3.3 Quality Assurance (QA)

The purpose of the QA process is to establish a planned and systematic pattern of actions necessary to provide sufficient confidence that processes and products conform to established requirements. The QA organization supports the execution of the TSP and verifies compliance through process and product evaluations.

The QA organization is independent of the NuPAC program Development organization.


Evaluation checklists Evaluation records Quality program reports.

The detail description of this process and its implementation for the generic NuPAC platform is documented in the NuPAC platform QAP (Reference 4-8).

4.2.3.4 Trade Studies

The trade studies process defines the methodology to define alternative solutions, to analyze alternative solutions, and to optimize solutions. This support process is invoked by all others, and serves as a single point to collect and standardize all trade studies.

The trade study reports are the work products for this process.


4.2.3.5 Measurement and Analysis

The measurements and analysis process defines how program performance measurements are selected, collected, and analyzed. It includes analysis methods and how to decide what analysis methods to use.

The detail description of this process and its implementation for the generic NuPAC platform is documented in the NuPAC platform PMP (Reference 4-9).

4.2.3.6 Reviews

The reviews process defines the means of periodically checking on the progress of the product being developed. Checklists and other ancillary information are provided to perform specific reviews defined within the TSP. Special purpose reviews may be held using the processes, provided scope, expectations, and other parameters are adequately defined.

Other processes invoke reviews defined within this process.

There are three different types of reviews—work product reviews, technical and schedule reviews, and program reviews.

4.2.3.6.1 Work Product Reviews

The purpose of work product reviews is to identify and remove defects early and efficiently. A secondary purpose is to verify that work products are internally consistent as well as consistent with external requirements (e.g., higher-level and corresponding requirements, design constraints, design standards). Reviewers are selected based on the content of the artifact to be reviewed to ensure the acceptable skills and knowledge.

NuPAC program products will have facilitated work product reviews. A facilitated review is an inspection of a work product that includes a meeting of the review team.


NuPAC_ED610000-047-P B 73 of 204 01/19/2012



NuPAC_ED610000-047-P B 74 of 204 01/19/2012



Work product review package Work product review log

Work product review records Problem and change requests.

4.2.3.6.2 Technical Reviews

Technical and schedule reviews are held to inform all program personnel of the state of the program throughout the life of the program. These reviews provide an opportunity for the status of each part of the program to be shared with the larger program audience. This review may be included as part of larger program reviews.

Technical and schedule reviews, as shown in the TPS (Figure 4.1-1), include:

MR SRR System design review (SDR)

PDR CDR TRR.


Review package Review checklists

Review records Action items.

4.2.3.6.3 Program Reviews

Program reviews are held at the request of a customer or senior management and provide an opportunity to review the status of the program effort. These program reviews are scheduled at key points to monitor a program's progress.

Program reviews include the program start meeting (PSM) and program startup review (PSR).


Review package Review checklists

Review records Action items.

4.2.3.7 Supplier Agreement Management

The supplier agreement management process provides a means of controlling agreements between LMGI/SNPAS and suppliers, and identifies the individuals or organizations responsible for the various aspects of the process on a program. The process includes the details of source selection and qualification, agreement generation and maintenance, source monitoring, and product acceptance.

The purpose of this process is to select qualified subcontractors and manage them effectively.


Procurement specifications Statements of work (SOW) ICDs Subcontract data requirement lists (SDRLs) Acceptance test plans (ATP) Source selection criteria

Test reports Meeting records Review records Action item reports Acceptance records Purchase orders/contracts.


NuPAC_ED610000-047-P B 75 of 204 01/19/2012


The detail description of this process and its implementation for the generic NuPAC platform is documented in the NuPAC platform SMP (Reference 4-10).

4.2.3.8 Corrective and Preventive Action Management

The corrective and preventive action management process is a means for identifying, analyzing, preventing, and eliminating nonconformities; and implementing corrective action and/or preventive action for designs, products, tools/equipment, and processes during engineering development and manufacturing/production.


Corrective/preventive action requests.

The detail description of this process and its implementation for the generic NuPAC platform is documented in the NuPAC platform QAP (Reference 4-8).

4.2.4 Independent Verification and Validation (I-V&V) Processes

I-V&V processes (Figure 4.2.4-1) establish the systematic approach to independently verify and validate the programmable logic developed as part of the NuPAC program.

Figure 4.2.4-1. TSP I-V&V Processes

This effort is planned and executed in accordance with the applicable portions of the following USNRC regulations, guidance, and endorsed industry standards:

IEEE Standard 603-1991 (Reference 4-11), including the correction sheet dated January 30, 1995 ASME NQA-1-1994 (Reference 4-12) USNRC Standard Review Plan, BTP 7-14 (Reference 4-13), Section B.3.1.10 RG 1.168, Revision 1 (Reference 4-14) IEEE Standard 1012-1998 (Reference 4-15) IEEE Standard 1028-1997 (Reference 4-16) RG 1.152, Revision 2 (Reference 4-17) IEEE Standard 7-4.3.2-2003 (Reference 4-18) DI&C-ISG-06 (Reference 4-19) NUREG/CR-6101 (Reference 4-20).

The following sub-processes and associated activities will be performed under the I-V&V effort:

The management process will be executed throughout the development life cycle. The process addresses planning, change control, review of I-V&V execution, technical review support, audit support and interface with organizational and support processes.

The acquisition process will scope the I-V&V effort, plan interfaces with the supplier and acquirer, review the draft systems requirements contained in the request for proposal, and assess the security controls on the system.

The supply process will verify that the requirements proposed to the supplier and the requirements imposed on the supplier are consistent and satisfy user needs.


NuPAC_ED610000-047-P B 76 of 204 01/19/2012


The development process will verify and validate the programmable logic design developed by the supplier. This sub-process is organized further into the following activity categories—concept, requirements, design, implementation, test, and installation and checkout.


V&V Plan Anomaly reports Task reports Activity reports Final report

Test plans Test specifications Test reports Test procedures Test cases.

The I-V&V effort continues through the completion of the PiV&V process, which provides a means for any programmable logic updates to be independently evaluated for effects on previously completed I-V&V tasks.

The detail description of this process and its implementation for the generic NuPAC platform is documented in the in the NuPAC platform Field Programmable Logic Verification and Validation (FPLVV) Plan (Reference 4-21).

4.2.5 Implementation Details

In late 2007, LMGI initiated development of a generic control system platform that would offer the state-of-the-art technology for safety critical control systems. By the beginning of 2008, a mission analysis was commissioned with trade studies performed in the areas of compliance, functionality, technology, and logistics. Armed with the whitepapers from the trade studies, LMGI determined typical user needs with supporting use cases and defined the mission and system effectiveness. As a result of mission analysis, the OCD for a generic safety control system platform was generated with a set of preliminary system requirements derived primarily from EPRI TR-107330 (Reference 4-22). A mission review was then conducted mid-2008.

Using the preliminary system requirements, the system requirements analysis (SRA) process commenced. An initial functional architecture (a PLC-like system with a centralized architecture) was developed and system requirements were defined with supporting trade studies and analyses; subsequently, the first SRR was conducted in August 2008. As a result of the review, it was determined that a different architecture was necessary to better align with the mission objectives. Consequently, a second iteration of the SRA process commenced based on the concept of a de-centralized architecture and a generic logic module-type approach (later known as the NuPAC platform). Due to the significant architecture change, new trade studies and system analyses were performed, and revised system requirements derived; the second SRR was conducted May 2009.

Once a set of baselined system requirements were defined and captured in the requirement database, the system design process commenced. The NuPAC program IPT developed the physical architecture from the functional architecture and allocated requirements to the CI-level after several trade studies on alternative hardware solutions were performed. It was the findings from these trade studies that led to another system requirements analysis (in parallel with system design process) to refine the system requirements once more; the third SRR was conducted successfully in October 2009. Two months later, a successful SDR was conducted.

The CI development process on the NuPAC platform followed the SDR with separate development processes for hardware and programmable logic. By using the allocated requirements as design principles, the NuPAC program IPT developed the NuPAC platform design requirements specifications (DRSs). With the DRSs, subsequent design was performed that led to the development and test of test articles (Generic Logic Module, chassis, Rear Transition Module, and supporting programmable logic). A PDR was conducted April 2010;


NuPAC_ED610000-047-P B 77 of 204 01/19/2012


immediately after the preliminary design was completed. As of this writing, the NuPAC program is approaching the end of the CI development process.

As part of the PiV&V process, the PiV&V Plan, MTP, and TEDP were developed. In addition, V&V and test requirements were defined and allocated. Subsequently, test equipment and test software were developed. As of this writing, the PiV&V activities are in lock step with the NuPAC platform development life cycle in the TSP.

4.3 Planning Documentation

The TSP prescribes the “what” of managing and developing the NuPAC program. The TSP requires developing a set of program plans, which control “how” the TSP is to be implemented and executed for the NuPAC program. There are multiple program plans that govern the execution of the NuPAC program for achieving program excellence. The following subsections provide an overview of each program plan. Table 4.3-1 identifies references to the planning documentation specific to the generic NuPAC platform development program.

Table 4.3-1. Generic NuPAC Platform Planning Documentation Plan Reference

Program Management Plan (PMP) 4-9 Integrated Master Plan (IMP) 4-23 Systems Engineering Management Plan (SEMP) 4-1 Product Integration, Verification, and Validation (PiV&V) Plan 4-3 Master Test Plan (MTP) 4-24 Hardware Development Plan (HDP) 4-2 Risk and Opportunity Management Plan (ROMP) 4-6 Reliability Program Plan (RPP) 4-25 Test Equipment Development Plan (TEDP) 4-4 Test Equipment Software Development Plan (TESDP) 4-5 Support Plan (SP) 4-26 System Security Plan (SSP) 4-27 Assurance Plan (AP) 4-28 Quality Assurance Plan (QAP) 4-8 Configuration Management Plan (CMP) 4-7 System Safety Plan (SSPP) 4-29 Commercial Grade Dedication Plan (CGDP) 4-30 Field Programmable Logic Verification and Validation (FPLVV) Plan 4-21 Subcontract Management Plan (SMP) 4-10

4.3.1 Program Management Plan (PMP)

The PMP provides the structure in managing the NuPAC program. The PMP is the top-level document describing the management approach. The contents of the PMP combined with the contents of other NuPAC plans, including those of the subcontractors/key suppliers form the foundation for program execution.

The NuPAC program IPT will use this PMP, along with applicable referenced plans, as key management documents to define, execute, and manage administrative/technical processes on the program. The IPT is responsible for the life cycle development, which includes design, test, production, specialty engineering and independent verification and validation to satisfy the program safety requirements, quality standards, technical performance, budgetary constraints, and schedule requirements.


NuPAC_ED610000-047-P B 78 of 204 01/19/2012


4.3.2 Integrated Master Plan (IMP)

The IMP provides a comprehensive description of the program logic and processes planned for the NuPAC program. The IMP defines an event-driven plan and the activities necessary to satisfy each event as well as the criteria needed to justify completion. It provides the basis for subsequent detailed program planning and schedules, and it measures program maturity by marking the initiation or conclusion of major intervals of program activity. The IMP is not driven by a calendar, but is rather developed to provide the following:

Facilitation of upfront preliminary planning Identification of integrated program requirements A basis in preparing the Integrated Master Schedule (IMS) A basis for verification of event completion.

4.3.3 Systems Engineering Management Plan (SEMP)

The SEMP is the top-level controlling document for the technical execution of the NuPAC program. This document provides the detailed instructions for technical task planning and control, the system engineering process, and engineering specialty integration requirements to be applied to the NuPAC program.

4.3.4 Product Integration, Verification, and Validation (PiV&V) Plan

The PiV&V Plan describes the NuPAC program integration, verification, and validation activities. The PiV&V Plan defines the overall NuPAC program integration flow and V&V activities, including aspects of test, inspection, demonstration, and analysis.

The PiV&V Plan will be used in conjunction with the MTP, which defines the V&V test activities for the NuPAC program.

4.3.5 Master Test Plan (MTP)

The MTP describes the NuPAC program test activities. The MTP includes the test flow through each level of test from subassembly acceptance tests through system-level integration and qualification testing.

The MTP will be used in conjunction with the PiV&V Plan, which defines the overall NuPAC program integration flow and V&V activities.

4.3.6 Hardware Development Plan (HDP)

The HDP details the NuPAC program hardware engineering effort. It provides technical supplements, with respect to hardware development, to the overall technical effort defined in the SEMP.

4.3.7 Risk and Opportunity Management Plan (ROMP)

The ROMP delineates how the program will conduct and manage risks and opportunities that are specific to the NuPAC program. The plan also provides a background for the risk and opportunity management process, lists reference documents, and defines personnel and processes that constitute the plan. The ROMP covers risk and opportunity management activities throughout the life cycle of the NuPAC program.

4.3.8 Reliability Program Plan (RPP)

The RPP details the tasks, methodologies, organizational relationships, authority, and milestones relative to the management, analysis, design participation, surveillance, disclosure, and testing necessary to achieve the NuPAC program reliability requirements.


NuPAC_ED610000-047-P B 79 of 204 01/19/2012


4.3.9 Test Equipment Development Plan (TEDP)

The TEDP describes the strategies, guidelines, and implementation details for the NuPAC program development of special test equipment, which will be used for development, acceptance testing, and qualification. The TEDP outlines the process used to develop the test equipment required to perform the testing specified in the MTP. This plan applies throughout the life cycle of the NuPAC program.

4.3.10 Test Equipment Software Development Plan (TESDP)

The TESDP details the NuPAC program software engineering effort for the development and maintenance of the software components that control ancillary test systems. Test systems may be used to provide automated signal stimulus needed for the design verification testing.

4.3.11 Support Plan (SP)

The SP, often referred to as Integrated Logistics Support Plan (ILSP), is the controlling document for logistical support of the NuPAC Program. This document will provide the detailed instructions for planning and managing integrated logistics support (ILS) activities. This plan will identify logistical resource requirements and the management processes necessary to achieve satisfactory compliance across logistics elements for the NuPAC program.

4.3.12 System Security Plan (SSP)

The SSP specifies the security controls for NuPAC platform. Secure development and operational environment controls are described in Section 9.2 of this LTR.

4.3.13 Assurance Plan (AP)

The Assurance organization of the NuPAC program is responsible for providing assurance controls on all phases of the TSP, including product delivery and support to meet the requirements and expectations. These assurance controls are documented in the AP.

The AP establishes the process for performing continuous evaluations of the NuPAC program to ensure conformance to requirements and the TSP, ensuring effective quality management to prevent defects, analyzing results of measurements and assessment activities, reporting findings, and requiring corrective action as necessary.

4.3.14 Quality Assurance Plan (QAP)

The QAP supplements the LMGI “Nuclear Quality Assurance Manual,” NQA 2000 (Reference 4-31) and establishes the implementation details for the NuPAC program quality engineering activities. The QAP is maintained throughout the life cycle of the NuPAC program.

This plan is also the controlling document for the quality assurance activities for the programmable logic development effort as described in Section 5.0.

4.3.15 Configuration Management Plan (CMP)

The CMP is the controlling document for execution of configuration management on the NuPAC program. The CMP provides the instructions for configuration management and planning, configuration identification, configuration control (including the CCB), configuration status accounting, and configuration audits.

4.3.16 System Safety Plan (SSPP)

The SSPP provides detailed instructions for planning and managing the system safety program activities. It defines the system safety management methodology and the system safety engineering methodology applied to the NuPAC program. In addition, it establishes the system safety design criteria and guidelines.


NuPAC_ED610000-047-P B 80 of 204 01/19/2012


This plan is also the controlling document for the safety assurance activities for the programmable logic development effort as described in Section 5.0.

4.3.17 Commercial Grade Dedication Plan (CGDP)

The CGDP is the controlling document for the dedication of NuPAC program commercial-grade items and services. The design and manufacturing associated with the NuPAC program is considered safety-related and requires the dedication of various commercial-grade components and services from commercial suppliers.

The CGDP is applicable to the nuclear power plant safety system generic platform that is being developed by LMGI/SNPAS under the QA program. This plan is applicable to the items and services procured for the NuPAC program that are intended for safety-related use and are procured from commercial suppliers. This plan does not apply to components or services that are procured as basic components from suppliers in compliance with 10 CFR Part 50 Appendix B or ASME NQA-1.

4.3.18 Field Programmable Logic Verification and Validation (FPLVV) Plan

The FPLVV Plan defines the independent verification and validation effort that is to be applied to programmable logic developed for the NuPAC program. The plan specifies the tasks to independently verify and validate the programmable logic in accordance with IEEE Standard 1012-1998 (Reference 4-15) as endorsed and modified by USNRC RG 1.168 (Reference 4-14).

4.3.19 Failure Reporting, Analysis and Corrective Action System (FRACAS) Plan

The FRACAS Plan is the controlling document for establishing a method for completing a failure analysis, a root cause investigation, and corrective action relevant to a failure as it relates to the NuPAC program. The plan also establishes and delineates areas of responsibility and will be utilized throughout all test phases of the program.

4.3.20 Subcontract Management Plan (SMP)

The SMP is the controlling document for subcontracts on the NuPAC program. This SMP sets forth the processes for developing subcontract strategies, managing and integrating activities with major program milestones, and driving excellent performance. It provides methods and guidance for the selection and management of subcontractors using proven concepts, tools, and techniques to assure successful NuPAC program execution.

This SMP provides guidance for subcontract management activities including:

Organization, roles, and responsibilities for NuPAC program subcontract execution Techniques for subcontractor performance management An introduction to a subcontract management team concept Management of subcontractors during execution of the NuPAC program.

This plan provides consistent processes for developing subcontracting strategies and managing subcontractors of the NuPAC program with the following expectations:

Early engagement with subcontractors Proactive planning of collaborative activities to enable excellent subcontract performance Consistent application of management oversight for all subcontractors Control of subcontractors through all phases of the program to minimize program impacts Defining and establishing coordinated supplier management teams with skill mixes focused on the program

phases


NuPAC_ED610000-047-P B 81 of 204 01/19/2012


Defining and establishing appropriate business relationships with subcontractors to ensure NuPAC program success.

4.3.21 Programmable Logic Planning Documentation

The programmable logic planning documentation is described in Section 5.0 of this LTR.


NuPAC_ED610000-047-P B 82 of 204 01/19/2012


4.4 Organizational Relationships

Figure 4.4-1 shows the NuPAC program organizational structure of teams and the relationships between each.

Figure 4.4-1. NuPAC Program Organizational Relationships

4.4.1 Leadership Teams

The leadership teams provide overall leadership to the NuPAC program teams, and establish the primary interface with executive staff. The executive staff has two direct lines of reporting from the NuPAC program teams, one via the Quality Assurance team and the other from the Line of Business (LOB) leadership team. The LOB leadership team has full responsibility and authority for program execution per contract and company policies. The LOB leadership team is responsible for the overall product line.

4.4.2 NuPAC Program Teams

Four separate teams with two distinct reporting lines back to the leadership teams constitute the NuPAC program teams. Relationships between the teams are shown in Figure 4.4-1, and the teams are described in detail in the following sections.


NuPAC_ED610000-047-P B 83 of 204 01/19/2012


4.4.2.1 NuPAC QA Team

The NuPAC QA team reports directly to the QA team. The QA team provides the independent quality monitoring and controls for the NuPAC program. It is responsible for implementing all QA processes for the program (see Section 4.2) and for development of the QA work products (see Section 4.3). The QA team interfaces to the Program Management, Development, and Assurance teams to track quality metrics and report on the performance of the quality system.

QA team tasks include:

Ensuring the processes are followed in accordance with program planning documentation Reviewing engineering documentation Reviewing specific procurements to ensure proper quality information is entered Resolving component issues and reviewing test data at the point of incoming inspection Writing inspection instructions to facilitate development Approving product routings Documenting all process and work product audits Checking artifacts for completeness and alignment with associated plans and requirements Conducting onsite supplier capability reviews and system audits.

As shown in Figure 4.4-1, the NuPAC QA team is dotted line to each of the other program teams and has the organizational freedom to report quality violations to the QA team.

4.4.2.2 NuPAC Program Management Team

The NuPAC Program Management team reports directly to the LOB leadership team and is responsible for implementing all PPMC processes (defined in Section 4.2) and for developing and maintaining the PPMC associated work products (defined in Section 4.3).

4.4.2.2.1 NuPAC Development Team

The NuPAC Development team reports directly to the LOB leadership team and is responsible for implementing all technical processes (defined previously in Section 4.2) and for developing and maintaining the associated work products (defined in Section 4.3).

4.4.2.2.2 NuPAC Assurance Team

The NuPAC Assurance team reports directly to the LOB leadership team and is responsible for implementing all safety and I-V&V processes (defined previously in Section 4.2) and developing and maintaining safety and I-V&V associated work products (defined in Section 4.3).

The NuPAC Assurance team is responsible for overall system safety activities related to planning and execution. It also performs system hazard analysis and fault tree analysis and participates on all safety-related design reviews.

The NuPAC Assurance team is also responsible for I-V&V which includes all aspects related to I-V&V activities of the NuPAC program in accordance with IEEE Standard 1012-1998 (Reference 4-15) as endorsed and modified by USNRC RG 1.168 (Reference 4-14). The independent nature of this organization does not allow any of the team members to participate in the development efforts.


NuPAC_ED610000-047-P B 84 of 204 01/19/2012


4.5 References

4-1 NuPAC Document No. NuPAC_SEMP610000-001, Rev. A, “NuPAC Systems Engineering Management Plan,” LMGI/SNPAS

4-2 NuPAC Document No. NuPAC_HDP610000-001, Rev. A, “NuPAC Hardware Development Plan,” LMGI/SNPAS

4-3 NuPAC Document No. NuPAC_PIVV610000-001, Rev. -, “NuPAC Product Integration, Verification, and Validation Plan,” LMGI/SNPAS

4-4 NuPAC Document No. NuPAC_TEDP610000-001, Rev. A, “NuPAC Test Equipment Development Plan,” LMGI/SNPAS

4-5 NuPAC Document No. NuPAC_SDP610820-001, Rev. A, “NuPAC Test Equipment Software Development Plan,” LMGI/SNPAS

4-6 NuPAC Document No. NuPAC_ROMP610000-001, Rev. A, “NuPAC Risk and Opportunity Management Plan,” LMGI/SNPAS

4-7 NuPAC Document No. NuPAC_CMP610000-001, Rev. A, “Configuration Management Plan,” LMGI/SNPAS

4-8 NuPAC Document No. NuPAC_QAP610000-001, Rev. A, “NuPAC Quality Assurance Plan,” LMGI/SNPAS

4-9 NuPAC Document No. NuPAC_PMP610000-001, Rev. A, “NuPAC Program Management Plan,” LMGI/SNPAS

4-10 NuPAC Document No. NuPAC_SMP610000-001, Rev. -, “NuPAC Subcontract Management Plan,” LMGI/SNPAS



4-13 Branch Technical Position (BTP) 7-14, Rev. 5, “Guidance on Software Reviews for Digital Computer-based Instrumentation and Control Systems,” US Nuclear Regulatory Commission, March 2007


4-15 IEEE Standard 1012-1998, “IEEE Standard for Software Verification and Validation,” Institute of Electrical and Electronics Engineers


NuPAC_ED610000-047-P B 85 of 204 01/19/2012


4-16 IEEE Standard 1028-1997, “IEEE Standard for Software Reviews,” Institute of Electrical and Electronics Engineers




4-20 NUREG/CR-6101, “Software Reliability and Safety in Nuclear Reactor Protection Systems,” Lawrence Livermore National Laboratory, June 1993

4-21 NuPAC Document No. NuPAC_FVVP610000-001, Rev. A, “NuPAC FPL Verification and Validation Plan,” LMGI/SNPAS


4-23 NuPAC Document No. NuPAC_IMP610000-001, Rev. -, “NuPAC Integrated Master Plan,” LMGI/SNPAS

4-24 NuPAC Document No. NuPAC_MTP610000-001, Rev. A, “NuPAC Master Test Plan,” LMGI/SNPAS

4-25 NuPAC Document No. NuPAC_RPP610000-001, Rev. -, “NuPAC Reliability Program Plan,” LMGI/SNPAS

4-26 NuPAC Document No. NuPAC_SP610000-001, Rev. A, “NuPAC Integrated Logistics Support Plan,” LMGI/SNPAS

4-27 NuPAC Document No. NuPAC_SSP610000-001, Rev. -, “NuPAC System Security Plan,” LMGI/SNPAS

4-28 NuPAC Document No. NuPAC_AP610000-001, Rev. -, “NuPAC Assurance Plan,” LMGI/SNPAS

4-29 NuPAC Document No. NuPAC_SSPP610000-001, Rev. B, “NuPAC System Safety Plan,” LMGI/SNPAS

4-30 NuPAC Document No. NuPAC_CGDP610000-001, Rev. A, “NuPAC Commercial-Grade Item/Service Dedication Plan,” LMGI/SNPAS

4-31 LMGI Document No. NQA 2000, Rev. C, “Nuclear Quality Assurance Manual,” Lockheed Martin Global, Inc., November 2010


NuPAC_ED610000-047-P B 86 of 204 01/19/2012


5.0 SOFTWARE DEVELOPMENT PROCESS FOR NuPAC PROGRAMMABLE LOGIC

This section summarizes the development processes for programmable logic (PL) activity within the NuPAC program. The processes used in the development of the NuPAC platform PL follow an incremental waterfall life cycle model, based on the activities defined in IEEE Standard 1074-1995 (Reference 5-1) as endorsed by USNRC RG 1.173 (Reference 5-2). The incremental waterfall life cycle model incorporates the strategy of developing the PL in a traditional waterfall approach that allows revisiting of requirements, design, and implementation based on the nature and evaluations of the safety critical aspects of the PL. The PL development consists of a requirements process, a design process, an implementation process, an integration process, and a validation process leading to a post-development PL support process.

System-level requirements, system-level allocations (functional and physical architecture), and requirements of hardware components are defined as part of the pre-development process leading into PL development. Hardware items provide the foundation to further allocate interface, functional, and performance requirements to PL configuration items (PLCIs). The PLCIs consist of the logic that is embedded in the programmable logic devices (PLDs). For each PLCI, the PL requirements are derived and the PL is designed, implemented, and evaluated against those requirements. Upon completion of PL validation, PL components are ready to be integrated with the PLDs and evaluated at the hardware-level as part of the PL post-development process.

The PL development process (Figure 5.0-1) maps life cycle processes and activities to the incremental waterfall model. The development process specifically addresses the requirements through the validation phase of the PL life cycle model. For thoroughness, the figure shows a complete waterfall life cycle model. Pre- and post-development activities are included, such as the allocation of system-level requirements, the PLCI installation in the PLDs, and the PLCIs’ operation and maintenance phases. The PL Development team, a subset of the NuPAC Development team (see Figure 4.4-1), is responsible for PLCI development and maintenance even as it hands off fully functional PLCIs for integration into the PLDs. The PL Independent Verification and Validation (I-V&V) team, a subset of the NuPAC Assurance team (see Figure 4.4-1), monitors PL development, ensuring compliance to program requirements and readiness for formal qualification.

The Programmable Logic Project Management Plan (Reference 5-3) addresses the management of PL processes and establishes the infrastructure and systematic approach for development of the PLCIs for the NuPAC platform. The Programmable Logic Development Plan (PLDP) (Reference 5-4) then provides the details for the NuPAC platform PL development life cycle. The PLDP documents the PL life cycle process; PL methods, tools, and techniques; standards; schedule and milestones; and technical documentation requirements. The PLDP is fully integrated with the configuration management process, as documented in the Programmable Logic Configuration Management Plan (Reference 5-5), and the quality assurance process, as documented in the Quality Assurance Plan (Reference 5-6).


NuPAC_ED610000-047-P B 87 of 204 01/19/2012




NuPAC_ED610000-047-P B 88 of 204 01/19/2012


Figure 5.0-1. Programmable Logic Development Process


NuPAC_ED610000-047-P B 89 of 204 01/19/2012




NuPAC_ED610000-047-P B 90 of 204 01/19/2012


5.1 Programmable Logic Life Cycle Description

The PL development consists of five processes —requirements, design, implementation, integration, and validation. The life cycle description for each process element, including pre- and post-development, is summarized below.

5.1.1 Pre-Development Process

The pre-development process of the PL life cycle is administered outside of the of the PL Development team’s area of influence. The Systems Engineering team provides the allocated requirements and the Hardware Development team, a subset of the NuPAC Development team (see Figure 4.4-1). The Systems Engineering and Hardware Development teams’ responsibilities are addressed in the Program Management Plan (Reference 5-7), Systems Engineering Management Plan (Reference 5-8), and the Hardware Development Plan (Reference 5-9).

5.1.2 Requirements Process

The PL requirements process further decomposes the pre-development activities and products to an agreed-upon set of clearly stated derived PLCI requirements. All aspects of the PL are considered and represented (including safety, information assurance, logistics, sustainment, and training requirements). PLCI requirements specifications capture baseline PLCI-level embedded and support requirements. The outcome of the requirements analysis and functional decomposition are captured in the NuPAC program requirements repository, a requirements management database (e.g., the IBM® Dynamic Object-Oriented Requirements System [DOORS®] tool), where all of the requirements are maintained and traced for system verification.

5.1.3 Design Process

The PL design process develops a coherent, well-organized representation of each PLCI such that implementation of the logic will meet the requirements defined during the requirements process. The PL design process defines candidate PLCI architectures and evaluates these for alternatives to select the best possible design. The functional architecture for the PL is developed and mapped to the PLCI and system-level requirements. Additional trade studies provide for selection of subcomponents that meet allocated and derived requirements. The PLCI detailed development specifications capture the baseline PLCI-level designs.

5.1.4 Implementation Process

The PL implementation process transforms the PLCI detailed development specifications into functioning logic. This process includes the generation, testing, and compliance assessments of the PLCIs’ VHDL or Verilog code. The purpose of the implementation and subcomponent testing is to build up and evaluate the components defined during the PL design process.

5.1.5 Integration Process

The PL integration process confirms the incorporation of the PLCI functionality within the PLCIs meet the baselined requirements. The integration process assembles the PLCI lower-level components into an overall structured product.

5.1.6 Validation Process

The PL validation process confirms the operation of the PLCIs within the constraints of the baselined requirements. The validation process assesses all of the PLCI’s components to verify that the logic operates to the provisions identified in each of the PLCI requirements. The validation process is managed by the PL I-V&V team as addressed in the FPLVV Plan (Reference 5-10).


NuPAC_ED610000-047-P B 91 of 204 01/19/2012


5.1.7 Post-development Processes

The PL post-development process of the PL life cycle, including the installation and product operation and maintenance processes, are administered outside of the PL Development team’s area of influence. The PLCI products are provided for integration with the PLD, Generic Logic Module (GLM), and higher-level NuPAC-based systems. The Systems Engineering, Integration, and Test (SEIT) team is responsible for embedding and integrating the PLCIs into the PLDs and the GLMs. The post-development process will ensure the Core PLCI is operational in the objective system (i.e., GLM or higher-level NuPAC-based system). Likewise, Application Specific (AS) PLCIs are integrated with GLMs and higher-level NuPAC-based system to ensure that they operate within their defined parameters. The SEIT team’s responsibilities are addressed in the Program Management Plan (Reference 5-7); Systems Engineering Management Plan (Reference 5-8); the Product Integration, Verification, and Validation Plan (Reference 5-11); and the Master Test Plan (Reference 5-12).

Although the PL post-development process is administered outside of the PL Development team’s area of influence, the team remains responsible for the operation and maintenance of the PLCIs. During this process, and in general for any baselined product during any process, defects and system anomalies will be recorded and reported back to the PL Development team via problem/change requests (P/CR) for the purposes of analysis and mitigation.

5.2 Programmable Logic Verification and Validation

The PL Development team is responsible for the development and evaluation of the PLCIs to verify they operate as specified. The PLDP identifies and supports verification and validation (V&V) oversight of the PLCIs throughout the life cycle to ensure compliance; as such, there are four levels of PL V&V oversight. The first level is the continuous quality assurance oversight and assessments throughout the PL development processes. The second level is the Pi-V&V activities that ensure that the PLCIs operate correctly when integrated with PLDs, GLMs, and higher-level NuPAC-based systems. The third level is the I-V&V (Independent V&V) that is responsible for the acceptance testing to ensure that the PLDs and GLMs are fully operational and meet the requirement specifications. Then finally, the fourth level is the system safety evaluation of the PL work products for compliance with the System Safety Plan (Reference 5-13).

5.3 Programmable Logic Planning Documentation

There are multiple planning documents that govern the execution of the development processes for NuPAC platform PL. The following sections provide an overview of each plan. Table 5.3-1 identifies references to the PL planning documentation that is specific to the generic NuPAC platform development program.

Table 5.3-1. Generic NuPAC Platform PL Planning Documentation Plan Reference

Programmable Logic Project Management Plan (PLPMP) 5-3 Programmable Logic Development Plan (PLDP) 5-4 Quality Assurance Plan (QAP) 5-6 Programmable Logic Integration Plan (PLIP) 5-14 System Safety Plan (SSPP) 5-13 Field Programmable Logic Verification and Validation (FPLVV) Plan 5-10 Programmable Logic Configuration Management Plan (PLCMP) 5-5 Programmable Logic Test Plan (PLTP) 5-15


NuPAC_ED610000-047-P B 92 of 204 01/19/2012


5.3.1 Programmable Logic Project Management Plan (PLPMP)

The PLPMP is the top-level document describing the management approach for all PL activities. The contents of the PLPMP combined with the contents of other PL plans form the foundation for project execution. The plan specifies the monitoring and controlling mechanisms, identifies the staffing needs and development environment, defines the design and coding standard, and identifies the plans needed for the successful development of NuPAC platform PLCIs.

The plan conforms to the format and content of IEEE Standard 1058.1-1987 (Reference 5-16) with additional guidance drawn from NUREG/CR-6101 (Reference 5-17) and IEEE Standard 1074-1995 (Reference 5-1), as endorsed by RG 1.173 (Reference 5-2).

5.3.2 Programmable Logic Development Plan (PLDP)

The PLDP is the basic governing document for the PL development activities. The PLDP defines the development of the PLCIs as a specific implementation of the software life cycle activities defined in IEEE Standard 1074-1995 (Reference 5-1) as endorsed by the RG 1.173 (Reference 5-2).

The PLDP defines the technical processes, activities, and tasks needed to design, implement, and evaluate the Core and Application Specific (AS) PLCIs. The plan enforces a series of practices that provides structure and guidance to the systems engineering, design engineering, component engineering and evaluation activities associated with the complexity of the PLCIs. It ensures that I-V&V, system safety, and supports activities are integrated into the development process.

5.3.3 Quality Assurance Plan (QAP)

The QAP previously discussed in Section 4.3.14 addresses the PL quality assurance activities and describes the necessary processes that ensure that the PLCIs attain a level of quality commensurate with their importance to safety function. The QAP conforms to IEEE Standard 730-1998 (Reference 5-18). The plan complies with the life cycle quality assurance activities of IEEE Standard 1074-1995 (Reference 5-1).

5.3.4 Programmable Logic Integration Plan (PLIP)

The PLIP is part a controlling document for the integration process. The plan defines the integration boundary, integration strategies, personnel, and responsibilities; it also describes the test procedures and test criteria, and identifies test equipment and tools.

The plan complies with IEEE Standard 1074-1995 (Reference 5-1), the software integration plan and installation activities sections of USNRC Standard Review Plan, BTP 7-14 (Reference 5-19), and the software integration plan and installation configuration tables sections of USNRC DI&C-ISG-06 (Reference 5-20). The plan supplements the PL Test Plan (PLTP) discussed in Section 5.3.12.

5.3.5 Installation Plan

The installation plan is only applicable to a plant-specific application, and is not applicable to the generic NuPAC platform. For future plant-specific NuPAC-based applications, a project-specific plan may be composed, as required by the licensee, to support installation activities. The plan will conform to applicable regulatory standards.

5.3.6 Maintenance Plan

The maintenance plan is only applicable to a plant-specific application, and is not applicable to the generic NuPAC platform. For future plant-specific NuPAC-based applications, a project-specific plan may be composed,


NuPAC_ED610000-047-P B 93 of 204 01/19/2012


as required by the licensee, to support maintenance activities. The plan will conform to applicable regulatory standards.

5.3.7 Training Plan

The training plan is only applicable to a plant-specific application, and is not applicable to the generic NuPAC platform. For future plant-specific NuPAC-based applications, a project-specific plan may be composed, as required by the licensee, to support training activities. The plan will conform to applicable regulatory standards.

5.3.8 Operations Plan

The operations plan is only applicable to a plant-specific application, and is not applicable to the generic NuPAC platform. For future plant-specific NuPAC-based applications, a project-specific plan may be composed, as required by the licensee, to support operational practices. The plan will conform to applicable regulatory standards.

5.3.9 System Safety Plan (SSPP)

The SSPP previously discussed in Section 4.3.16 addresses the PL safety assurance activities and describes the necessary processes for identifying risks and hazards associated with operation, maintenance, and support of the PLCIs and the NuPAC platform.

The plan conforms to IEEE Standard 1228-1994 (Reference 5-21) for format and content, with guidance from the identification and resolution of hazards annex section of IEEE Standard 7-4.3.2-2003 (Reference 5-22), the software safety plan and the acceptance criteria for safety analysis activities sections of USNRC Standard Review Plan, BTP 7-14 (Reference 5-19), and the software safety plan and the software safety analysis sections of USNRC DI&C-ISG-06 (Reference 5-20). The plan complies with the life cycle safety activities of IEEE Standard 1074-1995 (Reference 5-1).

5.3.10 Field Programmable Logic Verification and Validation (FPLVV) Plan

The FPLVV Plan previously discussed in Section 4.3.18 defines the I-V&V effort that is to be applied to programmable logic developed for the NuPAC platform. The plan describes the organization, schedule, PL integrity level scheme, resources, responsibilities, tools, techniques, and methods necessary to perform the PL I-V&V activities.

This plan was prepared and is maintained to comply with the applicable portions of the following USNRC regulations, and to conform to the applicable portions of the following guidance and endorsed industry standards:

IEEE Standard 603-1991 (Reference 5-23), including the correction sheet dated January 30, 1995 ASME NQA-1-1994 (Reference 5-24) USNRC Standard Review Plan, BTP 7-14 (Reference 5-19), Section B.3.1.10 RG 1.168, Revision 1 (Reference 5-25) IEEE Standard 1012-1998 (Reference 5-26) IEEE Standard 1028-1997 (Reference 5-27) RG 1.152, Revision 2 (Reference 5-28) IEEE Standard 7-4.3.2-2003 (Reference 5-22) DI&C-ISG-06 (Reference 5-20) NUREG/CR-6101 (Reference 5-17).


NuPAC_ED610000-047-P B 94 of 204 01/19/2012


5.3.11 Programmable Logic Configuration Management Plan (PLCMP)

The PLCMP is the governing document for PL configuration management activities. The plan describes PL configuration management, configuration item identification, configuration control, and configuration status accounting.

The PLCMP conforms to IEEE Standard 828-1990 (Reference 5-29) for format and content, with guidance from IEEE Standard 1042-1987 (Reference 5-30). The plan also complies with the life cycle activities of IEEE Standard 1074-1995 (Reference 5-1); the software tools, software configuration management, and firmware and software identification sections of IEEE Standard 7-4.3.2-2003 (Reference 5-22); the software configuration management plan and the acceptance criteria for software configuration management activities sections of USNRC Standard Review Plan, BTP 7-14 (Reference 5-19); and the software configuration management plan and the corresponding configuration management activities sections of USNRC DI&C-ISG-06 (Reference 5-20).

5.3.12 Programmable Logic Test Plan (PLTP)

The PLTP describes the scope, approach, resources, and schedule of the PL testing activities. It identifies the items being tested, the features to be tested, the testing tasks to be performed, and the personnel responsible for each task. The plan covers testing conducted on the PLCIs, including unit testing, integration testing, acceptance testing, and installation testing.

The plan complies with the software test plan and test activities sections of USNRC DI&C-ISG-06 (Reference 5-20), the integration through installation phases of IEEE Standard 1074-1995 (Reference 5-1), the software test plan and the acceptance criteria for testing activities sections of USNRC Standard Review Plan, BTP 7-14 (Reference 5-19), IEEE Standard 829-1983 (Reference 5-31), and ANSI/IEEE Standard 1008-1987 (Reference 5-32).

5.4 References

5-1 IEEE Standard 1074-1995, “IEEE Standard for Developing Software Life Cycle Processes,” Institute of Electrical and Electronics Engineers


5-3 NuPAC Document No. NuPAC_PLPMP610000-001, Rev. -, “NuPAC Programmable Logic Project Management Plan,” LMGI/SNPAS

5-4 NuPAC Document No. NuPAC_PLDP610000-001, Rev. -, “NuPAC Programmable Logic Development Plan,” LMGI/SNPAS

5-5 NuPAC Document No. NuPAC_PLCMP610000-001, Rev. -, “NuPAC Programmable Logic Configuration Management Plan,” LMGI/SNPAS




NuPAC_ED610000-047-P B 95 of 204 01/19/2012


5-8 NuPAC Document No. NuPAC_SEMP610000-001, Rev. A, “NuPAC Systems Engineering Management Plan,” LMGI/SNPAS

5-9 NuPAC Document No. NuPAC_HDP610000-001, Rev. A, “NuPAC Hardware Development Plan,” LMGI/SNPAS

5-10 NuPAC Document No. NuPAC_FVVP610000-001, Rev. A, “NuPAC FPL Verification and Validation Plan,” LMGI/SNPAS

5-11 NuPAC Document No. NuPAC_PIVV610000-001, Rev. -, “NuPAC Product Integration, Verification, and Validation Plan,” LMGI/SNPAS

5-12 NuPAC Document No. NuPAC_MTP610000-001, Rev. A, “NuPAC Master Test Plan,” LMGI/SNPAS

5-13 NuPAC Document No. NuPAC_SSPP610000-001, Rev. B, “NuPAC System Safety Plan,” LMGI/SNPAS

5-14 NuPAC Document No. NuPAC_PLDP610000-004, Rev. -, “NuPAC Programmable Logic Integration Plan - Core PLCI,” LMGI/SNPAS

5-15 NuPAC Document No. NuPAC_TPL610400-001, Rev. Draft, “NuPAC Programmable Logic Test Plan - Core PLCI,” LMGI/SNPAS

5-16 IEEE Standard 1058.1-1997, “IEEE Standard for Software Project Management Plans,” Institute of Electrical and Electronics Engineers

5-17 NUREG/CR-6101, “Software Reliability and Safety in Nuclear Reactor Protection Systems,” Lawrence Livermore National Laboratory, June 1993

5-18 IEEE Standard 730-1998, “IEEE Standard for Software Quality Assurance Plans,” Institute of Electrical and Electronics Engineers

5-19 Branch Technical Position (BTP) 7-14, Rev. 5, “Guidance on Software Reviews for Digital Computer-based Instrumentation and Control Systems,” US Nuclear Regulatory Commission, March 2007


5-21 IEEE Standard 1228-1994, “IEEE Standard for Software Safety Plans,” Institute of Electrical and Electronics Engineers




NuPAC_ED610000-047-P B 96 of 204 01/19/2012





5-27 IEEE Standard 1028-1997, “IEEE Standard for Software Reviews,” Institute of Electrical and Electronics Engineers


5-29 IEEE Standard 828-1990, “IEEE Standard for Software Configuration Management Plans,” Institute of Electrical and Electronics Engineers

5-30 IEEE Standard 1042-1987, “IEEE Guide to Software Configuration Management,” Institute of Electrical and Electronics Engineers

5-31 IEEE Standard 829-1983, “IEEE Standard for Software Test Documentation,” Institute of Electrical and Electronics Engineers

5-32 ANSI/IEEE Standard 1008-1987, “IEEE Standard for Software Unit Testing,” Institute of Electrical and Electronics Engineers


NuPAC_ED610000-047-P B 97 of 204 01/19/2012




NuPAC_ED610000-047-P B 98 of 204 01/19/2012


6.0 EQUIPMENT QUALIFICATION

6.1 Description of Test Specimen and Test Equipment

6.1.1 Test Specimen Configuration

The Test Specimen Configuration (TSC) is an example of a NuPAC-based application consisting of a mix of functions that match the relative mix of functions identified in NPP safety system operational scenarios. The TSC is the configuration of the NuPAC platform to be used for the qualification test program.

The TSC emulates a Reactor Trip System (RTS). An RTS is the overall system of instruments (sensors), trip logics, trip actuators, and scram logic circuitry that initiates rapid insertion of control rods (scram) to shut down a reactor. The system also establishes operating modes and provides status and control signals to other systems and annunciators. A RTS provides reliable single-failure-proof capability to automatically or manually initiate a reactor scram while maintaining protection against unnecessary scrams resulting from single failures. This is accomplished through the combination of fail-safe equipment design and a redundant two-out-of-four logic arrangement. Although the TSC is RTS-centric, the general functionality is applicable to Engineered Safety Features Actuation System (ESFAS) and other systems.

The TSC, as specified, is representative of a single division (one of the four redundant logic arrangements) of reactor trip detect logic and coincidence logic. Each division samples sensors, performs trip detect logic, transmits/receives trip conditions to/from every other division, and provides trip output to the actuators (scram) when the same trip condition exists in any two or more divisions (coincidence logic).

The TSC consists of at least one of each type of NuPAC platform hardware component listed in Section 3.1.4, including the Carrier Card, Logic Mezzanine, I/O mezzanines, Rear Transition Module (RTM), and chassis. Figure 6.1.1-1 shows a block diagram of the TSC. The TSC is a system consisting of two chassis. Each chassis is populated with GLMs/RTMs. One chassis is allocated to trip detect logic and is comprised of GLMs that are configured to utilize each of the types of inputs offered by the NuPAC platform. The inputs to this chassis simulate the inputs that are present in a typical RTS. The application-specific programmable logic determines whether the input value is above or below the setpoint value and communicates the trip conditions to the second chassis. The second chassis is allocated to coincidence logic and is populated with GLMs configured to provide a sample of the output types offered by the NuPAC platform. The application-specific programmable logic of this chassis compares the trip conditions received from the trip detect chassis with trip conditions received from three other simulated divisions of trip detect logic. It performs two-out-of-four voting and controls outputs consistent with outputs that are present in a typical RTS.


NuPAC_ED610000-047-P B 99 of 204 01/19/2012


Figure 6.1.1-1. TSC Block Diagram

6.1.2 Test Equipment

LMGI/SNPAS will test the TSC using an automated test system ( P/N TF610800-600), shown in Figure 6.1.2-1. It will be primarily used to provide stimulus to TSC inputs and to monitor TSC outputs.

As part of the NuPAC development project, this test system is designed, integrated, verified, and maintained under the auspices of the quality assurance program. Test system hardware and software are controlled via life cycle planning documentation, including the Program Management Plan (Reference 6-1), Test Equipment Development Plan (Reference 6-2), Test Equipment Software Development Plan (Reference 6-3), Quality Assurance Plan (Reference 6-4), and Configuration Management Plan (Reference 6-5).

The test system consists of two primary cabinets, which host the test equipment components, including data recording equipment (i.e., data logger). The test system is designed and built as portable, which will facilitate testing at external labs and facilitates. Two secondary test fixture types hold the TSC chassis during seismic, electromagnetic compatibility, and environmental testing. Redundant input power and field power are provided by the test system. These power supplies are not considered part of the TSC. The test system will apply inputs to the TSC and will monitor outputs from the TSC to verify operability. Cables are required to connect the power


NuPAC_ED610000-047-P B 100 of 204 01/19/2012


supplies and I/O. These cables are considered supporting test equipment and are not considered part of the TSC. An interface test adapter (ITA) and cable assembly will be provided for the interface.

The National Instruments LabVIEW® graphical programming language is used to develop all test system software and, as required, instrument drivers. The test system software will control test sequences to be applied to the TSC.

Data recording equipment (i.e., data logger) will be configured to monitor TSC test points. Via a wire harness interface, the data logger will monitor approximately 100 test points. The data logger is a commercial-off-the-shelf (COTS) instrument capable of storing inputs and responses to and from the TSC. All signals to the data logger will flow through the ITA. The data collected by the data logger will be used for system-level verification and operability testing. The data collected will be stored in the project repository.

NuPAC verification and qualification testing will be performed using the test setup shown in Figure 6.1.2-2. The stimulus, response, and measurement data will be collected using the data recording equipment.

Figure 6.1.2-1. Test System


NuPAC_ED610000-047-P B 101 of 204 01/19/2012


Figure 6.1.2-2. TSC Test Setup Block Diagram


NuPAC_ED610000-047-P B 102 of 204 01/19/2012


6.2 Qualification Test Program

The qualification test program is a combination of the events of verification and validation, which confirm the NuPAC platform meets its requirements that are demonstrated by test. This process is described in the NuPAC Master Test Plan (Reference 6-6). After a series of acceptance and verification tests and prior to the start of qualification testing, the TSC will go through a series of proof testing described in Section 6.2.1. Upon successful completion of proof testing the TSC will undergo a series of rigorous qualification tests described in Sections 6.2.2 through 6.2.8, as required by the NuPAC platform requirements to verify it is capable of performing its designed safety functions during specified operating conditions. Table 6.2-1 presents a summary of the qualification testing, including the tentative sequence of tests.

Table 6.2-1. Qualification Testing

Order Description Basis 1 Temperature and Humidity EPRI TR-107330 2 Radiation Withstand EPRI TR-107330 3 EMI/RFI USNRC RG 1.180 Revision 1, MIL-STD-461E 4 Surge Withstand USNRC RG 1.180 Revision 1, EPRI TR-107330 5 Class 1E to Non-1E Isolation EPRI TR-107330 6 Electrostatic Discharge EPRI TR-107330, EPRI TR-102323 7 Seismic Withstand USNRC RG 1.100, EPRI TR-107330

The testing order may vary due to equipment availability and scheduling at the test facilities. For example, radiation testing may be performed prior to temperature and humidity testing since radiation testing is performed at a separate facility. Seismic testing will be the final test performed.

Test procedures will be used to define and document the detailed steps required to integrate and/or test the TSC. These procedures document integration/test conditions, prerequisite events, safety criteria, personnel responsibilities, and reporting requirements. Clearly defined pass/fail criteria are specified. The following test procedures will be generated and submitted as part of Phase 2 information:

Operability test procedure Prudency test procedure Pre-qualification test procedure Environmental test procedure Seismic test procedure

Radiation test procedure EMI/RFI and surge withstand test procedure ESD test procedure Class 1E/non-Class 1E isolation test procedure.

A summary test report will be developed to document results of the qualification test program. The test report will describe the specific reason for conducting the tests, together with pertinent background information, as applicable. Following completion of each phase of testing, test report content will be developed to document test conduct and results. A summary test report with the following sections will be generated and submitted as part of Phase 2 information:

EMI/RFI and surge test report ESD test report

Class 1E/non-Class 1E isolation test report.

6.2.1 Proof Testing

The TSC will undergo various acceptance and operability tests prior to the qualification tests to confirm that the TSC operates correctly and to provide baseline data for some of the qualification tests. The proof testing of the TSC will be performed as described in the pre-qualification test procedure. The following tests will be performed:


NuPAC_ED610000-047-P B 103 of 204 01/19/2012


A 352-hour burn-in conducted under ambient conditions will be performed on the NuPAC platform components to detect any early life failures, which would corrupt the qualification test results.

The operability tests are performed at various points in the qualification process to confirm that the TSC operation is satisfactory, and include accuracy measurements, response time measurements, and I/O and communication operability. The operability testing of the TSC will be performed as described in the operability test procedure.

The prudency tests exercise the TSC to verify its ability to perform under highly dynamic conditions, which includes toggling specified inputs and outputs and applying faults and noise interference to various locations in the TSC. The prudency testing of the TSC will be performed as described in the prudency test procedure.

6.2.1.1 Pre-Qualification Testing

Prior to qualification testing, the NuPAC platform components undergo a series of acceptance tests. Acceptance test procedures will be developed for each level of assembly, which includes the Carrier Card, Logic Mezzanine, individual I/O mezzanines, GLM, RTM, chassis, and TSC. These procedures will be representative of the procedures used for acceptance testing during production.

LMGI/SNPAS will also perform design verification testing (DVT) of the GLM and chassis. DVT procedures will be developed to perform the testing of the GLM and chassis as individual assemblies to ensure compliance to functional requirements. As applicable, functional requirements that can be verified at this level will be tested.

In addition, DVT of the TSC will be performed. A DVT procedure will be developed to perform testing of the remainder of the functional requirements that were not tested at the GLM or chassis level. DVT will utilize simulated inputs as required by the TSC to verify performance. The verification philosophy will prove that the communication capabilities, the I/O capabilities, response time, and all other interface connections to external circuitry are operating in accordance with the specifications.

When the DVT is complete, the TSC will continue to the qualification test program.

6.2.2 Temperature and Humidity Testing

The temperature and humidity testing of the TSC will be performed as described in the environmental test procedure and in accordance with Electric Power Research Institute (EPRI) TR-107330 (Reference 6-7). The TSC will be placed in an environmental chamber and operated over the temperature range and cycling time shown in Figure 4-4 of EPRI TR-107330. The test setup will have sufficient length of cabling to allow the test system to be located outside the chamber during the testing. The operability test will be performed on the TSC during the three time periods identified in the figure. The prudency test will be performed at the end of the high temperature, high humidity cycle. The temperature and humidity testing will verify that the NuPAC platform meets its specified environmental conditions of temperature and humidity.

6.2.3 Seismic Withstand Testing

The seismic withstand testing, including resonance search tests, of the TSC will be performed as described in the seismic test procedure and in accordance with USNRC RG 1.100 (Reference 6-8). The test verifies the NuPAC platform will meet its performance requirements during and following the application of a safe shutdown earthquake (SSE) simultaneously applied in three orthogonal directions with levels, as specified in Figure 4-5 of EPRI TR-107330 (Reference 6-7). The test also verifies the NuPAC platform will withstand the SSE vibration following application of five operating basis earthquakes (OBEs), as specified in Figure 4-5 of EPRI TR-107330. The TSC will be installed into a fixture that will not amplify or attenuate input excitation. The test system will have sufficient cable length to allow the test system to be located off the seismic table. The operability test will be


NuPAC_ED610000-047-P B 104 of 204 01/19/2012


performed on the TSC before and after the SSE, and a subset of the prudency test will be performed during the SSE.

6.2.4 Radiation Withstand Testing

Radiation withstand testing of the TSC will be performed as described in the radiation test procedure and in accordance with EPRI TR-107330 (Reference 6-7). The total radiation exposure will be at least 1,000 radiation absorbed doses (RADs) of gamma radiation. The TSC will not be operational during the test. An operability test will be performed following test completion to verify radiation exposure did not affect NuPAC platform performance. Any special handling and safety concerns will be addressed in the test procedure.

6.2.5 EMI/RFI Testing

EMI/RFI testing of the TSC will be performed as described in the EMI/RFI test procedure. USNRC RG 1.180 Revision 1 (Reference 9) provides the guidance for the performance of the EMI testing. The test procedure will use MIL-STD-461E (Reference 6-10) methods identified in RG 1.180 Revision 1. The following tests will be performed with levels defined by MIL-STD-461E, including:

CE101 – Conducted Emissions, Low Frequency (30 Hz to 10 kHz) CE102 – Conducted Emissions, High Frequency (10 kHz to 2 MHz) RE101 – Radiated Emissions, Magnetic Field (30 Hz to 100 kHz) RE102 – Radiated Emissions, Electric Field (2 MHz to 1 GHz) CS101 – Conducted Susceptibility, Low Frequency (30 Hz to 150 kHz) CS114 – Conducted Susceptibility, High Frequency (10 kHz to 30 MHz) CS115 – Conducted Susceptibility, Bulk Cable Injection, Impulse Excitation CS116 – Conducted Susceptibility, Damped Sinusoidal Transients (10 kHz to 100 MHz) RS101 – Radiated Susceptibility, Magnetic Fields (30 Hz to 100 kHz) RS103 – Radiated Susceptibility, Electric Fields (30 MHz to 1 GHz).

The objective of EMI/RFI testing is to evaluate the electromagnetic emissions and EMI/RFI susceptibility of the NuPAC platform. EMI/RFI testing will demonstrate that the NuPAC platform will function properly in the projected electromagnetic environment and that the NuPAC platform will not create unacceptable levels of additional electromagnetic noise. If the defined limits are not attained, threshold levels will be identified.

6.2.6 Surge Withstand Testing

Surge withstand testing of the TSC will be performed as described in the surge test procedure and in accordance with EPRI TR-107330 (Reference 6-7), Section 4.6.2, and USNRC RG 1.180 Revision 1 (Reference 6-9), Section 5. The objective of surge withstand testing is to demonstrate the suitability of the NuPAC platform for qualification as a safety-related device with respect to AC power line electrical surge withstand capability.

The following three surge waveforms will be used for surge withstand testing:

Ring wave with 0.5 microsecond rise time, 100 kHz sine wave with continually decaying amplitude Combination wave with 1.2 microsecond rise time and 50 microsecond duration (open circuit voltage) Combination wave with 8-microsecond rise time and 20-microsecond duration (short circuit voltage).

The withstand level will be 3,000 volts peak for each waveform (based on location category B and medium exposure).


NuPAC_ED610000-047-P B 105 of 204 01/19/2012


The surges will be applied to the test locations recommended in EPRI TR-107330 (Reference 6-7), Section 4.6.2, as applicable.

6.2.7 Electrostatic Discharge Testing

Electrostatic discharge (ESD) testing of the TSC will be performed as described in the ESD Test Procedure and in accordance with EPRI TR-107330 (Reference 6-7), Section 6.4.2, to meet the requirements of Section 4.3.8 of that document and EPRI TR-102323 (Reference 6-11). Test points will be based on accessibility during operation. Front and rear panels will be tested, whereas side panels that are not exposed during operation will not. The objective of ESD testing is to demonstrate that subjecting the NuPAC platform to specified level of ESD will not disrupt operation or damage any equipment.

6.2.8 Class 1E to Non-1E Isolation Testing

The Class 1E to non-Class 1E isolation testing of the TSC will be performed as described in the Class 1E to non-Class 1E isolation test procedure and in accordance with EPRI TR-107330 (Reference 6-7), Section 6.3.6, to meet the requirement of Section 4.6.4 of that document, IEEE Standard 384-1992 (Reference 6-12), and USNRC RG 1.75 (Reference 6-13). The objective of Class 1E to non-Class 1E isolation testing is to demonstrate that the NuPAC platform isolation capabilities will maintain independence between Class 1E and non-Class 1E equipment.

A summary of tests and requirements is as follows:

Isolation capability of at least 600 VAC is applied for 30 seconds Isolation capability of at least 250 VDC is applied for 30 seconds Application of the above level to discrete I/O, relay outputs and analog inputs shall not disrupt the operation

of any other module, chassis or backplane Application of the above level to an analog output shall not change any other analog output more than

0.05% or disrupt the operation of any other module, chassis or backplane Redundancy functions shall perform as intended when subjected to specified voltages Application of the above levels to one type of point (input or output) shall not damage any other type

of point The test shall be performed on only a sample of each type of I/O point on the TSC.

6.3 Supporting Data for Analyses

This section describes the following supporting data to establish the basis for future system-level analyses for plant-specific NuPAC-based systems:

Failure analysis Reliability analysis Response time analysis Setpoint analysis.

6.3.1 Supporting Data for Failure Analysis

A failure modes and effects analysis (FMEA) and failure modes, effects, and criticality analysis (FMECA) will be prepared for the NuPAC platform per EPRI TR-107330 (Reference 6-7) and per guidance in IEEE Standard 352-1987 (Reference 6-14).

The FMEA will identify potential NuPAC platform failure modes and categorize the effect of each failure on performance in terms of the fault categories in EPRI TR-107330. The FMEA will group NuPAC platform failure modes by circuit card and by a specific fault associated with a function of that circuit card. Items included in the


NuPAC_ED610000-047-P B 106 of 204 01/19/2012


FMEA will be the Carrier Card, Logic Mezzanine, I/O mezzanines, backplane, power sources, and external loop power supplies. Specific information provided by the NuPAC platform FMEA will include:


NuPAC_ED610000-047-P B 107 of 204 01/19/2012


System component: system or subsystem being analyzed for failure modes Failure mode: description of defect or function loss Failure mechanism: cause of failure Failure category: failure category from definitions in EPRI TR-107330 Effect on I/O: result of failure mode on NuPAC platform inputs or outputs Effect on functionality: result of failure mode on overall NuPAC platform operability Method of Failure Detection: Identifies BIT capability of the NuPAC platform Compensating provisions: provisions for failure mode mitigation.

The likelihood of failure information will be presented in the form of a component-level (electronic components on the circuit card assemblies) FMECA. The component-level FMECA will be performed utilizing the guidance of IEEE Standard 352-1987. Failure rate information from the reliability prediction in conjunction with the fault information from the FMEA will be used to rank the individual failure mode end effect fault categories by probability of occurrence.

The FMEA/FMECA results are to be applied to future system-level failures analyses for plant-specific applications of the NuPAC platform, following the guidance in IEEE Standard 352-1987.

FMEA/FMECAs results will be documented in a report(s) and submitted as part of Phase 2 information.

6.3.2 Supporting Data for Reliability Analysis

A reliability analysis will be prepared for the NuPAC platform in accordance with the guidance contained in IEEE Standard 352-1987 (Reference 6-14).

The reliability analysis will provide NuPAC platform reliability predictions to the circuit card level, based on the random hardware failure rate of its components. The failure rate data may represent prediction, test, or observed field failure data. The reliability predictions will be performed using the parts stress analysis method. Component stress data, thermal data, and quality data will be elements of the reliability prediction and are identified with other component characteristics as the Pi values in the failure rate calculations. The piece part stress level of the electrical components on circuit cards will be calculated and recorded. These stress levels will be used in the reliability prediction to verify stress level compliance with de-rating criteria. The component failure rates will also be applied to the FMECA.

The reliability analysis results are to be applied to future system-level reliability and availability analyses for plant-specific applications of the NuPAC platform, following the guidance in IEEE Standard 352-1987.

The results of the reliability analysis will be documented in a reliability analysis report and submitted as part of the Phase 2 information.

6.3.3 Supporting Data for Response Time Analysis

A response time support document will be prepared for the NuPAC platform to facilitate future system-level response time calculations for its plant-specific applications. LMGI/SNPAS will prepare the response time support document per EPRI TR-107330 (Reference 6-7), Section 4.2.1.A guidance. This approach provides a method for calculating the maximum expected discrete input-to-discrete output and analog input-to-discrete output response time, including affects of serial data communication (for both external and backplane links) for specific NuPAC platform hardware and application-specific programmable logic configurations.

The response time support document will be submitted as part of the Phase 2 information.


NuPAC_ED610000-047-P B 108 of 204 01/19/2012


6.3.4 Supporting Data for Setpoint Analysis

A setpoint analysis support document will be prepared for the NuPAC platform to support future system-level setpoint calculations for plant-specific applications of the NuPAC platform, following the recommended practices of ISA S67.04-1994 (Reference 6-15) as endorsed by USNRC RG 1.105 (Reference 6-16). The setpoint analysis support document will be prepared per the guidance of Section 4.2.4 of EPRI TR-107330 (Reference 6-7) and will provide accuracy, repeatability, drift, and other related data for supported input and output types.

The setpoint analysis support document will be submitted as part of the Phase 2 information.

6.4 Limited Life Components

LMGI/SNPAS designed the NuPAC platform hardware to be installed in a mild environment, which does not require establishing a qualified life for the equipment, since maintenance is possible during and after accidents, based on guidance in IEEE Standard 323-2003 (Reference 6-17).

For NuPAC platform hardware described in Section 3.2, the non-volatile memory is the only identified life-limited component. The non-volatile memory has a limitation on the number of times data can be erased and reprogrammed in memory. However, the minimum number of write cycles is well beyond what would be expected to occur in normal use, based on the types of data stored in that non-volatile memory (e.g., setpoint values). There are no other known life-limited components in the generic NuPAC platform hardware described previously in Section 3.2.

Plant-specific NuPAC-based systems will be examined during development to identify if any life-limited components are introduced in the application-specific hardware. If life-limited components are identified, the operational life will be documented and an appropriate surveillance, testing, and maintenance program established to detect potential degradation.

6.5 Software Tool Evaluation

Section 6 of USNRC RG 1.168 (Reference 6-18) states, “Tools used in the development of safety system software should be handled according to IEEE Standard 7-4.3.2-1993, as endorsed by Revision 1 of Regulatory Guide 1.152.”

LMGI/SNPAS uses a COTS software tool to develop programmable logic for the NuPAC platform FPGAs. The Software Tool Evaluation Plan (Reference 6-19) provides the process for evaluating COTS software tools to ensure requirements of IEEE Standard 7-4.3.2-1993 (Reference 6-20) are met, in addition to those in IEEE Standard 7-4.3.2-2003 (Reference 6-21).

The NuPAC Platform Integrated Product Team (IPT) Lead is responsible for the execution and maintenance of the Software Tool Evaluation Plan. Software tools are identified in the Programmable Logic Development Plan (Reference 6-22). Provisions in the Software Tool Evaluation Plan ensure the programmable logic produced by the tool is subject to software verification and validation (V&V) activities that will detect flaws introduced by the tools. V&V activities include performing code reviews, functional level simulations and code coverage, post place and route simulations and hardware level testing. The plan requires the software tool to be placed under configuration control per the programmable logic configuration management plan (Reference 6-23). The plan also has provisions for evaluating the level of quality assurance the supplier imposed on the development and maintenance of software tool.


NuPAC_ED610000-047-P B 109 of 204 01/19/2012


6.6 References


6-2 NuPAC Document No. NuPAC_TEDP610000-001, Rev. A, “NuPAC Test Equipment Development Plan,” LMGI/SNPAS

6-3 NuPAC Document No. NuPAC_SDP610820-001, Rev. A, “NuPAC Test Equipment Software Development Plan,” LMGI/SNPAS


6-5 NuPAC Document No. NuPAC_CMP610000-001, Rev. A, “Configuration Management Plan,” LMGI/SNPAS

6-6 NuPAC Document No. NuPAC_MTP610000-001, Rev. A, “NuPAC Master Test Plan” LMGI/SNPAS


6-8 USNRC RG 1.100, Rev. 3, “Seismic Qualification of Electric and Mechanical Equipment for Nuclear Power Plants,” September 2009


6-10 MIL-STD-461E, “Requirements for the Control of Electromagnetic Interference Characteristics of Subsystems and Equipment,” US Department of Defense, August 1999

6-11 EPRI TR-102323, Rev. 2, “Guidelines for Electromagnetic Interference Testing in Power Plants,” Electric Power Research Institute, September 1994

6-12 IEEE Standard 384-1992, “Standard Criteria for Independence of Class 1E Equipment and Circuits,” Institute of Electrical and Electronics Engineers

6-13 USNRC RG 1.75, Rev. 3, “Physical Independence of Electric Systems,” February 2005

6-14 IEEE Standard 352-1987, “IEEE Guide for General Principles of Reliability Analysis of Nuclear Power Generating Station Safety Systems,” Institute of Electrical and Electronics Engineers

6-15 ISA S67.04-1994, “Setpoints for Nuclear Safety-Related Instrumentation," Instrument Society of America


NuPAC_ED610000-047-P B 110 of 204 01/19/2012


6-16 USNRC RG 1.105, Rev. 3, “Setpoints for Safety-Related Instrumentation,” December 1999

6-17 IEEE Standard 323-2003, “IEEE Standard for Qualifying Class 1E Equipment for Nuclear Power Generating Stations,” Institute of Electrical and Electronics Engineers


6-19 NuPAC Document No. NuPAC_PLDP610000-005, Rev. -, “Software Tool Evaluation Plan,” LMGI/SNPAS

6-20 IEEE Standard 7-4.3.2-1993, “IEEE Standard Criteria for Digital Computers in Safety Systems of Nuclear Power Generating Stations,” Institute of Electrical and Electronics Engineers


6-22 NuPAC Document No. NuPAC_PLDP610000-001, Rev. -, “NuPAC Programmable Logic Development Plan,” LMGI/SNPAS

6-23 NuPAC Document No. NuPAC_PLCMP610000-001, Rev. -, “NuPAC Programmable Logic Configuration Management Plan,” LMGI/SNPAS


NuPAC_ED610000-047-P B 111 of 204 01/19/2012


7.0 DIVERSITY AND DEFENSE-IN-DEPTH (D3)

7.1 Overview

Digital I&C systems can be subject to software, firmware, or programmed logic common cause failures (CCFs) which could render an entire system inoperable. CCFs become of particular interest for a digital I&C system designed to perform in nuclear safety-related applications like a Reactor Protection System (RPS). While the USNRC considers CCFs in digital systems to be beyond design basis, the digital RPS applications should be protected against CCFs. Diversity is a principle that ensures digital I&C systems are protected against postulated CCFs, specifically in portions of a digital I&C system that are not fully testable such as the software, firmware, or programmable logic. Defense-in-depth is a principle that ensures multiple layers of I&C systems exist to provide protection against a wide spectrum of anticipated operational occurrences and postulated accidents, both design basis and beyond design basis.

With limited exceptions, meeting the current regulatory guidance on D3 in safety-related I&C systems and replacing existing analog systems with modern digital systems requires installation of a Diverse Actuation System (DAS) that is separate from the I&C platform (or platforms) used by the RPS. If desired by a nuclear power plant, regulatory guidance allows the option of using a single digital safety-related I&C platform for the RPS without the need for a separate DAS, provided sufficient diversity can be shown to exist within that I&C platform. The goal of this section is to demonstrate how a NuPAC-based safety-related I&C system could be developed for a plant-specific application with sufficient diversity so that a separate DAS would not be required.

7.2 Background

The following regulatory documents provide the current USNRC position on the application of D3 to digital safety-related I&C systems:

NUREG 0800 Section 7.8, “Diverse Instrumentation and Control Systems” (Reference 7-1) Branch Technical Position (BTP) 7-19, “Guidance for Evaluation of Diversity and Defense-in-Depth in

Digital Computer-based Instrumentation and Control Systems” (Reference 7-2) DI&C-ISG-02, “Task Working Group #2: Diversity and Defense-in-Depth Issues” (Reference 7-3) DI&C-ISG-06, “Task Working Group #6: Licensing Process” (Reference 7-4) NUREG/CR-6303, “Method for Performing Diversity and Defense-in-Depth Analyses of Reactor

Protection Systems” (Reference 7-5) NUREG/CR-7007, “Diversity Strategies for Nuclear Power Plant Instrumentation and Control Systems”

(Reference 7-6) SECY-93-087, “Policy, Technical, and Licensing Issues Pertaining to Evolutionary and Advanced Light-

Water Reactor (ALWR) Designs” (Reference 7-7).

The guidance documents listed above are tailored to a D3 assessment performed for a plant-specific safety-related I&C system, so much of the guidance is not applicable to a generic qualification process. The diversity that can be designed into the NuPAC platform does not make assumptions regarding D3 strategies used for a plant-specific application. The following two sections discuss the application of the guidance specified in the above documents to defense-in-depth and diversity for a generic NuPAC platform.

7.2.1 Defense-in-Depth

The design principle of defense-in-depth is applied to safety-related I&C systems through the concept of echelons of defense. NUREG/CR-6303 defines four I&C echelons of defense: control system, Reactor Trip System (RTS), Engineered Safety Features Actuation System (ESFAS), and monitoring and indicator system. These four echelons are typically thought of as providing concentric barriers of protection.


NuPAC_ED610000-047-P B 112 of 204 01/19/2012


The current USNRC position on the realization of RTS and ESFAS echelons of defense, as stated in BTP 7-19 and DI&C-ISG-02, is that a RTS and an ESFAS do not need to be independent or diverse from each other; specifically, RTS and ESFAS echelons may be combined into a single digital I&C RPS platform. However, regardless of how RTS and ESFAS echelons are realized, each echelon must have sufficient diversity to ensure protection against a postulated programmable logic CCF, as discussed in Section 7.2.2.

The implementation of diversity in I&C echelons of defense is based on a plant-specific application. For example, a nuclear power plant (NPP) could use the NuPAC platform for the RTS and a completely separate platform for the ESFAS. Alternatively, a single NuPAC platform could be used for the RPS at a NPP, implementing both the RTS and ESFAS safety functions. For the latter example, the RTS cabinets and equipment would likely be independent from the ESFAS cabinets and equipment with the exception of any data communication necessary to exchange between the two echelons of defense.

The plant-specific realization of different I&C echelons of defense using the NuPAC platform is beyond the scope of this LTR. The diversity that could be provided within the NuPAC platform for a plant-specific application is sufficient to protect that echelon of defense from programmable logic CCFs whether the NuPAC platform is used for a RTS, an ESFAS, or both.

7.2.2 Diversity

Diversity is needed in safety-related I&C systems at NPPs to protect against postulated programmable logic CCFs. Section 7.8 of NUREG-0800 specifies three diverse I&C systems that are required for NPPs:

An Anticipated Transient Without Scram (ATWS) system that is diverse from the RTS as required per 10 CFR Part 50.62

A set of displays and controls in the main control room for manual system level actuation and control of safety-related equipment as described in SECY-93-087 and Point 4 of BTP 7-19

A DAS provided solely for the purpose of meeting the USNRC position on D3.

An ATWS system and the main control room displays and controls for manual system level actuation must be independent and diverse from the platform (or platforms) that comprise the RPS. These two systems greatly increase the diversity of the overall plant protection system, and are in addition to the diversity that can be designed into the NuPAC platform.

As part of an overall D3 assessment on a safety-related I&C system, NPPs are required to demonstrate that a postulated CCF in the RPS cannot disable a safety function. This demonstration cannot take credit for the ATWS system. Credit can be given to the main control room displays and controls used for manual system level actuation. However, this requires demonstrating that manual operator action can meet the time constraints of the postulated accident, which may be impractical to achieve. If the D3 assessment shows that a postulated CCF can disable a safety function, then a sufficiently diverse means to perform that safety function, or a different safety function that provides at least as much protection, must be provided. The concern that a postulated CCF in a single RPS platform could prevent a necessary protective action from occurring is the reason why the USNRC requires NPPs to provide a DAS as listed above.

BTP 7-19 states, “If sufficient diversity exists in the protection system, then the potential for CCF within the channels can be considered to be appropriately addressed without further action.” An example of a system provided in BTP 7-19 and DI&C-ISG-02 that meets the intent of this statement is a RPS design with two channels that use one type of digital system and two channels that use a sufficiently diverse digital system. In other words, if sufficient diversity could be shown to exist within the NuPAC platform, then a DAS would not be required. Section 7.3 describes how the NuPAC-based system could be developed with sufficient diversity so that a separate DAS would not be required.


NuPAC_ED610000-047-P B 113 of 204 01/19/2012


The USNRC has established some precedence for the amount of diversity required within a digital safety-related I&C design in two different systems: the generic Babcock & Wilcox Nuclear Technology (BWNT) STAR system designed for a RPS, and the plant-specific Main Steam and Feedwater Isolation System (MSFIS) controls developed by CS Innovations for Wolf Creek Generating Station. The key diversity aspects of these two systems are described in Sections 7.2.2.1 and 7.2.2.2.

7.2.2.1 STAR System Diversity

The STAR system developed by BWNT is a microprocessor-based system designed for use as a RPS (RTS, ESFAS, or both) in NPPs. BWNT proposed this diverse system in Topical Report BAW-10191, “STAR Systems Components for Reactor Protection System Digital Upgrades” (Reference 7-8). The USNRC approved the STAR system design by a Safety Evaluation dated August 3, 1995 (Reference 7-9).

The STAR system established sufficient diversity using diverse microprocessors on each STAR module. Each microprocessor uses diverse hardware and software and is functionally independent from the other microprocessor on the module. Each microprocessor is capable of fully implementing all safety functions of that module. The software for each microprocessor is developed using independent design and development teams. The software is developed using the same programming language for each microprocessor but with different compilers.

7.2.2.2 Wolf Creek MSFIS Diversity

The Wolf Creek Generating Station MSFIS upgrade consists of an FPGA-based system that is used to provide closing signals to individual valves to isolate one or more steam generators as part of the plant’s safety system response. The USNRC issued a license amendment for the Wolf Creek MSFIS upgrade on March 31, 2009 (Reference 7-10). The safety evaluation performed by the USNRC as part of the license amendment process emphasized that the amount of diversity required by this plant-specific safety-related I&C system does not necessarily apply to a safety-related I&C system used for a RPS because the Wolf Creek MSFIS is not a full trip or actuation system, and the safety functions required for the system are fairly simple and easy to verify.

Diversity is established in the Wolf Creek MSFIS design by using two diverse cores within a single FPGA. The logic developed for each core is sufficiently diverse and uses a different set of software tools for design and testing. A common verification and validation team provides oversight to ensure the FPGA logic designs are sufficiently different.

7.3 NuPAC Platform Diversity Approach

As mentioned previously, regulatory guidance allows the option of using a single digital safety-related I&C platform for a RPS without the need for a separate DAS, provided sufficient diversity can be shown to exist within that I&C platform. This section discusses how the NuPAC platform could be developed with sufficient diversity so that a separate DAS would not be required, if desired for the plant-specific application. The methodology used to demonstrate how the NuPAC platform could be developed with sufficient diversity consists of the following three processes:

1) Determining which components within the NuPAC platform need to be diverse (Section 7.3.1) 2) Specifying how diversity of those components would be achieved (Section 7.3.2) 3) Demonstrating that the amount of diversity within the NuPAC platform would be sufficient

(Section 7.3.3).


NuPAC_ED610000-047-P B 114 of 204 01/19/2012


7.3.1 Scope of Diversity

NPPs perform a D3 assessment on their safety-related I&C systems to determine what CCFs must be postulated, and to determine whether or not any protective actions can be disabled by those postulated CCFs. Adherence to regulatory guidance and industry standards that promote design principles—such as independence, separation, and isolation—can eliminate CCFs that are due to the system hardware architecture. Hardware failures are not typically considered as CCFs because the potential for hardware CCFs can be reduced to an acceptable minimum through proper choice of components, qualification, testing, surveillance, and maintenance. The NuPAC platform is developed under an approved 10 CFR Part 50 Appendix B program, which ensures a high-quality development process that adheres to the regulatory guidance and industry standards for safety-related systems. Therefore, the potential for CCFs do not need to be considered for the hardware architecture or the hardware itself.

For programmable logic CCFs, the USNRC states in BTP 7-19 that “…while the NRC considers (software) CCF in digital systems to be beyond design basis, digital safety systems should be protected against the effects of CCF.” The primary reason for this position taken by the USNRC is that software is not 100% testable, and therefore latent faults likely exist in the software even when developed under a high quality software Life Cycle process. LMGI/SNPAS concludes that, like software, programmed logic in FPGAs can also have inherent design errors that could lead to a programmed logic CCF.

BTP 7-19 states that the USNRC’s position on software CCFs applies to programmable logic CCFs as well. The current version of IEEE Standard 7-4.3.2 (Reference 7-11) concludes that programmed logic shall be considered along with software and firmware, since the hardware languages used to describe programmed logic can also contain design errors that could result in CCF. For FPGA-based systems, this includes both programmable logic and the FPGA in which the logic is embedded. Although FPGA-based digital I&C systems are significantly more testable than microprocessor-based systems, no feasible amount of FPGA logic testing can rule out the possibility of a programmable logic CCF. Therefore, a CCF must be assumed to exist in either the programmable logic or the FPGA that the logic resides in. This means diversity within the NuPAC platform must account for postulated CCFs in the FPGA logic and the FPGA hardware (device itself), and sufficient diversity must be demonstrated within the FPGA programmable logic. In other words, sufficient diversity must be demonstrated to exist between different Generic Logic Module (GLM) Logic Mezzanines in order to show sufficient diversity within the NuPAC platform.

If a diverse NuPAC-based system is required, two variants of the Logic Mezzanines, an alpha variant and a bravo variant, could be developed as shown in Figure 7.3.1-1. These two variants of the Logic Mezzanines are the cornerstone of the diversity that could be designed into a NuPAC-based system. The alpha and bravo variants of the Logic Mezzanines would be placed on separate GLMs to make two sufficiently diverse variants of the GLMs. As stated previously, it is not necessary to change the hardware architecture or components of the GLM, since the quality program the hardware is developed under removes the need to consider a CCF from the hardware design excluding the FPGAs. Figure 7.3.1-2 shows an alpha variant and a bravo variant of the GLM that can be used to provide diversity within the NuPAC platform.


NuPAC_ED610000-047-P B 115 of 204 01/19/2012


Figure 7.3.1-1. Diverse Logic Mezzanines


NuPAC_ED610000-047-P B 116 of 204 01/19/2012


Figure 7.3.1-2. Diverse Generic Logic Modules


NuPAC_ED610000-047-P B 117 of 204 01/19/2012


7.3.2 Methodology for Achieving Diversity

Much of the USNRC guidance regarding methods to achieve diversity in safety-related I&C systems is provided in NUREG/CR-6303 and NUREG/CR-7007. NUREG/CR-6303 defines different diversity attributes in a design that can be implemented to achieve a diverse system. NUREG/CR-7007 defines a metric for the amount of diversity that is required to be considered sufficient by comparing different diversity schemes among various nuclear and non-nuclear industries that require highly reliable I&C systems.

NUREG/CR-7007 provides seven categories of diversity:

1) Design diversity 2) Life cycle (human) diversity 3) Equipment manufacturer diversity 4) Logic processing equipment diversity 5) Logic (software) diversity 6) Functional diversity 7) Signal diversity.

These diversity categories were originally defined in NUREG/CR-6303, along with a detailed methodology for how to implement specific attributes from each diversity category. It should be noted that NUREG/CR-6303 only had six diversity categories because equipment manufacturer diversity and logic processing equipment diversity were presented as a single diversity category referred to as equipment diversity. NUREG/CR-7007 provides additional information with regards to the different diversity attributes associated with each diversity attribute.

The following sections describe the methodology that will be used for the NuPAC platform to achieve sufficient diversity between the alpha variant GLM and the bravo variant GLM using attributes from each of the seven categories listed above.

7.3.2.1 Design Diversity

Design diversity establishes the overall diversity strategy as defined in NUREG/CR 7007 and is based on the diversity of the technology being used. Strategy A is different technologies such as analog vs. digital; Strategy B is different approaches within the same technology such as microprocessor vs. FPGA; Strategy C is different architectures within the same technology such as two different FPGA designs or two different microprocessor designs. Design diversity Strategy C will be implemented in the NuPAC platform, if desired for a plant-specific application, by using different types of FPGAs: the standard Flash type FPGAs for one variant and alternate SRAM type FPGAs for the other variant. The Strategy C methodology has the lowest diversity rating of the three strategies; therefore, justification for why the Strategy C diversity methodology provides sufficient diversity for the NuPAC platform is provided in Section 7.3.3.

7.3.2.2 Life Cycle (Human) Diversity

Life Cycle diversity is probably the single most important aspect to establishing sufficient diversity in the NuPAC platform. Life Cycle diversity, referred to as human diversity in NUREG/CR-6303, accounts for the profound effect that people can have on the design, development, installation, operation, and maintenance of safety-related systems. Life Cycle diversity will be achieved using diverse and independent design, development, implementation, and test teams for the programmable logic. A graphical representation of the programmable logic Life Cycle diversity is shown in Figure 7.3.2.2-1.


NuPAC_ED610000-047-P B 118 of 204 01/19/2012


Figure 7.3.2.2-1. Life Cycle (Human) Diversity

A single QA effort is necessary because there is a single QA program under which all work for the NuPAC platform is performed. A single system safety effort working within the diverse design teams is necessary to ensure differences in design are evaluated similarly for safety and that critical safety concerns found in one design do not impact and are evaluated for the other design. A single Independent Verification and Validation (I-V&V) team is necessary to ensure differences in design are understood and to act as judge of both designs to ensure that the two teams do not inadvertently choose the same solution (i.e., use common algorithms). The degree of independence between the two design teams and the I-V&V team shall be consistent with the financial, managerial, and technical independence defined in IEEE Standard 1012 (Reference 7-12).

Four Life Cycle diversity attributes are provided in NUREG/CR-7007 and are listed in order of decreasing importance on their impact on the overall Life Cycle diversity: different design organizations/companies, different


NuPAC_ED610000-047-P B 119 of 204 01/19/2012


management teams within the same company, different design/development teams, and different implementation/validation teams. The Life Cycle diversity strategy for the NuPAC platform will credit the last two diversity attributes, as described above and shown in Figure 7.3.2.2-1. In addition, the Life Cycle diversity strategy will credit different organizations/companies; since crediting this diversity attribute is not readily apparent, a more detailed discussion is provided in Section 7.3.2.2.1 below.

7.3.2.2.1 Design Organization/Company

In NUREG/CR-7007, five different variants on the Strategy C methodology are provided. All but one of these five variants assumes a different design organization/company because a different equipment manufacturer has also been assumed. For the one Strategy C variant that does not use a different design organization/company, the same equipment manufacturer is assumed with two versions of the same design. The methodology used in NUREG/CR-7007 associates the design organization with the manufacturer; that is, a different equipment manufacturer implies a different design organization.

This association is not as clear with the NuPAC platform, where different FPGA manufacturers will provide different types of FPGAs and a different suite of software-based FPGA design tools, but the programmable logic for both types of FPGAs is still developed under an LMGI/SNPAS organization. As stated in NUREG/CR-7007, “The purpose of this Life Cycle diversity usage is to avoid the introduction of systematic faults during design and implementation of the diverse systems due to common mistakes or misunderstandings by shared human resources.” Providing sufficient Life Cycle diversity effectively mitigates any shared human resources in the Life Cycle design process.

The development of the FPGA logic consists of three distinct components to be developed: 1) the FPGA hardware, 2) the software-based FPGA design tools, and 3) the programmable logic code. Shared human resources used with the development of any of these three components could lead to a CCF in the two designs. The use of different FPGA manufacturers, as described in Section 7.3.2.3, eliminates shared human resources as a possible source of CCFs with the FPGA hardware and with the software-based FPGA design tools. In addition, the use of different design, development, implementation, and test teams eliminates the possibility of shared human resources as a possible source of CCFs with the programmable logic code. Therefore, the intent of the diversity attribute “different design organizations/companies” is met with the NuPAC platform design by using different FPGA manufacturers with different software-based FPGA design tools implementing different programmable logic code.

7.3.2.3 Equipment Manufacturer Diversity

To help achieve sufficient diversity within the NuPAC platform, FPGAs from the two different GLM variants would come from different manufacturers using fundamentally different FPGA designs (i.e., one FPGA will be based on Flash technology while the second FPGA will be based on SRAM technology). This diversity attribute provides the most diversity that can be achieved from the equipment manufacturer diversity category. Moreover, diverse software-based FPGA design tools would be utilized which, for FPGA designs, provides a significant amount of diversity.

The diversity obtained from using different suites of software-based FPGA design tools is not explicitly captured in NUREG/CR-7007, but this diversity is critical to provide sufficient diversity in FPGA logic. Some credit is given to the NuPAC platform for diversity of software tools by assuming different design organizations/companies, as described previously in Section 7.3.2.2.

7.3.2.4 Logic Processing Equipment Diversity

Different logic processing architectures for the variants of the two FPGAs would be used in the NuPAC platform. This diversity attribute provides the greatest diversity from the Logic Processing Equipment diversity


NuPAC_ED610000-047-P B 120 of 204 01/19/2012


category. Additional diversity could be obtained by using different circuit board designs or using different data flow architectures such as different bus structures. There will be inherent differences in the printed circuit boards since the FPGAs will have inherently different pin-outs, but will otherwise be common between the alpha and bravo variants. However, these two additional diversity attributes are based on hardware diversity which, as discussed previously in Section 7.3.1, is not required to demonstrate sufficient diversity within the NuPAC platform. The hardware architecture and components are developed under a high-quality development process under and approved 10 CFR Part 50 Appendix B program. Therefore, CCFs due to hardware faults do not have to be assumed.

7.3.2.5 Logic (Software) Diversity

Programmable logic diversity is a key aspect of developing sufficient diversity within the NuPAC platform. Programmable logic diversity, referred to as software diversity in NUREG/CR-6303, is defined as the use of different programs designed and implemented by different development groups with different key personnel to accomplish the same safety goals. As stated in Section 7.3.2.2, different design and development groups would be used to develop the programmable logic for the two FPGA variants, with a common I-V&V team that is responsible for ensuring that both teams do not inadvertently choose common algorithms.

The programmable logic diversity within the NuPAC platform credits diversity in three of the four logic diversity attributes listed in NUREG/CR-7007: different algorithms, logic, and program architecture; different timing and order of execution; different runtime environment. The fourth diversity attribute listed in NUREG/CR-7007, different functional representations, will not be part of the logic diversity of the NuPAC platform for reasons discussed in Section 7.3.2.5.2. In addition, the “different runtime environment” diversity attribute does not readily apply to FPGAs so the reason for crediting this attribute as part of the diversity of the NuPAC platform is discussed in more detail in Section 7.3.2.5.1.

7.3.2.5.1 Runtime Environment

A key advantage to using FPGAs is that no operating system is needed in the runtime environment. The FPGA hardwired logic is the runtime environment, so diversity in the FPGA logic implies diversity in the runtime environment. Moreover, if a specific technology does not use a design feature that has been previously classified as a potential diversity attribute, then the lack of that design feature should not be treated as a lack of diversity; else, the methodology used to show sufficient diversity would not be amenable to comparing different technologies.

7.3.2.5.2 Functional Representation

For microprocessor-based systems, the “different functional representations” diversity attribute is achieved by using different computer languages. However, although the amount of diversity provided from this diversity attribute is small, it is assigned the lowest weighted score when calculating a diversity rating. NUREG/CR-6303 states, “The reason that computer language…is not listed among the more effective criteria, is that modern languages are converging, offer a common set of features, and can often be intermixed at the subroutine level. Computer language, therefore, has little effect on algorithms, logic, architecture, timing, or operating system services.”

There are only two common languages for programming FPGAs, Verilog, and Very High-Speed Integrated Circuit Hardware Description Language (VHDL), and the differences between the two languages are not extreme. Therefore, there is little diversity benefit gained from programming one FPGA variant with VHDL and the other FPGA variant with Verilog. The first FPGA variant for the NuPAC platform will be programmed with VHDL, while the second variant may be programmed with VHDL or Verilog.


NuPAC_ED610000-047-P B 121 of 204 01/19/2012


It should be noted, however, that the “different timing and order of execution” diversity attribute is not credited in NUREG/CR-7007 as part of the Strategy C diversity method. This diversity attribute has a larger weight than the “different functional representation” diversity attribute. Therefore, crediting the former diversity attribute while not crediting the latter diversity attribute will actually increase the overall diversity rating of the NuPAC platform as compared to the nominal Strategy C diversity method. Section 7.3.3 has further discussion.

7.3.2.6 Functional Diversity

Two systems are functionally diverse if they perform different physical functions. Functional diversity is plant-specific and therefore no credit is given to this type of diversity in determining the diversity that could be developed within the NuPAC platform. Functional diversity can significantly improve overall RPS diversity.

7.3.2.7 Signal Diversity

Signal diversity is defined as the use of different sensed parameters to initiate a protective action. Signal diversity, like functional diversity, is plant-specific and therefore no credit is given to signal diversity in determining the diversity that could be developed within the NuPAC platform. As with functional diversity, signal diversity can be used to significantly improve overall RPS diversity.

7.3.3 Demonstration of Sufficient Diversity

NuPAC-based safety-related I&C systems could be developed with an overall diversity rating of 1.00 using the methodology from NUREG/CR-7007 and the diversity attributes described in Section 7.3.2. This diversity rating demonstrates that sufficient diversity, based on current USNRC guidance, could be developed within the NuPAC platform. The only assumption made in this assessment is that plant-specific functional and signal diversity attributes are consistent with the Strategy C diversity method presented in NUREG/CR-7007. Section 7.3.3.1 provides further discussion.

The diversity rating determined for a NuPAC-based system likely would have the same diversity rating as the microprocessor-based BWNT STAR system discussed in Section 7.2.2.1 because the STAR system also uses a Strategy C diversity method. The diversity that could be designed into the STAR system was accepted by the NRC as sufficient diversity for use in a RPS without the need for a DAS. Consequently, the diversity described herein for the NuPAC system should also be sufficient for a RPS application without the need for a DAS. Moreover, FPGAs are inherently more testable when compared to microprocessors, so the use of FPGAs in safety-related applications significantly reduces the probability of having a latent fault in the logic used for those applications. Section 7.3.3.2 provides further discussion.

7.3.3.1 Diversity Rating for a Generic NuPAC Platform

The methodology outlined in NUREG/CR-7007 is based on a plant-specific application, which requires knowledge of the functional and signal diversities being used to calculate an overall diversity rating score. Table 6.3 of NUREG/CR-7007 shows that every variant of the Strategy C method uses the same functional and signal diversity attributes. For calculating a base diversity rating for the generic NuPAC platform the functional and signal diversity attributes listed in Table 6.3 of NUREG/CR-7007 are assumed the same. The assumptions made concerning functional and signal diversity are not part of establishing diversity within the generic NuPAC platform; they are only necessary to facilitate comparisons between a generic design and a plant-specific design. In addition to functional and signal diversity, a plant-specific design would take credit in its overall diversity rating for other diverse systems such as ATWS, as discussed in Section 7.2.2, which would significantly increase the plant’s overall protection system diversity rating.

As discussed in Section 6.3.3.4 of NUREG/CR-7007, the Strategy C4 variant is the most closely aligned diversity strategy to what could be used by the NuPAC platform based on the diversity attribute discussions from


NuPAC_ED610000-047-P B 122 of 204 01/19/2012


Section 7.3.2 above. The Strategy C4 variant does not assume any diversity in the overall circuit board design, which would be the case for the NuPAC platform as discussed in Section 7.3.2.4. However, one improvement for the diversity of the NuPAC platform is the programmable logic (software) diversity attributes discussed in Section 7.3.2.5.

Table 7.3.3.1-1 shows the overall diversity rating for a NuPAC platform designed with diverse GLMs using the methodology presented in NUREG/CR-7007. The overall diversity rating for this generic NuPAC platform design is 1.00. This is larger than the average Strategy C diversity rating listed in Figure A.1 of NUREG/CR-7007, which is just under 1.00. A diversity rating of 1.00 for the NuPAC platform means that the system could be developed with an average amount of diversity when compared to similar I&C systems. Moreover, as stated above, this diversity score does not include the additional diversity provided from an ATWS system and the manual system level actuation, both of which are required in NPPs as discussed in Section 7.2.2. A diversity rating of 1.00 indicates NuPAC-based systems could be developed with sufficient diversity so that a separate DAS would not be required for a RPS.

Table 7.3.3.1-1. Diversity Rating for the NuPAC Platform1

Diversity Attribute Rank DCE Wt

NuPAC Platform INT INH Score

Design Diversity Different technologies 1 0.500

0.000

Different approaches within a technology 2 0.333

0.000 Different architectures 3 0.167 x

0.167

DAE Wt. and Subtotal

1.000

0.167 0.167 Equipment Manufacturer Diversity Different manufacturers of fundamentally different equipment designs 1 0.400 x

0.400

Same manufacturer of fundamentally different equipment designs 2 0.300

0.000 Different manufacturers of same equipment design 3 0.200

0.000

Same manufacturer of different versions of same equipment design 4 0.100

0.000 DAE Wt. and Subtotal

0.929

0.372 0.400

Logic Processing Equipment Diversity Different logic processing equipment architectures 1 0.400 x

0.400

Different logic processing versions in same equipment architecture 2 0.300

0.000 Different component integration architectures 3 0.200

0.000

Different data flow architectures 4 0.100


0.500

0.200 0.400

Functional Diversity Different underlying mechanisms to accomplish safety function 1 0.500

0.000

Different purpose, function, control logic, or actuation means of same mechanism 2 0.333 x

0.333

Different response time scale 3 0.167


0.548

0.183 0.333

Life Cycle (Human) Diversity

Different design organizations/companies 1 0.400 x

0.400

Different management teams within the same company 2 0.300

0.000 Different designers, engineers, and/or programmers 3 0.200 x

0.200

Different testers, installers, or certification personnel 4 0.100 x


0.643

0.450 0.700


NuPAC_ED610000-047-P B 123 of 204 01/19/2012


Diversity Attribute Rank DCE Wt

NuPAC Platform INT INH Score

Signal Diversity Different reactor or process parameters sensed by different physical effects 1 0.500 x

0.500

Different reactor or process parameters sensed by the same physical effect 2 0.333 x

0.333 Same process parameter sensed by different redundant set of similar sensors 3 0.167 x

0.167


0.833

0.833 1.000 Logic (Software) Diversity2

Different algorithms, logic, and logic architecture 1 0.400 x

0.400 Different timing or order of execution 2 0.300 x

0.300

Different runtime environments 3 0.200 x

0.200 Different functional representations 4 0.100

0.000


0.607

0.546 0.900 Score (x100) 275

Normalized Score 1.00

Notes: 1 Abbreviations include Diversity Attribute Effectiveness (DAE), Diversity Criterion Effectiveness (DCE), Intentional Use (INT), and Inherent Use (INH). See NUREG/CR-7007 for further detail. 2 As discussed in Section7.3.2.5, the “different timing and order of execution” diversity attribute would be credited and the “different functional representation” diversity attribute would not be credited by the NuPAC platform diversity method. This is opposite from the diversity attributes credited in NUREG/CR-7007 as part of the Strategy C diversity method. The former diversity attribute has a larger weight than the latter diversity attribute for reasons discussed in Section 7.3.2.5. Therefore, crediting the former diversity attribute while not crediting the latter diversity attribute increases the overall diversity rating of the NuPAC platform as compared to the nominal Strategy C diversity method presented in NUREG/CR-7007.

7.3.3.2 Comparison to Other Safety I&C System Diversity Designs

The Wolf Creek MSFIS (discussed in Section 7.2.2.2) and the NuPAC platform both use FPGAs in their design and have similar diversity in the programmable logic development such as different software-based FPGA design tools, different design teams, and a common V&V team. However, the diversity that could be provided within the NuPAC platform is significantly greater than the Wolf Creek MSFIS using different FPGA manufacturers and technologies, as described in Section 7.3. This additional diversity would be necessary to ensure the NuPAC platform is suitable for use as a RPS.

The diversity provided in the BWNT STAR system (discussed in Section 7.2.2.1) is similar to the diversity that could be provided for the NuPAC platform with two key differences. These are: 1) in lieu of microprocessors, the NuPAC platform uses FPGAs, which are inherently more testable; and 2) each diverse FPGA that could be developed for the NuPAC platform would reside on a separate GLM. Therefore, there would be less sharing of hardware as compared to the STAR system where diverse microprocessors are shared on the same module.

The use of FPGAs in digital safety-related I&C systems reduces the likelihood of latent faults that can lead to CCFs since 1) FPGAs do not use a microprocessor, operating system, or executable software; and 2) FPGAs are more simple and deterministic. There is complexity in the designing of FPGAs, specifically with the software-based tools used in the FPGA design process, but the final combination of the FPGA with the programmed logic is highly testable when compared to a microprocessor-based system and does not consist of any software or operating system. This means the chance of having a latent fault that is not detected during the programmable logic development process is significantly lower. However, based on the guidance of BTP 7-19, either a system shall be 100% testable or it must be shown to be sufficiently diverse. The methodology provided in NUREG/CR-7007 provides a demonstration of sufficient diversity, but this methodology does not take into


NuPAC_ED610000-047-P B 124 of 204 01/19/2012


consideration the inherent testability of one design over another. That is, an FPGA-based design and a microprocessor-based design would have the same Strategy C diversity rating if they took credit for the same design attributes, even though the FPGA-based design is a significantly more testable design.

Therefore, sufficient diversity should be defined by not only quantifying the amount of diversity relative to other safety-related systems, but also by considering the testability of the design relative to those same safety-related systems. For the NuPAC platform, the combination of 1) using inherently more testable FPGAs in lieu of microprocessors and 2) providing diversity of FPGA designs makes the platform sufficiently diverse for a safety-related I&C system at a NPP. In other words, the Strategy C diversity method used to establish diversity for the NuPAC platform is acceptable because the NuPAC platform does not need as much diversity as a microprocessor-based system due to the inherent testability of FPGA designs.

7.4 Examples of Diversity Applications

This section provides some common examples of how the NuPAC platform would be expected to be implemented in a NPP as a RTS, ESFAS, or both (in a single RPS) and how this implementation would affect the different diversity strategies for the NuPAC platform.

7.4.1 NuPAC Platform with a Diverse Actuation System

The NuPAC platform could be used for a safety-related I&C system with no diversity within the NuPAC platform, provided a separate DAS is also installed to meet the USNRC’s requirements for diversity. Figure 7.4.1-1 illustrates how this diverse system could be implemented in a typical four division safety-related I&C system. One disadvantage to this configuration, which is not illustrated in Figure 7.4.1-1, is that a priority logic module (PLM) would be required at many interfaces between the safety-related I&C system implemented by the NuPAC platform and the (non-safety related) DAS implemented by some other platform.

Figure 7.4.1-1. NuPAC Platform with Diverse Actuation System

Although this I&C architecture is common and expected to be more easily accepted by the USNRC due to familiarity of design, it does not take advantage of the diversity that can be built into a NuPAC-based system. The


NuPAC_ED610000-047-P B 125 of 204 01/19/2012


advantage of having a non-safety related DAS which is cheaper and may be less difficult to maintain is balanced by the disadvantage of having to install, operate, surveillance test, and maintain multiple platforms.


NuPAC_ED610000-047-P B 126 of 204 01/19/2012


7.4.2 NuPAC Platform without a Diverse Actuation System

As demonstrated in Section 7.3, the NuPAC-based system can be developed with sufficient diversity by providing an alpha variant GLM and a bravo variant GLM. Figure 7.4.2 -1 illustrates two types of diversity schemes that can be achieved by using these two GLM variants: inter-divisional diversity and intra-divisional diversity. A standard four-division system is used to illustrate the difference between the two types of diversity schemes. The following sections discuss the potential advantages and disadvantages of each of these diversity schemes.

Figure 7.4.2-1. NuPAC Platform Diversity Schemes


NuPAC_ED610000-047-P B 127 of 204 01/19/2012


7.4.2.1 Inter-divisional Diversity Scheme

The inter-divisional diversity scheme is achieved by splitting divisions into two types: divisions that use only alpha variant GLMs and divisions that uses only bravo variant GLMs. Figure 7.4.2.1-1 provides an example of a four division safety-related system that uses an inter-divisional diversity scheme.

Some key advantages provided by an inter-divisional diversity scheme with the NuPAC platform include:

This method of diversity is explicitly endorsed by the USNRC in BTP 7-19 and DI&C-ISG-02 as an acceptable diversity design method, provided sufficient diversity can be shown to exist between divisions (see discussion in Section 7.2.2).

Demarcation between the alpha variant components and the bravo variant components is simpler to maintain when compared to intra-divisional diversity.

This design uses a minimum number of GLMs while still achieving sufficient diversity. This design, along with signal diversity, can be used to improve the overall system diversity as discussed in

Section 7.3.2.7.

Some potential disadvantages of using an inter-divisional diversity scheme include:

The four divisions are not all redundant copies of each other, so additional design effort would be required outside the divisions to ensure protection against a postulated programmable logic CCF (e.g., when designing 2 out of 3 logic to generate a trip or actuate signal);

An odd number of divisions may be difficult to implement with this design and may require an extra division or additional logic within a division.

Figure 7.4.2.1-1. NuPAC Platform with Inter-divisional Diversity


NuPAC_ED610000-047-P B 128 of 204 01/19/2012


7.4.2.2 Intra-divisional Diversity Scheme

The intra-divisional diversity scheme is achieved by providing all logic within a division on fully redundant alpha variant GLMs and bravo variant GLMs within a division. Since each safety function is replicated within the division, a programmable logic CCF of one GLM variant would not prevent the division from accomplishing its safety functions. Figure 7.4.2.2-1 shows an example of a four division safety-related system that uses an intra-divisional diversity scheme from the NuPAC platform.

Some key advantages provided by an intra-divisional diversity scheme with the NuPAC platform include:

Surveillance testing of the I&C components could be performed online without bypass (i.e., taking a division out of service) of a safety function.

A postulated programmable logic CCF would not remove any of the divisions from service. The diversity would be simple to implement regardless of whether there were an even or odd number of

divisions.

Some potential disadvantages to using an intra-divisional diversity scheme include:

Demarcation between the alpha variant components and the bravo variant components would be more difficult to maintain.

This design would potentially use twice the number of GLMs per division as compared to the inter-divisional diversity scheme.

A final 2-out-of-2 voting scheme, which reduces to 1-out-of-1 with one variant out of service, would be needed within each division for each pair of GLMs to ensure a postulated programmable logic CCF in one of the GLM variants could not disable the divisional safety function output.

Figure 7.4.2.2-1. NuPAC Platform with Intra-divisional Diversity


NuPAC_ED610000-047-P B 129 of 204 01/19/2012


7.4.2.3 Choosing a Diversity Scheme

The choice of inter-divisional diversity scheme vs. intra-divisional diversity scheme for the NuPAC platform is, for the most part, a plant-specific decision. For a safety-related I&C system with four divisions, either diversity scheme could be used to provide sufficient diversity, with the advantages and disadvantages described in the previous two sections.

A safety-related I&C system with an odd number of divisions (or trains) would be more complicated to implement depending on which type of diversity scheme was chosen for the NuPAC platform. Consider, for example, a three train ESFAS. Three possible diversity schemes, in order of architectural simplicity, are:

1) Intra-divisional diversity only (AB). Architecture consists of three divisions, each with intra divisional diversity: Division 1AB is dedicated to Train 1, Division 2AB is dedicated to Train 2, and Division 3AB is dedicated to Train 3. No special voting scheme would be needed.

2) Combined intra-divisional and inter-divisional diversity (A, B, and AB). Architecture consists of three divisions, two with inter-divisional diversity and one with intra-divisional diversity: Division 1A is dedicated to Train 1, Division 2B is dedicated to Train 2, and Division 3AB is dedicated to Train 3. No special voting scheme would be needed.

3) Inter-divisional diversity only (A and B). Architecture consists of four divisions, each with inter divisional diversity: Division 1A is dedicated to Train 1, Division 2B is dedicated to Train 2, and Divisions 3A and 4B are dedicated to Train 3. A special voting scheme would be required so that failure of either Division 3A or Division 4B would not disable the safety functions of Train 3.

7.5 References

7-1 NUREG 0800 Section 7.8, Rev. 5, “Diverse Instrumentation and Control Systems,” US Nuclear Regulatory Commission, March 2007

7-2 Branch Technical Position (BTP) 7-19, Rev. 6, “Guidance for Evaluation of Diversity and Defense-in-Depth in Digital Computer-based Instrumentation and Control Systems,” US Nuclear Regulatory Commission, March 2010



7-5 NUREG/CR-6303, “Method for Performing Diversity and Defense-in-Depth Analyses of Reactor Protection Systems,” Lawrence Livermore National Laboratory, December 1994

7-6 NUREG/CR-7007, “Diversity Strategies for Nuclear Power Plant Instrumentation and Control Systems,” Oak Ridge National Laboratory, February 2010

7-7 SECY-93-087, “Policy, Technical, and Licensing Issues Pertaining to Evolutionary and Advanced Light-Water Reactor (ALWR) Designs,” US Nuclear Regulatory Commission, July 21, 1993

7-8 BWNT Topical Report BAW-10191, “STAR Systems Components for Reactor Protection System Digital Upgrades,” B&W Nuclear Technologies, September 15, 1994


NuPAC_ED610000-047-P B 130 of 204 01/19/2012


7-9 USNRC Safety Evaluation Report, “Safety Evaluation for Topical Report BAW-10191P, “Star System Components for Reactor Protection System Digital Upgrades,” US Nuclear Regulatory Commission, August 3, 1995

7-10 USNRC Letter to Wolf Creek Nuclear Operating Corporation, “Wolf Creek Generating Station – Issuance of Amendment Re: Modification of the Main Steam and Feedwater Isolation System Controls (TAC No. MD4839),” US Nuclear Regulatory Commission, March 31, 2009




NuPAC_ED610000-047-P B 131 of 204 01/19/2012




NuPAC_ED610000-047-P B 132 of 204 01/19/2012


8.0 COMPLIANCE WITH STANDARDS AND INTERIM STAFF GUIDANCE

The suitability of a digital control system platform for use in NPP safety systems is dependent on the quality of platform components; quality of the design process; and aspects of system implementation, such as real time performance, independence, and online testing. The NuPAC platform is being developed and will be qualified and supplied under a 10 CFR 50 Appendix B-compliant quality program. LMGI/SNPAS designed the NuPAC platform in accordance with provisions of:

IEEE Standard 603-1991 (Reference 8-1), “IEEE Standard Criteria for Safety Systems for Nuclear Power Generating Stations”

IEEE Standard 7-4.3.2-2003 (Reference 8-2), “IEEE Standard Criteria for Digital Computers in Safety Systems of Nuclear Power Generating Stations.”

In designing the NuPAC platform, LMGI/SNPAS also followed USNRC Interim Staff Guidance (ISG) as an interpretation of the codes and RGs:

DI&C-ISG-02 (Reference 8-3), ISG on Diversity and Defense-in-Depth Issues DI&C-ISG-04 (Reference 8-4), ISG on Highly Integrated Control Rooms and Digital Communication

Systems.

LMGI/SNPAS also used DI&C-ISG-06 (Reference 8-5), licensing process ISG, when preparing this LTR.

8.1 Compliance with IEEE Standard 603-1991

The NuPAC platform conforms to IEEE Standard 603-1991 (Reference 8-1) as set forth by 10 CFR 50.55a(h) (Reference 8-6) and endorsed in USNRC RG 1.153 (Reference 8-7). Please refer to the IEEE Standard 603-1991 compliance matrix in Appendix B for more detailed data.

8.2 Compliance with IEEE Standard 7-4.3.2-2003

The NuPAC platform conforms to IEEE Standard 7-4.3.2-2003 (Reference 8-2) as endorsed in USNRC RG 1.152 Revision 2 (Reference 8-8). Please refer to the IEEE Standard 7-4.3.2-2003 compliance matrix in Appendix C for more detailed data.

8.3 DI&C-ISG-02, Rev. 2

Diversity and Defense-in-Depth (D3) analysis is a plant-wide evaluation based on overall considerations and general characteristics of the collection of devices—both safety and non-safety—rather than the specifications of any single device in an I&C system suite. The qualification of the NuPAC digital control system platform will provide assurance for a qualified device. With respect to D3, the methodology, as described in Section 7.0, provides an approach, which is sufficient to eliminate the consideration of NuPAC platform common cause failure (CCF). This conclusion is based on the guidance provided in USNRC document DI&C-ISG-02 (Reference 8-3).

8.4 DI&C-ISG-04, Rev. 1

The aspects of USNRC document DI&C-ISG-04 (Reference 8-4) area of interest #1, interdivisional communication, are applicable to the generic NuPAC digital control system platform. The generic NuPAC platform design supports interdivisional communication, described previously in Section 3.4.2. The generic NuPAC digital control system platform and plant-specific NuPAC-based systems will comply with DI&C-ISG-04 guidance regarding interdivisional communication. (Refer to the DI&C-ISG-04 compliance matrix in Appendix D.) Compliance with the other aspects of DI&C-ISG-04, areas of interest #2 and #3, will be addressed as part of future system-level analyses for plant-specific NuPAC-based systems.


NuPAC_ED610000-047-P B 133 of 204 01/19/2012


8.5 DI&C-ISG-06, Rev. 1

This LTR and the supporting documentation submitted by LMGI for the USNRC review of the generic NuPAC digital safety I&C platform are consistent with the guidance, for a Tier 3 review, provided in USNRC document DI&C-ISG-06 (Reference 8-5). Refer to the DI&C-ISG-06 compliance matrix in Appendix E of this LTR.

8.6 References




8-4 DI&C-ISG-04, Rev. 1, “Highly-Integrated Control Rooms – Digital Communication Issues,” U.S. Nuclear Regulatory Commission, March 2009


8-6 10 CFR 50.55a(h), “Codes and Standards, paragraph (h), Protection and safety systems”

8-7 USNRC RG 1.153, Rev. 1, “Criteria for Safety Systems,” June 1996



NuPAC_ED610000-047-P B 134 of 204 01/19/2012


9.0 SECURE DEVELOPMENT AND OPERATIONAL ENVIRONMENT

This section discusses the NuPAC digital control system platform vulnerability assessment and identifies the associated methodology to apply secure development and operational environment controls.

9.1 Vulnerability Assessment

LMGI/SNPAS conducted vulnerability assessments for the NuPAC platform to identify security threats (vulnerabilities), determine acceptable levels of risk, and stimulate action to mitigate identified vulnerabilities. LMGI/SNPAS used 10 CFR 73.54 (Reference 9-1) and USNRC RG 5.71 (Reference 9-2) as basis for this assessment.

LMGI/SNPAS identified portions of the NuPAC platform development and operational environment, which are likely to be considered critical digital assets in a Licensee’s program. LMGI/SNPAS evaluated each critical digital asset to establish and prioritize management of physical, cyber, and personnel security vulnerabilities and risks. The critical asset evaluation included the life cycle processes, facilities, hardware, software, and information necessary to develop, produce, and maintain the NuPAC digital control system platform. LMGI/SNPAS will periodically reevaluate the vulnerability assessment to ensure continued security.

LMGI/SNPAS documented the NuPAC platform vulnerability assessment in a vulnerability assessment report (Reference 9-3). The report presents a generic methodology, which can be applied as a basis for conducting future system-level analyses for plant-specific NuPAC-based systems. Methods used to control or at least mitigate the vulnerabilities are identified in a system security plan (Reference 9-4).

9.2 Secure Development and Operational Environment Controls

LMGI/SNPAS has implemented a system security plan (Reference 9-4) that specifies the security controls for NuPAC platform development and operational environment. The plan was developed in accordance with the guidance contained in USNRC RG 1.152 (Reference 9-5), RG 1.173 (Reference 9-6), IEEE Standard 1074-1995 (Reference 9-7), and the Advisory Committee on Reactor Safeguards (ACRS) letter (Reference 9-8) on cyber security and RG 1.152.

Execution of the system security plan enables the program to achieve high assurance that the NuPAC platform and its critical assets are protected and monitored throughout its life cycle. The plan addresses physical, cyber, and personnel security vulnerabilities at all phases of development from concept through testing. It also describes responsibilities and accountability regarding safeguarding of the NuPAC platform development and operational environment. LMGI/SNPAS will maintain the system security plan to ensure continued security. Recommendations will be made to Licensees regarding appropriate requirements in their security programs to protect the NuPAC-based systems from cyber security threats.

9.3 References

9-1 10 CFR 73.54, “Protection of digital computer and communication systems and networks”

9-2 USNRC RG 5.71, “Cyber Security Programs for Nuclear Facilities”

9-3 NuPAC Document No. NuPAC_ED610000-041, Rev. -, “NuPAC Vulnerability Assessment,” LMGI/SNPAS

9-4 NuPAC Document No. NuPAC_SSP610000-001, Rev. -, “NuPAC System Security Plan,” LMGI/SNPAS


NuPAC_ED610000-047-P B 135 of 204 01/19/2012


9-5 Draft Final RG 1.152, Rev. 3, “Criteria for Digital Computers in Safety Systems of Nuclear Power Plants,” June 2010


9-7 IEEE Standard 1074-1995, “IEEE Standard for Developing Software Life Cycle Processes,” Institute of Electrical and Electronics Engineers

9-8 USNRC Letter from Said Abdel-Khalik, ACRS, to Borchardt, EDO, “Draft Final Revision 3 of Regulatory Guide 1.152, ‘Criteria for Use of Computers in Safety Systems of Nuclear Power Plants”


NuPAC_ED610000-047-P B 136 of 204 01/19/2012


APPENDIX A NuPAC PLATFORM APPLICATION GUIDE


NuPAC_ED610000-047-P B 137 of 204 01/19/2012




NuPAC_ED610000-047-P B 138 of 204 01/19/2012


1.0 INTRODUCTION

This Application Guide provides NuPAC platform as well as plant design and implementation guidelines for applying the LMGI/SNPAS NuPAC platform to facilities regulated by the United States Nuclear Regulatory Commission (USNRC) in systems classified as Safety Related and Important to Safety. The guidance provided in this document is intended to facilitate the use and application of the NuPAC platform. Additional requirements and limitations may apply to a plant-specific NuPAC-based system, based on plant-specific requirements.

Some of the guidance provided in this document is not specific to the NuPAC platform or software tools associated with the NuPAC platform, as some of the guidance is required by any installation of digital equipment in a nuclear facility. As an example, installation practices can create long-term problems, which are typically ascribed to faults and failures in the programmable logic. Correct initial system installation will enhance safe, reliable system operation.

Guidelines are provided for design, licensing, installation, operation, and maintenance of the system. Many of the guidelines in this document are interrelated. As an example, annunciation of alarms from faults and failures within the NuPAC platform have implications in design, operating and maintenance procedures, plant interface, the main control room design, and several other seemingly unrelated topics, including system power supply. Therefore, these guidelines should be considered as a whole, rather than as separate, individual, unrelated pieces.

A summary of the NuPAC platform, architecture, and theory of operation is provided in this LTR, which should be used as a reference by the Licensee.

The qualified equipment for the NuPAC platform includes:

Generic Logic Module (GLM), P/N 610300 Logic Mezzanine for the GLM, P/N 610320

Rear Transition Module (RTM), P/N 610120 Chassis, P/N 610100.

Qualified I/O mezzanine cards for the GLM include:

Serial Communication Mezzanine, P/N 610360 Discrete/Pulse Input Mezzanine, P/N 610340 Discrete Output Mezzanine, P/N 610380

Analog Input Mezzanine, P/N 610330 Thermocouple/RTD Input Mezzanine, P/N 610350 Analog Output Mezzanine, P/N 610370.

Redundant logic power supplies are not included in the qualified equipment. Field power supplies for the 4-20 mA analog loops are not included in the qualified equipment.

2.0 SYSTEM DESIGN GUIDANCE

2.1 Power

2.1.1

The NuPAC platform has a defined response to loss of power. All discrete outputs turn off, all analog outputs go to a zero output value, and all communications links are disabled.

2.1.2

The NuPAC platform has a defined response to power restoration. When power is restored, power-on self-test (POST) starts and the platform logic holds all discrete and analog outputs in their safe state, discrete outputs off and analog outputs set to 0 mA. When POST completes, outputs are set to the state commanded by the application logic. Serial output communication is not disabled during POST. If POST fails, it can be reported using serial output.


NuPAC_ED610000-047-P B 139 of 204 01/19/2012


Power supplies are not included in the NuPAC topical report. However, requirements are still provided for power to ensure safe, reliable operation of the NuPAC platform. Power supply design considerations specific to the NuPAC platform are included in Sections 2.1.3 through 2.1.9 below.

2.1.3

The chassis is designed to accept dual redundant power supplies. Each supply shall be capable of providing 100% of the power requirements for the supplied chassis.

2.1.4

The cabinet, power supplies, and field wiring must be wired and grounded according to installation procedure requirements.

2.1.5

Redundant or at least diverse paths to input power should be provided to the dual power supply connections on each NuPAC chassis. With this configuration, failure of either supply does not impact the NuPAC platform. The chassis power supplies should meet the following minimum characteristics:

Normal operating voltage tolerance of +12 VDC, ±3%, maximum Maximum ripple voltage of 150 mVPK-PK Maximum abnormal output voltage of +16 VDC during a power supply overvoltage failure.

2.1.6

The NuPAC platform shall be configured to provide a loss of a power alarm in the control room for both input power and power output from either or both redundant chassis and field power supplies. Conditions to be alarmed should include over and under voltage on the diode-auctioned power as well as over and under voltage on each of the regulated power supplies. Discrete outputs may be used to provide faults and failures to a plant annunciation system. Since power failures are expected to be infrequent, maintenance procedures should be generated by the Licensee to respond to and resolve such faults and failures.

2.1.7

Redundant analog field power supplies should be provided in each cabinet. Redundant or at least diverse paths to input power must be provided to the redundant analog field power supplies. With this configuration, failure of one analog field power supply or the power to that supply does not affect system operation. The single failure of an analog field power supply will be annunciated.

2.1.8

The method of auctioneering for field or Loop supplies could be provided by the supplies themselves or included as external devices located within the cabinet as part of RPS design. It is possible to purchase power supplies that are designed to work redundantly without any additional external aid. External auctioneering may need to be provided within the cabinet to achieve the desired redundancy.

2.1.9

For testing of field or loop supplies, it is recommended that each supply be monitored using available I/O mezzanine functionality. If the selected supply supports a “Power Good” discrete output signal then this signal can be monitored by one of the GLM backplane discrete input monitor points rather than using an I/O mezzanine card. Supplies should be monitored both before and after any auctioneering to facilitate fault isolation.


NuPAC_ED610000-047-P B 140 of 204 01/19/2012


2.2 Connection to Plant Instrumentation and Controls

2.2.1

All analog field sensors/transmitters are hardwired to RTM connectors, which provide dedicated connection to analog input mezzanine cards. All discrete field sensors/transmitters are hardwired to RTM connectors, which provide dedicated connections to discrete input mezzanine cards.

2.2.2

All analog field actuated devices are hardwired to RTM connectors, which provide dedicated connection to analog output mezzanine cards. All discrete field actuated devices are hardwired to RTM connectors, which provide dedicated connections to discrete output mezzanine cards.

2.2.3

Each actuated discrete field device may be configured in the application logic either as a pair of programmable width pulses used separately to turn on and turn off a device or as a level.

2.2.4

If redundant inputs are provided to a single division, those redundant inputs shall not be processed on a single GLM. If redundant outputs are created in a single division, those redundant outputs shall not be sourced from a single GLM.

2.3 System Configuration

2.3.1

Each GLM has a defined delay from input to output, based on the programmable logic on that GLM. Groups of GLMs are not synchronized, other than all GLMs start roughly together after power up. Messages are not internally synchronized. Section 6.3.3 of this LTR describes the methods needed to determine the maximum time delay from change in input to change in output for various configurations of GLMs, ranging from the cycle time for one GLM to respond where all inputs, all logic, and all outputs are on that single GLM through configurations where multiple GLMs, in multiple cabinets, and in multiple divisions are required to change outputs in response to the change in inputs.

2.3.2

The safety system response-time calculations shall assume a data error rate that is greater than or equal to the design basis error rate and is supported by the error rate observed in design and qualification testing.

2.3.3

The NuPAC platform is designed to support divisional redundancy. The NuPAC platform is designed to be provided in redundant systems. Each plant-specific system design shall provide redundant channels, divisions, and trains as required.


NuPAC_ED610000-047-P B 141 of 204 01/19/2012


2.3.4

Selective internal redundancy can be applied within each channel, division, or train as necessary to enhance reliability or provide means to perform technical specification surveillance without entering a Limiting Condition for Operability (LCO) when taking a division’s safety function out of service.

2.3.5

The NuPAC platform may be configured with individual field sensors split across separate I/O mezzanines and/or separate GLMs for redundancy.

2.3.6

The NuPAC platform may be configured with redundant voting on redundant GLMs.

2.3.7

The NuPAC platform may be configured to provide voting on the discrete outputs, using multiple series or parallel discrete outputs, as appropriate, to enhance reliability.

2.3.8

Analysis shall be performed on each communication link with more than one message being sent across the link in each communication cycle, to establish the bandwidth used for all messages passing over that link.

2.3.9

Communication links with excessive bandwidth shall have traffic routed to other, lesser used, communication links to balance the normal loading on each link.

2.3.10

All external (through the Serial RS485 Mezzanine) and internal (through the LVDS communication paths on the backplane) communication messages and processing shall be designed such that faults and failures do not adversely affect the safety function, except for the detectable loss of the data contained in that message.

2.3.11

Faults and failures in external and internal communication message and processing shall not be considered single failures, as described in the single failure criterion.

2.3.12

Communications of highly safety critical information, such as the sharing of channel trip decisions for the purpose of voting, shall include provisions for ensuring that received messages are correct and are correctly understood.


NuPAC_ED610000-047-P B 142 of 204 01/19/2012


2.3.13

Communications of highly safety critical information shall employ error-detecting or error-correcting coding along with means for dealing with corrupt, invalid, untimely, or otherwise questionable data. The effectiveness of error detection/correction should be demonstrated in the design and proof testing of the associated codes, but once demonstrated is not subject to periodic testing. Error-correcting methods, if used, should be shown to always reconstruct the original message exactly or to designate the message as unrecoverable. None of this activity should affect the operation of the safety functions.

2.3.14

All serial data communication outside a GLM platform chassis should be performed only over point-to-point communication links. This is the preferred approach but it should not be a limitation. The NuPAC platform can support an RS-485 bus structure if desired. This may be advantageous in retrofit situations where a bus structure already exists.

2.3.15

No handshaking shall be required across divisions or for safety to non-safety system communication.

2.3.16

All messages shall be preformatted and shall have predefined content. The plant-specific application logic shall define the format and content of all serial data communication messages, with the exception of the routing data placed on internal communication messages by the platform logic.

2.3.17

Failure to receive a predefined number of periodic broadcast messages shall be treated appropriately by the receiving application logic. For messages that provide data to safety functions, this failure should be treated as if the sending division has failed. Failure of multiple sending divisions shall be addressed in the plant-specific application logic.

2.3.18

The serial communication pathways provided on the NuPAC platform backplane provide two mesh-star point-to-point networks. To minimize the transit time of bistable, voting, and status communications, one of the mesh-star networks may be dedicated to the transmission of these data types. All other data would be transmitted through the second mesh-star network.


NuPAC_ED610000-047-P B 143 of 204 01/19/2012


2.3.19

As shown logically in Figure 2.3.20-1, divisional field sensors are hardwired to one or more GLM implementing the channel logic, shown as a solid line. The field sensor data is sampled through the I/O mezzanine cards on those GLM. The GLM includes application logic to compare input data against predefined setpoint values to determine whether this channel concludes that protective action is required.

Figure 2.3.20-1. Channels and Divisions

2.3.20

The channel bistables provide votes to trip or actuate to separate GLMs that perform the voting at the division level, which may provide data to separate GLMs for the actuation logic or the actuation logic may be on the same GLM as the voter. Connections from channels to divisions are shown as dotted lines in Figure 2.3.20-1, which may be either hardwired or serial data communication connections. Connections to the field equipment are hardwired and shown as solid lines in the figure.

2.3.21

Except for quality calculations, channels shall not make use of any engineering unit data from other divisions.

2.3.22

Channels shall make use of bypass or quality status from other divisions.


NuPAC_ED610000-047-P B 144 of 204 01/19/2012


2.3.23

Channel bistables may be in a separate chassis from the divisional voters and output logic or the channel bistables may be grouped separately from the divisional voters and output drivers within the same chassis. Channel functions shall not be combined with division functions on a single GLM. Installation in the same chassis minimizes communication delay between the bistables and the voters/drivers.

2.3.24

Non-safety functions, such as channel cross comparison and alarming, shall be performed only in a separate non-safety system. Each safety related division of each plant-specific system implemented with the NuPAC platform shall provide that division’s data over separate, communication links to the non-safety system. Each division’s communication links are separate from any other division’s communication links.

2.3.25

I/O mezzanine cards provide the required electrical isolation between safety-related divisions and trains, using the separation guidance provided in Section 2.3.26 and/or 2.3.27.

2.3.26

If fiber-optic cable is used, separation shall be in accordance with IEEE Standard 384-2008, “IEEE Standard Criteria for Independence of Class 1E Equipment and Circuits.” Each fiber optic cable that crosses divisional boundaries shall be assigned to the division that would be affected by the loss of that cable. An external fiber optic converter is required to interface with the NuPAC platform.

2.3.27

If any hardwired connections cross-divisional boundaries, the copper cable shall be separated in accordance with IEEE Standard 384-1992, as endorsed by RG 1.75, Revision 3, “Criteria for Independence of Electrical Safety Systems.” In accordance with that standard, the cable shall be separated based on the division applying power to the cable.

2.3.28

Voters shall not access or be provided with engineering unit data from their own division or from other divisions. Voters shall have access only to status information (e.g., votes to trip or not trip, votes to actuate or not actuate, input sensor good/bad (quality information), division of sensors bypassed, division of outputs bypassed) as well as votes to actuate/trip from within the division and from other divisions.

2.3.29

Votes to trip or actuate and required status can be transferred between divisions using two methods. The preferred method for the plant-specific systems implemented with the NuPAC platform to transfer information is by use of communication links. With a communication link sending periodic messages, failure to receive and other faults (see DI&C ISG 04) can be detected. Alternatively, with appropriate wiring and programming, data can be sent from discrete outputs in one division through qualified electrical isolation to discrete inputs in another division. Each bit of information to be sent requires a discrete output, electrical isolator, and discrete input.

2.3.30

The interconnection of divisions is plant-specific. The interconnection of divisions shown in Figure 2.3.30-1 is an example of reactor trip system divisional interconnection, which could be implemented using the NuPAC platform. For engineered safety features systems, the number of voters and actuator outputs may vary, depending on the required number of various types of pumps and valves to meet the plant-licensing basis.


NuPAC_ED610000-047-P B 145 of 204 01/19/2012


Figure 2.3.30-1. Signal Paths between Divisions

2.3.31

Electrical separation shall be implemented between channels and divisions within the NuPAC-based plant-specific system. Electrical separation may be reduced as allowed by the Licensee’s plant-specific requirements.

2.3.32

Each division of plant-specific systems designed with the NuPAC platform may receive votes to trip or actuate, bypass status, and data status from other safety systems. This information types is used by the plant-specific system in voting to actuate or trip. Communication across divisional boundaries requires qualified isolation.

2.4 Chassis Configuration

2.4.1

The NuPAC platform chassis is not explicitly protected from dust, corrosive atmospheres, water, or falling debris. The user shall provide atmospheric and airborne particle protection by mounting the equipment inside an appropriate enclosure.

2.4.2

The NuPAC platform shall be installed in a mild environment.

2.4.3

Each chassis shall be assigned to a specific electrical division. Each chassis shall not be split between electrical divisions.

2.4.4

Redundant communications cables should not be routed together outside the cabinet. For maximum protection from failure, the communication cables should be routed through diverse routes within the cabinet.

2.5 External Communication Interface

2.5.1

Communications capabilities to external equipment is normally dual redundant, for reliability.

2.5.2

Data communicated from other safety systems for display may not be used by application logic in the NuPAC division for safety functions.


NuPAC_ED610000-047-P B 146 of 204 01/19/2012


2.5.3

Electrical separation is required in communications between the NuPAC platform and other safety systems.

2.5.4

Electrical separation shall be implemented between each division of plant-specific systems designed with the NuPAC platform and any non-safety systems.

2.5.5

If transmission of safety-related information from a NuPAC platform to a non-safety system is required, each division of plant-specific systems designed with the NuPAC platform shall independently broadcast that division’s information to the non-safety equipment. Each division of plant-specific systems designed with the NuPAC platform shall be configured to preclude receiving data that can alter or impede the established safety function while the division is online performing its safety functions.

2.5.6

If the NuPAC-based system communicates data to a non-safety system, then additional non-safety system software could be provided in that non-safety system to retain historical data.

2.5.7

Data from external systems shall be used only when that use does not violate data independence between echelons of defense (see NUREG/CR-6303).

2.5.8

The following credible communication faults have been considered in the LVDS communication system design. The following credible communication faults and failures should be considered in the external communication messaging design, which shall not be limited to the following:

1) Messages may be corrupted due to errors in communication processing errors introduced in buffer interfaces, errors introduced in the transmission media, or from interference or electrical noise.

2) Messages may be repeated at an incorrect point in time. 3) Messages may be sent in the incorrect sequence. 4) Messages may be lost, which includes both failures to receive an uncorrupted message or to acknowledge

receipt of a message. 5) Messages may be delayed beyond their permitted arrival time window for several reasons, including

errors in the transmission medium, congested transmission lines, interference, or by delay in sending buffered messages.

6) Messages may be inserted into the communication medium from unexpected or unknown sources. 7) Messages may be sent to the wrong destination, which could treat the message as a valid message. 8) Messages may be longer than the receiving buffer, resulting in buffer overflow and memory corruption. 9) Messages may contain data that is outside the expected range. 10) Messages may appear valid, but data may be placed in incorrect locations within the message. 11) Messages may occur at a high rate that degrades or causes the system to fail (i.e., an event similar to a

broadcast storm). 12) Message headers or addresses may be corrupted.


NuPAC_ED610000-047-P B 147 of 204 01/19/2012


2.5.9

Network connectivity, liveness, and real-time properties essential to the safety application shall be verified in the communication protocol. Liveness, in particular, is taken to mean that no connection to any network outside the division can cause an RTS/ESFAS communication protocol to stall, either deadlock or livelock.

The prohibition of non-safety serial communication inputs may be relaxed in cases where the input is dedicated and localized to the prioritization and control of discrete field devices. When non-safety communications are considered the following shall apply:

A dedicated GLM shall provide isolation for reception and acceptance of external non-safety communications prior to any distribution within the NuPAC system.

All non-safety serial communications message content shall be designed to be identifiable as such.

All ports not dedicated to non-safety message handling shall independently reject and annunciate the arrival of any message originating from the non-safety system.

2.6 Operator Interface

2.6.1

The NuPAC platform design supports use of traditional switches, meters, recorders, and lights for human-system interface.

2.6.2

The NuPAC platform design supports provision of traditional contact closure signals to control room annunciators.

2.6.3

The NuPAC platform design supports communications to and from a video display safety system within the control room for human-system interface.

2.6.4

Each data item that is communicated to/from a video display safety system shall be checked (e.g., CRC) for correct data transmission. Each connection between programmable logic and configuration in the video display shall be verified and validated.

2.6.5

The plant-specific design shall provide appropriate control of the setpoint memory write protect line for each chassis. Appropriate key lock switches, or other physical and administrative processes, shall be supplied to ensure that changes to the setpoint values in each chassis are controlled and protected in accordance with the Licensee’s cyber security program.

2.6.6

The plant-specific application logic should implement range checks for all NVM stored plant application variables, calibration constants and measurement limits. Modifications of NVM data should implement safeguards to prohibit access and limit modification of data or ranges to acceptable values. Any modifications of NVM should include a confirmation read-back/ validation.


NuPAC_ED610000-047-P B 148 of 204 01/19/2012


2.7 Bypass Indication and Status Indication

2.7.1

Maintenance and operating bypass implementation is specific to the plant-specific system application. Bypasses shall be added as necessary and designed into the application logic in accordance with plant licensing, reliability, availability, surveillance, maintenance, and operations requirements.

2.7.2

Bypass inputs to the application logic should be provided through appropriate hardware interfaces (e.g. joystick or other such interface devices). Provisions in the application logic should be implemented to preclude multiple divisions simultaneously in bypass.

2.7.3

Operating bypasses are also provided through plant-specific design using a combination of application logic and hardware. Automatic operating bypasses may be designed into the plant-specific application logic.

2.7.4

For operating bypasses, more than one bypass can be active at any point in time based on the requirements of the operations procedures dealing with the plant conditions. Application logic shall verify permissive conditions are met for all active operating bypasses. If permissive conditions are not met, the application logic shall clear the bypass condition, restore permissive plant conditions, or initiate the appropriate safety feature.

2.7.5

Bypass, inoperable, and other status indication may be provided through discrete hardwired outputs to drive lamps in the control room or through serial communication to video displays in the control room.

2.7.6

If the NuPAC-based system communicates data to a non-safety system, then additional non-safety system software could be provided in that non-safety system to provide Bypassed and Inoperable Status Indication.

2.8 Self-Test and Surveillance Test Capabilities

2.8.1

A safety system design must provide the ability to conduct periodic testing consistent with the plant-specific requirements and procedures. The NuPAC-based system applications can be designed to provide these capabilities in accordance with the requirements established in the regulatory guidance documents referenced in BTP 7-17. There is nothing inherent in the NuPAC platform or the software tools used with the NuPAC platform that fails to comply with the requirements of IEEE Standard 603-1991, as required by BTP 7-17. However, since the NuPAC platform architecture is different from any analog system it replaces, traditional surveillance test provisions for analog systems are likely not adequate or appropriate. The required surveillance testing capabilities for each plant-specific application will be designed into the application logic. The surveillance tests and support for surveillance testing will be evaluated to assure adequacy to fulfill the requirements and the intent of the surveillance tests. The implications of surveillance capabilities on maintenance are discussed in Section 8.3.

2.8.2

Modifications to existing surveillance tests and Technical Specification licensing commitments shall be considered based on the additional capabilities provided in the NuPAC-based system. An analysis shall compare the NuPAC-based system self-test features, single failure analyses, FMEA, and application logic against the


NuPAC_ED610000-047-P B 149 of 204 01/19/2012


requirements established in the plant’s Technical Specifications and USNRC requirements. Self-tests and automatic analog input calibration should be considered as means of reducing either surveillance testing or calibration requirements for the plant-specific system. Additional application logic should be considered to support surveillance testing by eliminating any requirements for lifted leads and temporary configuration changes. The analysis shall ensure that nothing done in these tests could prevent the performance of the system’s safety function(s).

2.8.3

A NuPAC-based system may be configured to periodically test for coil presence and output switch functionality by verifying current flow or briefly changing state. This capability should be evaluated in lieu of manual surveillance testing, and for decreasing surveillance-testing frequency.

2.8.4

The concepts used to determine test intervals for a NuPAC-based system should consider the reliability of the NuPAC-based system. Changes to surveillance frequency will require licensing change.

2.8.5

A NuPAC-based system shall be designed and validated to detect and identify failures to the greatest extent that is practical.

2.8.6

The application logic should provide the capability to confirm that the automatic tests are still functional during plant operation.

2.8.7

A NuPAC-based plant-specific implementation shall include evaluation of the effects on the plant when a NuPAC-based system goes to a fail-safe state. Upon detection of faulted output conditions, a NuPAC-based plant-specific implementation should command all outputs to a fail-safe state.

2.8.8

Plant-specific application logic shall be designed to annunciate detected faults and failures in the control room. Mechanisms for operator notification of detected faults and failures shall comply with the system status indication provisions of IEEE Standard 603 and should be consistent with, and support, plant-specific requirements, operating procedures, and maintenance procedures.

The plant-specific application logic BIT should be such that loss of GLM functionality, on any GLM card, is detected and reported by at least one other GLM within the system architecture. In addition to other methods of annunciating an alarm it is recommended that each GLM use the LVDS serial communication to report any local failure or alarm condition.

2.8.9

Procedures shall be written or updated to support the NuPAC platform and the plant staff in operations and maintenance.

2.8.10

As required by IEEE Standard 279, Section 4.13; IEEE Standard 603, Section 5.8.3; and RG 1.47, if the protective action of some part of a protection system is bypassed or deliberately rendered inoperative for testing, that fact shall be continuously indicated in the control room. Provisions shall also be made to inform the control


NuPAC_ED610000-047-P B 150 of 204 01/19/2012


room operator when the protection system is restored. Application logic with each NuPAC-based system shall be provided for bypass and status generation.

2.8.11

The field-actuated device testing specified in Regulatory Guide 1.22 is still applicable. The NuPAC platform application logic can be configured to perform any of the testing described in RG 1.22, from complete function to judicious choice of components for several tests.

2.8.12

The risk associated with logic complexity associated with automating the required surveillance testing should be offset by the reduced risk associated with manual performance of such testing, including lifting leads. Consistent with the requirements of RG 1.118, makeshift test setups, including temporary modifications of data or plant wiring that must be removed to restore the system to service, shall be avoided.

2.8.13

Hardware and programmable logic used to perform surveillance functions shall be classified as safety related and shall be integral to the NuPAC platform. The scope and extent of interfaces required to perform these tests shall be designed to maintain channel independence, maintain system integrity, and meet the single failure criterion. The scope and extent of interfaces between programmable logic that perform safety functions and programmable logic for testing functions should be designed to minimize the complexity of the logic and data structures.

2.8.14

Plant procedures should specify manual compensatory actions and mechanisms for recovery from indicated faults and failures.

3.0 DIVERSITY IMPLEMENTATION

For the equipment qualified in this topical report, no diversity is supplied. Thus, for the equipment qualified, LMGI/SNPAS makes every attempt to minimize the possibility for introducing a Common Cause Failure (CCF) including any that may be introduced by software tools and logic designs.

LMGI/SNPAS recommendation for establishing diversity is included in Section 7.0 of the NuPAC Platform Topical Report. The Diversity and Defense-in-Depth methodology supplied in this topical report may be approved by the USNRC. If the approach is approved, LMGI/SNPAS may design, develop, qualify, and furnish diverse Logic Mezzanines with sufficient diversity to be able to claim that programmable logic (i.e., software) common cause failure is not credible. In this case, no additional diverse actuation or diverse protection system equipment is required, beyond that already licensed in the facility.

4.0 SETPOINT ANALYSIS AND ACCURACY

The accuracy, repeatability, thermal effects, and other necessary data for use in setpoint analyses will be provided in this Application Guide, following applicable development and testing.

5.0 ENVIRONMENT AND LOCATION

The NuPAC platform will undergo qualification for installation in a mild environment. A mild environment is defined in IEEE Standard 323-1983 as an environment that would at no time be significantly more severe than the environment that would occur during normal plant operations, including anticipated operational occurrences.


NuPAC_ED610000-047-P B 151 of 204 01/19/2012


The specific requirements and qualification testing pertaining to the environment in which a safety-related NuPAC platform may be located are discussed in this section.

Upon completion of environmental testing this Application Guide will be updated with the test details and results. The test details will include a list of the specific hardware that underwent testing. The test results will specify the operating condition envelopes verified by testing for each of the following subsections.

A plant-specific evaluation will be needed to determine whether the as-tested limits bound the plant requirements. If not, additional evaluation or testing is required.

5.1 Mounting

5.1.1

The NuPAC chassis is designed to fit within industry-standard cabinets (19-inch minimum).

5.1.2

Each chassis shall be mounted consistently with the mounting methods and requirements used during seismic testing, which shall be updated in this Application Guide at the completion of Equipment Qualification testing.

5.1.3

The NuPAC chassis do not require additional stand-off spacing between chassis.

5.2 Temperature and Humidity

An Environmental Test will be performed in accordance with the requirements of EPRI TR 107330, Section 4.3.6. This testing demonstrates that the NuPAC platform will not experience failures due to abnormal service conditions of temperature and humidity as required by USNRC Regulatory Guide 1.89, “Environmental Qualification of Certain Electric Equipment Important to Safety for Nuclear Power Plants,” and IEEE Standard 323-2003, “IEEE Standard for Qualifying Class 1E Equipment for Nuclear Power Generating Stations,” subject to the enhancements and exceptions listed in Section C of USNRC Regulatory Guide 1.209, “Guidelines for Environmental Qualification of Safety related Computer-Based Instrumentation and Control Systems in Nuclear Power Plants.”

Once completed, a future revision of this Application Guide will provide the temperature/humidity envelope to which qualification testing was performed.

5.3 Heat Loads in Cabinets and Rooms

When mounting the NuPAC chassis into enclosures, heat management calculations must be made to avoid exceeding the qualified ambient temperature ratings. For purposes of these calculations, all power consumed by the NuPAC platform should be assumed to be a source of heat inside the enclosure where the chassis is mounted. The NuPAC platform temperature range must be computed with cabinet doors open and closed.

If the room temperature plus any heat rise within the cabinet exceeds the NuPAC platform qualification envelope provided in this Application Guide, Section 5.2, additional provision must be made for temperature control.

5.4 Seismic Acceleration Limits

Seismic testing of a standalone chassis will be performed in accordance with the requirements of EPRI TR 107330, Section 4.3.9, and IEEE Standard 344-2004.


NuPAC_ED610000-047-P B 152 of 204 01/19/2012


Seismic testing will demonstrate the NuPAC platform is qualified as a Category I seismic device within the test limits shown on Figure 5.4-1.

Once completed, a future revision of this Application Guide will provide the seismic envelope to which qualification testing was performed.

A plant-specific evaluation will be needed to determine whether the as-tested limits bound the plant seismic acceleration requirements. If not, additional evaluation or seismic testing may be required.

Figure 5.4-1. Seismic Withstand Response Spectrum


NuPAC_ED610000-047-P B 153 of 204 01/19/2012


5.5 Radiation Fields

The NuPAC platform will be tested for withstand capability to mild environment radiation exposure of 1,000 RADS integrated over a 40-year period. Testing shall be performed using a prompt gamma dose of at least 1,100 RADS over a short period.

Once completed, a future revision of this Application Guide will provide the radiation exposure to which qualification testing was performed.

5.6 Electro-Magnetic Compatibility

The following electromagnetic interference (EMI)/radiofrequency interference (RFI) tests will be performed on a chassis to demonstrate acceptable performance of the NuPAC platform in accordance with the EMI/RFI criteria specified in RG 1.180, Revision 1, “Guidelines for Evaluating Electromagnetic and Radio-Frequency Interference in Safety Related Instrumentation and Control Systems.”

5.6.1 Radiated Magnetic Field Emissions from 30 Hz to 100 kHz (RE101)

Once completed, a future revision of this Application Guide will provide the radiated magnetic field emissions envelope for the NuPAC platform, as shown in Figure 5.6.1-1.

Figure 5.6.1-1. Magnetic Field Radiated Emissions Envelopes (RG 1.180 Rev.1)


NuPAC_ED610000-047-P B 154 of 204 01/19/2012


5.6.2 Radiated Electric Field Emissions from 10 kHz to 10 GHz (RE102)

Once completed, a future revision of this Application Guide will provide the radiated electric field emissions envelope for the NuPAC platform, as shown in Figure 5.6.2-1.

Figure 5.6.2-1. Electric Field Radiated Emissions Envelopes (RG 1.180 Rev.1)


NuPAC_ED610000-047-P B 155 of 204 01/19/2012


5.6.3 Low-Frequency Conducted Emissions from 30 Hz to 10 kHz (CE101)

Once completed, a future revision of this Application Guide will provide the low-frequency conducted emissions envelope for the NuPAC platform when using the power supply selected to support the NuPAC platform qualification, as shown in Figure 5.6.3-1.

Figure 5.6.3-1. Low-Frequency Emissions Envelopes (RG 1.180 Rev. 1)


NuPAC_ED610000-047-P B 156 of 204 01/19/2012


5.6.4 High-Frequency Conducted Emissions from 10 kHz to 2 MHz (CE102)

Once completed, a future revision of this Application Guide will provide the high-frequency conducted emissions envelope for the NuPAC platform when using the power supply selected to support the NuPAC platform qualification, as shown in Figure 5.6.4-1.

Figure 5.6.4-1. High-Frequency Emissions Envelopes (RG 1.180 Rev. 1)


NuPAC_ED610000-047-P B 157 of 204 01/19/2012


5.6.5 Radiated Magnetic Field Susceptibility from 30 Hz to 100 kHz (RS101)

Once completed, a future revision of this Application Guide will provide the radiated magnetic field susceptibility envelope for the NuPAC platform, as shown in Figure 5.6.5-1.

Figure 5.6.5-1. Low-Frequency Radiated Susceptibility Envelopes (RG 1.180 Rev. 1)

5.6.6 Radiated Electric Field Susceptibility from 10 kHz to 10 GHz (RS103)

The impressed electric field should be 10V/m (rms) across the entire frequency band.

Once completed, a future revision of this Application Guide will provide the radiated electric field susceptibility envelope for the NuPAC platform.


NuPAC_ED610000-047-P B 158 of 204 01/19/2012


5.6.7 Low-Frequency Conducted Susceptibility Power Leads from 30 Hz to 150 kHz (CS101)

Once completed, a future revision of this Application Guide will provide the low-frequency conducted susceptibility envelope for the NuPAC platform when using the power supply selected to support the NuPAC platform qualification, as shown in Figure 5.6.7-1.

Figure 5.6.7-1. Low-Frequency Conducted Susceptibility Operating Envelope (RG 1.180 Rev. 1)


NuPAC_ED610000-047-P B 159 of 204 01/19/2012


5.6.8 High-Frequency Conducted Susceptibility Power Leads from 10 kHz to 30 MHz (CS114)

Once completed, a future revision of this Application Guide will provide the high frequency conducted susceptibility envelope for the NuPAC platform when using the power supply selected to support the NuPAC platform qualification, as shown in Figure 5.6.8-1.

High Frequency Conducted Susceptibility from 10 kHz to 30 MHz (CS114)

Figure 5.6.8-1. High-Frequency Conducted Susceptibility Operating Envelope (RG 1.180 Rev. 1)

5.6.9 Conducted Susceptibility Tests for Interconnecting Signal Lead

Table 5.6.9-1 shows conducted susceptibility tests for interconnecting signal leads.

Table 5.6.9-1. Conducted Susceptibility Operating Envelopes for Signal Leads (RG 1.180 Rev. 1)

Method Description CS114 100 dBµA, from 10 kHz to 200 MHz

97 dBµA, from 200 MHz to 1 GHz CS115 2 A CS116 5 A

5.6.10 Conducted Susceptibility, High Frequency, 10 kHz to 30 MHz (CS114)

Once completed, a future revision of this topical report will provide the high frequency conducted susceptibility envelope for the NuPAC platform.

5.6.11 Conducted Susceptibility, Bulk Cable Injection, Impulse Excitation (CS115)

Once completed, a future revision of this Application Guide will provide the bulk injection, impulse excitation conducted susceptibility envelope for the NuPAC platform.


NuPAC_ED610000-047-P B 160 of 204 01/19/2012


5.6.12 Conducted Susceptibility, Damped Sinusoidal Transients, 10 kHz to 100 MHz (CS116)

Once completed, a future revision of this Application Guide will provide the damped sinusoidal transient conducted susceptibility envelope for the NuPAC platform.

5.7 Electrical Fast Transient Capability

An electrical fast transient (EFT) test will be performed to demonstrate acceptable performance of the NuPAC platform in accordance with the EFT susceptibility criteria specified in USNRC RG 1.180, Revision 1.

Once completed, a future revision of this Application Guide will provide the response of the NuPAC platform to electrical fast transients.

5.8 Surge Withstand Capability

A surge withstand test will be performed to demonstrate acceptable performance of the NuPAC platform in accordance with the Surge Withstand susceptibility criteria specified in USNRC RG 1.180, Revision 1.

Once completed, a future revision of this Application Guide will provide the response of the NuPAC platform to electrical surges. Table 5.8.2-1 lists power surge waveforms.

Table 5.8.2-1. Power Surge Waveforms (RG 1.180 Rev. 1) Parameter Ring Wave Combination Wave EFT

Waveform Open-circuit voltage Open-circuit voltage Short-circuit current Pulses in 15-ms bursts Rise time 0.5 μs 1.2 μs 8 μs 5 ns Duration 100 kHz ringing 50 μs 20 μs 50 ns

5.9 Electrostatic Discharge (ESD) Testing

An electrostatic discharge (ESD) test will be performed to demonstrate acceptable performance of the NuPAC platform in accordance with the ESD susceptibility criteria specified in EPRI TR-107330, “Generic Requirements Specification for Qualifying a Commercially Available PLC for Safety Related Applications in Nuclear Power Plants.”

Once completed, a future revision of this Application Guide will provide the response of the NuPAC platform to ESD events.

5.10 Isolation Testing

Class 1E to Non-1E isolation testing will be conducted on the NuPAC platform in accordance with the requirements of EPRI TR-107330 and IEEE Standard 384-1981. This test will qualify each of the I/O mezzanine cards as a Class 1E to Non-1E isolator.

The testing will demonstrate electrical isolation capability of the communication port to applied voltages of 250 VAC at 10 amperes maximum and 250 VDC at 5 amperes maximum for 30 seconds.

Testing for analog and discrete inputs and outputs will demonstrate compliance with the expectations defined in BTP 7-11, “Guidance on Application and Qualification of Isolation Devices.”

Once completed, a future revision of this topical report will provide the Class 1E to non-Class 1E isolation capabilities of the NuPAC platform.


NuPAC_ED610000-047-P B 161 of 204 01/19/2012


6.0 SOFTWARE LIFE CYCLE PROCESSES

The following life cycle process requirements will ensure the long-term maintainability of the NuPAC-based system, as installed in a facility. Considerations for the system life cycle include the following:

6.1.1

Applications shall be created using nuclear safety related software life cycle processes acceptable to the USNRC as outlined in the Standard Review Plan (NUREG-0800) Branch Technical Position (BTP) 7-14. The LMGI/SNPAS life cycle processes are customized as necessary to fit FPGA programmable logic development, rather than software. The LMGI/SNPAS life cycle plans shall comply with the life cycle plans defined in this topical report. Differences between the process in this topical report and any future LMGI/SNPAS process improvements shall be documented and controlled through the configuration management program with any applicable licensing reviews performed as required.

6.1.2

Currently, there are no plans to turn over responsibility for application programming to the Licensee. The same plans used to generate the application logic, or improvements to those plans, will be used for all maintenance activities. Changes to the programmed logic in any NuPAC-based system must be made under strict change control procedures as defined in BTP 7-14. All changes must be thoroughly verified and validated, as well as audited and approved by the plant safety change control committee or equivalent. After an approved change is made, all appropriate software and documentation must be archived.

6.1.3

Configuration data shall be retained for the hardware configuration, programmable logic configuration, and software tools.

6.1.4

Since the human-readable applications logic cannot be easily reconstructed from the platform, LMGI/SNPAS must retain all data files as well as the configuration of the personal computer (PC) on which the human-readable software and the software tools reside. Maintenance of configuration data is critical for long-term maintenance. In addition to printed documentation of the application program, at least two electronic copies of the program must be archived in separate locations. This is necessary to comply with requirements for dual storage of safety related quality records.

6.1.5

The Licensee shall be provided with at least the electronic, loadable programmable logic FPGA images for configuration control and long-term support. The Licensee shall be provided with software tools that provide the capability to load the programmable logic FPGA images into the Logic Mezzanine. The Licensee shall be provided with instructions on use of these software tools and on maintenance of configuration (i.e., which programmable logic images are required for each GLM in the system). The configuration data will be maintained by LMGI/SNPAS appropriately, as changes are made.

6.1.6

The archival media must be write-protected after storage of the design documents and FPGA image, to avoid accidental changes. The configuration management programs at LMGI/SNPAS and at the Licensee must ensure that the media on which this storage occur remains viable. The storage media must continue to be supported by current PCs or the storage media must be copied to media that is supported by current PCs and the copy verified for correctness.


NuPAC_ED610000-047-P B 162 of 204 01/19/2012


7.0 GUIDANCE FOR APPLICATION PROGRAMMING

The guidance provided in this section is intended to ensure that 1) the chance of design errors built into the application logic is minimized, 2) the chance of errors resulting from translation of human-readable software into machine instructions loaded into the NuPAC platform is minimized, and 3) the implementation of the software life cycle processes are ensured.

7.1.1

Plant-specific application programming activities shall ensure that all requirements of this topical report are implemented.

7.1.2

The PCs used for all activities associated with the plant-specific application programming shall be protected in accordance with guidance provided in RG 1.152, supporting a secure development organization, and the cyber security requirements of RG 5.71.

7.1.3

Plant-specific application design shall ensure that a secure operational environment is created and maintained, in accordance with guidance provided in RG 1.152, and the cyber security requirements of RG 5.71.

7.1.4

The symbols on the design basis logic drawings should be reviewed prior to starting programming. Any special requirements in those logic drawings (e.g., logic that expects a set-reset flip-flop to preferentially treat the invalid simultaneous turning on of both set and reset inputs as ignoring one of the inputs) shall be understood and communicated to the entire applications development team. Special provisions shall be made to verify and validate the operation of these special requirements during V&V activities.

7.1.5

Programs shall be created in accordance with LMGI/SNPAS application programming coding guidelines. A comparison of those coding guidelines against other safety critical industries should be performed. The guidelines must conform to all guidance provided in the NuPAC topical report.

7.1.6

Applications logic shall be a product of a disciplined implementation process, providing the traceability necessary to tie source code and testing with higher-level design documents to enhance verification, validation, systems safety, and other aspects required for high criticality software development.

7.1.7

To support long-term maintainability of the plant-specific application logic, the structure of logic shall be maximized.

7.1.8

Plant-specific application logic shall be designed to maximize readability. Graphical diagrams with logic flow from left to right and top to bottom, with as few signals as possible flowing from right to left or bottom to top should be considered as a logic design aide.


NuPAC_ED610000-047-P B 163 of 204 01/19/2012


7.1.9

Plant-specific application logic shall be designed to reduce the likelihood that faults or failures will be introduced during adaptive or corrective software changes both before and after delivery.

7.1.10

Each variable shall be initialized.

7.1.11

Constant values shall be declared, and not just inserted as numeric values.

7.1.12

Comments shall be provided either within the human-readable programmable logic HDL files, or referenced to a separate document. Each HDL file shall contain a human-readable purpose and reference the logic diagram from which the programmable logic was derived. Operations or series of operations shall be described in comments, to maximize the ease of reading, understanding, and modifying the application logic. Comments shall be structured and preferably placed in the programmable logic to minimize interface ambiguities and errors.

7.1.13

For any unusual or complex constructs, as well as any deviations from normal programming practices, comments shall be provided explaining the purpose and operation of the construct or the reason for the deviation.

7.1.14

Names used in the programmable logic for variables, procedures, functions, data types, constants, exceptions, objects, methods, labels, and other identifiers should be descriptive, consistent, and traceable to higher-level documents. Naming conventions are an important part of coding style and practices. Using the same name for multiple variables should be avoided unless obviously advantageous. When the same name is reused, clear, consistent, and unambiguous notations in all locations where the variable is used shall accompany each reuse.

7.1.15

To the extent required by reliability or safety, open and short circuits in the wiring between the NuPAC platform and critical field devices should be detected and annunciated.

7.1.16

Detection that a GLM has not completed processing within the expected period, has stopped completely, has not been sending messages, and other detectable faults and failures shall be annunciated to the control room. LMGI/SNPAS shall supply documentation from which procedures can be written by the Licensee for troubleshooting and resolution.

7.1.17

Setpoint values shall be programmed into EEPROM. Documentation and electronic files used to generate the setpoint values shall be provided to the Licensee, and shall be maintained for the life of the NuPAC platform in the facility.

7.1.18

Data from the NuPAC platform can be provided to non-safety systems for information purposes. This communication is expected to be performed through GLMs acting as communication aggregators. This communication is restricted to a one-way communication link by not providing a communication path to receive


NuPAC_ED610000-047-P B 164 of 204 01/19/2012


data from the non-safety systems and by programmable logic configuration on each GLM used for this purpose. When used to transmit data (one-way) to a non-safety system, the GLM performing that communication shall perform no safety function, and shall solely function as a communication buffer.

7.1.19

While the qualified equipment in this topical report does not include a video display unit (VDU), qualified VDUs can be installed with the NuPAC platform. Each VDU should only be installed in one division. Redundant VDUs should be made available to the control room operator in each division to provide continued indication in the presence of a single failed VDU.

7.1.20

Maintenance and test equipment should only be communicating (bi-directional) with the NuPAC platform when the plant-specific application is bypassed and out of service. Attachment of the maintenance and test equipment should be annunciated in the control room when the equipment is plugged into a GLM. When the NuPAC platform plant-specific application is not bypassed, maintenance and test equipment should only be receiving (uni-directional) status and monitoring data from the NuPAC platform.

7.1.21

Any open cabinet door on any cabinet containing NuPAC equipment shall annunciate the open cabinet door or doors in the control room.

7.1.22

Upon programming (EEPROM, flash memory, and FPGA), card level labeling is applied to show the installed configuration, including revision number, which is traceable to configuration management documentation.

7.1.23

Each cabinet containing NuPAC platform equipment will be identified in accordance with plant-specific identification systems and Clause 5.11 of both IEEE Standard 603-1991 and IEEE Standard 7-4.3.2-2003.

7.1.24

The plant-specific application logic shall support I/O mezzanine card inventory check for correct installation of expected I/O mezzanine card, and shall not start operation if an incorrect mezzanine card is installed.

7.1.25

The plant-specific application logic shall support a slot and chassis check for correct installation in identified slot and chassis, and shall not start operation if the location is incorrect.

7.1.26

Chassis numbers are configured within the non-power (i.e., not the power supply connectors) rear chassis connector. No valid chassis address shall be set to the chassis number that results when the wiring to that connector is removed.


NuPAC_ED610000-047-P B 165 of 204 01/19/2012


8.0 INSTALLATION, COMMISSIONING, AND MAINTENANCE

This section discusses considerations for installation, commissioning, and long-term maintenance of safety related NuPAC platforms. This guidance is intended to identify important considerations for these activities particularly for FPGA-based safety systems. As such, much of the guidance is relatively generic in nature and is not specific only to the NuPAC platform.

8.1 Required Testing

8.1.1

Functional testing must be performed to validate the correct design and operation of the application logic for commissioning and after any modification is implemented. The amount of validation after a change must be appropriate to the magnitude and safety criticality of the modification.

8.1.2

After a safety system is commissioned, no changes to the system logic may be performed without re-commissioning the system.

8.1.3

Periodic testing shall be performed to meet the requirements established in the Technical Specifications. Credit for self-tests can be used to reduce the requirement for surveillance testing, based on changes to the Technical Specifications. Guidance for applying the inherent and application-generated capabilities of the NuPAC platform will be added to this Application Guide in a later revision.

8.2 Operations Procedures

8.2.1

Depending on the level to which faults are displayed in the control room, abnormal operating and alarm response procedures will require modification.

8.2.2

Operating Procedures for a replaced safety system will require modification for use with the NuPAC platform. Procedures for new fault alarms will have to be created. Procedures for entry, exit, and performance of maintenance and surveillance testing will require modification to account for alterations in the operation and indications of the new digital protection system.

8.3 Corrective Maintenance Procedures

8.3.1

While 15 kV electrostatic discharge (ESD) protection is designed into each GLM, maintenance staff shall still wear properly grounded ESD protective wrist straps when handling the GLM, and work on the GLM on a properly grounded static mat.

8.3.2

Repairs to the system must be performed in an expeditious manner. While the system can cope with one or more single failures within a division, operation with faults and failures should be limited and repairs conducted to reduce the possibility of loss of a division or entry into a Limiting Condition of Operation.


NuPAC_ED610000-047-P B 166 of 204 01/19/2012


8.3.3

Procedures shall be developed to support normal corrective maintenance functions. No connections are available for technicians to perform diagnostics on installed components, so all corrective maintenance will require removal of the faulted GLM from its card slot.

8.3.4

A correctly configured replacement card may only be located in the same card slot as the card it replaces. All corrective maintenance will require removing the affected chassis from service.

8.3.5

In order to assure timely access to spare modules, sufficient spare GLM, unprogrammed Logic Mezzanines, I/O mezzanines, RTM, and other spares should be maintained. Maintenance procedures to program Logic Mezzanine spares developed along with plant-specific operating procedures.

8.3.6

Modifications resulting from maintenance procedures must be coordinated with Operations to minimize risk during performance of the maintenance procedures, including surveillance testing.

8.4 Preventative Maintenance Procedures

8.4.1

The GLMs do not require any regular maintenance or inspection once installed in the NuPAC platform.

8.4.2

The fans installed within each NuPAC platform chassis will require periodic inspection, cleaning, and replacement. Maintenance procedures and schedules to support these tasks shall be developed.

8.4.3

Preventive maintenance planning shall ensure that non-volatile memory, including EEPROM and flash memory, is rewritten before excessive leak-off of the space charge results in erroneous changes in the stored memory bits. The current chosen manufacturer states that this will not occur until 20 years after the last write. Procedures shall be provided by LMGI/SNPAS to ensure that nonvolatile memory is refreshed.

8.5 Application Logic Maintenance Procedures

8.5.1

The NuPAC platform has been designed with no provisions for access to, or alteration of, NuPAC platform logic or memory while GLM are inserted into a chassis. All Application Program Maintenance will require removal of cards and shall be controlled by the same procedure as was used for initial installation.

8.5.2

The utility shall establish and maintain configuration control over all programmed logic throughout the operating life of the installed NuPAC platform. Additionally, the utility shall establish and maintain similar configuration control over information loaded onto all EEPROMs and flash memories.


NuPAC_ED610000-047-P B 167 of 204 01/19/2012


8.5.3

If the utility intends to conduct application logic self-maintenance of the NuPAC platform they will establish and maintain a configuration management and secure development and operational environment for all software tools used in this maintenance.

8.5.4

Any changes to the programmed logic after commissioning must be made under strict change-control procedures, such as those required in BTP 7-14. Modifications to the programmed logic shall be made using the life cycle process described in this topical report. All changes must be thoroughly verified and validated, as well as audited and approved by the plant safety change control committee or group. After an approved change is made, it must be archived.

8.6 Maintenance and Bypass Capabilities

Existing safety related systems in nuclear power plants require bypass capabilities for maintenance and testing. Implementation of these capabilities in a digital system requires particular attention to prevent undesired operation of the system. Generic guidance on the implementation of bypass capabilities is provided below.

8.6.1

Maintenance bypasses can be initiated either using switches connected as digital inputs, or overrides can be programmed into the application logic to enable a remote device to serially request the override. This allows the user to request bypassing a single sensor, all sensors, a single channel of logic, or all divisional outputs, as the USNRC has licensed for the facility’s license.

8.6.2

If switches are used to initiate the bypass, these discrete inputs will be used to deactivate actuators and sensors under maintenance or to force safety functions to an enabled or disabled state. The switches shall conform to the specifications and requirements for Class 1E devices and circuits.

8.6.3

If the application logic enables a remote device to request the bypass over appropriate serial communication links to a GLM, the programming must be implemented in accordance with USNRC regulatory guidance.

8.6.4

Connecting to a GLM over serial lines shall be performed using protocols with protection from garbled or corrupted communication packets. Any communication protocol used should include CRC, address check, and check of the communication time frame.

8.6.5

If no bypass functions are active, lost communication should lead to a warning to the operator. If bypass functions are active, lost communication shall be annunciated to the operator. After loss of communication, the design safety evaluation should determine whether a time delayed automatic removal of the bypass is desirable. If this function is implemented, a warning should be provided to the operator prior to implementing the removal.


NuPAC_ED610000-047-P B 168 of 204 01/19/2012


APPENDIX B IEEE STANDARD 603–1991 COMPLIANCE MATRIX


NuPAC_ED610000-047-P B 169 of 204 01/19/2012




NuPAC_ED610000-047-P B 170 of 204 01/19/2012


IEEE Standard 603–1991 Compliance Matrix Section No. Section Title NuPAC Platform Compliance 1 Scope No requirements 2 Definitions No requirements 3 References No requirements 4 Safety System Designation Plant-specific requirement(s), not applicable to the generic NuPAC platform. Plant-specific requirements will be provided

for the plant-specific applications. The generic NuPAC platform has been designed based on nuclear power plant requirements, regulatory requirements, and regulatory expectations.

5 Safety System Criteria Summary-type requirement(s), compliance through sub-clauses, see below 5.1 Single-Failure Criterion Plant-specific requirement(s), not directly applicable to a generic NuPAC platform.

The single-failure criterion is implemented in the design of plant-specific Class 1E systems, which will have redundant, independent divisions. With respect to the generic NuPAC platform: The NuPAC platform includes features which minimize the possibility of a postulated single-failure precluding the

actuation of a safety action when requested, including: The NuPAC platform will be qualified under a 10 CFR 50 Appendix B-compliant quality program and to

mild-environment (including seismic and electromagnetic compatibility) criteria, which eliminates these causal common-cause failures.

The NuPAC platform self-diagnostic testing and periodic surveillance testing identify credible failures within the platform.

NuPAC platform data will be provided to support plant-specific analysis, including: FMEA and hazard analysis which conform to IEEE Standard 352-1987 and IEEE Standard 577-2004.

Reference Section 6.3.1 of this LTR. Reliability analysis and predictions which conform to IEEE Standard 352-1987 and IEEE Standard 577-

2004. Reference Section 6.3.2 of this LTR. 5.2 Completion of Protective

Action Plant-specific requirement(s), not directly applicable to the generic NuPAC platform. The NuPAC platform design does not preclude meeting the requirement(s).

5.3 Quality The generic NuPAC platform is being developed under a 10 CFR 50 Appendix B-compliant quality program, which complies with NQA-1-1994, RG 1.28, and ANSI N45.2, and associated daughter standards for basic components. Reference Section 1.4 of this LTR.


NuPAC_ED610000-047-P B 171 of 204 01/19/2012


IEEE Standard 603–1991 Compliance Matrix Section No. Section Title NuPAC Platform Compliance 5.4 Equipment Qualification The generic NuPAC platform equipment will be qualified in accordance with EPRI TR-107330, which conforms to the

requirements of IEEE Standard 323-2003 (as endorsed by RG 1.209, which complements RG 1.89) for qualifying Class 1E equipment. For electromagnetic compatibility, the generic NuPAC platform equipment will be qualified in accordance with RG 1.180 Revision 1. Reference Section 6.2 of this LTR.

5.5 System Integrity The generic NuPAC platform has been designed and will be tested to confirm the equipment demonstrates performance adequate to ensure completion of protective actions over the full range of its design basis conditions, transient and steady state. The applicable conditions defined by EPRI TR-107330 and RG 1.180 revision 1 formed the primary design basis. The generic NuPAC platform equipment will be qualified in accordance with EPRI TR-107330, which conforms to the requirements of IEEE Standard 323-2003 (as endorsed by RG 1.209, which complements RG 1.89) for qualifying Class 1E equipment. For electromagnetic compatibility, the generic NuPAC platform equipment will be qualified in accordance with RG 1.180 revision 1. Reference Section 6.2 of this LTR.

5.6 Independence Summary-type requirement(s), compliance through sub-clauses, see below 5.6.1 Between Redundant Portions

of a Safety System Plant-specific requirement(s), not directly applicable to the generic NuPAC platform. The NuPAC platform design does not preclude meeting the requirement(s).

5.6.2 Between Safety Systems and Effects of Design Basis Event

Compliance through Clause 5.4 of IEEE Standard 603-1991.

5.6.3 Between Safety Systems and Other Systems

Plant-specific requirement(s), not directly applicable to a generic NuPAC platform. With respect to the generic NuPAC platform: The NuPAC platform provides built-in isolation features which conform to the requirements of IEEE Standard

384-1992 (as endorsed by RG 1.75). Reference Section 3.2.1.2 of this LTR. The associated Class 1E to non-Class 1E test procedures and reports will be in accordance with IEEE Standard

384-1992 (as endorsed by RG 1.75). Reference Section 6.2.8 of this LTR. The associated failure analysis data for the isolation features will conform to IEEE Standard 352-1987 and IEEE

Standard 577-2004. Reference Section 6.3.1 of this LTR. 5.6.4 Detailed Criteria The generic NuPAC platform provides built-in isolation features which conform to the requirements of IEEE Standard

384-1992 (as endorsed by RG 1.75). Reference Section 3.2.1.2 of this LTR. The associated Class 1E to non-Class 1E test procedures and reports will be in accordance with IEEE Standard 384-1992 (as endorsed by RG 1.75). Reference Section 6.2.8 of this LTR.


NuPAC_ED610000-047-P B 172 of 204 01/19/2012


IEEE Standard 603–1991 Compliance Matrix Section No. Section Title NuPAC Platform Compliance 5.7 Capability for Test and

Calibration Plant-specific requirement(s), not directly applicable to a generic NuPAC platform. The NuPAC platform design does not preclude meeting the requirement(s). With respect to the generic NuPAC platform: The NuPAC platform design does provide self-test features. Reference Section 3.2 of this LTR. In addition, plant-

specific applications can be designed to provide periodic surveillance test capabilities in accordance with the regulatory guidance (RG 1.22 and RG 1.118) and endorsed standard, IEEE Standard 338-1987. Support of surveillance testing is provided via the configurability (inputs/outputs and logic solving capability) of the NuPAC platform to implement such features.

5.8 Information Displays Summary-type requirement(s), compliance through sub-clauses, see below 5.8.1 Displays for Manually

Controlled Actions Plant-specific requirement(s), not applicable to the generic NuPAC platform. Display instrumentation is not part of the generic NuPAC platform.

5.8.2 System Status Indication Plant-specific requirement(s), not directly applicable to a generic NuPAC platform. Display instrumentation is not part of the generic NuPAC platform. With respect to the generic NuPAC platform: The NuPAC platform supports this requirement(s) by including inputs/outputs and logic solving capability that may be

used for this purpose. Reference Section 3.2 of this LTR. 5.8.3 Indication of Bypasses Plant-specific requirement(s), not directly applicable to a generic NuPAC platform. Display instrumentation is not part of

the generic NuPAC platform. With respect to the generic NuPAC platform: The NuPAC platform supports this requirement(s) by including inputs/outputs and logic solving capability that may be

used for this purpose. Reference Section 3.2 of this LTR. 5.8.4 Location Plant-specific requirement(s), not applicable to the generic NuPAC platform. Display instrumentation is not part of the

generic NuPAC platform. 5.9 Control of Access Plant-specific requirement(s), not directly applicable to a generic NuPAC platform.

With respect to the generic NuPAC platform: The NuPAC platform supports this requirement(s) by including inputs/outputs and logic solving capability that may be

used for this purpose. Specifically, the NuPAC platform design does provide provisions to implementation a hardwired memory protect feature for the nonvolatile memory of the NuPAC platform. Reference Section 3.2 of this LTR.


NuPAC_ED610000-047-P B 173 of 204 01/19/2012


IEEE Standard 603–1991 Compliance Matrix Section No. Section Title NuPAC Platform Compliance 5.10 Repair Plant-specific requirement(s), not directly applicable to a generic NuPAC platform.

With respect to the generic NuPAC platform: The NuPAC platform design does provide self-test, failure detection, and failure isolation features. In addition, the

Generic Logic Modules (GLMs) are hot swappable. Reference Section 3.2 of this LTR. 5.11 Identification Plant-specific requirement(s), not directly applicable to a generic NuPAC platform.

With respect to the generic NuPAC platform: The NuPAC platform design provides provisions for equipment marking. Specifically, each GLM card-top and the front

and rear faces of chassis provides areas to accommodate plant-specific markings (e.g., name plates, stenciled text, decals).

5.12 Auxiliary Features In the context of the generic NuPAC platform, all features are considered integral to the NuPAC platform design and are not classified as auxiliary features; therefore, the requirement(s) is not applicable.

5.13 Multi-Unit Stations Plant-specific requirement(s), not directly applicable to the generic NuPAC platform. The NuPAC platform design does not preclude meeting the requirement(s).

5.14 Human Factors Considerations

In the context of the generic NuPAC platform, human factors engineering (HFE) aspects are limited to interactive features, display features, and features important to human performance in support of maintenance. The generic NuPAC platform provides these features, as applicable, in accordance with the respective requirements of EPRI TR-107330.

5.15 Reliability Plant-specific requirement(s), not directly applicable to a generic NuPAC platform. With respect to the generic NuPAC platform: NuPAC platform data will be provided to support plant-specific analysis, including reliability analysis. Reliability

analysis and predictions will conform to IEEE Standard 352-1987 and IEEE Standard 577-2004. Reference Section 6.3.2 of this LTR.

6 Sense and Command Features- Functional and Design Requirements

Summary-type requirement(s), compliance through sub-clauses, see below.


NuPAC_ED610000-047-P B 174 of 204 01/19/2012


IEEE Standard 603–1991 Compliance Matrix Section No. Section Title NuPAC Platform Compliance 6.1 Automatic Control Plant-specific requirement(s), not directly applicable to a generic NuPAC platform.

With respect to the generic NuPAC platform: The NuPAC platform is designed to work in cooperation with plant-specific functional logic to automatically initiate and

execute protective actions with precision and reliability. NuPAC platform data will be provided to support plant-specific analysis, including such factors as FMEA, reliability, response time, setpoints, margins, and errors. Reference Section 6.3 of this LTR.

6.2 Manual Control Plant-specific requirement(s), not directly applicable to the generic NuPAC platform. The NuPAC platform design does not preclude meeting the requirement(s).

6.3 Interaction Between the Sense and Command Features and Other Systems

Plant-specific requirement(s), not directly applicable to the generic NuPAC platform. The NuPAC platform design does not preclude meeting the requirement(s). With respect to the generic NuPAC platform: NuPAC-based plant-specific applications will be designed to preclude non-safety system failures from affecting or

preventing any safety-related functions. If data communication is required to external non-safety-related systems, communication implementation from within a NuPAC-based safety system should be done such that the communication is under safety system control and makes use of unidirectional outbound communication only (e.g., information dissemination instead of information being gathered from non-safety systems). Reference Section 3.4.2 of this LTR.

6.4 Derivation of System Inputs Plant-specific requirement(s), not directly applicable to a generic NuPAC platform. With respect to the generic NuPAC platform: The NuPAC platform supports this requirement(s) by including inputs/outputs and logic solving capability that may be

used for this purpose. Reference Section 3.2 of this LTR. 6.5 Capability for Testing and

Calibration Plant-specific requirement(s), not directly applicable to the generic NuPAC platform. The NuPAC platform design does not preclude meeting the requirement(s).

6.6 Operating Bypasses Plant-specific requirement(s), not directly applicable to the generic NuPAC platform. The NuPAC platform design does not preclude meeting the requirement(s).

6.7 Maintenance Bypass Plant-specific requirement(s), not directly applicable to the generic NuPAC platform. The NuPAC platform design does not preclude meeting the requirement(s).


NuPAC_ED610000-047-P B 175 of 204 01/19/2012


IEEE Standard 603–1991 Compliance Matrix Section No. Section Title NuPAC Platform Compliance 6.8 Setpoints Plant-specific requirement(s), not directly applicable to a generic NuPAC platform.

With respect to the generic NuPAC platform: NuPAC platform data will be provided to support plant-specific analysis, including setpoint analysis. Information will

be provided to support an ISA S67.040-1987 compliant plant-specific setpoint analysis. Reference Section 6.3.4 of this LTR.

7 Executive Feature- Functional and Design Requirements

Summary-type requirement(s), compliance through sub-clauses, see below

7.1 Automatic Control Plant-specific requirement(s), not applicable to the generic NuPAC platform. The scope of the generic NuPAC platform does not extend into the execute features (i.e., the scope of the generic NuPAC platform ends at the sense and command features output).

7.2 Manual Control Plant-specific requirement(s), not applicable to the generic NuPAC platform. The scope of the generic NuPAC platform does not extend into the execute features (i.e., the scope of the generic NuPAC platform ends at the sense and command features output).

7.3 Completion of Protective Action

Plant-specific requirement(s), not applicable to the generic NuPAC platform. The scope of the generic NuPAC platform does not extend into the execute features (i.e., the scope of the generic NuPAC platform ends at the sense and command features output).

7.4 Operating Bypass Plant-specific requirement(s), not applicable to the generic NuPAC platform. The scope of the generic NuPAC platform does not extend into the execute features (i.e., the scope of the generic NuPAC platform ends at the sense and command features output).

7.5 Maintenance Bypass Plant-specific requirement(s), not applicable to the generic NuPAC platform. The scope of the generic NuPAC platform does not extend into the execute features (i.e., the scope of the generic NuPAC platform ends at the sense and command features output).

8 Power Source Requirements Summary-type requirement(s), compliance through sub-clauses, see below 8.1 Electrical Power Sources Plant-specific requirement(s), not directly applicable to a generic NuPAC platform.

With respect to the generic NuPAC platform: The NuPAC platform design includes provisions for the equipment to be powered by redundant +12 VDC power

supplies. Reference Section 3.2.4 of this LTR. 8.2 Non-electrical Power Sources Plant-specific requirement(s), not applicable to the generic NuPAC platform.


NuPAC_ED610000-047-P B 176 of 204 01/19/2012


IEEE Standard 603–1991 Compliance Matrix Section No. Section Title NuPAC Platform Compliance 8.3 Maintenance Bypass Plant-specific requirement(s), not directly applicable to a generic NuPAC platform.

With respect to the generic NuPAC platform: The NuPAC platform design includes provisions for the equipment to be powered by redundant +12 VDC power

supplies. Reference Section 3.2.4 of this LTR.


NuPAC_ED610000-047-P B 177 of 204 01/19/2012


APPENDIX C IEEE STANDARD 7-4.3.2-2003 COMPLIANCE MATRIX


NuPAC_ED610000-047-P B 178 of 204 01/19/2012




NuPAC_ED610000-047-P B 179 of 204 01/19/2012

Company


IEEE Standard 7-4.3.2-2003 Compliance Matrix

Section No.

Section Title

Relationship to IEEE Standard 603-1991 Requirements NuPAC Platform Compliance

1 Scope No requirements No requirements 2 References No requirements No requirements 3 Definitions and

Abbreviations No requirements No requirements

4 Safety System Design Basis

No requirements beyond IEEE Standard 603

See compliance matrix for IEEE Standard 603-1991 Section 4. Reference Appendix B of this LTR.

5 Safety System Criteria See specific subsections, below Summary-type requirement(s), compliance through sub-clauses, see below 5.1 Single-Failure Criterion No requirements beyond IEEE

Standard 603 See compliance matrix for IEEE Standard 603-1991 Section 5.1. Reference Appendix B of this LTR.

5.2 Completion of Protective Action


See compliance matrix for IEEE Standard 603-1991 Section 5.2. Reference Appendix B of this LTR.

5.3 Quality Section 5.3 requirements addresses software quality. These are in addition to IEEE Standard 603, which addresses hardware quality.

The generic NuPAC platform is being developed under a 10 CFR 50 Appendix B-compliant quality program, which complies with NQA-1-1994, RG 1.28, and ANSI N45.2, and associated daughter standards for basic components. Reference Section 1.4 of this LTR. Under the auspices of the quality assurance program, the development and integration of NuPAC hardware and programmable logic is controlled via life cycle planning documentation, including the following plans: programmable logic project management plan, programmable logic development plan, programmable logic verification and validation plan, system safety plan, quality assurance plan, programmable logic configuration management plan, programmable logic integration plan, and programmable logic test plan. A discussion of the NuPAC development life cycle and associated planning documentation is provided. Reference Section 4 and Section 5 of this LTR.

5.3.1 Software Development The quality assurance plan conforms to the requirements of IEEE Standard 730-1998. Reference Section 5.3.3 of this LTR.

5.3.1.1 Software Quality Metrics The programmable logic quality metrics activities conform to the requirements of IEEE Standard 1061-1998. Applicable quality metrics activities are incorporated in the quality assurance plan. Reference Section 5.3.3 of this LTR.


NuPAC_ED610000-047-P B 180 of 204 01/19/2012

Company



Section No.

Section Title


5.3.2 Software Tools Software tools are controlled per “NuPAC Programmable Logic Configuration Management Plan,” NuPAC document number NuPAC_PLCMP610000-001, Revision -, which conforms to the requirements of IEEE Standard 828-1990, as endorsed by RG 1.169. Reference Section 5.3.11 of this LTR. Software tools suitability is confirmed per “Software Tool Evaluation Plan,” NuPAC document number NuPAC_PLDP610000-005, Revision -. Reference Section 6.5 of this LTR.

5.3.3 Verification and Validation

V&V activities are performed in accordance with ”NuPAC Product Integration, Verification, and Validation Plan,” NuPAC document number NuPAC_PIVV610000-001, Revision -, ”NuPAC Master Test Plan”, NuPAC document number NuPAC_MTP610000-001, Revision A, and “NuPAC FPL Verification and Validation Plan,” NuPAC document number NuPAC_FVVP610000-001, Revision A. Reference Section 4.4.5, Section 4.4.4, and Section 5.3.10 of this LTR. Programmable logic V&V activities are performed in accordance with “NuPAC FPL Verification and Validation Plan,” NUPAC document number NuPAC_FVVP610000-001, Revision A, which conforms to the requirements of IEEE Standard 1012-1998, as endorsed by RG 1.168 Revision 1. Reference Section 5.3.10 of this LTR. Note integration of a NuPAC-based system in a NPP is not within the scope of the generic NuPAC platform, and as such is not part of this LTR.


NuPAC_ED610000-047-P B 181 of 204 01/19/2012

Company



Section No.

Section Title


5.3.4 Independent V&V (I-V&V) Requirements

V&V activities are performed in accordance with ‟NuPAC Product Integration, Verification, and Validation Plan,” NUPAC document number NuPAC_PIVV610000-001, Revision -, and ‟NuPAC Master Test Plan”, NUPAC document number NuPAC_MTP610000-001, Revision A, with organizational independence in accordance with the LMGI 10 CFR 50 Appendix B-compliant quality assurance program (i.e., V&V activities are performed with resources that are independent of the development resources). Reference Section 4.4.5, Section 4.4.4, and Section 1.4 of this LTR. Programmable logic V&V activities are performed in accordance with “NuPAC FPL Verification and Validation Plan,” NUPAC document number NuPAC_FVVP610000-001, Revision A, which conforms to the requirements of IEEE Standard 1012-1998, as endorsed by RG 1.168 Revision 1, with organizational independence in accordance with RG 1.168, Regulatory Position 3. Reference Section 5.3.10 of this LTR.

5.3.5 Software Configuration Management

Programmable logic configuration management activities, including programmable logic baselines and change control, are performed in accordance with “NuPAC Programmable Logic Configuration Management Plan,” NUPAC document number NuPAC_PLCMP610000-001, Revision -, which conforms to the requirements of IEEE Standard 828-1990 and the guidance of IEEE Standard 1042-1987, as endorsed by RG 1.169. Reference Section 5.3.11 of this LTR.

5.3.6 Software Project Risk Management

Programmable logic risk management activities conform to the requirements of IEEE Standard 1540-2001. Applicable risk management activities are incorporated in the “NuPAC Risk and Opportunity Management Plan,” NUPAC document number NuPAC_ROMP610000-001, Revision ‟A”. Reference Section 4.4.7 of this LTR.

5.4 Equipment Qualification Section 5.4 requirements are necessary to qualify digital computers for use in safety systems and are in addition to the equipment qualification criteria in IEEE Standard 603.



NuPAC_ED610000-047-P B 182 of 204 01/19/2012

Company



Section No.

Section Title


5.4.1 Computer System Testing

A test specimen configuration (TSC) will be utilized as a representative NuPAC-based plant-specific application. The TSC consists of a mix of functions that match the relative mix of functions identified in typical NPP safety system operational scenarios. The TSC provides representative functionality to support adequate operability and prudency to demonstrate safety functions and functionality during qualification testing. Operational performance will be monitored by recording and evaluating inputs, outputs, and built-in self-diagnostic data collected during testing. Reference Section 6.6.1 of this LTR.

5.4.2 Qualification of Existing Commercial Computers

In the context of the generic NuPAC platform, there are no existing commercial computers or commercial grade software to be installed in a nuclear facility; therefore, the requirement(s) is not applicable. For software tools, compliance through Clause 5.3.2 of IEEE Standard 7-4.3.2-2003.

5.4.2.1 Preliminary Phase of the COTS Dedication Process

In the context of the generic NuPAC platform, there are no existing commercial computers or commercial grade software to be installed in a nuclear facility; therefore, the requirement(s) is not applicable.

5.4.2.2 Detailed Phase of the COTS Dedication Process


5.4.2.3 Maintenance of Commercial Dedication


5.5 System Integrity Section 5.5 requirements are necessary to achieve system integrity in digital equipment for use in safety systems and are in addition to the system integrity criteria in IEEE Standard 603.



NuPAC_ED610000-047-P B 183 of 204 01/19/2012

Company



Section No.

Section Title


5.5.1 Design for Computer Integrity

The generic NuPAC platform has been designed and will be tested to confirm the equipment demonstrates performance adequate to ensure completion of protective actions over the full range of its design basis conditions, transient and steady state. The applicable conditions defined by EPRI TR-107330 and RG 1.180 Revision 1 formed the primary design basis. The generic NuPAC platform equipment will be qualified in accordance with EPRI TR-107330, which conforms to the requirements of IEEE Standard 323-2003 (as endorsed by RG 1.209, which complements RG 1.89) for qualifying Class 1E equipment. For electromagnetic compatibility, the generic NuPAC platform equipment will be qualified in accordance with RG 1.180 revision 1. Reference Section 6.2 of this LTR.


NuPAC_ED610000-047-P B 184 of 204 01/19/2012

Company



Section No.

Section Title


5.5.2 Design for Test and Calibration

Plant-specific requirement(s), not directly applicable to the generic NuPAC platform. The NuPAC platform design does not preclude meeting the requirement(s). With respect to the generic NuPAC platform: The NuPAC platform design does provide self-test features. Reference Section 3.2

of this LTR. In addition, plant-specific applications can be designed to provide periodic surveillance test capabilities in accordance with the regulatory guidance (RG 1.22 and RG 1.118) and endorsed standard, IEEE Standard 338-1987. Support of surveillance testing is provided via the configurability (inputs/outputs and logic solving capability) of the NuPAC platform to implement such features.

The NuPAC platform is designed to support typical NPP maintenance bypasses, such as a mutually exclusive bypassing of a single channel of sensor inputs or a single division of actuation outputs. Moreover, the NuPAC platform is designed to plant-specific functions like bypassing of one division for test and/or calibration without affecting the operation of the other divisions, automatic progression from 2 out of 4 to 2 out of 3 voting with verification (permissive functionality) that only one division is bypassed at a time for compliance with single failure, etc.

A NuPAC-based system, as defined by plant-specific requirements, can be integrated to support interfacing with a separate test and calibration computer; however, such computer is not within the scope of the generic NuPAC platform. Furthermore, the plant-specific realization of such a computer will mandate a life cycle suitable for implementing the safety function(s).

Compliance through Clause 5.5.1 of IEEE Standard 7-4.3.2-2003.


NuPAC_ED610000-047-P B 185 of 204 01/19/2012

Company



Section No.

Section Title


5.5.3 Fault Detection and Self-diagnostics

Plant-specific requirement(s), not directly applicable to the generic NuPAC platform. The NuPAC platform design does not preclude meeting the requirement(s). With respect to the generic NuPAC platform: The NuPAC platform design does provide self-test features, including power-on built-

in test, continuous built-in test, and alarms upon detecting faults. Reference Section 3.2 of this LTR. In addition, plant-specific applications can be designed to provide additional fault detection and self-diagnostic capabilities in accordance with the plant-specific requirements. Support of these capabilities is provided via the configurability (inputs/outputs and logic solving capability) of the NuPAC platform to implement such features.

Compliance through Clause 5.5.1of IEEE Standard 7-4.3.2-2003. 5.6 Independence In addition to the requirements of

IEEE Standard 603, this section addresses independence of data communication between safety channels or between safety and non-safety systems.

The NuPAC platform supports this requirement(s) by including communication features that may be used for data communication between safety channels or between safety and non-safety systems. Design guidance for the NuPAC-based systems has been documented to ensure that data independence is maintained in system designs. Reference Section 3.4 and Appendix A of this LTR. Non-safety functions, such as channel cross-comparisons, shall be performed outside the safety system to the largest extent practical. This minimizes complexity and communication requirements within the safety system. Any non-safety programmable logic to be incorporated into a NuPAC-based safety system will be designed to the same requirements and under the same process as programmable logic implementing the safety functions. While programmable logic in the system may implement non-safety functions, those functions will be designed to insure that the safety functions perform as required.

5.7 Capability for Test and Calibration




NuPAC_ED610000-047-P B 186 of 204 01/19/2012

Company



Section No.

Section Title


5.8 Information Displays The requirements in IEEE Standard 603 are limited to one-way information displays. Additional requirements are imposed for computer workstations that include control and display functions.

Plant-specific requirement(s), not directly applicable to the generic NuPAC platform. The NuPAC platform design does not preclude meeting the requirement(s). With respect to the generic NuPAC platform: A NuPAC-based system, as defined by plant-specific requirements, can be

integrated to support interfacing with separate computer workstations that include control and display functions; however, such computer is not within the scope of the generic NuPAC platform. Furthermore, the plant-specific realization of such a computer will mandate a life cycle suitable for implementing the safety function(s).

5.9 Control of Access No requirements beyond IEEE Standard 603


5.10 Repair No requirements beyond IEEE Standard 603


5.11 Identification Section 5.11 supplements IEEE Standard 603 with additional requirements to ensure that the computer system hardware and software are installed in the appropriate system configuration

Programmable logic identification activities are performed in accordance with “NuPAC Programmable Logic Configuration Management Plan,” NUPAC document number NuPAC_PLCMP610000-001, Revision -, which conforms to the requirements of IEEE Standard 828-1990 and the guidance of IEEE Standard 1042-1987, as endorsed by RG 1.169. Reference Section 5.3.11 of this LTR. The generic NuPAC platform design does provide provisions to retrieve identification data associated with the programmable devices (i.e., FPGAs and non-volatile memories). The generic NuPAC platform design does provide provisions for physical marking, including marking the programmable devices. See compliance matrix for IEEE Standard 603-1991 Section 5.11. Reference Appendix B of this LTR.

5.12 Auxiliary Features No requirements beyond IEEE Standard 603


5.13 Multi-unit Stations No requirements beyond IEEE Standard 603


5.14 Human Factor Considerations




NuPAC_ED610000-047-P B 187 of 204 01/19/2012

Company



Section No.

Section Title


5.15 Reliability In addition to the requirements of IEEE Standard 603, when reliability goals are identified, the proof of meeting the goals shall include the software

Reliability analysis and predictions conform to the requirements of IEEE Standard 352-1987 and IEEE Standard 577-2004. Reference Section 6.3.2 of this LTR.

6 Sense and Command Features—Functional And Design Requirements


See compliance matrix for IEEE Standard 603-1991 Section 6 and its sub-clauses. Reference Appendix B of this LTR.

7 Execute Features—Functional and Design Requirements



8 Power Source Requirements





NuPAC_ED610000-047-P B 188 of 204 01/19/2012


APPENDIX D DI&C-ISG-04 COMPLIANCE MATRIX


NuPAC_ED610000-047-P B 189 of 204 01/19/2012




NuPAC_ED610000-047-P B 190 of 204 01/19/2012


DI&C-ISG-04 Revision 1 Compliance Matrix Section/Staff Position Requirement NuPAC Platform Compliance

1. Interdivisional Communications/ Staff Position 1

A safety channel should not be dependent upon any information or resource originating or residing outside its own safety division to accomplish its safety function. This is a fundamental consequence of the independence requirements of IEEE Std. 603. It is recognized that division voting logic must receive inputs from multiple safety divisions.

Plant-specific requirement(s), not directly applicable to the generic NuPAC platform. The NuPAC platform design does not preclude meeting the requirement(s). With respect to the generic NuPAC platform: NuPAC-based safety systems shall not receive any information from

outside of its own safety division to perform its safety function, except as required to implement voting of the individual channel trips or to enhance the performance of the safety function, which may include communication of trip conditions, trip condition status, and bypass status information. Reference Appendix A Sections 2.3, 2.5, and 7 of this LTR.


The safety function of each safety channel should be protected from adverse influence from outside the division of which that channel is a member. Information and signals originating outside the division must not be able to inhibit or delay the safety function. This protection must be implemented within the affected division (rather than in the sources outside the division), and must not itself be affected by any condition or information from outside the affected division. This protection must be sustained despite any operation, malfunction, design error, communication error, or software error or corruption existing or originating outside the division.

Plant-specific requirement(s), not directly applicable to the generic NuPAC platform. The NuPAC platform design does not preclude meeting the requirement(s). With respect to the generic NuPAC platform: NuPAC-based safety systems shall be failsafe, and as such, the

correct operation of the interdivisional communication is only necessary to prevent a spurious trip. Reference Appendix A Section 2.3 of this LTR.

1. Interdivisional Communications/ Staff Position 3a

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. Receipt of information that does not support or enhance the safety function would involve the performance of functions that are not directly related to the safety function.

Plant-specific requirement(s), not directly applicable to the generic NuPAC platform. The NuPAC platform design does not preclude meeting the requirement(s). With respect to the generic NuPAC platform: NuPAC-based safety systems shall not receive any information from

outside of its own safety division to perform its safety function, except as required to implement voting of the individual channel trips or to enhance the performance of the safety function, which may include communication of trip conditions, trip condition status, and bypass status information. Reference Appendix A Sections 2.3, 2.5, and 7 of this LTR.


NuPAC_ED610000-047-P B 191 of 204 01/19/2012



1. Interdivisional Communications/ Staff Position 3b

Safety systems should be as simple as possible. Functions that are not necessary for safety, even if they enhance reliability, should be executed outside the safety system. A safety system designed to perform functions not directly related to the safety function would be more complex than a system that performs the same safety function, but is not designed to perform other functions. The more complex system would increase the likelihood of failures and software errors. Such a complex design, therefore, should be avoided within the safety system. For example, comparison of readings from sensors in different divisions may provide useful information concerning the behavior of the sensors (for example, On-Line Monitoring). Such a function executed within a safety system, however, could also result in unacceptable influence of one division over another, or could involve functions not directly related to the safety functions, and should not be executed within the safety system.

Plant-specific requirement(s), not directly applicable to the generic NuPAC platform. The NuPAC platform design does not preclude meeting the requirement(s). With respect to the generic NuPAC platform: NuPAC-based safety systems should perform only functions (e.g.,

calculation and monitoring of the variables) necessary for supporting or enhancing the performance of the safety function. Reference Appendix A Sections 2.3, 2.5, and 7 of this LTR.

1. Interdivisional Communications/ Staff Position 3c

Receipt of information from outside the division, and the performance of functions not directly related to the safety function, if used, should be justified. It should be demonstrated that the added system/software complexity associated with the performance of functions not directly related to the safety function and with the receipt of information in support of those functions does not significantly increase the likelihood of software specification or coding errors, including errors that would affect more than one division. The applicant should justify the definition of “significantly” used in the demonstration.

Plant-specific requirement(s), not applicable to the generic NuPAC platform. With respect to the generic NuPAC platform: NuPAC-based safety systems can receive data from outside safety

equipment, subject to the requirements in Appendix A Sections 2.3, 2.5, and 7 of this LTR.


NuPAC_ED610000-047-P B 192 of 204 01/19/2012




The communication process itself should be carried out by a communications processor, separate from the processor that executes the safety function, so that communications errors and malfunctions will not interfere with the execution of the safety function. The communication and function processors should operate asynchronously, sharing information only by means of dual-ported memory or some other shared memory resource that is dedicated exclusively to this exchange of information.

Plant-specific requirement(s), not directly applicable to the generic NuPAC platform. The NuPAC platform design does not preclude meeting the requirement(s). With respect to the generic NuPAC platform: Within NuPAC-based safety systems, interdivisional communication

functionality shall be allocated to dedicated GLMs. These GLMs shall perform no other safety functions, and shall buffer other GLMs performing other safety functions from communication errors. Reference Appendix A Section 7 of this LTR.


The function processor, the communications processor, and the shared memory, along with all supporting circuits and software, are all considered to be safety-related, and must be designed, qualified, fabricated, etc., in accordance with 10 CFR Part 50, Appendices A and B.

The generic NuPAC platform components utilized to implement interdivisional communication functionality have been designed and will be qualified and fabricated in accordance with 10 CFR Part 50, Appendices A and B. Likewise, the plant-specific application (i.e., implementation of the generic NuPAC platform components) will be designed, qualified, and fabricated in accordance with 10 CFR Part 50, Appendices A and B. Reference Section 1.4, Section 4.0, and Section 5.0 of this LTR.

1. Interdivisional Communications/ Staff Position 4c

Access to the shared memory should be controlled in such a manner that the function processor has priority access to the shared memory to complete the safety function in a deterministic manner. For example, if the communication processor is accessing the shared memory at a time when the function processor needs to access it, the function processor should gain access within a timeframe that does not impact the loop cycle time assumed in the plant safety analyses. If the shared memory cannot support unrestricted simultaneous access by both processors, then the access controls should be configured such that the function processor always has precedence.


functionality shall be allocated to dedicated GLMs. These GLMs shall perform no other safety functions, and shall buffer other GLMs performing other safety functions from communication errors. Reference Appendix A Section 7 of this LTR.

The memories of the respective GLMs (i.e., those allocated to communications versus those allocated to safety functions) are physically separate, and thus are not shared; therefore, the requirement(s) is not applicable.


NuPAC_ED610000-047-P B 193 of 204 01/19/2012



1. Interdivisional Communications/ Staff Position 4d

The safety function circuits and program logic should ensure that the safety function will be performed within the timeframe established in the safety analysis, and will be completed successfully without data from the shared memory in the event that the function processor is unable to gain access to the shared memory.

Plant-specific requirement(s), not directly applicable to the generic NuPAC platform. The NuPAC platform design does not preclude meeting the requirement(s). With respect to the generic NuPAC platform: A response time support document will be prepared for the NuPAC

platform to support future system-level response time calculations for plant-specific applications of the NuPAC platform. Reference Section 6.3.3 and Appendix A Section 2.3 of this LTR.

NuPAC-based safety systems shall be failsafe, and as such, the correct operation of the interdivisional communication is only necessary to prevent a spurious trip. Reference Appendix A Section 2.3 of this LTR.


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. This longest-possible completion time should include the response time of the memory itself and of the circuits associated with it, and should also include the longest possible delay in access to the memory by the function processor assuming worst-case conditions for the transfer of access from the communications processor to the function processor. Failure of the system to meet the limiting cycle time should be detected and alarmed.

Plant-specific requirement(s), not directly applicable to the generic NuPAC platform. The NuPAC platform design does not preclude meeting the requirement(s). With respect to the generic NuPAC platform: A response time support document will be prepared for the NuPAC

platform to support future system-level response time calculations for plant-specific applications of the NuPAC platform. Reference Section 6.3.3 and Appendix A Section 2.3 of this LTR.


The safety function processor should perform no communication handshaking and should not accept interrupts from outside its own safety division.

Plant-specific requirement(s), not directly applicable to the generic NuPAC platform. The NuPAC platform design does not preclude meeting the requirement(s). With respect to the generic NuPAC platform: There are no interrupts in the GLM design. NuPAC-based safety systems interdivisional communications shall be

designed with no requirements for handshaking or acknowledgement. Reference Appendix A Section 2.3 of this LTR.


NuPAC_ED610000-047-P B 194 of 204 01/19/2012




Only predefined data sets should be used by the receiving system. Unrecognized messages and data should be identified and dispositioned by the receiving system in accordance with the pre-specified design requirements. Data from unrecognized messages must not be used within the safety logic executed by the safety function processor. Message format and protocol should be pre-determined. Every message should have the same message field structure and sequence, including message identification, status information, data bits, etc. in the same locations in every message. Every datum should be included in every transmit cycle, whether it has changed since the previous transmission or not, to ensure deterministic system behavior.

Plant-specific requirement(s), not directly applicable to the generic NuPAC platform. The NuPAC platform design does not preclude meeting the requirement(s). With respect to the generic NuPAC platform: NuPAC-based safety systems interdivisional communications shall be

designed and implemented in the application-specific logic with fixed, predefined message formats and protocols. Reference Appendix A Section 2.3 of this LTR.


Data exchanged between redundant safety divisions or between safety and non-safety 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.


and safety to non-safety communication functionality shall be allocated to dedicated GLMs. These GLMs shall perform no other safety functions, and shall buffer other GLMs performing other safety functions from communication errors. Reference Appendix A Sections 2.3 and 7.0 of this LTR.

NuPAC-based safety systems shall be failsafe, and as such, the correct operation of the interdivisional communication is only necessary to prevent a spurious trip. Reference Appendix A Section 2.3 of this LTR.


NuPAC_ED610000-047-P B 195 of 204 01/19/2012




Incoming message data should be stored in fixed predetermined locations in the shared memory and in the memory associated with the function processor. These memory locations should not be used for any other purpose. The memory locations should be allocated such that input data and output data are segregated from each other in separate memory devices or in separate pre-specified physical areas within a memory device.


functionality shall be allocated to dedicated GLMs. These GLMs shall perform no other safety functions, and shall buffer other GLMs performing other safety functions from communication errors. Reference Appendix A Sections 2.3, 2.5, and 7.0 of this LTR.

The memories of the respective GLMs (i.e., those allocated to communications versus those allocated to safety functions) are physically separate, and thus are not shared; therefore, the requirement(s) is not directly applicable.

NuPAC-based safety systems interdivisional communications shall be designed and implemented such that incoming messages are stored in dedicated fixed predetermined memory locations in GLMs allocated to communication functionality. Likewise, those GLMs performing corresponding safety functions (i.e., function processor) shall utilize dedicated fixed predetermined memory locations to store associated data. Reference Appendix A Section Sections 2.3 and 7.0 of this LTR.


Safety division software should be protected from alteration while the safety division is in operation. On-line changes to safety system software should be prevented by hardwired interlocks or by physical disconnection of maintenance and monitoring equipment.

The generic NuPAC platform FPGA configurations can only be altered via JTAG interfaces which are not accessible when the GLM is in its installed position (i.e., plugged into the chassis), and thus changes cannot occur while the NuPAC platform is performing its safety functions. Reference Sections 3.2.1.1 and 3.2.1.3 of this LTR.


NuPAC_ED610000-047-P B 196 of 204 01/19/2012




A workstation (e.g., engineer or programmer station) may alter addressable constants, set points, parameters, and other settings associated with a safety function only by way of the dual-processor / shared-memory scheme described in this guidance, or when the associated channel is inoperable. Such a workstation should be physically restricted from making changes in more than one division at a time. The restriction should be by means of physical cable disconnect, or by means of keylock switch that either physically opens the data transmission circuit or interrupts the connection by means of hardwired logic. “Hardwired logic” as used here refers to circuitry that physically interrupts the flow of information, such as an electronic AND gate circuit (that does not use software or firmware) with one input controlled by the hardware switch and the other connected to the information source: the information appears at the output of the gate only when the switch is in a position that applies a “TRUE” or “1” at the input to which it is connected. Provisions that rely on software to effect the disconnection are not acceptable. It is noted that software may be used in the safety system or in the workstation to accommodate the effects of the open circuit or for status logging or other purposes.

Plant-specific requirement(s), not directly applicable to the generic NuPAC platform. The NuPAC platform design does not preclude meeting the requirement(s). With respect to the generic NuPAC platform: The generic NuPAC platform provides for distribution of an active low

non-volatile memory protect signal (write protect input) to all GLMs within the chassis. The memory protect signal inhibits any write to the safety critical non-volatile memory when write protect input is active. Reference Section 3.2.1.3 and Appendix A Section 2.6 of this LTR.

NuPAC-based safety systems should be designed and implemented utilizing the non-volatile memory protect feature. Reference Appendix A Section 2.6 of this LTR.


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 not in service.

The generic NuPAC platform is FPGA-based with no embedded software; therefore, the requirement(s) is not applicable.


The progress of a safety function processor through its instruction sequence should not be affected by any message from outside its division. For example, a received message should not be able to direct the processor to execute a subroutine or branch to a new instruction sequence.

The generic NuPAC platform is FPGA-based with no processor or main operating loop (MOL); therefore, the requirement(s) is not applicable.


NuPAC_ED610000-047-P B 197 of 204 01/19/2012




Communication faults should not adversely affect the performance of required safety functions in any way. Faults, including communication faults, originating in non-safety equipment, do not constitute “single failures” as described in the single failure criterion of 10 CFR Part 50, Appendix A. Examples of credible communication faults include, but are not limited to, the following: <which are not listed here>


and safety to non-safety communication functionality shall be allocated to dedicated GLMs. These GLMs shall perform no other safety functions, and shall buffer other GLMs performing other safety functions from communication errors. Reference Appendix A Sections 2.3, 2.5, and 7 of this LTR.


Vital communications, such as the sharing of channel trip decisions for voting, should include provisions for ensuring that received messages are correct and are correctly understood. Such communications should employ error-detecting or error-correcting coding along with means for dealing with corrupt, invalid, untimely, or otherwise questionable data. The effectiveness of error detection/correction should be demonstrated in the design and proof testing of the associated codes, but once demonstrated is not subject to periodic testing. Error-correcting methods, if used, should be shown to always reconstruct the original message exactly or to designate the message as unrecoverable. None of this activity should affect the operation of the safety-function processor.

Plant-specific requirement(s), not directly applicable to the generic NuPAC platform. The NuPAC platform design does not preclude meeting the requirement(s). With respect to the generic NuPAC platform: NuPAC-based safety systems shall be designed and implemented

utilizing serial communication data quality checks at least as robust as a CRC-16 check. Reference Appendix A Sections 2.3, 2.5, and 7of this LTR.

NuPAC-based safety systems may be designed and implemented utilizing serial communication error-correcting code (ECC). Reference Appendix A Section 2.5 of this LTR.


Vital communications should be point-to-point by means of a dedicated medium (copper or optical cable). In this context, “point-to-point” means that the message is passed directly from the sending node to the receiving node without the involvement of equipment outside the division of the sending or receiving node. Implementation of other communication strategies should provide the same reliability and should be justified.

Plant-specific requirement(s), not directly applicable to the generic NuPAC platform. The NuPAC platform design does not preclude meeting the requirement(s). With respect to the generic NuPAC platform: NuPAC-based safety systems shall be designed and implemented

utilizing point-to-point serial data links. Reference Appendix A Section 2.3 of this LTR.


NuPAC_ED610000-047-P B 198 of 204 01/19/2012




Communication for safety functions should communicate a fixed set of data (called the "state") at regular intervals, whether data in the set has changed or not.


designed and implemented in the application-specific logic with fixed, predefined message formats and protocols. Reference Appendix A Sections 2.3 and 2.5 of this LTR.


Network connectivity, liveness, and real-time properties essential to the safety application should be verified in the protocol. Liveness, in particular, is taken to mean that no connection to any network outside the division can cause an RPS/ESFAS communication protocol to stall, either deadlock or livelock. Note: This is also required by the independence criteria of:

1) 10 CFR Part 50, Appendix A, General Design Criteria (“GDC”) 24, which states, “interconnection of the protection and control systems shall be limited so as to assure that safety is not significantly impaired.”; and

2) IEEE 603-1991 IEEE Standard Criteria for Safety Systems for Nuclear Power Generating Stations.) (Source: NUREG/CR-6082, 3.4.3)


designed and implemented in the application-specific logic to expect to receive communication messages from applicable sources at a pre-determined interval, and shall flag failures to receive valid messages as errors. Reference Appendix A Section 2.3 and 2.5 of this LTR.


Pursuant to 10 C.F.R. §50.49, the medium used in a vital communications channel should be qualified for the anticipated normal and post-accident environments. For example, some optical fibers and components may be subject to gradual degradation as a result of prolonged exposure to radiation or to heat.

Plant-specific requirement(s), not applicable to the generic NuPAC platform.


In addition, new digital systems may need susceptibility testing for EMI/RFI and power surges, if the environments are significant to the equipment being qualified.

For electromagnetic compatibility and power surges, the generic NuPAC platform equipment will be qualified in accordance with RG 1.180 Revision 1. Reference Section 6.2 and Appendix A Section 5 of this LTR.


NuPAC_ED610000-047-P B 199 of 204 01/19/2012




Provisions for communications should be analyzed for hazards and performance deficits posed by unneeded functionality and complication.

Plant-specific requirement(s), not applicable to the generic NuPAC platform.


If data rates exceed the capacity of a communications link or the ability of nodes to handle traffic, the system will suffer congestion. All links and nodes should have sufficient capacity to support all functions. The applicant should identify the true data rate, including overhead, to ensure that communication bandwidth is sufficient to ensure proper performance of all safety functions. Communications throughput thresholds and safety system sensitivity to communications throughput issues should be confirmed by testing.


designed and implemented with sufficient capacity. Data throughput for interdivisional communication links shall be calculated based on evaluation of the data items to be passed, the message formats, the message protocols, and processing times of both the sending and the receiving GLMs. Data throughput for interdivisional communication links shall be verified and validated during testing activities. Reference Appendix A Sections 2.3, 2.5, and 7 of this LTR.


The safety system response time calculations should assume a data error rate that is greater than or equal to the design basis error rate and is supported by the error rate observed in design and qualification testing.

Plant-specific requirement(s), not directly applicable to the generic NuPAC platform. The NuPAC platform design does not preclude meeting the requirement(s). With respect to the generic NuPAC platform: Means will be provided to calculate the maximum data delay

associated with each GLM, which can then be aggregated into the data delay through the system (see Section 6.3.3 of this LTR). Since the data delay is directly proportional to the amount of data sent, and since the baud rate for each message path is pre-defined as part of the application-specific design, each application for an individual system design will require calculation of the maximum delay due to data transmission. This analysis will be part of the system’s total delay analysis, which will include assumptions concerning additional delays associated with faults and failures in communicated messages. Reference Appendix A Section 2.3 of this LTR.

2. Command Prioritization/ Staff Positions 1 to 10

Various requirements for Priority Logic Modules Priority Logic Modules are not included in this LTR. Therefore, the positions provided do not apply to this LTR.


NuPAC_ED610000-047-P B 200 of 204 01/19/2012



3.1 Independence and Isolation/ Staff Position 1

Non-safety stations receiving information from one or more safety divisions.

Requirements are provided in this LTR to handle safety to non-safety unidirectional communication. Reference Appendix A Section 2.3 of this LTR.

3.1 Independence and Isolation/ Staff Position 2

Safety related stations receiving data from one or more safety divisions

This LTR does not license multiple divisional video display units. However, the guidance for single division video display units is adopted in this LTR. Reference Appendix A Sections 2.3 and 2.5, of this LTR. In addition, data crossing divisional boundaries and data provided from external systems that does not cross divisional boundaries are discussed in this LTR. Reference Appendix A Sections 2.3, 2.5, and 7 of this LTR.

3.1 Independence and Isolation/ Staff Positions 3 to 5

Various requirements for multi-divisional communication Communications as described in these staff positions are not included in this LTR. Therefore, the positions provided to not apply to this LTR.

3.2 Human Factors Considerations

Various requirements for Human Factors Engineering for the associated system

Human factors engineering not discussed in the LTR. LGMI expects HFE to be part of the plant-specific application; therefore, the positions provided do not apply to this LTR.

3.3 Diversity and Defense-in-Depth Considerations

Various requirements for D3 analyses The base LTR does not provide a diverse solution. However, an approach to creating sufficient diversity is included in the LTR. Reference Section 7 and Appendix A Section 3 of this LTR.


NuPAC_ED610000-047-P B 201 of 204 01/19/2012




NuPAC_ED610000-047-P B 202 of 204 01/19/2012


APPENDIX E DI&C-ISG-06 COMPLIANCE MATRIX


NuPAC_ED610000-047-P B 203 of 204 01/19/2012




NuPAC_ED610000-047-P B 204 of 204 01/19/2012


DI&C-ISG-06 Revision 1 Compliance Matrix Section No. Section Title NuPAC Platform Compliance A Introduction No requirements B Purpose No requirements C Digital I&C Review Process No requirements D Review Areas Summary-type requirement(s), compliance through sub-clauses, see below D.1 System Description Summary-type requirement(s), compliance through sub-clauses, see below D.1.1 Scope of Review No requirements D.1.2 Information to Be Provided System description provided in Section 3.1 of this LTR. As required, additional details available

in “System Description Document,” NUPAC document number NuPAC_SYS610000-001, Revision A

Digital hardware configuration items identified in Section 3.1.4 of this LTR D.1.3 Regulatory Evaluation No requirements D.1.4 Technical Evaluation No requirements D.1.5 Conclusion No requirements D.2 Hardware Development Process Summary-type requirement(s), compliance through sub-clauses, see below D.2.1 Scope of Review No requirements D.2.2 Information to Be Provided Hardware design process described in Section 4.0 of this LTR D.2.3 Regulatory Evaluation No requirements D.2.4 Technical Evaluation No requirements D.2.5 Conclusion No requirements D.3 Software Architecture Summary-type requirement(s), compliance through sub-clauses, see below D.3.1 Scope of Review No requirements D.3.2 Information to Be Provided Programmable logic architecture summarized in Section 3.3 of this LTR

Programmable logic architecture description provided in the “NuPAC Programmable Logic Development Specification - Core PLCI,” NUPAC document number NuPAC_PLDS610400-001, Revision -

Programmable logic configuration items identified in Section 3.1.4 of this LTR D.3.3 Regulatory Evaluation No requirements D.3.4 Technical Evaluation No requirements D.3.5 Conclusion No requirements


NuPAC_ED610000-047-P B 205 of 204 01/19/2012


DI&C-ISG-06 Revision 1 Compliance Matrix Section No. Section Title NuPAC Platform Compliance D.4 Software Development Processes Summary-type requirement(s), compliance through sub-clauses, see below D.4.1 Scope of Review No requirements D.4.2 Information to Be Provided Software development process for programmable logic described in Section 5.0 of this LTR

Organizational structure identified in Section 5.2 of this LTR Compliance through Clause D.4.4 of DI&C-ISG-06

D.4.3 Regulatory Evaluation No requirements D.4.4 Technical Evaluation Summary-type requirement(s), compliance through sub-clauses, see below D.4.4.1 Software Planning Documentation Summary-type requirement(s), compliance through sub-clauses, see below D.4.4.1.1 Software Management Plan (SMP) SMP summarized in Section 5.3.1 of this LTR

Reference “NuPAC Programmable Logic Project Management Plan,” NUPAC document number NuPAC_PLPMP610000-001, Revision -

D.4.4.1.2 Software Development Plan (SDP) SDP summarized in Section 5.3.2 of this LTR Reference “NuPAC Programmable Logic Development Plan,” NUPAC document number

NuPAC_PLDP610000-001, Revision - D.4.4.1.3 Software Quality Assurance Plan (SQAP) SQAP summarized in Section 5.3.3 of this LTR.

Reference “Quality Assurance Plan,” NUPAC document number NuPAC_QAP610000-001, Revision A.

D.4.4.1.4 Software Integration Plan (SIntP) SIntP summarized in Section 5.3.4 of this LTR Reference “NuPAC Programmable Logic Integration Plan - Core PLCI,” NUPAC document

number NuPAC_PLDP610000-004, Revision - D.4.4.1.5 Software Installation Plan (SInstP) Plant-specific requirement(s), not applicable to the generic NuPAC platform D.4.4.1.6 Software Maintenance Plan (SMaintP) Plant-specific requirement(s), not applicable to the generic NuPAC platform D.4.4.1.7 Software Training Plan (STrngP) Plant-specific requirement(s), not applicable to the generic NuPAC platform D.4.4.1.8 Software Operations Plan (SOP) Plant-specific requirement(s), not applicable to the generic NuPAC platform D.4.4.1.9 Software Safety Plan (SSP) SSPP summarized in Section 5.3.9 of this LTR

Reference “System Safety Plan,” NUPAC document number NuPAC_SSPP610000-001, Revision A

D.4.4.1.10 Software Verification and Validation Plan (SVVP) SVVP summarized in Section 5.3.10 of this LTR Reference “NuPAC Field-programmable Logic Verification and Validation Plan,” NUPAC

document number NuPAC_FVVP610000-001, Revision A


NuPAC_ED610000-047-P B 206 of 204 01/19/2012


DI&C-ISG-06 Revision 1 Compliance Matrix Section No. Section Title NuPAC Platform Compliance D.4.4.1.11 Software Configuration Management Plan (SCMP) SCMP summarized in Section 5.3.11 of this LTR

Reference “Programmable Logic - Configuration Management Plan,” NUPAC document number NuPAC_PLCMP610000-001, Revision -

D.4.4.1.12 Software Test Plan (STP) STP summarized in Section 5.3.12 of this LTR Reference draft of “NuPAC Programmable Logic Test Plan - Core PLCI,” NUPAC document

number NuPAC_TPL610400-001 (available for audit) D.4.4.2 Software Plan Implementation Summary-type requirement(s), compliance through sub-clauses, see below D.4.4.2.1 Software Safety Analysis (SSA) Software safety analysis submitted as part of Phase 2 review information D.4.4.2.2 V&V Analysis and Reports V&V analysis and reports submitted as part of the Phase 2 review information D.4.4.2.3 Configuration Management Activities System configuration documentation submitted as part of the Phase 2 review information D.4.4.2.4 Testing Activities Test design specifications submitted as part of the Phase 2 review information

Summary test reports submitted as part of the Phase 2 review information Summary of test results submitted as part of the Phase 2 review information

D.4.4.3 Design Outputs Summary-type requirement(s), compliance through sub-clauses, see below D.4.4.3.1 Software Requirements Specification (SRS) Reference “NuPAC Programmable Logic Requirement Specification - Core PLCI,” NUPAC

document number NuPAC_PLRS610400-001, Revision - D.4.4.3.2 Software Architecture Description (SAD) Reference “NuPAC Programmable Logic Development Specification - Core PLCI,” NUPAC

document number NuPAC_PLDS610400-001, Revision - D.4.4.3.3 Software Design Specification Reference “NuPAC Programmable Logic Development Specification - Core PLCI,” NUPAC

document number NuPAC_PLDS610400-001, Revision - D.4.4.3.4 Code Listings During Phase 2, code listing available for thread audits D.4.4.3.5 System Build Documents (SBDs) SBDs submitted as part of Phase 2 review information D.4.4.3.6 Installation Configuration Tables Configuration tables submitted as part of the Phase 2 review information D.4.4.3.7 Operations Manual Plant-specific requirement(s), not applicable to the generic NuPAC platform D.4.4.3.8 Software Maintenance Manuals Plant-specific requirement(s), not applicable to the generic NuPAC platform D.4.4.3.9 Software Training Manuals Plant-specific requirement(s), not applicable to the generic NuPAC platform D.4.5 Conclusion No requirements D.5 Environmental Equipment Qualifications Summary-type requirement(s), compliance through sub-clauses, see below D.5.1 Scope of Review No requirements


NuPAC_ED610000-047-P B 207 of 204 01/19/2012


DI&C-ISG-06 Revision 1 Compliance Matrix Section No. Section Title NuPAC Platform Compliance D.5.2 Information to Be Provided Equipment qualification described in Section 6.0 of this LTR

Reference “Master Test Plan,” NUPAC document number NuPAC_MTP610000-001, Revision A Equipment qualification test methodologies submitted as part of Phase 2 review information Equipment qualification summary reports submitted as part of Phase 2 review information

D.5.3 Regulatory Evaluation The generic NuPAC platform equipment will be qualified in accordance with EPRI TR-107330, which conforms to the requirements of IEEE Standard 323-2003 (as endorsed by RG 1.209, which complements RG 1.89) for qualifying Class 1E equipment. For electromagnetic compatibility, the generic NuPAC platform equipment will be qualified in accordance with RG 1.180 Revision 1. Reference Section 6.2 of this LTR.

D.5.4 Technical Evaluation Summary-type requirement(s), compliance through sub-clauses, see below D.5.4.1 Atmospheric Temperature and humidity testing summarized in Section 6.2.2 of this LTR

Reference “Master Test Plan,” NUPAC document number NuPAC_MTP610000-001, Revision A D.5.4.2 Radiation Radiation withstand testing summarized in Section 6.2.4 of this LTR

Reference “Master Test Plan,” NUPAC document number NuPAC_MTP610000-001, Revision A D.5.4.3 Electromagnetic Interference/Radio Frequency

Interference Summary-type requirement(s), compliance through sub-clauses, see below

D.5.4.3.1 Susceptibility EMI/RFI testing summarized in Section 6.2.5 of this LTR Reference “Master Test Plan,” NUPAC document number NuPAC_MTP610000-001, Revision A

D.5.4.3.2 Interference EMI/RFI testing summarized in Section 6.2.5 of this LTR Reference “Master Test Plan,” NUPAC document number NuPAC_MTP610000-001, Revision A

D.5.4.4 Sprays and Chemicals Generic NuPAC platform design basis does not include exposure to sprays; therefore, requirement(s) not applicable

D.5.4.5 Seismic Seismic testing summarized in Section 6.2.3 of this LTR Reference “Master Test Plan,” NUPAC document number NuPAC_MTP610000-001, Revision A

D.5.5 Conclusion No requirements D.6 Defense-in-Depth and Diversity Summary-type requirement(s), compliance through sub-clauses, see below D.6.1 Scope of Review No requirements D.6.2 Information to Be Provided NuPAC platform methodology to address Diversity and Defense-in-Depth provided in

Section 7.0 of this LTR D.6.3 Regulatory Evaluation No requirements


NuPAC_ED610000-047-P B 208 of 204 01/19/2012


DI&C-ISG-06 Revision 1 Compliance Matrix Section No. Section Title NuPAC Platform Compliance D.6.4 Technical Evaluation NuPAC platform methodology to address Diversity and Defense-in-Depth provided in

Section 7.0 of this LTR D.6.4.1 Adequate Safety System Diversity and Manual

Actions Plant-specific requirement(s), not applicable to the generic NuPAC platform

D.6.4.2 Diverse Displays and Controls for System Level Actuation

Plant-specific requirement(s), not applicable to the generic NuPAC platform

D.6.5 Conclusions No requirements D.7 Communications Summary-type requirement(s), compliance through sub-clauses, see below D.7.1 Scope of Review No requirements D.7.2 Information to Be Provided NuPAC platform approach to data communication provided in Section 3.4 of this LTR

A DI&C-ISG-04 compliance matrix, for area of interest #1, provided in Appendix D of this LTR D.7.3 Regulatory Evaluation NuPAC platform approach to data communication provided in Section 3.4 of this LTR

A DI&C-ISG-04 compliance matrix, for area of interest #1, provided in Appendix D of this LTR D.7.4 Technical Evaluation NuPAC platform approach to data communication provided in Section 3.4 of this LTR

A DI&C-ISG-04 compliance matrix, for area of interest #1, provided in Appendix D of this LTR D.7.5 Conclusions No requirements D.8 System, Hardware, Software, and Methodology

Modifications Since the generic NuPAC platform has not be previously reviewed by the USNRC, the

requirement(s) not applicable D.9 Compliance with IEEE Std. 603 IEEE Standard 603-1991 compliance matrix provided in Appendix B of this LTR D.10 Conformance with IEEE Std. 7-4.3.2 IEEE Standard 7-4.3.2-2003 compliance matrix provided in Appendix C of this LTR D.11 Technical Specifications Summary-type requirement(s), compliance through sub-clauses, see below D.11.1 Scope of Review No requirements D.11.2 Information to Be Provided Plant-specific requirement(s), not applicable to the generic NuPAC platform D.11.3 Regulatory Evaluation Plant-specific requirement(s), not applicable to the generic NuPAC platform D.11.4 Technical Evaluation Plant-specific requirement(s), not applicable to the generic NuPAC platform D.11.5 Conclusion No requirements D.12 Secure Development and Operational Environment Summary-type requirement(s), compliance through sub-clauses, see below D.12.1 Scope of Review No requirements


NuPAC_ED610000-047-P B 209 of 204 01/19/2012


DI&C-ISG-06 Revision 1 Compliance Matrix Section No. Section Title NuPAC Platform Compliance D.12.2 Information to Be Provided Generic NuPAC platform vulnerability assessment and associated methodology to apply secure

development and operational environment controls summarized in Section 9.0 of this LTR Reference “NuPAC Vulnerability Assessment,” NUPAC document number NuPAC_ED610000-

041, Revision - Reference “NuPAC System Security Plan,” NUPAC document number NuPAC_SSP610000-

001, Revision - D.12.3 Regulatory Evaluation Generic NuPAC platform vulnerability assessment and associated methodology to apply secure



001, Revision - D.12.4 Technical Evaluation Generic NuPAC platform vulnerability assessment and associated methodology to apply secure



001, Revision - D.12.5 Conclusion No requirements


NuPAC_ED610000-047-P B 210 of 204 01/19/2012


APPENDIX F DOCUMENTATION CROSS-REFERENCE MATRIX


NuPAC_ED610000-047-P B 211 of 204 01/19/2012




NuPAC_ED610000-047-P B 212 of 204 01/19/2012


DI&C-ISG-06 Tier 3 Phase 1 Document Cross-Reference Matrix

DI&C-ISG-06 Enclosure B Documents for Tier 3 Phase 1 Review

Corresponding NuPAC Document Submitted/ Available for Audit Description Document Identifier

Hardware Architecture Descriptions Licensing Topical Report, Section 3.2 NuPAC_ED610000-047-P Submitted NuPAC Generic Logic Module (GLM) DAR NuPAC_ED610300-011 Submitted Chassis/Rear Transition Module (RTM) Design Report NuPAC_ED610100-003 Submitted

Quality Assurance Plan for Digital Hardware NuPAC Quality Assurance Plan NuPAC_QAP610000-001 Submitted Software Architecture Descriptions Licensing Topical Report, Section 3.3 NuPAC_ED610000-047-P Submitted

NuPAC Programmable Logic Development Specification - Core PLCI

NuPAC_PLDS610400-001 Submitted

Software Management Plan NuPAC Programmable Logic Project Management Plan

NuPAC_PLPMP610000-001 Submitted

Software Development Plan NuPAC Programmable Logic Development Plan NuPAC_PLDP610000-001 Submitted

Software QA Plan NuPAC Quality Assurance Plan NuPAC_QAP610000-001 Submitted Software Integration Plan NuPAC Programmable Logic Integration Plan –

Core PLCI NuPAC_PLDP610000-004 Submitted

Software Safety Plan NuPAC System Safety Plan NuPAC_SSPP610000-001 Submitted Software V&V Plan NuPAC FPL Verification and Validation Plan NuPAC_FVVP610000-001 Submitted

Software Configuration Management Plan NuPAC Programmable Logic Configuration Management Plan

NuPAC_PLCMP610000-001 Submitted

Software Test Plan NuPAC Programmable Logic Test Plan - Core PLCI NuPAC_TPL610400-001 Available for Audit1 Software Requirements Specification NuPAC Programmable Logic Requirement

Specification – Core PLCI NuPAC_PLRS610400-001 Available for Audit2

Software Design Specification NuPAC Programmable Logic Development Specification – Core PLCI

NuPAC_PLDS610400-001 Submitted

Equipment Qualification Testing Plans NuPAC Master Test Plan NuPAC_MTP610000-001 Submitted D3 Analysis Licensing Topical Report, Section 7.0 NuPAC_ED610000-047-P Submitted Design Analysis Reports NuPAC Generic Logic Module (GLM) DAR NuPAC_ED610300-011 Submitted

Chassis/Rear Transition Module (RTM) Design Report NuPAC_ED610100-003 Submitted System Description (to block diagram level) Licensing Topical Report, Section 3.1 NuPAC_ED610000-047-P Submitted


NuPAC_ED610000-047-P B 213 of 204 01/19/2012


DI&C-ISG-06 Tier 3 Phase 1 Document Cross-Reference Matrix

DI&C-ISG-06 Enclosure B Documents for Tier 3 Phase 1 Review

Corresponding NuPAC Document Submitted/ Available for Audit Description Document Identifier

NuPAC System Description NuPAC_SYS610000-001 Available for Audit3 Design Report on Computer Integrity, Test and Calibration, and Fault Detection

NuPAC Generic Logic Module (GLM) DAR NuPAC_ED610300-011 Submitted Chassis/Rear Transition Module (RTM) Design Report NuPAC_ED610100-003 Submitted

System Response Time Analysis Report Licensing Topical Report, Section 6.3.3 NuPAC_ED610000-047-P Submitted Theory of Operation Description Licensing Topical Report, Section 3.1 NuPAC_ED610000-047-P Submitted

Setpoint Methodology Licensing Topical Report, Section 6.3.4 NuPAC_ED610000-047-P Submitted Vendor Software Plan Not Applicable4 Software Tool Verification Program Software Tool Evaluation Plan NuPAC_PLDP610000-005 Submitted

Software Project Risk Management Program NuPAC Risk and Opportunity Management Plan NuPAC_ROMP610000-001 Submitted Commercial Grade Dedication Plan NuPAC Commercial-Grade Item/

Service Dedication Plan NuPAC_CGDP610000-001 Submitted

Vulnerability Assessment NuPAC Vulnerability Assessment NuPAC_ED610000-041 Submitted Secure Development and Operational Environment Controls

NuPAC System Security Plan NuPAC_SSP610000-001 Submitted

Notes: 1 At the time of this writing and commensurate with the programmable logic development, the test plan was preliminary and is not included as part of the Phase 1 submittal. As the programmable logic development progresses, the test documentation will be finalized, including the test plan. 2 The programmable logic DOORS® database is available for audit to support USNRC review. 3 The content of Section 3.1 of this LTR is believed to provide a sufficient system description. As required, additional details are available in the LMGI/SNPAS “System Description Document”, NuPAC document number NuPAC_SYS610000-001, Revision A. 4 A Vendor Software Plan is not applicable, as the NuPAC platform does not include the integration of vendor provided software.

As part of the Phase 2 information submittal, this appendix will be updated to include a DI&C-ISG-06 Tier 3 Phase 2 document submittal cross-reference matrix.