DCL-13-048, Response to Request for Additional Information on License Amendment Request for Digital Process Protection System Replacement and Submittal of Revised PPS Replacement System Quality Assurance Plan

Response to Request for Additional Information on License Amendment Request for Digital Process Protection System Replacement and Submittal of Revised PPS Replacement System Quality Assurance Plan

ML13130A059
Person / Time
Site:	Diablo Canyon
Issue date:	05/09/2013
From:	Allen B Pacific Gas & Electric Co
To:	Office of Nuclear Reactor Regulation, Document Control Desk
References
DCL-13-048
Download: ML13130A059 (49)

Text

Pacific Gas and Electric Company Barry S. Allen Diablo Canyon Power Plant Site Vice President Mail Code 104/6 P. O. Box 56 Avila Beach, CA 93424 805.545 . 4888 May 9, 201 3 Internal: 691.4888 Fax: 805.545.6 445 PG&E Letter DCL-13-048 u.s. Nuclear Regulatory Commission 10 CFR 50.90 ATTN: Docu ment Control Desk Washington, DC 20555-0001 Docket No. 50-275, OL-DPR-80 Docket No. 50-323, OL-DPR-82 Diablo Canyon Units 1 and 2 Response to Request for Additionallhformation on License Amendment Request for Digital Process Protection System Replacement and Submittal of Revised PPS Replacement System Quality Assurance Plan

References:

1. PG&E Letter DCL-11-104, "License Amendment Request 11-07, Process Protection System Replacement," dated October 26, 2011 (ADAMS Accession No. ML11307A331 ).

2. Digital Instrumentation and Controls Digital I&C-ISG-06, "Task Working Group #6: Licensing Process, Interim Staff Guidance,"

Revision 1, January 19, 2011 (ADAMS Accession No. ML110140103).

3. NRC Letter "Diablo Canyon Power Plant, Unit Nos. 1 and 2 -

Acceptance Review of License Amendment Request for Digital Process Protection System Replacement (TAC Nos. ME7522 and ME7523)," dated January 13, 2012.

4. NRC Letter "Diablo Canyon Power Plant, Unit Nos. 1 and 2 - Request For Additional Information Regarding Digital Replacement of the Process Protection System Portion of the Reactor Trip System and Engineered Safety Features Actuation System (TAC NOS. ME7522 AND ME7523)," dated April 12, 2013 (ADAMS Accession No. ML13101A072).

Dear Commissioners and Staff:

In Reference 1, Pacific Gas and Electric (PG&E) submitted License Amendment Request (LAR) 11-07 to request NRC Staff (Staff) approval to replace the Diablo Canyon Power Plant (DCPP) Eagle 21 digital process protection system (PPS) with a new digital PPS that is based on the Invensys Operations Management Tricon Programmable Logic Controller, Version 10, and the CS Innovations, LLC (CS Innovations) (a Westinghouse Electric Company), Advanced Logic System. The LAR A member of the STARS (Strategic Teaming and Resource Sharing) Alliance Callaway. Comanche Peak. Diablo Canyon

• Palo Verde

• San Onofre

• South Texas Project. Wolf Creek

Document Control Desk PG&E Letter DCL-13-048 May 9,2013 Page 2 format and contents in Reference 1 are consistent with the guidance provided in Enclosure E and Section C.3, respectively, of Digital Instrumentation and Controls (I&C), Revision 1, of Interim Staff Guidance Digital I&C-ISG-06, "Task Working Group #6: Licensing Process," (ISG-06) (Reference 2). In Reference 3, the Staff documented its acceptance of Reference 1 for review.

The NRC requested additional information to complete the review of Reference 1 in Reference 4. This letter responds to the additional information requested in Reference 4.

This information does not affect the results of the technical evaluation or the significant hazards consideration determination previously transmitted in Reference 1.

In addition, the revised PPS replacement System Quality Assurance Plan (SyQAP) document is submitted. The PPS Replacement SyQAP, Revision 1, is contained in to the Enclosure and supersedes SyQAP, Revision 0, previously submitted in Reference 1.

If you have any questions, or require additional information, please contact Mr. Tom Baldwin at (805) 545-4720.

This communication does not contain regulatory commitments (as defined by NEI 99 04).

I state under penalty of perjury that the foregoing is true and correct.

Executed on May 9, 2013.

Sincerely, B"!!C;:Zn5. ~

Site Vice President kjse/4328 SAPN 50271918 Enclosure cc: Diablo Distribution cc/enc: Thomas R. Hipschman, NRC Senior Resident Inspector Arthur T. Howell, III, NRC Region IV Gonzalo L. Perez, Branch Chief, California Department of Public Health James T. Polickoski, NRR Project Manager A member of the STARS (Strategic Teaming and Resource Sharing) Alliance Callaway

• Comanche Peak

• Diablo Canyon

• Palo Verde

• San Onofre

• South Texas Project

• Wolf Creek

Enclosure PG&E Letter DCL-13-048 Response to Request for Additional Information on license Amendment Request for Digital Process Protection System Replacement and Submittal of Revised PPS Replacement System Quality Assurance Plan In Pacific Gas and Electric (PG&E) Letter DCL-11-104, "License Amendment Request 11-07, Process Protection System Replacement," dated October 26,2011, PG&E submitted License Amendment Request (LAR) 11-07 to request NRC Staff (Staff) approval to replace the Diablo Canyon Power Plant (DCPP) Eagle 21 digital process protection system (PPS) with a new digital PPS that is based on the Invensys Operations Management Tricon Programmable Logic Controller, Version 10, and the CS Innovations, LLC (CS Innovations) (a Westinghouse Electric Company), Field Programmable Gate Array (FPGA) based Advanced Logic System (ALS). The LAR 11-07 format and contents are consistent with the guidance provided in Enclosure E and Section C.3, respectively, of Digital Instrumentation and Controls (I&C), Revision 1, of Interim Staff Guidance Digitall&C-ISG-06, "Task Working Group #6: Licensing Process." The Staff documented its acceptance of LAR 11-07 for review in the NRC Letter "Diablo Canyon Power Plant, Unit Nos. 1 and 2 - Acceptance Review of License Amendment Request for Digital Process Protection System Replacement (TAC Nos. ME7522 and ME7523)," dated January 13, 2012.

The Staff requested additional information to support the review of LAR 11-07 in NRC Letter "Diablo Canyon Power Plant, Unit Nos. 1 and 2 - Request For Additional Information Regarding Digital Replacement of the Process Protection System Portion of the Reactor Trip System and Engineered Safety Features Actuation System (TAC NOS. ME7522 AND ME7523)," dated April 12, 2013 (ADAMS Accession No. ML13101A072). The requested additional information (RAI) is addressed below for RAls twenty-one to fifty-three. Each RAI begins with a reference to an Open Item (01) that corresponds to the number of the item in the 01 table that PG&E has discussed with the NRC staff during various public meetings. Response to RAls one to nine, eleven to thirteen, and fifteen to twenty were previously provided in PG&E Letter DCL-12-083, "Response to Request for Additional Information on License Amendment Request for Digital Process Protection System Replacement," dated September 11,2012 (ADAMS Accession No. ML12256A308). RAls ten and fourteen were not used and therefore did not require a response.

Several responses state that information contained in the RAI response has been included in the supplement to LAR 11-07 that was submitted separately in PG&E Letter DCL-13-043, "Supplement to License Amendment Request 11-07, 'Process Protection System Replacement,'" dated April 30, 2013. Any commitments contained in these responses have been included in the new commitments contained in the supplement to LAR 11-07 (PG&E Letter DCL-13-043).

1

Enclosure PG&E Letter DCL-13-048 NRC RAI21 (01 21 and 01 35) Software Test Plan'- Westinghouse/CS Innovations (CSI)

Document 6116-00005, "Diablo Canyon PPS System Test Plan," states that the ALS-102 FPGA design is changed for the DCPPS System. Furlher, Section 5.3.3 states: "Test as many of the ALS-1 02 requirements as possible." Please identify what document describes the design verification test for this board.

The scope of Revision 1 of Document 6116-00005 is different from the scope described in Revision 0 of that same document. For example, Section 1.2 in both revisions states that test coverage includes all ALS modules, backplane, line sense modules (LSM), and ALS service unit (ASU). However Section 2 is different between revisions 0 and 1. Revision 1 only focuses on ALS-1 02 and backplane assemblies. This section does not include other ALS modules, LSM and ASU as in Revision O. Please explain why these other ALS modules are not included in Section 2 of revision 1.

PG&E Response to RAI 21 The documents that describe the design verification tests for the ALS-1 02 board are ALS Document Nos. 6116-70140, "Diablo Canyon PPS System Test Design Specification" and 6116-10216, "Diablo Canyon PPS VV Simulation Environment Specification."

The scope of both Revisions 0 and 1 of the DCPP PPS Test Plan, ALS Document No. 6116-00005, are the same. The Revision 1 changes to the DCPP PPS Test Plan added more detail into the overall scope. The details are broken down into two main parts, the individual components and the system components.

The combination of both parts encompass the entire ALS based DCPP system which includes all ALS modules, the backplane, the ASU, LSM, ALS-102A18 Boards specific to DCPP, and the full ALS subsystem test, which includes the testing of ALS slave cards required by the DCPP configuration.

NRC RAI22 (01 38) Software Management Plan - PG&E document "PPS Replacement Concept, Requirements, and Licensing Phase 1 Project Plan," Revision 1 (Attachment 3 of the license amendment request [LAR]), Section 2, "Project Organization" does not describe the activities to be performed by the Engineering of Choice Design Change Package Team. Additionally, this document does not clarify the roles and responsibilities for this team. Please clarify and provide the applicable PG&E control document that describes PG&E roles and responsibilities specifically for the Engineering of Choice Design Change Package Team.

2

Enclosure PG&E Letter DCL-13-048 PG&E Response to RAI 22 The activity performed by the Engineering of Choice Design Change Package Team is to support PG&Ein development of the design change package for the PPS replacement project. PG&E has a contract with an engineering company, currently Enercon Services, Inc., to be the "engineer of choice," to provide nuclear engineering design services to PG&E. For individual scopes of work, PG&E develops a purchase request for the scope of work and a purchase order is issued to the engineering company that is the engineer of choice. When the engineer of choice is performing a design change package for DCPP, the engineer of choice uses the PG&E Design Change Procedure, CF3.ID9, "Design Change Development," and PG&E performs an owner acceptance of the work using PG&E Procedure CF3.ID17, "Design and Analysis Documents Prepared by External Contractors. "

NRC RAI23 (0139) Software Management Plan - Figure 2-1 of the PG&E document, "PPS Replacement Concept, Requirements, and Licensing Phase 1 Project Plan," and Figure 3-1 of the PPS System Quality Assurance Plan (SyQAP) identify "Altran" under the PG&E Project Engineering box. However, Figure 4-1 of the PPS System Replacement Verification and Validation Plan (SyVVP) identifies the "PG&E project team" under the PG&E Project Engineering box. Please provide a description of the roles and responsibilities for "Altran" and the "PG&E project team" during the PPS Replacement Project.

PG&E Response to RAI 23 The PPS Organization Chart shown in Figure 4-1 of the PPS SyVVP, Revision 0, was a simplified rendering of the organization charts in Figure 2-1 of the Project Plan and Figure 3-1 of the PPS SyQAP. The SyVVP, Revision 1, includes a revised Figure 4-1 that is the same as Figure 2-1 of the Project Plan and Figure 3-1 of the SyVVP, and that identifies the Altran Project Team under the Project Team that is under the Diablo Canyon PPS Upgrade Project Manager.

Altran is acting as a subcontractor providing engineering support to the PG&E Project Team. Altran supported the LAR preparation and is providing continuing support through the LAR review process. Altran's work is governed by the Altran Engineering Procedures Manual. Documents submitted to PG&E are prepared in accordance with Altran procedures Altran Operating Procedure 3.3 (reports) and Engineering Operating Procedure (EOP) 5.4 (specifications). All Altran documents are verified in accordance with Altran EOP 3.4 (verification). In addition, PG&E accepts Altran documents under PG&E Procedure CF7.ID4, "Processing of Documents Received from Suppliers," as applicable.

3

Enclosure PG&E Letter DCL-13-048 NRC RAI24 (0141) Software Verification and Validation (V&V) and Test Plan -

Westinghouse/CSI Document 6116-00005, "Diablo Canyon PPS System Test Plan,"

Revision 1, Section B.2 identifies the software tools to be used in the PPS replacement project. However, this list is not consistent with the list of Independent Verification and Validation (IV&V) tools identified in Section 3.6 of ALS V&V Plan, Document 6002-00003. Specifically, the test tools identified in 6002-00003 are not listed in 6116-00005 and vice versa. For example, the V& V Plan (6002-00003) identifies Automated test Equipment (ATE) tool for IV&V, but this tool is not listed in 6116-0005, Revision 1. Furlhermore, the staff reviewed 6116-0005, Revision 0, and found that the A TE tool was listed in this version. Please clarify what software tools will be used and what document describes them.

PG&E Response to RAI 24 A new revision of the ALS V&V Plan 6002-00003, Revision 8, Figure 3-2, identifies the ALS Board Test System (ABTS) and the IV&V Simulation Environment (ISE) as the IV&V test tools. This new revision was docketed February 15, 2013, on the ALS platform docket. The ATE is removed from the set of IV&V test tools. The tools listed in Section 8.2 of the DCPP PPS Test Plan, Document No. 6116-00005, Revision 1, and the tools listed in DCPP PPS V&V Simulation Environment Specification, Document No. 6116-10216, Revision 1, encompass the IV&V test tools in the ALS V&V Plan, 6002-00003, Revision 8.

NRC RAI25 (01 42) Software V& V - The PG&E "PPS System Replacement Verification and Validation Plan (SyVVP) " does not describe the V&V activities to be petformed during the Operation Phase and Maintenance Phase. This document states that these activities are covered by approved DCPP procedures. Please identify these procedures.

PG&E Response to RAJ 25 Control of the software modifications to the Tricon and ALS platforms, once the PPS replacement project is completed and the PPS is in the Operations and Maintenance phase, is by the Process Protection System Replacement Software Configuration Management Plan, SCM 36-01, Revision 0, which was submitted as part of the Phase 2 document submittal on June 6, 2012, in Attachment 4 to the Enclosure of PG&E Letter DCL-12-050. Modification to the PPS replacement components produced by the vendors, CS Innovations and Invensys Operations Management, will need to be performed by the vendors, and verification and validation is controlled by the vendor verification and validation plans created for the 4

Enclosure PG&E Letter DCL-13-048 DCPP PPS replacement (Document No. 6116-00003 for CS Innovations and Document No. 993754-1-802 for Invensys Operations Management).

NRC RAI26 (0143) Software V&V - PG&E "PPS System Replacement System Verification and Validation Plan (SyVVP),: Section 5. 1. 1, explains that during the Concept Phase, PG&E will verify system requirements in accordance with PG&E Procedure CF2.ID9, "Software Quality Assurance for Software Development."

However, Staff understanding is that Procedure CF2.ID9 is for in-house development of software applications. Please explain how this procedure is going to be used to verify the system requirements for the DCPP PPS replacement project.

Furlhermore, Section 5.1.2 of Procedure CF2.ID9 states that an independent review of the functional requirements prepared during the Concept Phase would be performed. The PG&E SyVVP does not identify this review, and thus there is no specific V&V product for this phase. Please identify who will perform this review and if this review is considered a V&V product.

PG&E Response to RAI 26 Altran developed the PPS Replacement Functional Requirement Specifications (FRS) during the Concept Phase in accordance with Altran procedure EOP 5.4, and verified it in accordance with Altran Procedure EOP 3.4. Altran used PG&E Procedure CF3.ID16, "Specifications," for additional guidance. PG&E accepted the FRS under PG&E Procedure CF7.ID4, which constituted verification of system requirements. The development of the FRS was a design activity rather than a V&V activity and there is no specific V&V product for this phase.

NRC RAI27 (0146) Software V&V - Several sections in the Invensys document 993754-1-802, "Software Verification and Validation Plan (SVVP) " reference "applicable Project Procedure Manual (PPM)" to perform cerlain activities. The Reference section in this document only identifies "PPM" (see Reference 2.4.4). It is not clear if the PPM is constituted by several procedures or if it is only one procedure. For example, Section 1.1, states the SVVP was prepared in accordance with PPM 7.0 (Ref. 2.4.4), and then Section 4 states that V&Vactivities will be planned and scheduled in accordance with the applicable PPM. Please describe what the PPM is, and explain how this is going to be used in the PPS replacement project.

5

Enclosure PG&E Letter DCL-13-048 PG&E Response to RAI 27 The PPM provides appropriate controls for project activities conducted at the Invensys Lake Forest facility. These controls will ensure that all nuclear Class 1E projects (or non-1 E projects where the customer has specified certain 1E requirements) processes, project activities, and project documents will meet the requirements of 10 CFR 50, Appendix B, 10 CFR 21, and the Invensys Quality Management System. This procedures manual provides specific controls for Invensys Operations Management North America Delivery as well as other Invensys organizations that perform nuclear safety-related system integration project activities. The PPM is a collection of different procedures, including referenced forms, and is a controlled document. Each PPM procedure is intended to implement key areas of project activities. Each procedure within the PPM is assigned a unique document number and title.

Several procedures within the PPM, as defined in the SVVP, Invensys Document No. 993754-1-802, govern the V&V activities during the PPS Replacement Project.

The SVVP was revised in Document No. 993754-1-802, Revision 3, to add the title of each procedure within the PPM where the PPM is referenced. For example, in the SVVP, Section 1.1, where it previously stated that, "the SVVP is prepared in accordance with PPM 7.0 (Ref. 2.4.4)," has been revised to state that "the SVVP is prepared in accordance with PPM 7.0, Application Program Development." The revised SVVP, Revision 3, was submitted in PG&E Letter DCL-12-028, "Submittal of Revised System Verification and Validation Plan and Tricon Documents for the License Amendment Request for Digital Process Protection System Replacement,"

dated March 25, 2013.

NRC RAI28 (0147) Software V&V -Invensys Document No. 993754-1-802, "Software Verification and Validation Plan" requires the use of V& V metrics to evaluate software development process and products. This section does not explain what methods and criteria will be used for software safety metrics. The need for and imparlance of this information is described in RG 1. 152, "Criteria for Use of Computers in Safety Systems of Nuclear Power Plants;" RG 1. 173, "Developing Software Life Cycle Processes for Digital Computer Software Used in Safety Systems of Nuclear Power Plants;" IEEE Standard 1061, "Software Quality Metrics Methodology;" and IEEE Standard 1074, "Developing Software Life Cycle Processes. Please provide this information.

PG&E Response to RAI 28 The V&V metrics are used during development of the PPS replacement software that eventually will reside/execute on the V1 0 Tricon portion of the PPS replacement. The V&V metrics measure the thoroughness of V&V reviews and 6

Enclosure PG&E Letter DCL-13-048 testing efforts. These measurements yield data utilized to gain reasonable assurance that the design outputs are of high quality commensurate with the intended use in the PPS replacement application. The V&V metrics methodology, utilizing a diversity of software measures, provides insight into the rigor of the PPS software development process. V&V uses three distinct metrics during PPS software development, Software Quality Metrics, V&V Effectiveness Metrics, and Software Safety Metrics, that are described below.

Software Quality Metrics The purpose of these metrics is to measure software quality by tracking the number of defects found in the design outputs (e.g., design documents, software). The method is to count and categorize defects found during V&V review of design outputs. The acceptance criterion is that no technical defects remain at the end of the current phase to receive V&V recommendation to proceed to the next project phase. Any defects that cause the noncompliance with customer requirements and/or noncompliance with NRC guidance are considered technical defects.

V&V Effectiveness Metrics The purpose of these metrics is to measure the effectiveness of V&V reviews by measuring the percentage of design outputs which V&V reviews or tests. The method determines the percentage of design outputs actually reviewed by V&V, which is meaningful for in-process design changes necessitating a change impact analysis, revisions to released design outputs, and a regression analysis. The Acceptance Criterion is that 100 percent of comprehensive or delta change reviews is achieved in the current phase to receive V&V recommendation of proceeding to the next project phase.

Software Safety Metrics The purpose of these metrics is to assess whether software safety requirements are being met. Methods are to count software hazards found during V&V review or testing of design outputs and to confirm software hazard mitigation in each project phase, or at a minimum, by the end of the project and approval at the completion of acceptance testing. The Acceptance Criterion is that all software hazards are mitigated by the end of the Test Phase to receive approval of the results of acceptance testing.

NRC RAI29 (0149) Software V&V -Invensys Document No~ 993754-1-802, "Software Verification and Validation Plan," Section 6.3 states that the Invensys personnel prepared the System Deficiency Integration Reporl (SDIR) to document non-7

Enclosure PG&E Letter DCL-13-048 conformances and corrective actions during testing, and that the SDIR is prepared in accordance with PPM 10. O. Please explain what PPM this is.

Furlhermore, the Invensys "Validation Test Plan," Section 5.4.2 states that the Test Review Board and PG&E shall review SOIRs, but this is not indicated in the Invensys V& V plan. Please explain why this review activity is not identified as a V& V task in the V& V Plan.

PG&E Response to RAI 29 The PPM 10.0 Procedure defines the process to control nonconforming items and identify appropriate corrective action for all nuclear application projects developed at the Invensys Operations Management (Invensys) Lake Forest facility. This procedure is intended to provide controls for nonconforming items and corrective actions related to project activities. As used in the PPM 10.0 Procedure, the term "nonconformance" describes deficiencies in parts and materials (items),

documentation, and/or deviations from stated requirements. This procedure addresses the identification, documentation, evaluation, and disposition of nonconforming items. This procedure also describes the corrective action process to be used for project-related issues where corrective action is warranted.

Section 6.3 of Invensys Document No. 993754-1-802, Revision 3, "Software Verification and Validation Plan", has been revised to reference PPM 10.0 for the guidelines for the SDIR. Also, Section 5.4.2 of the system-level Validation Test Plan (VTP), Document No. 993754-1-813, Revision 2, has been revised to state that the Project Review Committee (PRC) shall review and approve the disposition of all SIDRs and assure that all required testing has been satisfactorily performed and that PG&E representative(s) will also review and approve the disposition of all SIDRs. The revised VTP, Revision 2, was submitted in PG&E Letter DCL-12-028, "Submittal of Revised System Verification and Validation Plan and Tricon Documents for the License Amendment Request for Digital Process Protection System Replacement," dated March 25, 2013.

NRC RAI30 (01 50) Software V&V - The Invensys document "Validation Test Plan," Section 8.2, states that the Narrative Test Logs are used to document conduct of testing and any anomalies that occur. Please explain if the Narrative Test Logs are used only during validation, and why this is not mentioned in the Invensys SVVP. Furlhermore, please explain how the Narrative test Logs are used in conjunction with Document Review Comment Sheet (ORCS) and System Deficiency Integration Reporl (SDIR)?

8

Enclosure PG&E Letter DCL-13-048 PG&E Response to RAI 30 PPM 6.0, Test Control, defines the Test Logs. All test activities shall be recorded in a Test Log. The Test Log constitutes a continuous, hand-written journal of all test activities from the point of initial entry into the Test Procedure until the conclusion of all testing, including any required retesting. The Test Log shall include entries for sign-in and sign-out of all participating personnel, establishment of indicated prerequisites and initial conditions for testing, and performance of testing and retesting, identification of problems, etc. The Test Log is intended to be a detailed journal of all testing activities sufficient to fully document the actual sequence of testing performed, the test results achieved, and any problems that occurred, including their impact on test performance. The Test Log shall be reviewed by the PRC as part of its evaluation of the test results.

The Test Logs are independent and separate from the DRCS and SDIR. However, as a test narrative, the Test Log may identify the fact that a SDIR was generated as a result of test anomaly.

NRC RAI31 (01 51. 1.a) Software Configuration Management - In 01 4, the Staff requested the description of the software configuration management activities for configurable boards (e.g., ALS FPGA-102 board). Since the ALS FPGA-102 board is customer specific to the PG&E design, its configuration management activities are not covered by the "ALS Configuration Management Plan." Even though item 4 is closed, this request was not addressed in the response to item 4. Please complete the response to 01 4.

PG&E Response to RAI 31 The FPGA installed on the ALS-1 02 board itself is specific to the DCPP PPS Protection set and the ALS subsystem in which it is installed. PG&E will not have the capability to alter the FPGA. Any change to the FPGA must be made by CS Innovations. PG&E capability to change ALS-1 02 configuration is limited to ALS-102 board-level replacement. ALS-102 FPGA configuration management activities are covered by the CS Innovations Document No. 6002-00002, "ALS Configuration Management Plan,"

'NRC RAI32 (01 51. 1.b) Software Configuration Management - The PG&E Software Configuration Management Plan (SCMP) SCM 36-01, Item 1.2.8, states that ALS board has two sets of Non-Volatile Random Access Memory (NVRAM).

Furlhermore, this item explains that the configuration of the NVRAM can be changed only by removing the subject board from the ALS chassis and inserling it 9

Enclosure PG&E Letter DCL-13-048 into a special test fixture. It is not clear who controls the NVRAM configuration process. Please explain.

PG&E Response to RAI 32 ALS input/output (I/O) boards are generic; that is, each board is configured using its NVRAM for the specific function it is to perform. This activity is described in PG&E Document No. SCM 36-01, "PPS Replacement Software Configuration Management Plan", Section 1.2.8, which states that the configuration of the NVRAM is changed by removing the subject board from the ALS chassis and inserting it into a special test fixture. This would be performed as part of a maintenance activity, such as replacing a failed board. If the functionality of an I/O board required modification as a result of an application change, then all required NVRAM configuration alterations would need to be performed by CS Innovations under the ALS Configuration Management Plan.

PG&E will not have the capability to alter the NVRAM configuration itself. PGE capability to change the NVRAM configuration for a specific I/O board will be limited to loading NVRAM images, that are under CS Innovations configuration control, and that have been previously verified and validated at the system level by CS Innovations. Configuring the NVRAM in order to replace an I/O board will be performed by PG&E under an approved plant maintenance procedure. This information has been included in revised Section 4.5.7.3 of the supplement to LAR 11-07.

NRC RAI33 (01 51.1.c) Software Configuration Management - Section 1.2 of the Invensys Document No. 993754-1-909, "Software Configuration Management Plan,"

states that this plan controls the operating system of the computers used to run TriStation 1131 and the signal simulation software used for testing purposes.

However, the description provided throughout the plan only focuses on the configuration activities for the Test Software Application Program (TSAP) and not for the TriStation 1131 (e.g., Section 2.3 states that the software configuration management (SCM) procedures are for the TSAP). Furthermore and later in this same section identifies the software configuration to be managed, and this list does not include the operating system of the computers used to run TriStation 1131 and the signal simulation software used for testing purpose. Please clarify the scope of this plan and how the configuration of TriStation 1131 and the signal simulation software is managed.

PG&E Response to RAI 33 There was no intent for the Invensys Document No. 993754-1-909, SCMP, to do more than track the revision of Commercial Off The Shelf (COTS) software, such as 10

Enclosure PG&E Letter DCL-13-048 the operating system of the computers used to run TriStation 1131 and the signal simulation software used for testing purposes. In this case "Control" is defined as tracking the revision levels such that they are recorded on the project Master Configuration List, Invensys project Document No. 993754-1-803. On Page 7 of the SCMP, under "Limitations," it states, in part, that the SCMP will track COTS software revision levels (see SCMP page 7 excerpt below).

"Limitations The SCMP is limited to the software and documentation created by Invensys Operations Management. Commercial Off The Shelf (COTS) software, such as Microsoft's operating system, or software supplied by the customer are tracked by revision but Invensys Operations Management is not responsible for configuration management of COTS software."

NRC RAI34 (01 51.3.b) Software Configuration Management - Section 3.2.4.7 of the SCM 36-01 states that PG&E uses an SAP order to track changes, but the same Section 3.2.4.7 also states that both the Change Package and an SAP order are entered in the Record Management System to track changes. Additionally, Section 3.3 describes a Configuration Status Account, which is used to track changes of configuration items. Please clarify and describe what PG&E uses to track changes.

PG&E Response to RAI 34 The means to track modifications related changes is the SAP order. The Record Management System (RMS) is the system used at DCPP to store and allow retrieval of documents to meet 10 CFR 50, Appendix B, quality assurance requirements.

Completed Change Packages and SAP orders are entered into the RMS for storage and to allow later retrieval.

NRC RAI35 (0155) Final Safety Analysis Report (FSAR) - PG&E Letter DCL-12-050 dated June 6, 2012, "Submittal of Phase 2 Documents for the License Amendment Request for Digital Process Protection System Replacement," Attachment 2, "Final Safety Analysis Report Changes for Process Protection System Replacement," FSAR Section 7.1.2.5, "Conformance with Other Applicable Documents" (page 7.1-13) does not indicate that the NRC Safety Evaluation, that is, the NRC staff's basis for the potential approval of the PPS LAR, will be incorporated into this documentation.

The staff's Safety Evaluation Report (SER) should become part of the DCPP Unit 1&2 licensing basis once it is issued. How will the SER for the PPS LAR be documented within the FSAR?

11

Enclosure PG&E Letter OCL-13-048 PG&E Response to RAI 35 The reference to the Staff SER was included in FSAR Section 7.2.1.1.5 for the reactor trip portion of the process protection system and in Section 7.3.1.1.4.1 for the engineered safety features actuation system portion of the process protection system in the FSAR markups included in Attachment 5 to the Enclosure of PG&E Letter OCL-13-043, "Supplement to License Amendment Request 11-07,

'Process Protection System Replacement,'" dated April 30, 2013.

NRC RAI36 (0156) Final Safety Analysis Report - PG&E Letter DCL-12-050 dated June 6,2012, "Submittal of Phase 2 Documents for the License Amendment Request for Digital Process Protection System Replacement," Attachment 2, "Final Safety Analysis Report Changes for Process Protection System Replacement," FSAR Section 7.2. 1.2, "Design Basis Information" (page 7.2-23) states that the evaluation for common mode failure in the PPS is presented in the DCPP PPS Diversity and Defense-in-Depth (D3) Licensee Topical Report (L TR) and approved in the staff's SER for the DCPP PPS D3 L TR. It is noted, however, that this staff D3 SER states that theD3 design features were approved based on confirmation that the proposed built-in diversity of the ALS sUb-system is found to be acceptable. This confirmation will be performed as part of the forthcoming DCPP PPS SER. Please confirm that a reference to the SER for the DCPP PPS will be included in the FSAR.

PG&E Response to RAI 36 The reference to the Staff SER for LAR 11-07 was included in FSAR Section 7.2.2.1.2, in addition to the Staff SER for the OCPP 03 LTR, in the FSAR markups included in Attachment 5 to the Enclosure of PG&E Letter OCL-13-043, "Supplement to License Amendment Request 11-07, 'Process Protection System Replacement,'" dated April 30, 2013.

NRC RAI37 (0157) Final Safety Analysis Report - PG&E Letter DCL-12-050 dated June 6, 2012, "Submittal of Phase 2 Documents for the License Amendment Request for Digital Process Protection System Replacement," Attachment 2, "Final Safety Analysis Report Changes for Process Protection System Replacement," FSAR, Section 7.2.2.2.9.2, "IEEE 603-1991 Clause 5, System," Clause 5.12, "Auxiliary Features" (Page 12) states that ".. .the communication path between the maintenance workstation and the ALS subsystem is normally disabled with a hardwired switch ... " Also, Attachment 3, "PG&E PPS Interface Requirements Specification (IRS)," Revision 6 to PG&E Letter DCL-12-069 dated August 2, 2012, states in Section 1.5.6 "... TAB communications between the ALS and Maintenance Work Station (MWS) takes place via RS-485 data link. The TAB is physically 12

Enclosure PG&E Letter DCL-13-048 disconnected from the MWS when the TAB is not in use ... the TAB is open at all times unless maintenance is being performed on the ALS ... " Please identify administrative controls and design features associated with the PPS that are used to control how the MWS is disconnected/disabled from the PPS.

PG&E Response to RAI 37 The communication link from the ALS subsystem to the ALS MWS will be physically disconnected when the Test ALS Bus (TAB) is not being used for surveillance testing, maintenance, and trouble-shooting. When the TAB is used for surveillance testing, maintenance, or trouble shooting, the connection to the ALS subsystem will be performed under administrative control using an approved plant procedure.

This is a PPS replacement design change that has been included in revised Sections 3.2.2.2 and 4.2.13.5 of the supplement to LAR 11-07. Section 4.2.13.5 of the supplement to LAR 11-07 states" ... the MWS functions that use interactive TAB communications will be available: (1) only when the TAB is physically connected to the ALS MWS by qualified personnel under administrative controls; and (2) only on one ALS '~" or "B" subsystem at a time."

NRC RAI38 (01 58) CSI Failure Modes and Effects Analysis (FMEA) - There are several failure modes identified in Table 4-4 of the CS Innovations Document 6116-00029, "Diablo Canyon PPS ALS Reliability Analysis and FMEA" where the System Effects entry provides a description of functions that are not affected by the failure mode identified, instead of stating what the effects of the failure mode are. For example, the System Effects in the Energize to Trip (ETT) failure in line 5b of table 4-4 are that the Alarm Function remains operational. Though this may be the case, it does not state what the effects of the failure mode are. Other examples of this can be found in lines 5b, 6a, 6b, 7a, 9h, 9i, 11 b, 11 c, and 11 d. Please provide appropriate and complete information for System Effects in Table 4-4.

PG&E Response to RAI 38 In the ALS Document No. 6116-00029, Revision 1, "Diablo Canyon PPS ALS Reliability Analysis and FMEA," the System Effects entry does describe the functions that are affected by the failure mode. For example, the cited row for ETT failure in line 5b discusses the effects of failures of the ALS-402-1 digital output board, which sends Alarm Signals to other systems. In the case of ETT a stuck open output channel will prevent the core A rack from being able to actuate the Alarm (an ETT Alarm is cited in the row for ETT failure in line 5b, the "Containment Pressure in Test Alarm"). Due to the ALS compensating features, which in this case is the redundant implementation of the function in the ALS Core B Rack, the System Effect is that the alarm function remains operational. A similar explanation applies to the other examples cited.

13

Enclosure PG&E Letter DCL-13-048 NRC RAI39 (01 60) Technical Specifications - In order for the NRC staff to make a determination that the existing technical specifications and surveillance intervals remain acceptable for the replacement PPS system, an evaluation to compare the ALSlTricon PPS system reliability and performance characteristics with those of the Eagle 21 system must be performed by PG&E.

Please provide an evaluation summary reporl to supporl the application of existing technical specification and surveillance test intervals to the upgraded ALSlTricon based PPS. This summary reporl is expected to include a quantitative analysis to demonstrate the new system's ability to perform its required safety functions between established surveillance test intervals. This reporl should also include a qualitative (i.e., deterministic) analysis which describes the self diagnosis and fault detection features of the replacement PPS. In addition, this summary reporl should address the staff's previous findings in Section 4.3, "Applicability of WCAPs

['Westinghouse Commercial Atomic Power' reporlsj to DCPP," of Amendment No.

179, dated January 31,2005 (ADAMS Accession No. ML050330315).

PG&E Response to RAI 39 An evaluation summary report to support application of the existing technical specification (TS) and TS surveillance test intervals is contained in the Westinghouse Document, "Justification for the Application of Technical Specification Changes in WCAP-14333 and WCAP-15376 to the Tricon/ALS Process Protection System," that was submitted in Attachment 9 to the Enclosure of PG&E Letter DCL-13-016, "Submittal of Setpoint Calculations, Setpoint Methodology, and Justification for Application of Technical Specification Changes in WCAP-14333 and WCAP-15376 Documents for the License Amendment Request for Digital Process Protection System Replacement," dated March 5, 2013. The document provides a qualitative comparison of features important to the reliability of the Tricon and ALS subystems and the Eagle 21 system, evaluates the applicability of the WCAP-14333-P-A, Revision 1, and WCAP-15376-P-A, Revision 1, analyses to the PPS replacement configuration, and evaluates the compliance with the Staff conditions and limitations contained in the NRC safety evaluations for WCAP-14333 and WCAP-15376 and Section 4.3 of the Amendments No. 179 for DCPP Unit 1 and No.

181 for DCPP Unit 2. Additional information on the evaluation summary report has been included in Section 4.12.3 of the supplement to LAR 11-07.

14

Enclosure PG&E Letter DCL-13-048 NRC RAI40 (01 64) Software Management Plan - To close Items 27 and 29, PG&E issued the DCPP PPS Project Quality Assurance Plan to define the oversight activities to be petiormed during the PPS replacement project. Section 2 of this plan describes the responsibilities of those involved in oversight activities. However, it is not clear how these roles and responsibilities correlate to the project organization described in PG&E PPS Replacement Plan (Attachment 3 of the LAR) and PG&E PPS Replacement System Quality Assurance Plan (Attachment 4 of the LAR). For example, the Project Quality Assurance Plan describes the responsibilities of the "PPS replacement" Project Manager, but this role is not described in other documents. Furthermore, the responsibility described seems to align with the responsibility of the "PG&E" Project Manager. Please explain the relationship, if any, of the roles and responsibilities described in the DCPP PPS Project Quality Assurance Plan and those provided in other PG&E plans.

PG&E Response to RAI 40 The "Quality Assurance Plan for Diablo Canyon Process Protection System Replacement" was a project-specific document created by the Quality Verification group (a Quality Assurance (QA) organization) to identify the QA tasks to be performed by the Quality Verification group for the project. The "Quality Assurance Plan for Diablo Canyon Process Protection System Replacement" provides the specific plan to be used by the "Supervisor Project QA" identified in Section 3.5.1 (Page 19) of the System Quality Assurance Plan (SyQAP) and the "Project QA Engineer or Equivalent" identified in Section 3.5.8 of the SyQAP to provide PG&E quality oversight for the project which in part supports meeting 10 CFR 50, Appendix B, QA requirements for the project. The DCPP Project Manager has overall project responsibilities including quality of design, timely integration with site schedules, supplier quality management/oversight, quality field implementation, and successful post-installation testing. The DCPP Project Manager shares the responsibility for meeting the quality goals and objectives of the project and for the implementation of quality management throughout the project.

Figure 2-1 in the PPS Replacement Project Plan, Revision 2, has been revised to include the DCPP Supervisor of Supplier Quality, and Section 2.1.1 has been revised to include the responsibility for the DCPP Supervisor of Supplier Quality.

Figure 3-1 in the SyQAP, Revision 1, has been revised to include the DCPP Supervisor of Supplier Quality, and Section 3.3.1.2 has been revised to include the responsibility for the DCPP Supervisor of Supplier Quality.

NRC RAI41 (01 66) - Section 4.2. 13. 1 of the LAR (page 85) states, "... The NetOptics port aggregator tap device (Port Tap) was approved previously by NRC for a similar 15

Enclosure PG&E Letter DCL-13-048 application in the Oconee Reactor Protection System (RPS)/(Engineered Safeguards Protection System (ESPS) SER Section 3.1.1.4.3. The NRC staff determined that due to the electrical isolation provided by use of fiber optic cables and the data isolation provided by the Pori Tap and the Maintenance and Service Interface (MSI) in the Oconee RPS, there was reasonable assurance that a fault or failure within the Oconee Gateway computer or the Operator Aid Computer will not adversely affect the ability of the Oconee safety protection system to accomplish its safety functions. "

The Tricon V10 topical repori safety evaluation also approved the NetOptics Pori aggregator Tap, Model 96443, No. PA-CU, or PAD-CU, as an acceptable data isolation device.

Please verify that the model number of the Pori Tap that PG&E will use in the DCPP PPS is the same as Model 96443 and provide an explanation of its equivalency to the Pori Tap approved for the Oconee RPS/ESPS LAR.

PG&E Response to RAI 41 The PPS replacement application will use the NetOptics Model PA-CU Network Port Aggregator Tap to isolate the Tricon portion of the PPS replacement from the gateway computer, as described in Section 4.2.13.1 of the supplement to LAR 11-07. NetOptics has confirmed via e-mail (Case# 205591) that part number "96443" is the same as PA-CU. Part number "96443" is the old SKU part number for the Model PA-CU Network Port Aggregator Tap.

NRC RAI42 (0167) Section 4.2.13.1 of the DCPP PPS LAR (pg. 85) states, "Pori aggregator dual in-line package (DIP) switch positions will be controlled by DCPP configuration management processes."

Please provide a documented basis (e.g., a plant procedure, or engineering design package) that demonstrates how DIP switch positions will be controlled.

PG&E Response to RAI 42 The Port aggregator DIP switch positions will be controlled by a plant procedure or plan that will be developed as part of the design change for installation of the PPS replacement after NRC approval of the LAR. These controls have been included in revised Section 4.2.13.1 of the supplement to LAR 11-07.

16

Enclosure PG&E Letter DCL-13-048 NRC RAI43 (0172) KVM Switch Question 3 - The KVM (keyboard, video, mouse) switch brochure indicates that there are other features and paris that may not be used for the DCPP PPS safety system. Please enumerate which features will not be used for the DCPP PPS application and explain how these unused features, such as the audio interface, unused USB (universal serial bus) poris, and remote control/channel switching by external control, will be disabled and how configuration control will be maintained for these disabled features.

PG&E Response to RAI 43 Section 2.3.7 of the Interface Requirement Specifications (IRS) states the KVM switch shall permit only connections between a single computer and the selected video display and peripheral devices. Connection between the computers shall not be permitted. In addition Section 2.3.7 of the IRS states the AV4PRO-VGA KVM switch shall utilize the default switching mode, in which the video display, keyboard and mouse and the enumerated USB ports are all switched simultaneously. This specification prevents the enumerated ports from being switched separately from the KVM. The user console's two switched USB ports, which use enumerated switching, pass data straight through the KVM switch without interpretation. If a keyboard is connected to the USB 1 or USB2 port, the hotkeys cannot be used to perform switching, and USB 1 and USB2 traffic cannot cause an inadvertent switch.

The keyboard and mouse use the emulated switching function, not the enumerated switching function, and thus only the keyboard, mouse, and the button on the KVM switch can control the switch. A user console switched USB port will be used by the local printer for each protection set.

The unused MWS and KVM switch ports are addressed in accordance with the DCPP Cyber Security Program. The local printer for each protection set is controlled by the PG&E SCMP. Remote control KVM switching or KVM firmware update requires a custom serial cable. The KVM firmware update requires specialized software on the computer being used to perform the update. KVM firmware update will only be done by procedure. The MWS and KVM switch will be inside a locked cabinet inside a vital area inside the protected area, which will minimize the possibility of the inadvertent actions. In addition, administrative and PG&E SCMP configuration controls prevent inadvertent loading of an Erasable Programmable Read Only Memory (EPROM) image that could corrupt operation of the KVM switch.

This information has been included in new Section 4.2.14 of the supplement to LAR 11-07.

17

Enclosure PG&E Letter DCL-13-048 NRC RAI44 (0173) KVM Switch Question 4 - This question is related to RAI # 46 and may be answered in conjunction with that RAI response if desired. Please explain how a KVM switch failure that permits data flows between the two platforms (Tricon V10 and ALS), would not corrupt the safety function of the Tricon V10 and ALS systems.

If the safety function for one or both platforms is affected by the KVM switch failure, then explain how the PPS will still perform its safety functions in light of these failures. If the KVM switch failure will not cause the platforms to fail then provide a detailed explanation of how the engineering design principals of the Tricon/ALS platforms physically prevent bad/erroneous data from corrupting the platforms.

More directly, explain how these erroneous messages emanating from the MWS (regardless of origin) will be disregarded/rejected by the Tricon/ALS platforms.

PG&E Response to RAI 44 The design of the Transmit Busses TxB 1 and TxB2 data communication paths from the ALS-1 02 Core Logic Board and the Gateway Computer and MWS, respectively, are EIA-422 communication links in which receive capability is physically disabled by hardware as described in CSI Document No. 6002-10202, ALS-1 02 Design Specification. The receiver is configured such that the transmit data is looped back for channel integrity testing. The ALS-1 02 is physically and electrically incapable of receiving information from outside the ALS-1 02. Therefore, messages are effectively disregarded or rejected by the ALS-1 02 since they are never received from the ALW MWS. Additional information is provided in the response to RAI 46 and RA149.

The RS-422 is the common short form title of American National Standards Institute (ANSI) standard ANSIiTIAlEIA-422-B Electrical Characteristics of Balanced Voltage Differential Interface Circuits. This technical standard specifies the electrical characteristics of the balanced voltage digital interface circuit. For the purposes of the LAR 11-07, the two designations are equivalent and may be used interchangeably.

NRC RAI45 (01 76) Tricon V10 platform changes/software revisions - The documents listed below are necessary for the staff to complete its assessment of the Tricon V10 platform changes and software revisions that have occurred since the platform was approved generically, and will be applied to the DCPP PPS:

a. Product Discrepancy Reporl (PDR) IRTX#21105

b. Technical Advisory Bulletin (TAB) 183

c. Engineering Project Plan (EPP) V10.5.2, 9100346-001, Rev. 1.4

d. Tricon V10.5.2 V&V Test Reporl, revision 1.1, January 14,2011 18

Enclosure PG&E Letter DCL-13-048

e. Software Release Definition (SRD) V10.5.2, 6200003-226, revision 1.0

f. PDR IRTX#22481

g. Product Alert Notice (PAN) 25

h. Document "ARR 932 NSC Evaluation .pdf'

i. Tricon PAN 25 Fix Engineering Project Plan (EPP) 9100428-001, revision 1.2

j. Tricon PAN 25 Master Test Report, Rev. 1.0

k. Software Release Definition (SRD) V10.5.3, 6200003-230, revision 1.0 I. Product Alert Notice (PAN) 22

m. Product Alert Notice (PAN) 24

n. Technical Advisory Notice (TAB) 147

o. Engineering Project Plan (EPP) TriStation V4.9 & Safety Suite Apps, 9100359-001, revision 1.3

p. TriStation V4.9.0 Test Report, Rev. 0.4

q. Software Release Definition (SRD) 6200097-038, revision 1.2 PG&E Response to RAI 45 The documents requested to be submitted were submitted by Invensys Operations Management to the NRC in Letter 993754-53T, dated February 11, 2013.

NRC RAI46 (0168) Data communication with NSR (non safety related) Gateway - Figure 4-13 (page 87) of the LAR indicates that data communications are provided directly between the SR (safety related) ALS '~" & ALS "B" Protection Sets I, II, III, and IV, and the NSR Gateway Computers via RS-422 copper media (i.e., not through the Port Tap). Section 4.8.2.b) (page 110 of the LAR) states that " ...AII other communication to non-safety equipment, i.e., Plant Computer, is via continuous one-way communication channels on the ALS-1 02." Please describe how Class 1E/non-Class 1E data communication and electrical isolation is implemented within the ALS portion of the PPS for this configuration. Also, please explain how the Gateway computer and the Gateway Switch communication protocols will not corrupt the data signals coming from the ALS Protection Sets 1-4 and not impact the execution of the ALSsafety function. A detailed response to this question is needed in either the revised LAR or supporting documents.

In addition, please explain how the ALS '~" & "B" inputs to the NSR Gateway computers are isolated from each other, and explain the data communication protocols associated with processing this data within the Gateway Computers.

Furthermore, please provide a detailed functional description of the DCPP PPS NSR Gateway Computer(s) system, including computers/processors, communications protocols, and data isolation details. Provide an explanation of the Gateway Switch discussed within the LAR (Fig. 4-13), including its operating principal (hardware, 19

Enclosure PG&E Letter DCL-13-048 logic based, etc.), data/electrical isolation design features, and any other pertinent information pertaining to its failure mechanisms.

PG&E Response to RAI 46 The DCPP Gateway computer and Gateway switch are part of an existing system that was installed by a previous project, and therefore were not included in the scope of the changes requested for approval in the LAR.

Communications from the Gateway Switch to the Tricon are functionally isolated by the Triconex Communication Module (TCM) and NetOptics Model PA-CU Network Port Aggregator Tap as discussed in Section 3.7.2.1 of the Tricon Vi 0 SER. A fiberoptic data link provides electrical isolation.

The NetOptics PA-CU Network Port Aggregator Tap was approved for this use in the NRC SER for the Oconee RPS. The PA-CU prevents inbound communications from external devices or systems connected to Port 1 of the Port Aggregator from being sent to interactive Ports A and B. As a transmit only device, it does not listen to and is not affected by the communications protocol (or lack thereof) of the external device or system to which it is connected. The ability of the Port Aggregator Tap to prevent inbound communications to the Tricon from its Port 1 will be verified at the Tricon V10 Factory Acceptance Test (FAT) and the Site Acceptance Test (SAT), as previously stated in Section 4.15 of the supplement to LAR 11-07.

The Transmit Bus TxB 1 transmits data from the ALS-1 02 CLB to the Gateway Computer. Both TxB1 and TxB2 are EIA-422 communication links in which receive capability is physically disabled by hardware as described in the CS Innovations Document No. 6002-10202, "ALS-102 Design Specification." The receiver is configured such that the transmit data is looped back for channel integrity testing.

The ALS-1 02 is physically and electrically incapable of receiving information from outside the ALS-1 02 via the Transmit Busses TxB1 and TxB2. Therefore, messages are effectively disregarded and rejected by the ALS-1 02 because they are never received. In effect, this is the same as the data isolation achieved by a "broken wire."

The Class 1E/non-1 E data communication for the ALS-1 02 CLB is described in Sections 2.2.1.3 and 5.3.2 of the ALS Topical Report, and in Position 2 in CS Innovations Document No. 6116-00054, "Diablo Canyon PPS ISG04 Matrix." The electrical isolation of the transmit busses is performed by magnetic couplers located on the ALS-1 02 CLB. The TxB isolators are described in Section 3.9.1 of CSI Document No. 6002-10202, "ALS-102 Hardware Design Specification." Fault isolation occurs by way of board mounted transient voltage suppressors, board mounted fuses, and external fuses. The electrical isolation qualification of the 1E/non-1 E data communication is not part of the ALS Platform review, and will be 20

Enclosure PG&E Letter DCL-13-048 qualified with an isolation fault test that will be conducted per IEEE Std 384-1992, "IEEE Standard Criteria for Independence of Class 1E Equipment and Circuits" and Regulatory Guide 1.75, "Criteria for Independence of Electrical Safety Systems." A supplemental test report will be issued by November 15, 2013.

NRC RAI47 (0169) Application programs within the MWS computers - Please provide an explanation of the application programs contained within the Tricon and ALS MWS computers. Include how these programs will be used to support or enhance the performance of the PPS safety function as discussed in Staff Position 1, Point 3 of ISG (Interim Staff Guidance)-04.

PG&E Response to RAI47 Information on the application programs contained within the Tricon and ALS MWS computers; how they will be used to support or enhance the performance of the PPS safety function, and how they are used to perform required maintenance, and surveillance has been included in the following sections of the supplement to LAR 11-07; Section 4.2.13.3 for the Tricon and ALS MWS, Section 4.2.13.4 for the Tricon MWS, Section 4.2.13.5 for the ALS MWS, and Section 4.8.10 for the Tricon and ALS MWS.

NRC RAI48 (01 70) KVM Switch Question 1 - The KVM Switch brochure indicates on page 3 that the Enumeration Switching Process will not enable control switching using the USB keyboard or mouse. However, it further states that Emulation USB switching was developed to support these enhanced monitor switching functions/devices (keyboard hotkeys or mouse buttons).

Please explain if the Enumerated USB switching function will be used in the PPS design and, if so, if the keyboard hotkeys and mouse buttons will be used to perform switching between the Tricon MWS and the ALS MWS? Please clarify how the KVM switching function will be accomplished and controlled during PPS system operation and maintenance.

PG&E Response to RAI 48 The USB 1 and USB2 ports use enumerated switching and pass data straight through the KVM switch without interpretation. A keyboard or mouse connected to USB1 or USB2 cannot be used to control the switch.

As shown in the block diagram on Page 3 of the KVM switch brochure, switching functions are directed by the front panel "Computer" switch and the emulation 21

Enclosure PG&E Letter DCL-13-048 engine. The emulation engine receives manual switching commands from the "Computer" switch but can also generate switching commands as directed by the host controller, which responds to the mouse and keyboard. The passive enumerated switch is directed by switching commands from the "Computer" switch or the emulation engine. The enumerated switch does not provide input to the emulation engine or the host controller; thus USB 1 and USB2 traffic cannot cause inadvertent switch operation. Only the front panel "Computer" button and the keyboard and mouse (when connected to the User Console "Keyboard" and Mouse" ports) can control the KVM switch.

During PPS operation and maintenance, the KVM switch will be controlled by the Maintenance Workstation keyboard and mouse which will be connected to the emulated User Console "Keyboard" and "Mouse" USB ports. The enumerated ports will be used for the touchscreen device and the printer.

NRC RAI49 (01 71) KVM Switch Question 2 (Open Item 71) - Please explain if the KVM switch be continuously on-line while the MWSs are monitoring data from either the Tricon or the ALS platform? If so, please provide a failure modes and affects analysis to address potential failures of the KVM switch. Also, provide an explanation of how failures of the KVM switch are prevented from being propagated into the MWS computers, and hence into the Tricon or ALS safety system processors.

This analysis should delineate how communications through the KVM switch conform to ISG-04, Points 10 & 11. Provide design documentation to support this analysis, such as ALS-1 02 Design Specification document 6002-10202.

PG&E Response to RAI 49 The KVM switch will be on-line 24 hours2.777778e-4 days <br />0.00667 hours <br />3.968254e-5 weeks <br />9.132e-6 months <br /> per day, 7 days per week (24-7) for monitoring data from either the Tricon or ALS platform via the respective MWS computers. There is additional isolation because the ALS communicates strictly one way to its MWS except when TAB communications are enabled by connecting the TAB cable. Connection of the TAB is performed as directed by trained technician using an approved procedure. Therefore, if the KVM switch failed in some way to connect the two MWS together, the ALS subsystem would not be affected. The Tricon subsystem may be affected, but the 03 analysis considers complete Tricon failure due to a common cause failure.

The following paragraphs have been added to the IRS, Revision 8, Section 2.3.7:

b. The KVM switch shall permit only connections between a single computer and the selected video display and HMI interface devices. Connection between the computers shall not be permitted.

22

Enclosure PG&E Letter DCL-13-048

g. The AV4PRO-VGA KVM switch shall utilize the default switching mode, in which the video display, keyboard and mouse and the enumerated USB ports are all switched simultaneously.

Paragraph g was necessary to prevent the enumerated ports from being switched separately from the KVM.

During normal, non-maintenance operation, the ALS communicates one-way to its dedicated MWS computer via Transmit Bus TxB2. Inter-divisional safety to nonsafety communications are addressed in Section 5.2.3 of the ALS Topical Report. The TxB2 data communication paths from the ALS-1 02 Core Logic Board to the ALS MWS computer is a EIA-422 communication link in which receive capability is physically disabled by hardware as described in CS Innovations Document No. 6002-10202, ALS-1 02 Design Specification. The receiver is configured such that the transmit data is looped back for channel integrity testing.

The ALS-1 02 is physically and electrically incapable of receiving information from outside the ALS-1 02 board. Therefore, the ALS subsystem cannot be affected by a malfunction in the dedicated MWS computer associated with an ALS protection set, regardless of whether the malfunction is caused by KVM switch malfunction or by malfunction of the MWS computer itself.

The 1E/non-1 E data communication is described in the ALS Topical Report, Sections 2.2.1.3 and 5.3.2; and in Position 2 of Document No. 6116-00054, "Diablo Canyon PPS ISG04 Matrix." The electrical isolation of the transmit busses is performed by magnetic couplers located on the ALS-102 CLB. The TxB isolators are described in Section 3.9.1 of CSI Document No. 6002-10202, "ALS-102 Hardware Design Specification."

NRC RAI50 (0174) KVM Switch Question 5 - Please explain in detail how connection between the MWS computers via the KVM switch will be prevented. Please explain if this be handled via a configuration control process, administrative controls, or a physical means of preventing connection between computers?

23

Enclosure PG&E Letter DCL-13-048 PG&E Response to RAI 50 The IRS includes specifications to control the type of connection and operation modes of the KVM switch. Section 2.3.7 of the IRS states the KVM switch shall permit only connections between a single computer and the selected video display and peripheral devices. Connection between the computers shall not be permitted.

In addition, Section 2.3.7 of the IRS states the AV4PRO-VGA KVM switch shall utilize the default switching mode in which the video display, keyboard and mouse, and the enumerated USB ports are all switched simultaneously. This specification prevents the enumerated ports from being switched separately from the KVM.

The user console's two switched USB ports, which use enumerated switching, pass data straight through the KVM switch without interpretation. If a keyboard is connected to the USB 1 or USB2 port, the hotkeys cannot be used to perform switching, and USB1 and USB2 traffic cannot cause an inadvertent switch. The keyboard and mouse will use the emulated switching function, not the enumerated switching function, and thus only the keyboard, mouse, and the button on the KVM switch can control the switch. Refer to the response to RAI 48 for additional information.

The unused MWS and KVM switch ports will be addressed in accordance with the DCPP Cyber Security Plan. Remote control KVM switching or KVM firmware update requires a custom serial cable. The KVM firmware update requires specialized software on the computer being used to perform the update. KVM firmware update will only be done by procedure. The MWS and KVM switch will be inside a locked cabinet inside a vital area inside the protected area, which will minimize the possibility of the inadvertent actions. In addition, administrative and PG&E SCMP configuration controls will prevent inadvertent loading of an EPROM image that could corrupt operation of the KVM switch. If the KVM switch fails and connects the ALS and Tricon MWS together, the above-described physical and electrical restrictions of the ALS-1 02 board will prevent the ALS from being corrupted by its MWS computer.

This information has been included in new Section 4.2.14 of the supplement to LAR 11-07.

NRC RAI51 (01 51.3a) Software Configuration Management - Changes and Problems Identification PG&E document SCM 36-01 states that software, hardware, and configuration problems are reporled in accordance with PG&E OM7.ID1 and that software and/or configuration problems are reporled via a "PROG PDCM" Notification. The NRC staff requires an understanding of when and how these processes are used. For 24

Enclosure PG&E Letter OCL-13-048 example, for software problems, is the problem reported using both PG&E OM7.ID1 and PROG PDCM notification processes? Note that PG&E CF2.ID2 states that all problems associated with plant computer system should be reported and document per OM7.ID1 (See section 5.11 and 5.16.10 (b) of CF2.ID2).

Furthermore, Section 3.2. 1 of SCM 36-01 states that all PPS modifications should be initiated and tracked per plant procedures or CF4. 10 1. Section 3.2.2 states that the implementation of the change is documented in the associated Change Package and an SAP notification and order. Section 3.2. 10 states that all identified problems and corrective actions are documented using a "notification," which is not specified.

It is therefore unclear whether software modifications require reporting and tracking using OM7.ID1, CF4.ID1, "PROG PDCM" Notification, Change Package, and/or SAP Order. Please explain PG&E procedures for different changes and the documenting and tracking system used for all types of modification.

PG&E Response to RAI 51 All problems are entered into the corrective action program using PG&E Administrative Procedure OM? .101 and are required to be entered into an SAP (electronic business management software) notification (electronic tracking document). Notifications can be identified as different Work Types in order to categorize the type of problem, the priority of the problem, and to facilitate routing the problem to appropriate personnel needed to review and resolve the problem. A "PROG POeM" type notification is a program (PROG) plant digital configuration management (POCM) type of problem and software and configuration problems are examples of problems that would be assigned a Work Type of "PROG POCM" in the notification. Plant hardware problems are assigned a Work Type of "EQPR" to identify the problem as an equipment problem.

Plant modifications, including software modifications, are requested using Plant Procedure CF4.I01, "Plant Modification Request and Approval" and the modifications are performed using paper/electronic image based change documentation (Change Package) and are tracked in SAP using a notification and an order. An order is an electronic tracking document that allows detailed tracking of job requirements, parts, details, schedule, and approval.

NRC RAI52 (01 51.4a) Software Configuration Management - Document Repository Section 2.3.3 of Document SCM 36-01 identifies the Digital Systems Engineering SourceSafe as the repository to maintain the PPS configuration, system, firmware, and application source code, but Section 3.2.5.5 identifies http://dcpp 142/idmws/home/asp. Section 3.29 then states that the files necessary 25

Enclosure PG&E Letter DCL-13-048 for recovery of the baseline are maintained in the PPS database in SC-I-36M, Eagle 21 Tunable Constants. It is not clear if these three sections are referring to the same document repository. Please clarify.

PG&E Response to RAI 52 The SourceSafe is used for executable files (exe files), source code, program code, and database files, etc. The link http://dcpp142/idmws/home/aspistoFileNet,an electronic file storage system. FileNet is used to store documentation like the PPS Replacement Project documents (e.g., Software Configuration Management document, Functional Requirements Specification, Interface Requirements Specification, etc.). Section 3.29 is referring to the Source Safe repository.

NRC RAI53 (01 51.4b) Software Configuration Management - Document Repository Access Restrictions PG&E has implemented restrictions to access files and documents associated with PPS replacement project. Furlhermore, PG&E requires user authentication and access to edit configuration, software, and data. It is not clear if these restrictions apply for access to the Digital Systems Engineering SourceSafe or the repository in http://dcpp142/idmws/home/asp. Please clarify and explain the applicability of access restrictions.

PG&E Response to RAI 53 Microsoft SourceSafe requires special permissions to access the appropriate directory and then requires a login and special software to access the files. FileNet allows files to be viewed without a special login, but to modify, delete, or add, files special permissions need to be assigned.

ATTACHMENTS

1. PG&E Document "Process Protection System (PPS) Replacement System Quality Assurance Plan (SyQAP)," Revision 1 26

Enclosure Attachment 1 PG&E Letter DCL-13-048 PG&E Document "Process Protection System (PPS) Replacement System Quality Assurance Plan (SyQAP)," Revision 1

Pacific Gas & Electric Company Diablo Canyon Power Plant Units 1 & 2 Process Protection System (PPS) Replacement System Quality Assurance Plan (SyQAP)

Nuclear Safety Related Rev 1 Prepared by: Date 03/18/2013 Print Last Name User ID JWH3 Reviewed by: )~O~ Date 03 Lff!.2:.'/ l I

1/

Print Last Name 5c,hV'Ader User ID tersE QA Supv. Date 3/ ,SICZ-01J.

Print Last Name User ID TB~ l Cyber Security Lead Date /r tf14.(/ ZtJ ! 3 Print Last Name User ID ~d~ 2, PPS Upgr. prOjectM~ ... Date J1/~/~I Print Last Name IV' User ID 5l?P1

PPS Replacement System Quality Assurance Plan (SyQAP) Rev 1 Page 1 of 19 REVISION HISTORY Revision Affected Reason for Revision Number Pages 0 All Initial Issue All General reformat to align with IEEE 730 format Title sheet Added signoff for Supplier Quality, Cyber Security Lead and Licensing Lead per NRC 01 #31.

Section 1 Revised to clarify SyQAP purpose and scope for PPS replacement project Section 2.1 Deleted unused references; remaining references renumbered Section 2.1.2.16 Added IEEE 610.12 Glossary of Software Engineering Terminology Section 2.3.7 Added SyWP, SCMP, Project Quality Plan to References Section 2.3.8 Section 2.3.9 Section 3 (all) Clarified responsibility for quality Removed tasks governed by supplier procedures Resequenced for clarity Figure 3-1 Revised to match PPS Project Plan Rev 2 Figure 2-1 and SyWP Figure 4-1 per NRC 01 #39 Table 3-1 Added lifecycle cross reference Table 3-1 per NRC 01 #26 Deleted activities controlled by supplier procedures Section 3.2.1.1 Added description of PG&E Conceptual Design activities.

Section 3.2.1.2 Updated Installation and Checkout activities; retitled section "Test Phase" 1 Section 3.2.1.3 DCPP Operation & Maintenance Phase tasks are performed per the Section 3.2.1.4 SCMP Section 3.3.1.1 Clarified role of PG&E Project Manager regarding project re-evaluation.

Section 3.3.1.2 Added Supervisor, Supplier Quality per NRC 01 #64 Section 3.3.1.3 Clarified "Project Team" role to agree with SyWP per NRC 01 #39.

Section 3.3.1.4 Added Altran role description per NRC 01 #39 Section 3.3.1.5 Clarified Project Engineering Team and EoC roles per NRC 01 #38 Section 3.3.1.6 Added Cyber Security Lead role description per NRC 01 #31 Section 3.3.1.7 Added DCPP Licensing Lead role description per NRC 01 #31 Section 4 Resequenced for clarity and to align with IEEE 730 Section 4.2.4 Added DCPP Controller Transfer Function Design Input Specification Section 4.2.5 Added Project Quality Plan per NRC 01 #64 Section 4.2.7 Added DCPP Software Configuration Management Plan (SCMP) to align with IEEE 730.

Section 4.2.8 Added DCPP Cyber Security Plan description Section 4.3 Clarified documentation that is controlled by 10 CFR 50 Appendix B supplier procedures Added specific analyses required by purchase order Section 4.4 Deleted documents governed by supplier procedures.

PPS Replacement System Quality Assurance Plan (SyQAP) Rev 1 Page 2 of 19 REVISION HISTORY, continued Sections 5-16 General revision to remove content that is controlled by 10 CFR 50 Appendix B supplier procedures and clarify PG&E responsibilities Section 8.1 Clarified use of OM7.ID1 per NRC 01 # 48 Section 10 Added Code Control Section 11 Clarified that media is controlled by SCMP following delivery Section 13 Clarified documentation control after PPS delivery to DCPP Section 16 Replaced section with reference to IEEE 610.12

PPS Replacement System Quality Assurance Plan (SyQAP) Rev 1 Page 3 of 19 Table of Contents

1. PURPOSE .............................................................................................................................................5 1.1 OVERViEW ........................................................................................................................................ 5 1.2 SCOPE ............................................................................................................................................. 5

2. REFERENCE DOCUMENTS ................................................................................................................ 5 2.1 DEVELOPMENTAL REFERENCES AND STANDARDS ............................................................................... 5

3. MANAGEMENT ..................................................................................................................................... 8 3.1 ORGANIZATION ................................................................................................................................. 8 3.2 TASKS .............................................................................................................................................. 9 3.3 ROLES & RESPONSiBILITIES ............................................................................................................ 11

4. DOCUMENTATION ............................................................................................................................. 13 4.1 PURPOSE ....................................................................................................................................... 13 4.2 OVERVIEW OF PG&E DOCUMENTS .................................................................................................. 13 4.3 OVERVIEW OF 1 OCFR50 ApPENDIX B SUPPLIER DOCUMENTS .......................................................... 15

5. STANDARDS, PRACTICES, CONVENTIONS, AND METRICS ........................................................ 16 5.1 DOCUMENTATION STANDARDS ......................................................................................................... 16 5.2 LOGIC STRUCTURE (DESIGN) STANDARDS ......................................................................................... 16 5.3 TESTING STANDARDS AND PRACTICES ............................................................................................. 16 5.4 SELECTED SQA PRODUCT AND PROCESS METRiCS ......................................................................... 16

6. SOFTWARE REVIEWS AND AUDITS ............................................................................................... 16

7. TEST .................................................................................................................................................... 16

8. PROBLEM REPORTING AND CORRECTIVE ACTION .................................................................... 17 8.1 ANOMALY RESOLUTION AND REPORTING .......................................................................................... 17 8.2 TASK ITERATION POLiCy .................................................................................................................. 17

9. TOOLS, TECHNIQUES, AND METHODOLOGIES ............................................................................ 17

10. CODE CONTROL ............................................................................................................................ 17

11. MEDIA CONTROL ........................................................................................................................... 17

12. SUPPLIER CONTROL..................................................................................................................... 17

13. RECORDS COLLECTION, MAINTENANCE AND RETENTION ................................................... 18

14. TRAINING ........................................................................................................................................ 18

15. RISK MANAGEMENT ...................................................................................................................... 19

16. GLOSSARY ..................................................................................................................................... 19

17. SYQAP CHANGE PROCEDURE AND HISTORY .......................................................................... 19

PPS Replacement System Quality Assurance Plan (SyQAP) Rev 1 Page 4 of 19 Figures Figure 3-1 PPS Project Organization ....................................................................................................... 8 Tables Table 3-1 Lifecycle Phase Cross Reference .......................................................................................... 9

PPS Replacement System Quality Assurance Plan (SyQAP) Rev 1 Page 5 of 19

1. Purpose 1.1 Overview The purpose of this System Quality Assurance Plan (SyQAP) is to: (1) establish the goals, processes, and responsibilities required to implement effective software quality management for the Process Protection Set (PPS) replacement system software at Diablo Canyon Power Plant (DCPP); (2) ensure any required software functions perform correctly; and (3) ensure that the required software functions conform to established technical requirements, conventions, rules, and standards.

1.2 Scope This SyQAP applies to the nuclear safety related DCPP PPS replacement software development and software maintenance activities shown in Table 3-1. PG&E will perform the conceptual design activities as described in the System Verification and Validation Plan (SyWP) [2.1.3.7] for this project. The software will be developed by the suppliers in accordance with 10 CFR 50 Appendix B programs. Section 3.2.2 briefly describes vendor activities; however, vendor activities are not governed by this Plan.

The supplier's system development process will extend to the end of Factory Acceptance Testing (FAT).

After the software has been delivered to DCPP, PG&E will perform the SQA activities shown in the table; specifically, the Site Acceptance Test (SAT), installation, and Design Verification Test (DVT). PG&E will not perform software modifications following FAT. Such modifications, if necessary, will be performed by the 10 CFR 50 Appendix B suppliers.

2. Reference Documents 2.1 Developmental References and Standards 2.1.1 U.S. Regulatory Guidance 2.1.1.1 Title 10 CFR, Part 50, Appendix B, "Quality Assurance Criteria for Nuclear Power, Plants and Fuel Reprocessing Plants" 2.1.1.2 NUREG-0800 BTP 7-14, Branch Technical Position: Guidance on Software Reviews for Digital Computer-Based Instrumentation and Control Systems, Revision 5, March 2007.

2.1.1.3 Regulatory Guide 1.152, Criteria for Use of Computers in Safety Systems of Nuclear Power Plants, Revision 3, July 2011.

2.1.1.4 Regulatory Guide 1.168, Verification, Validation, Reviews, and Audits for Digital Computer Software Used in Safety Systems of Nuclear Power Plants, Revision 1, February 2004 2.1.1.5 Regulatory Guide 1.174, An Approach for Using Probabilistic Risk Assessment in Risk-Informed Decisions on Plant-Specific Changes to the Licensing Basis, Revision 1, November 2002 2.1.1.6 Interim Staff Guide DI&C-ISG-01 , Cyber Security, Revision 0

PPS Replacement System Quality Assurance Plan (SyQAP) Rev 1 Page 6 of 19 2.1.1.7 Interim Staff Guide DI&C-ISG-06, Licensing Process, Revision 1, January 2011 2.1.2 Industry Codes and Standards 2.1.2.1 ANSI/IEEE Std. 983-1986, IEEE Guide for Software Quality Assurance Planning 2.1.2.2 ASME NQA-1-1994, 1997, Quality Assurance Requirements for Nuclear Facility Applications 2.1.2.3 EPRI TR-1 03291, Handbook of Verification and Validation for Digital Systems, Revision 1, December 1998 2.1.2.4 NEI 08-09, Revision 6, Cyber Security Plan for Nuclear Reactors 2.1.2.5 IEEE Std. 7-4.3.2-2003 IEEE Standard Criteria for Digital Computers in Safety Systems of Nuclear Power Generating Stations, Appendix D (Informative) Identification and Resolution of Hazards 2.1.2.6 IEEE Std. 352-1987, IEEE Guide for General Principles of Reliability Analysis of Nuclear Power Generating Station Safety Systems 2.1.2.7 IEEE Std. 577-1976, IEEE Standard Requirements for Reliability Analysis in the Design and Operation of Safety Systems for Nuclear Power Generating Stations 2.1.2.8 IEEE Std. 603-1991, IEEE Standard Criteria for Safety Systems for Nuclear Power Generating Stations 2.1.2.9 IEEE Std. 730-2002, Standard for Software Quality Assurance Plans 2.1.2.10 IEEE Std. 829-1983, Standard for Software Test Documentation 2.1.2.11 IEEE Std. 1008-1987, IEEE Standard for Software Unit Testing 2.1.2.12 IEEE Std. 1012-1998, Standard for Software Verification and Validation 2.1.2.13 IEEE Std. 1028-1997 (reaffirmed 2002), Standard for Software Reviews 2.1.2.14 IEEE Std. 1044-1997, IEEE Standard for Classification of Software Anomalies 2.1.2.15 IEEE Std. 1233-1998, Guide for Developing System Requirements Specifications 2.1.2.16 IEEE Std. 610.12-1990 -IEEE Standard Glossary of Software Engineering Terminology.

PPS Replacement System Quality Assurance Plan (SyQAP) Rev 1 Page 7 of 19 2.1.3 DCPP References and Procedures:

2.1.3.1 PG&E Procedure, IDAP AD7.ID8, Project Management 2.1.3.2 PG&E Procedure, IDAP CF3.ID9, Design Change (Package) Development 2.1.3.3 PG&E Procedure, IDAP CF2.ID9, Software Quality Assurance Plan Software Development 2.1.3.4 PG&E Procedure, IDAP CF2.ID2, Software Configuration Management for Computers & Software Used for Plant Operations and Operations Support 2.1.3.5 PG&E Form 69-20164, Work Group Specific Training Record 2.1.3.6 PG&E Procedure, AD1 0.101, Storage and Control of Quality Assurance Records 2.1.3.7 DCPP PPS Replacement System Verification and Validation Plan (SyWP) 2.1.3.8 SCM 36-01 PPS System Configuration Management Plan (SCMP) 2.1.3.9 DCPP PPS Replacement Project Quality Plan

PPS Replacement System Qua lity Assu rance Plan (SyQAP) Rev 1 Page 8 of 19

3. Management 3.1 Organization Quality is the responsibility not only of management, but also of all project personnel who perform work for, and provide services and products for the project. Different organizational units, their responsibilities and relationships with regard to Quality are discussed in this SyQAP. The basic organizational structure that influences software quality is shown in Figure 3-1.

The Supervisor, Supplier Quality represents an independent oversight organization responsible for overall implementation of the Quality Program at DCPP.

Figure 3-1 PPS Project Organization Diablo Canyon Diablo Canyon PPS Upgrade Supervisor Project Manager Supplier Quality

- - - - - - - - - - - - -,- - - - - - - r - - - - - - -, - - - - ---r - - - - - - - - - - I 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 The PG&E Project Team determines the functional requirements of the software and hardware while the 10CFR50 Appendix B supplier designs the application software and hardware with the aid of engineering and software development tools.

As mentioned in DI&C-ISG-06 Rev 1 [2.1.1.7], an applicant may have different names for similar documents. This plan does not specify that an approved software supplier meet a particular terminology, only that the intent of this plan is followed and a high quality software product is generated for plant use.

Table 3-1 provides a cross reference to the terminology used within this section and that will be used by the suppliers and also illustrates the general development process for the DCPP PPS replacement software and hardware, including both PG&E and supplier activities. The specific development processes employed by the 10CFR50 Appendix B suppliers are determined by their procedures. The 10CFR50 Appendix B suppliers' SQA processes are subject to review and acceptance by PG&E.

PPS Replacement System Quality Assurance Plan (SyQAP) Rev 1 Page 9 of 19 Table 3-1 Lifecycle Phase Cross Reference PG&ESyQAP DCPP Lifecycle 10M Lifecycle CSllWestinghouse Lifecycle Phase Activities Phase Lifecycle Phase (per IEEE-1 012) (perSyWP)

Project Initiation and No V&V outputs Planning Planning Planning Conceptual Design COD (Info)

FRS IRS Transfer Function Spec SyWP Requirements Requirements Development Design Design Implementation Implementation Manufacturing Integration Tricon & ALS System Level Integration Test Test (Validation) System Test (FAT) (FAT)

Site Acceptance Test (SAT)

Installation & Design Installation Verification Test 3.2 Tasks 3.2.1 DCPP Lifecycle Tasks DCPP lifecycle activities are described in the System Verification and Validation Plan (SyWP) [2.1.3.7].

A brief description is provided here for convenience. Documents prepared are listed in Section 4.2.

3.2.1.1 Conceptual Design Phase During the Concept phase, the system architecture is selected, and system requirements are allocated to hardware, software, and user interface components. PG&E considers the concept phase output documents to be the products of design activity, rather than V&V activity, with verification through the stakeholder signature process described in the SyWP. The concept phase outputs are inputs to 10 CFR 50 Appendix B supplier development process. There are no specific V&V products for this phase.

3.2.1.2 Test Phase The DCPP Test Phase Installation and Checkout V&V activity shown in Table 3-1 addresses system installation and acceptance support. The Installation and Checkout phase begins when the developed system is assembled in the Project Integration and Test Facility (PITF) for pre-installation staging and checkout. Performance of the site acceptance test (SAT) per DCPP procedure, is conducted in the PITF by PG&E. The developed system is then installed in the final target environment/location and performance of the design verification testing (DVT) per PG&E plant procedure is conducted. PG&E is responsible for acceptance of the results of the SAT and DVT.

Tasks performed in this phase:

PPS Replacement System Quality Assurance Plan (SyQAP) Rev 1 Page 10 of 19

• Audit the installation configuration to verify that all software products required to correctly install and operate the software are present in the installation package. Validate that all site-dependent parameters or conditions to verify supplied values are correct.

• Installation Checkout by V&V; Conduct analyses or tests to verify that the installed software corresponds to the software subjected to V&V. Verify that the software code initializes, executes, and terminates as specified.

• Verify that the installation procedures and installation environment does not introduce new hazards; Update the hazard analysis;

• Conduct SAT and DVT per approved procedures

• Review and update risk analYSis using prior task reports; Provide recommendations to eliminate, reduce, or mitigate the risks; and

• Generate the V&V Final Report - Depending upon project scope, either PG&E or the supplier will be responsible for developing this report; Summarize in the V&V final report the V&V activities, tasks and results, including status and disposition of anomalies.

• Provide an assessment of the overall software quality.

Outputs of this phase are the Operations Manual, the Installation Configuration Tables, Training. Manuals, Maintenance Manuals, an Installation Safety Analysis, a V&V Installation Analysis and Test Report, and a CM Installation Report 3.2.1.3 Operation Phase V&V The operation process covers the operation of the developed and installed system by PG&E in the target environment/location, and operational support by the system supplier. PG&E will have primary responsibility for V&V activities during this phase (unless contracted out to a software supplier with an approved and audited 10CFR50 Appendix B quality program). The objectives of Operation V&V tasks are to evaluate new constraints in the system, assess proposed changes and their impact on the software, and evaluate operating procedures for correctness and usability.

Operations Phase V&V activities are performed per the DCPP PPS Replacement Software Configuration Management Plan SCM 36-01.

3.2.1.4 Maintenance Phase V&V The maintenance process is activated when the software product undergoes modifications to code and associated documentation caused by a problem or a need for improvement or adaptation. The Maintenance V&V activity addresses modifications (e.g., enhancements, additions, and deletions),

migration, or retirement of the software during the operation process.

Maintenance Phase V&V activities are performed per the DCPP PPS Replacement Software Configuration Management Plan SCM 36-01.

3.2.2 10CFR50 Appendix B Supplier Tasks 3.2.2.1 Project Initiation and Planning Phase Tasks The Planning phase confirms that the system to be acquired is what is actually needed, and that it will be in compliance with the licensing basis of the plant. This phase also produces procedures for managing the interface with the supplier, and for managing changes to requirements.

3.2.2.2 Conceptual Design Phase Tasks

PPS Replacement System Quality Assurance Plan (SyQAP) Rev 1 Page 11 of 19 The Conceptual design phase defines the scope of the V&V effort according to their procedures. The supplier initial V&V Plan, SQAP, and FRS (or their equivalents) are products of this phase.

3.2.2.3 Requirements Phase V&V Tasks In this phase, a Software Requirements Specification (SRS) or its equivalent will be prepared by the 10 CFR 50 Appendix B suppliers according to their procedures. The SRS will be developed based on the functional requirement specification and the system interface requirements specification, each of which must be approved by the customer prior to beginning.

3.2.2.4 Design Phase V&V Tasks In this phase, the 10 CFR 50 Appendix B suppliers prepare the Software Design Description (SDD) or its equivalent for each applicable software product according to their procedures. The SOD will be developed based on the software requirement specification and the software and hardware architecture or their equivalents.

3.2.2.5 Implementation Phase V&V (Unit/Component Testing)

During this phase the executable code is produced and tested according to the 10 CFR 50 Appendix B Supplier procedures. The correct implementation of the SRS is validated during function tests with the software development and simulation tools, and during testing on the test/development system.

3.2.2.6 Integration Phase V&V Tasks Integration Testing is a separate software Lifecycle activity per NUREG-0800 BTP 7-14 [2.1.1.2] that can be mapped to IEEE 1012-1998 [2.1.2.12] and is a continuation of the Implementation Phase. The software is integrated with the hardware and integration testing in accordance with the supplier's test procedures. Integration test execution results are analyzed to determine if the system implements the requirements and design and that the software components function correctly together.

3.2.2.7 Test Phase V&V Tasks System tests are performed in accordance with the 10 CFR 50 Appendix B Supplier test procedures.

Tests are analyzed to determine if the system implements the requirements and design and that the software components function correctly together. Test results are analyzed to determine if the software satisfies system objectives. Tests pass or fail based on the acceptance criteria stipulated in the SRS and on specific requirements found in the RTM.

3.2.2.8 Final V&V Tasks The final V&V tasks include issuing the Final V&V Report, which summarizes all life cycle V&V tasks and the task results. It will also summarize the discrepancies and their resolution found during the V&V evaluation. The report will give an assessment of overall software quality and provide any recommendations.

3.3 Roles & Responsibilities The different roles and responsibilities for Software Quality Assurance as they relate to this SyQAP are discussed below:

3.3.1 PG&E Roles and Responsibilities 3.3.1.1 DCPP Project Manager The DCPP Project Manager has the ultimate responsibility, authority, and accountability for all aspects of the project. Responsibilities include quality of design, timely integration with site schedules, supplier quality management/oversight, quality field implementation, and successful post-installation testing. The

PPS Replacement System Quality Assurance Plan (SyQAP) Rev 1 Page 12 of 19 DCPP Project Manager is also responsible to recommend re-evaluation if changes are needed that have the potential to alter the decision to proceed to the next project phase.

The DCPP Project Manager shares the responsibility for meeting the quality goals and objectives of the project and for the implementation of quality management throughout the project.

The project manager will:

• Release the system level V&V plan and reports

• Establish cost controls

• Enter the plan activities into the master project schedule.

• Review progress of the SyQAP and V&V program

• Evaluate any reported deviations or anomalies for their potential risk and impacts to project cost and schedule.

• Approve corrective actions, scope changes and resource allocations.

• Coordinate the disposition of discrepancy reports generated in the course of verification and validation.

3.3.1.2 DCPP Supervisor, Supplier Quality The DCPP Supervisor, Supplier Quality is responsible for implementing the requirements of the DCPP Quality Program as defined in Chapter 17 of the FSAR Update.

3.3.1.3 DCPP Project Team The DCPP Project Team conducts and ensures quality-related inter-group coordination for design and engineering between software and hardware design activities. The project team is responsible for identifying the processes and corresponding standards and procedures to guide project performance.

The project team is further responsible for ensuring work activities are performed in compliance with these standards and procedures.

3.3.1.4 Altran Altran is a subcontractor providing engineering support to the PG&E Project Team. Altran activities are controlled by contract.

3.3.1.5 DCPP Project Engineering Team The DCPP Project Engineering Team is responsible for the design change process utilized by DCPP for the design and implementation of modifications to controlled Structures, Systems, and Components. The Project Engineering Team is also responsible for establishing quality goals and objectives for their organization consistent with those of the project. The DCPP Project Engineering Team utilizes an Engineer of Choice (EoC) for the work associated with the design change package development, review, and issuance. The EoC engineering activities are controlled by contract.

3.3.1.6 Cyber Security Lead The DCPP Cyber Security Lead is responsible for implementing the requirements of the commission-approved DCPP Cyber Security Plan as required by Section 2.E of the DCPP Operating Licenses and as defined in Chapter 13.7 of the FSAR Update.

3.3.1.7 DCPP Licensing Lead

PPS Replacement System Quality Assurance Plan (SyQAP) Rev 1 Page 13 of 19 The DCPP Licensing Lead is responsible for the 10 CFR 50.90 licensing process for the PPS Replacement Project per the guidance provided in NRC ISG-06 "Licensing Process". The licensing process includes coordination of the meetings, audits, and inspections with the NRC, the preparation and submittal of the License Amendment Request (LAR) and all associated documentation, and response to NRC requests for additional information.

3.3.2 10CFR50 Appendix B Supplier Roles & Responsibilities Detailed roles and responsibilities for each of the 10CFR50 Appendix B suppliers are provided in the respective 10CFR50 Appendix B supplier SQAP.

4. Documentation 4.1 Purpose The NRC has issued Interim Staff Guidance (ISG) in digital instrumentation and control DI&C-ISG-06

[2.1.1.7] that describes the licensing process that may be used in the review of License Amendment Request (LAR) associated with digital I&C system modifications.

DI&C-ISG-06, Enclosure B, lists documents that are typically submitted by the licensee in support of a submittal during Phases 1 and 2 of review. The Phase 1 documents that are associated with this project are summarized in a separate attachment to the LAR. A list of Phase 2 documents associated with this project will be provided 12 months prior to the requested LAR approval date.

The documentation discussed below is a summary of the documents to be provided by PG&E and the 10CFR50 Appendix B supplier(s). As stated above, specific documents associated with this project are listed in separate lists provided with the LAR and Phase 2 submittal enclosure.

4.2 Overview of PG&E Documents The following is a summary of the documents to be provided by PG&E.

4.2.1 Conceptual Design Document (COD)

The CDO will provide a high level description of the overall system to be implemented by the DCPP PPS upgrade project.

4.2.2 Functional Requirements Specification (FRS)

The FRS will provide a general description of what PG&E expects the system to do. All known customer requirements will be documented. The FRS should state the specific customer requirements as clearly and consistently as possible. It will describe the operations the user wants to perform with the software and define all the constraints that the customer wishes to impose upon any solution. The FRS will describe the external interfaces to the system. IEEE Std. 1233 [2.1.2.15] can be used for guidance in regards to the content, table of contents and details that should be included in the FRS. The FRS is a deliverable from PG&E.

4.2.3 Interface Requirements Specification (IRS)

The IRS will provide a general description of how PG&E expects the separate deliverables from each of the 10CFR50 Appendix B suppliers to interface with one another. Specifically, the IRS will provide:

(1) Requirements for the interfaces between external field devices such as process transmitters and the 10CFR50 Appendix B suppliers' equipment;

PPS Replacement System Quality Assurance Plan (SyQAP) Rev 1 Page 14 of 19 (2) Electrical and communication interfaces between the 10CFR50 Appendix 8 suppliers equipment and their associated peripheral devices; and (3) Other interfacing Diablo Canyon Power Plant (DCPP) systems such as the Plant Process Computer (PPC), Main Annunciator System (MAS), Safety Parameter Display System (SPDS) and the Safety-Related 120 Vac and 125 Vdc Power Systems.

4.2.4 Controller Transfer Function Design Input Specification The PPS FRS identifies the requirements that must be implemented by the PPS in terms that are hardware independent. This specification provides details for developing algorithms for use by a digital system to implement the controller transfer functions specified in the PPS FRS.

4.2.5 Project Quality Plan (PQP)

The PQP identifies the key Quality Assurance tasks to be performed for the DCPP PPS replacement project. The PQP excludes the details of the quality-related project activities. Each organization participating in the DCPP PPS replacement project is required to perform its quality-related activities in accordance with established approved procedures, policies and guidelines. The DCPP Supplier Quality Verification Director is responsible for the PQP.

4.2.6 System Verification & Validation Plan (SyWP)

The System Verification and Validation Plan (SyWP) [2.1.3.7] for the overall system life cycle will be prepared according to IEEE Std. 1012 [2.1.2.12]. PG&E will review and approve 10CFR50 Appendix 8 supplier life cycle outputs providing independent V&V activities including review, evaluation, analysis, and inspection. It will include 'both an assessment of the development process, and independent testing of the software and logic products within the Site Acceptance Test (SAT).

In accordance with the system verification & validation plan, the overall plan for the verification and validation of the system is described. All methods, criteria, and tasks are listed, including required inputs and outputs.

4.2.7 Software Configuration Management Plan (SCMP)

The Software Configuration Management Plan establishes and documents a process of change control and software configuration management for the replacement Process Protection System (PPS) from the time the equipment arrives at the offsite PG&E Project Integration and Test Facility (PITF), through Site Acceptance Test (SAT), Installation, Design Verification Test, and for the remainder of its Operation and Maintenance life cycle following installation at DCPP.

4.2.8 Cyber Security Plan (CSP)

The DCPP Cyber Security Plan is being implemented to prevent damage to, unauthorized access to, and allow restoration of computers, electronic communications systems, electronic communication services, wire communication, and electronic communication, including information contained therein, to ensure its availability, integrity, authentication, confidentiality, and non-repudiation. The commission-approved DCPP Cyber Security Plan is a requirement contained in Section 2.E of the DCPP Operating Licenses.

4.2.9 Site Acceptance Test (SAT) Plan The SAT Test Plan prescribes the scope, approach, resources, and schedule of the testing activities. It identifies the items to be tested, the features to be tested, the testing tasks to be performed, the personnel responsible for each task, and the risks associated with the plan. The SAT Plan describes the formal acceptance testing approach, methodology, and acceptance criteria that will enable PG&E to

PPS Replacement System Quality Assurance Plan (SyQAP) Rev 1 Page 15 of 19 accept the system for implementation in the plant. Test plans, test cases, and test procedures are developed in accordance with IEEE Std. 829 [2.1.2.10]. See Section 7 for further details about testing.

4.2.10 Requirements Traceability Matrix (RTM)

The RTM will be used to demonstrate traceability for each function through all phases of the system development. Regulatory guidance requires traceability analysis only for software requirements.

However, formal requirements management is considered to be a good business practice toward development of a high-quality digital system. Therefore, it is recommended that the RTM cover hardware, software, and interface requirements of the digital system to the extent practical.

A RTM is created to demonstrate that all requirements have been successfully implemented in the design and tested in the testing program. Both forward and reverse paths must exist to be able to trace each design requirement to and from the SAT. During the RTM development there may be some requirements that cannot be validated by testing. For these, techniques such as analysis or reviews can be used and noted in the RTM. More information can be found in the EPRI V&V handbook (TR-103291).

4.2.11 System Verification and Validation (SyWR) Final Report The System Verification and Validation Final Report summarize all results of the execution of the SyWP

[2.1.3.7]. It lists all deficiencies found; provides the results of reviews, audits and tests.

4.3 Overview of 10CFR50 Appendix B Supplier Documents 4.3.1 Lifecycle Documentation A detailed listing and description of the documents supplied by each of the 10CFR50 Appendix B suppliers is provided in the respective 10CFR50 Appendix B supplier SQAP. PG&E will review and accept the requirements, design and implementation phase documentation, traceability analyses and V&V reports after comments and any anomalies have been resolved according to the 10 CFR 50 Appendix B supplier procedures and the PPS replacement SyWP.

Traceability documentation and analyses will start from the PG&E design inputs (FRS, IRS, Controller Transfer Function Design Input Specification) continuing through Factory Acceptance Testing (FAT), and will be performed per the respective 10 CFR 50 Appendix B supplier control procedures.

PG&E will review and accept the final supplier V&V reports, which summarize all life cycle V&V tasks and the task results, after comments and anomalies have been resolved according to the 10 CFR 50 Appendix B supplier procedures 4.3.2 Analysis Documentation The 10 CFR 50 Appendix suppliers will perform the following analyses as required by the procurement documents:

• Reliability Analysis evaluates the failure rates of modules in terms of the probability of system failure on demand. Reliability analyses should be performed per the guidance of IEEE Std. 577 [2.1.2.7]

and may be included in the FMEA.

• Failure Modes and Effects Analysis (FMEA): The detailed FMEA will specifically consider systematic random single failures based on the hardware design and architecture of the integrated system.

Particular attention is paid to safety functions and software failures. The analysis is typically extended to include common mode failures. Recommendations are made based on potential failures, severity, and risks involved, which could result in design changes to the system. The FMEA should be performed following the guidance of IEEE Std. 352 [2.1.2.6].

PPS Replacement System Quality Assurance Plan (SyQAP) Rev 1 Page 16 of 19 PG&E will perform a project-level FMEA during detailed design.

• Response Time Analysis: This analysis calculates the overall Response Time of the system, which should be lower than the shortest required response time, described in the FRS.

4.3.3 Test Documentation Details of the software test documentation supplied by each of the 10CFRSO Appendix B suppliers are provided in the respective 10CFRSO Appendix B supplier SQAP.

5. Standards, Practices, Conventions, and Metrics This project adheres to regulatory guidance and ANSI/IEEE, and International standards considered acceptable for software used in nuclear plant safety systems. In particular, NUREG-0800, BTP 7-14

[2.1.1.2], IEEE 603-1991 [2.1.2.8], IEEE 7-4.3.2-2003 [2.1.2.S], and IEEE 1012-1998 [2.1.2.12] are used as the basis for the overall V&V process to be applied to SIL-4 systems. The design of the PPS is intended to meet the requirements of IEEE Standards that are currently endorsed by various NRC Regulatory Guides at the time of the design.

5.1 Documentation Standards The documentation standards defined in the 10CFRSO Appendix B supplier SWP, this SyQAP, and the 10CFRSO Appendix B supplier SQAP will be followed.

5.2 Logic structure (design) standards IEEE standards will be used for the overall organization of the SRS, SAD and SOD. Function logic diagrams and SAMA diagrams are predefined by the software development tools and cannot be altered by the user.

5.3 Testing Standards and Practices Test procedures, test scripts and the results of the test are part of the documentation described in Section

7. The structure of test procedures and test scripts is in conformance with IEEE Std. 829 [2.1.2.10] and IEEE Std. 1008 [2.1.2.11] as verified as part of the V&V testing activities described in the 10CFRSO Appendix B supplier SWP.

5.4 Selected SQA Product and Process Metrics A minimum set of quality metrics should be defined in each of the 10CFRSO Appendix B supplier SWP.

A required metric is the requirements coverage ratio, defined as the fraction of requirements specified in the SRS that are traceable into the SOD and testing program.

6. Software Reviews and Audits Reviews and audits are part of the Verification and Validation (V&V) activity. Reviews and audits of PG&E activities are specified in the SyWP. Software development reviews and audits will be performed per the 10 CFR SO Appendix Supplier's procedures. Oversight will be performed as described in the Project Quality Plan [2.1.3.9].

7. Test Tests will be performed per the 10 CFR SO Appendix Supplier's procedures for supplier activities and the PG&E SCMP for PG&E activities.

PPS Replacement System Quality Assurance Plan (SyQAP) Rev 1 Page 17 of 19

8. Problem Reporting and Corrective Action Problem reporting and corrective action procedures are part of the SCM activity and documented accordingly in the PG&E SCMP [2.1.3.8] as well as the individual10CFR50 Appendix B suppliers' SCMP.

8.1 Anomaly Resolution and Reporting Anomalies are software discrepancies discovered by the V&V team, either during independent testing or observation of testing by the design and testing organizations. The V&V team will use the normal, applicable discrepancy reporting process of the project. The 10CFR50 Appendix B suppliers' corrective action process will be used for supplier activities and the PG&E corrective action process described in OM7.ID1 will be used for PG&E activities.

8.2 Task Iteration Policy The 10CFR50 Appendix B suppliers' SWP describe the criteria used to determine the extent to which a V&V task will be repeated when its input is changed or task procedure is changed. These criteria may include assessments of change, software integrity level, and effects on budget, schedule, and quality.

9. Tools, Techniques, and Methodologies Tools, techniques and methods for software production will be defined at the project level, and documented in the relevant 10CFR50 Appendix B suppliers' documents. It is an SQA activity, under the responsibility of each of the 10CFR50 Appendix B supplier Lead Verification Engineers, to check that appropriate tools, techniques and methods are selected and to monitor their correct application.

10. Code Control The 10CFR50 Appendix B supplier SCMP(s) will define requirements for code control and disaster recovery. Following delivery to PG&E, code control and disaster recovery will be implemented according to the PG&E SCMP [2.1.3.8].

11. Media Control The media for storing each deliverable work product and the associated documentation during development will be defined by the Appendix B suppliers SCMP(s). Following delivery to PG&E, methods and facilities used to maintain, store, secure and document controlled versions of the identified software will be implemented according to the DCPP SCMP [2.1.3.8]. Prior to delivery to PG&E, media control will be performed in accordance with the individual10CFR50 Appendix B supplier SCMP(s).

12. Supplier Control Supplier control will be maintained by PG&E performing reviews, inspections, and audits. All project documents developed by the suppliers will undergo PG&E review prior to final approval. Inspections can be performed to monitor the execution of any testing. PG&E I&C Project(s) Engineering will review and approve the 10CFR50 Appendix B suppliers SQAP(s).

Oversight requirements, including schedule and tasks to be performed are described in the Project Quality Plan [2.1.3.9].

PPS Replacement System Quality Assurance Plan (SyQAP) Rev 1 Page 18 of 19

13. Records Collection, Maintenance and Retention Following delivery to DCPP, the PG&E project manager is responsible for ensuring all documentation and records will be maintained in accordance with AD1 O.ID1 [2.1.3.6]. This includes, as a minimum the following:

• All final approved documents listed in Section 4 of this SyQAP.

• All formal Review and Comment Resolution Sheets.

• All Audits will be stored per lAW applicable QV requirements.

• Problem Reports and Log.

• All written Project Correspondence (Incoming and Outgoing)

• All final approved Supplier Documentation

• Issued Purchase Orders and any subsequent Change Orders

• Records of performance of any Training All software documentation, formal correspondence, or other documents required by this plan will be archived in DCPP Filenet.

14. Training The PG&E PPS Project Engineering Team will conduct Project Specific Training for PG&E PPS Project Engineering team members on Project administration to include (but not be limited to):

• Project formal correspondence (Incoming and Outgoing)

• Software control (including version control)

• LAN Access and File Storage location

• Project Administration

• Project Problem Reporting

• Selected PG&E Procedures (AD10.ID1 [2.1.3.6], CF2.ID9 [2.1.3.3], etc.)

• Other Training to be determined by the Project Team as required.

The PG&E PM will ensure that all team members have been trained on the elements of this SyQAP as outlined above. The training will be documented on Form 69-20164, Work Group Specific Training.

The 10CFR50 Appendix B suppliers will ensure the following:

• The personnel assigned will be qualified in accordance with appropriate codes and standards.

• The overall management of training is the responsibility of the Project Manager. Training can be considered as a means to reduce risk levels due to the technical experience and skills of the human resources for the project. If a risk factor due to training or skill deficiency is actually identified, this should be documented.

• The Project Manager will verify that training needs have been properly assessed and documented, and monitor the implementation of training plans.

PPS Replacement System Quality Assurance Plan (SyQAP) Rev 1 Page 19 of 19

15. Risk Management Risk is defined as the probability of an adverse event or outcome multiplied by the cost or impact of its occurrence. Risk Management requires specification of the methods used to identify and manage risks associated with the V&V process. Risk management includes identification of risk factors that may cause the V&V task to fail to perform its functions, and methods to recover from any such failure. These methods may range from doing nothing (i.e. live with the risk) to redesign. Redesign options can include eliminating the software feature if acceptable.

Risk management during software development is performed by the 10CFR50 Appendix B suppliers according to their procedures.

16. Glossary Refer to IEEE 610.12-1990 [2.1.2.16], IEEE Standard Glossary of Software Engineering Terminology for definition of terms used in this document.

17. SyQAP Change Procedure and History This section is not applicable. Page two of this SyQAP contains a Revision History Page per PG&E procedures.