ML15099A062: Difference between revisions

From kanterella
Jump to navigation Jump to search
(Created page by program invented by StriderTol)
(Created page by program invented by StriderTol)
 
(5 intermediate revisions by the same user not shown)
Line 17: Line 17:


=Text=
=Text=
{{#Wiki_filter:Enclosure Attachment 3PG&E Letter DCL-1 1-104Diablo Canyon Power Plant Process Protection System (PPS) Replacement
{{#Wiki_filter:Enclosure Attachment 3 PG&E Letter DCL-1 1-104 Diablo Canyon Power Plant Process Protection System (PPS) Replacement Concept, Requirements, and Licensing Phase 1 Project Plan, Revision I (LAR Reference 57)
: Concept, Requirements, and Licensing Phase 1 Project Plan, Revision I(LAR Reference  
: 57)
II~IPacific Gas & Electric Companyiablo Canyon Power PlantUnitslt & 2Process Protection System (PPS) Replacement
: Concept, Requirements, and Licensing Phase IProject PlanRev IPrepared SioPMtI Lest NameReviewed Sig,\k~r 7~Date c r t _Mor IDPrint Lvst NameC" rd SVLOfg~1L2A Print Lest5 Name__________
Approval Sig, ____________
Print Last Namef? ý :1DateUsert IDDate _ _ _UseriDcLTRcj PPS Replacement Project Plan Rev 1Page 1 of 27Revision HistoryRevision Affected Reason for RevisionNumber Item0 All Initial Issue1 Updated per current scope1.2 Revised to reflect Tier 2 Tricon Submittal Figure 1-2 Updated dates1.7 Updated items 28, 29Table 4-1 Updated to reflect current vendor document scopeGeneral Minor editorial changes as marked.
PPS Replacement Project Plan Rev 1Page 2 of 27Table of ContentsSProject Overview
.............................................................................................................................................
41 .1 .P u rp o s e ......................................................................................................................................................
41 .2 .S c o p e ...............................
..........................................................................................................................
41 .3 .O bje c tiv e ....................................................................................................................................................
41.4. Project Organization
..................................................................................................................................
41 .5 .B a c k g ro u n d ................................................................................................................................................
51.6. Project Deliverables
...................................................................................................................................
71 .7 .R e fe re n c e s .................................................................................................................................................
82 Project Organization
.....................................................................................................................................
102.1. Roles and Responsibilities
.......................................................................................................................
103 Developm ent and Licensing Process ....................................................................................................
133.1. Development Process ..............................................................................................................................
133.2. Licensing Process ....................................................................................................................................
164 Schedule, Cost, and Com m unications
..................................................................................................
224.1. Schedule Management
...........................................................................................................................
224.2. Cost Management
....................................................................................................................................
224.3. Cost Estimating and Project Scoping ..................................................................................................
224.4. Project Reporting and Com m unications
.............................................................................................
255 Project Initiation and Planning
....................................................................................................................
266 Supporting Plans ..........................................................................................................................................
276.1. System Quality Assurance Plan (SyQAP) ...........................................................................................
276.2. System Verification and Validation Plan (SyW P) .............................................................................
276 .3 .T ra in in g P la n ............................................................................................................................................
2 76 .4 .In sta lla tio n P la n ........................................................................................................................................
2 76 .5 .O p e ra tio n P la n .........................................................................................................................................
2 76.6. Maintenance Plan ....................................................................................................................................
276.7. Sum mary Software Test Plan ..................................................................................................................
27 PPS Replacement Project Plan Rev 1Page 3 of 27FIGURESFigure 1-1 Existing DCPP Process Protection System ...............................................................................
5Figure 1-2 Proposed PPS LA R Tim eline ....................................................................................................
6Figure 2-1 PPS Replacement Project Organization
....................................................................................
12Figure 3-1 Digital I&C Licensing Process Flow Chart ...............................................................................
16Figure 3-2 Phase 1 Documentation to be submitted to the NRC ...............................................................
19Figure 3-3 Phase 2 Documentation to be submitted to the NRC and available for audit by the NRC ...........
20Figure 3-4 Phase 3 Documentation to be available for inspection after approval
....................................
21Figure 5-1 PPS Replacement Project Lifecycle Document Flow ...............................................................
26TABLESTable 4-1 PPS Replacement PG&E Document Submittals
.....................................................................
23Table 4-2 Project Reporting and Communications
...................................................................................
25 PPS Replacement Project Plan Rev 1Page 4 of 271 Project OverviewThe Project Plan is the "starting point" for a particular project.
The Project Plan identifies specifics aboutthe project, such as the purpose of the project, project scope, project objectives, high-level projectschedule, and the project team. This Project Plan provides the high level details of the Process Protection System (PPS) Project.
The PPS Project Plan is treated as a living document, and will be updatedperiodically throughout the project lifecycle or if there is a significant change in the overall project.1.1. PurposeThe purpose of the PPS Replacement Project is to replace the existing digital Eagle 21 ProcessProtection System (PPS) with a software-based Triconex TRICON platform for the primary PPS functions and incorporate a logic-based Westinghouse/CS Innovations, LLC Advanced Logic System (ALS) forfunctions which require built-in-diversity.
The PPS Replacement Project is schedule to be implemented inthe plant during 1R18 and 2R18, in February, 2014 and September, 2014, respectively.
1.2. ScopeThe new PPS will be supplied by two subvendors:
(1) Invensys/Triconex (2) Westinghouse/CS Innovations, LLC. The scope of work includes the design, fabrication,
: testing, and delivery of a newsystem. The new PPS will be installed in existing cabinets.
It is PG&E's expectation that Invensys willcomplete generic licensing of the Triconex
: platform, however the Safety Evaluation Report (SER) is notexpected to be issued until after the October 2011 LAR submittal.
A Tier 2 review process per ISG-06[1.7.14]
Section C.1 for the Triconex portion of the PPS Replacement License Amendment submittal willbe employed.
Westinghouse/CSI has submitted Phase 1 documentation for generic licensing of the ALSplatform.
The TR for the ALS likely will not be completed in time to support the October 2011 LARsubmittal, thus requiring Tier 3 documentation for the ALS subsystem.


===1.3. Objective===
Pacific Gas & Electric Company I
The primary objective of the Eagle 21 Replacement Project is to install a new PPS that addresses obsolescence issues on a long term basis, provides Diversity and Defense-in-Depth to automatically mitigate all FSAR Chapter 15 accidents or events concurrent with a CCF where the Chapter 15 analysiscurrently credits automatic mitigation, and to improve plant availability and safety.1.4. Project Organization The Eagle 21 PPS Replacement Project is to be accomplished by three primary entities.
I~I                            iablo Canyon Power Plant Unitslt & 2 Process Protection System (PPS) Replacement Concept, Requirements, and Licensing Phase I Project Plan Rev I Prepared Sio                            Date    c  r  t _
The entities are:1) PG&E/DCPP;
PMtI Lest Name Reviewed Sig,    \k~r 7~
: 2) Invensys/Triconex; and 3) Westinghouse/CS Innovations, LLC. A diagram of theproject organization is provided in the Section 3 of this document.
Print Lvst Name                        Mor ID f?
1.4.1 Functionality and Design BasisThe Diablo Canyon Power Plant (DCPP) digital Eagle 21 Process Protection System (PPS) is beingreplaced to address obsolescence and other issues. The PPS comprises Protection Racks 1-16, whichin turn comprise the four redundant PPS rack sets shown in Figure 1-1. The PPS monitors plantparameters, compares them against setpoints and provides signals to the Solid State Protection System(SSPS) if setpoints are exceeded.
C"rd SVLOfg~1L2A                        Date      ý :1 Print Lest5 Name__________              UsertID Approval Sig,  ____________            Date                _ _ _
The SSPS evaluates the signals through coincident logic andperforms Reactor Trip System (RTS) and Engineered Safety Features Actuation System (ESFAS)command functions to mitigate an event that may be in progress.
Print Last Name                        UseriD cLTRcj
PPS Replacement Project Plan Rev 1Page 5 of 27Figure 1-1 Existing DCPP Process Protection SystemEaagle 21Prot Set III(R11 R13 -- Eagle 211(RB.RIO Eagle 21 To Diverse AMSACIsolated Outputs to: PR14Se116)
 
Digital Feedwater Control SystemAuniliary Feedwater Rod Speed & Direction ControlPressurizer PressurePressurizer LevelSteam Dump ControlCondenser Hotwell Level ControlPost-Accident Monitoring Plant ComputerHardvwred Indicators
PPS Replacement Project Plan Rev 1 Page 1 of 27 Revision History Revision Affected    Reason for Revision Number      Item 0          All    Initial Issue 1    Updated per current scope 1.2    Revised to reflect Tier 2 Tricon Submittal Figure 1-2  Updated dates 1.7    Updated items 28, 29 Table 4-1  Updated to reflect current vendor document scope General    Minor editorial changes as marked.
& Recorders SSPS SSPS SSPS SSPSNB NB NB A/BI II III IV1.4.2 Technical Specification ChangesTechnical Specification changes will be necessary if Safety Analysis Limits or Nominal Setpoints changeas a result of the setpoint study to be performed for this project.1.5. Background The Diablo Canyon Power Plant (DCPP) digital Eagle 21 Process Protection System (PPS) is beingreplaced to address obsolescence issues. The PPS monitors plant parameters, compares them againstsetpoints and provides signals to the Solid State Protection System (SSPS) if setpoints are exceeded.
 
The SSPS evaluates the signals through coincident logic and performs Reactor Trip System (RTS) andEngineered Safety Features Actuation System (ESFAS) command functions to mitigate an event thatmay be in progress.
PPS Replacement Project Plan Rev 1 Page 2 of 27 Table of Contents SProject Overview .............................................................................................................................................             4 1 .1 . P u rp os e ......................................................................................................................................................      4 1.2 . S c o p e ............................... .......................................................................................................................... 4 1.3 . O bjec tiv e ....................................................................................................................................................        4 1.4. Project Organization ..................................................................................................................................                  4 1.5 . Ba c kg ro u n d ................................................................................................................................................        5 1.6. Project Deliverables ...................................................................................................................................                7 1.7 . R e fe re n c e s .................................................................................................................................................      8 2    Project Organization .....................................................................................................................................                  10 2.1. Roles and Responsibilities .......................................................................................................................                      10 3    Developm ent and Licensing Process ....................................................................................................                                    13 3.1. Development Process ..............................................................................................................................                      13 3.2. Licensing Process ....................................................................................................................................                  16 4    Schedule, Cost, and Com m unications ..................................................................................................                                    22 4.1. Schedule Management ...........................................................................................................................                        22 4.2. Cost Management ....................................................................................................................................                    22 4.3. Cost Estimating and Project Scoping ..................................................................................................                                  22 4.4. Project Reporting and Com m unications .............................................................................................                                    25 5    Project Initiation and Planning ....................................................................................................................                        26 6    Supporting Plans ..........................................................................................................................................                27 6.1. System Quality Assurance Plan (SyQAP) ...........................................................................................                                      27 6.2. System Verification and Validation Plan (SyW P) .............................................................................                                          27 6 .3 . T ra in ing P la n ............................................................................................................................................        27 6 .4 . Insta lla tio n P la n ........................................................................................................................................        27 6 .5 . O p e ra tio n P la n .........................................................................................................................................        27 6.6. Maintenance Plan ....................................................................................................................................                  27 6.7. Sum mary Software Test Plan ..................................................................................................................                          27
The Eagle 21 PPS comprises Protection Racks 1-16. There are four separate PPS rack sets. Theoriginal Westinghouse/Hagen 7100 analog protection sets were replaced in 1 R6 and 2R6 with theexisting Westinghouse Eagle 21 PPS.The proposed PPS will address current regulations and guidance regarding Diversity and Defense-in-Depth. It will implement automatic protective functions in a Class IE software-based Triconex TRICON[1.7.10]
 
processor to mitigate events for which the Eagle 21 SER [1.7.1] credited available diverseautomatic mitigating functions.
PPS Replacement Project Plan Rev 1 Page 3 of 27 FIGURES Figure 1-1 Existing DCPP Process Protection System ...............................................................................              5 Figure 1-2 Proposed PPS LA R Tim eline .................................................................................................... 6 Figure 2-1 PPS Replacement Project Organization ....................................................................................          12 Figure 3-1 Digital I&C Licensing Process Flow Chart ...............................................................................            16 Figure 3-2 Phase 1 Documentation to be submitted to the NRC ...............................................................                    19 Figure 3-3 Phase 2 Documentation to be submitted to the NRC and available for audit by the NRC ...........                                    20 Figure 3-4 Phase 3 Documentation to be available for inspection after approval ....................................                          21 Figure 5-1 PPS Replacement Project Lifecycle Document Flow ...............................................................                    26 TABLES Table 4-1  PPS Replacement PG&E Document Submittals .....................................................................                    23 Table 4-2  Project Reporting and Communications ...................................................................................          25
The proposed PPS will implement automatic protective functions in alogic-based Class IE Westinghouse/CS Innovations, LLC Advanced Logic System (ALS) [1.7.11]
 
withbuilt-in diversity that address software CCF per NRC ISG-02 [1.7.13]
PPS Replacement Project Plan Rev 1 Page 4 of 27 1            Project Overview The Project Plan is the "starting point" for a particular project. The Project Plan identifies specifics about the project, such as the purpose of the project, project scope, project objectives, high-level project schedule, and the project team. This Project Plan provides the high level details of the Process Protection System (PPS) Project. The PPS Project Plan is treated as a living document, and will be updated periodically throughout the project lifecycle or if there is a significant change in the overall project.
Position 1 to automatically mitigateevents that otherwise would require manual protective action if the events were to occur with a concurrent software Common Cause Failure (CCF) to the PPS.A License Amendment Request (LAR) is being prepared and will be submitted to the NRC forreplacement of the Eagle 21 PPS.Figure 1-2 illustrates the proposed PPS LAR timeline.
1.1.          Purpose The purpose of the PPS Replacement Project is to replace the existing digital Eagle 21 Process Protection System (PPS) with a software-based Triconex TRICON platform for the primary PPS functions and incorporate a logic-based Westinghouse/CS Innovations, LLC Advanced Logic System (ALS) for functions which require built-in-diversity. The PPS Replacement Project is schedule to be implemented in the plant during 1R18 and 2R18, in February, 2014 and September, 2014, respectively.
PPS Replacement Project Plan Rev 1Page 6 of 27Figure 1-2 Proposed PPS LAR TimelineDCPP PPS Replacement Project Timeline4120/2012 5/20/2012 Vendor Phase 2 Items Complete Phase 2 Items 12//2012 2/25Provided to PG&E Provided to NRC .vendoor FAS Design PaComplete5/2013 2/14/2014 ckage Issued 5/20/2013 PPS Installation 4/30/2014 2/1/2011 3/1/2011 4/1/2011 5/1/2011 6/1/2011 7/1/2011 8/1/2011 9/1/2011 10/1/2011 11/1/2011 12/1/2011 11,/2011LAR Submittal I2/3V2011 PPS Replacement Project Plan Rev 1Page 7 of 271.6. Project Deliverables The project deliverables consists of items from each of the entities participating in the project.Deliverables include the physical equipment as well as the documentation associated with the design,testing, installation, maintenance, and operation of the equipment.
1.2.          Scope The new PPS will be supplied by two subvendors: (1) Invensys/Triconex (2) Westinghouse/CS Innovations, LLC. The scope of work includes the design, fabrication, testing, and delivery of a new system. The new PPS will be installed in existing cabinets. It is PG&E's expectation that Invensys will complete generic licensing of the Triconex platform, however the Safety Evaluation Report (SER) is not expected to be issued until after the October 2011 LAR submittal. A Tier 2 review process per ISG-06
1.6.1 Deliverables from PPS Subsystem VendorsThe PPS subsystem vendors are responsible for the delivery of the physical equipment to be installed inexisting PPS cabinets.
[1.7.14] Section C.1 for the Triconex portion of the PPS Replacement License Amendment submittal will be employed. Westinghouse/CSI has submitted Phase 1 documentation for generic licensing of the ALS platform. The TR for the ALS likely will not be completed in time to support the October 2011 LAR submittal, thus requiring Tier 3 documentation for the ALS subsystem.
The physical equipment shall meet the requirements of the PPS Functional Requirements Specification, Interface Requirements Specification, and Purchase Specification(s).
1.3.          Objective The primary objective of the Eagle 21 Replacement Project is to install a new PPS that addresses obsolescence issues on a long term basis, provides Diversity and Defense-in-Depth to automatically mitigate all FSAR Chapter 15 accidents or events concurrent with a CCF where the Chapter 15 analysis currently credits automatic mitigation, and to improve plant availability and safety.
The physical deliverables list for the project will be updated during subsequent project phases as thedetails of the equipment becomes available.
1.4.          Project Organization The Eagle 21 PPS Replacement Project is to be accomplished by three primary entities. The entities are:
The documentation deliverables of the project include:1. ISG-06 Vendor Required Documentation, see Section 4 Development and Licensing Process forISG-06 Document Submittal Matrix for Phase 1 and Phase 2 document submittals
: 1) PG&E/DCPP; 2) Invensys/Triconex; and 3) Westinghouse/CS Innovations, LLC. A diagram of the project organization is provided in the Section 3 of this document.
: 2. Outline Drawings3. Functional Logic Diagram4. Assembly Drawings5. Wiring Diagrams6. Equipment Qualification Plan (if not included in vendor Topical Report)7. Equipment Qualification Report (if not included in vendor Topical Report)8. Equipment Travelers
1.4.1        Functionality and Design Basis The Diablo Canyon Power Plant (DCPP) digital Eagle 21 Process Protection System (PPS) is being replaced to address obsolescence and other issues. The PPS comprises Protection Racks 1-16, which in turn comprise the four redundant PPS rack sets shown in Figure 1-1. The PPS monitors plant parameters, compares them against setpoints and provides signals to the Solid State Protection System (SSPS) if setpoints are exceeded. The SSPS evaluates the signals through coincident logic and performs Reactor Trip System (RTS) and Engineered Safety Features Actuation System (ESFAS) command functions to mitigate an event that may be in progress.
: 9. Certificate of Conformance
 
: 10. Instruction and Operating Manuals11. Resolution of any qualification anomalies 1.6.2 Deliverables from PG&EThe documentation deliverables of the project include:1. ISG-06 Utility Required Documentation; see Section 4 Development and Licensing Process forISG-06 Document Submittal Matrix for Phase 1 and Phase 2 document submittals
PPS Replacement Project Plan Rev 1 Page 5 of 27 Figure 1-1  Existing DCPP Process Protection System Eaagle 21 Prot Set III (R11 R13Eagle 211                --
: 2. Conceptual Design Document (CDD) [1.7.25]3. Functional Requirements Specification (FRS) [1.7.2614. Interface Requirements Specification (IRS, including I/O List) [1.7.27]5. Design Change Package (by Engineer of Choice (EOC))6. Project Level V&V Documents
(RB.RIO            Eagle21                        To DiverseAMSAC Isolated Outputs to:                                                                      PR14Se116)
: a. System Verification and Validation Plan (SyWP)b. Requirements Traceability Matrix (RTM)c. Site Acceptance Test (SAT) Procedure and Test Execution
Digital Feedwater Control System Auniliary Feedwater Rod Speed & Direction Control Pressurizer Pressure Pressurizer Level Steam Dump Control Condenser Hotwell Level Control Post-Accident Monitoring Plant Computer Hardvwred Indicators &Recorders SSPS                SSPS          SSPS          SSPS NB                    NB            NB            A/B I                  II            III            IV 1.4.2                Technical Specification Changes Technical Specification changes will be necessary if Safety Analysis Limits or Nominal Setpoints change as a result of the setpoint study to be performed for this project.
1.5.                Background The Diablo Canyon Power Plant (DCPP) digital Eagle 21 Process Protection System (PPS) is being replaced to address obsolescence issues. The PPS monitors plant parameters, compares them against setpoints and provides signals to the Solid State Protection System (SSPS) if setpoints are exceeded.
The SSPS evaluates the signals through coincident logic and performs Reactor Trip System (RTS) and Engineered Safety Features Actuation System (ESFAS) command functions to mitigate an event that may be in progress.
The Eagle 21 PPS comprises Protection Racks 1-16. There are four separate PPS rack sets. The original Westinghouse/Hagen 7100 analog protection sets were replaced in 1 R6 and 2R6 with the existing Westinghouse Eagle 21 PPS.
The proposed PPS will address current regulations and guidance regarding Diversity and Defense-in-Depth. It will implement automatic protective functions in a Class IE software-based Triconex TRICON
[1.7.10] processor to mitigate events for which the Eagle 21 SER [1.7.1] credited available diverse automatic mitigating functions. The proposed PPS will implement automatic protective functions in a logic-based Class IE Westinghouse/CS Innovations, LLC Advanced Logic System (ALS) [1.7.11] with built-in diversity that address software CCF per NRC ISG-02 [1.7.13] Position 1 to automatically mitigate events that otherwise would require manual protective action if the events were to occur with a concurrent software Common Cause Failure (CCF) to the PPS.
A License Amendment Request (LAR) is being prepared and will be submitted to the NRC for replacement of the Eagle 21 PPS.
Figure 1-2 illustrates the proposed PPS LAR timeline.
 
PPS Replacement Project Plan Rev 1 Page 6 of 27 Figure 1-2                Proposed PPS LAR Timeline DCPP PPS Replacement Project Timeline 4120/2012                5/20/2012 Vendor Phase 2 Items Complete  Phase 2 Items              12//2012          2/25 Provided to PG&E        Provided to NRC            .                        5/2013                                      2/14/2014 vendoor FAS    Design Pa ckage Issued    5/20/2013                PPS Installation Complete 4/30/2014 2/1/2011 3/1/2011 4/1/2011  5/1/2011            6/1/2011          7/1/2011 8/1/2011            9/1/2011            10/1/2011      11/1/2011 12/1/2011 11,/2011                                                          LAR Submittal                                                                                        I2/3V2011
 
PPS Replacement Project Plan Rev 1 Page 7 of 27 1.6.          Project Deliverables The project deliverables consists of items from each of the entities participating in the project.
Deliverables include the physical equipment as well as the documentation associated with the design, testing, installation, maintenance, and operation of the equipment.
1.6.1          Deliverables from PPS Subsystem Vendors The PPS subsystem vendors are responsible for the delivery of the physical equipment to be installed in existing PPS cabinets. The physical equipment shall meet the requirements of the PPS Functional Requirements Specification, Interface Requirements Specification, and Purchase Specification(s).
The physical deliverables list for the project will be updated during subsequent project phases as the details of the equipment becomes available.
The documentation deliverables of the project include:
: 1.        ISG-06 Vendor Required Documentation, see Section 4 Development and Licensing Process for ISG-06 Document Submittal Matrix for Phase 1 and Phase 2 document submittals
: 2.      Outline Drawings
: 3.        Functional Logic Diagram
: 4.      Assembly Drawings
: 5.      Wiring Diagrams
: 6.        Equipment Qualification Plan (if not included in vendor Topical Report)
: 7.        Equipment Qualification Report (if not included in vendor Topical Report)
: 8.        Equipment Travelers
: 9.        Certificate of Conformance
: 10.      Instruction and Operating Manuals
: 11.      Resolution of any qualification anomalies 1.6.2          Deliverables from PG&E The documentation deliverables of the project include:
: 1.        ISG-06 Utility Required Documentation; see Section 4 Development and Licensing Process for ISG-06 Document Submittal Matrix for Phase 1 and Phase 2 document submittals
: 2.        Conceptual Design Document (CDD) [1.7.25]
: 3.        Functional Requirements Specification (FRS) [1.7.261
: 4.        Interface Requirements Specification (IRS, including I/O List) [1.7.27]
: 5.        Design Change Package (by Engineer of Choice (EOC))
: 6.        Project Level V&V Documents
: a. System Verification and Validation Plan (SyWP)
: b. Requirements Traceability Matrix (RTM)
: c. Site Acceptance Test (SAT) Procedure and Test Execution
: d. System V&V Report (SyWR)
: d. System V&V Report (SyWR)
PPS Replacement Project Plan Rev 1Page 8 of 271.7. References
 
: 1. NRC, "Safety Evaluation Report Eagle 21 Reactor Protection System Modification With BypassManifold Elimination, PG&E, Diablo Canyon Power Plant," October 7, 19932. NRC, NUREG-0800, Standard Review Plan, Branch Technical Position (BTP) 7-19, "Guidance for Evaluation of Defense-in-Depth and Diversity in Digital Computer-Based Instrumentation andControl Systems,"
PPS Replacement Project Plan Rev 1 Page 8 of 27 1.7. References
March 20073. NRC, NUREG-0800, Standard Review Plan, BTP 7-14, Guidance on Software Reviews for DigitalComputer-Based Instrumentation and Control Systems4. NRC, Regulatory Guide 1.168, Rev 1, Verification, Validation,  
: 1. NRC, "Safety Evaluation Report Eagle 21 Reactor Protection System Modification With Bypass Manifold Elimination, PG&E, Diablo Canyon Power Plant," October 7, 1993
: Reviews, And Audits For DigitalComputer Software Used in Safety Systems of Nuclear Power Plants5. NRC, Regulatory Guide 1.169, Configuration Management Plans for Digital Computer SoftwareUsed in Safety Systems of Nuclear Power Plants6. NRC, Regulatory Guide 1.170, Software Test Documentation for Digital Computer Software Usedin Safety Systems of Nuclear Power Plants7. NRC, Regulatory Guide 1.171, Software Unit Testing for Digital Computer Software Used inSafety Systems of Nuclear Power Plants8. NRC, Regulatory Guide 1.172, Software Requirements Specifications for Digital ComputerSoftware Used in Safety Systems of Nuclear Power Plants9. NRC, Regulatory Guide 1.173, Developing Software Life Cycle Processes for Digital ComputerSoftware Used in Safety Systems of Nuclear Power Plants10. Letter No. NRC-V1 0-09-01, J. Polcyn (Invensys) to NRC, "Nuclear Safety-Related Qualification ofthe Tricon TMR Programmable Logic Controller (PLC) -Update to Qualification Summary ReportSubmittal" and "Application for withholding Proprietary Information from Public Disclosure,"
: 2. NRC, NUREG-0800, Standard Review Plan, Branch Technical Position (BTP) 7-19, "Guidance for Evaluation of Defense-in-Depth and Diversity in Digital Computer-Based Instrumentation and Control Systems," March 2007
September 9, 200911. Westinghouse/CS Innovations, LLC, Advanced Logic System Topical Report, July 201012. PG&E Topical Report: Process Protection System Replacement Diversity  
: 3. NRC, NUREG-0800, Standard Review Plan, BTP 7-14, Guidance on Software Reviews for Digital Computer-Based Instrumentation and Control Systems
& Defense-in-Depth Assessment
: 4. NRC, Regulatory Guide 1.168, Rev 1, Verification, Validation, Reviews, And Audits For Digital Computer Software Used in Safety Systems of Nuclear Power Plants
: 13. Digital Instrumentation and Controls DI&C-ISG-02 Task Working Group #2: Diversity andDefense-in-Depth Issues Interim Staff Guidance Revision 2, June 5, 200914. Digital Instrumentation and Controls DI&C-ISG-06 Task Working Group #6: Licensing Process,Rev 1 (ADAMS MLl101401030)
: 5. NRC, Regulatory Guide 1.169, Configuration Management Plans for Digital Computer Software Used in Safety Systems of Nuclear Power Plants
: 15. IDAP CF2.1D2, Software Configuration Management for Computers  
: 6. NRC, Regulatory Guide 1.170, Software Test Documentation for Digital Computer Software Used in Safety Systems of Nuclear Power Plants
& Software Used for PlantOperations and Operations Support16. IDAP CF2.1D9, Software Quality Assurance Plan Software Development
: 7. NRC, Regulatory Guide 1.171, Software Unit Testing for Digital Computer Software Used in Safety Systems of Nuclear Power Plants
: 17. IDAP CF3.1D9,  
: 8. NRC, Regulatory Guide 1.172, Software Requirements Specifications for Digital Computer Software Used in Safety Systems of Nuclear Power Plants
[Design Change (Package)
: 9. NRC, Regulatory Guide 1.173, Developing Software Life Cycle Processes for Digital Computer Software Used in Safety Systems of Nuclear Power Plants
Development
: 10. Letter No. NRC-V1 0-09-01, J. Polcyn (Invensys) to NRC, "Nuclear Safety-Related Qualification of the Tricon TMR Programmable Logic Controller (PLC) - Update to Qualification Summary Report Submittal" and "Application for withholding Proprietary Information from Public Disclosure,"
September 9, 2009
: 11. Westinghouse/CS Innovations, LLC, Advanced Logic System Topical Report, July 2010
: 12. PG&E Topical Report: Process Protection System Replacement Diversity & Defense-in-Depth Assessment
: 13. Digital Instrumentation and Controls DI&C-ISG-02 Task Working Group #2: Diversity and Defense-in-Depth Issues Interim Staff Guidance Revision 2, June 5, 2009
: 14. Digital Instrumentation and Controls DI&C-ISG-06 Task Working Group #6: Licensing Process, Rev 1 (ADAMS MLl101401030)
: 15. IDAP CF2.1D2, Software Configuration Management for Computers & Software Used for Plant Operations and Operations Support
: 16. IDAP CF2.1D9, Software Quality Assurance Plan Software Development
: 17. IDAP CF3.1D9, [Design Change (Package) Development
: 18. IDAP AD7.1D8, Project Management
: 18. IDAP AD7.1D8, Project Management
: 19. IEEE 829-1983, Standard for Software Test Documentation
: 19. IEEE 829-1983, Standard for Software Test Documentation
Line 134: Line 106:
: 22. IEEE 1016, IEEE Recommended Practice for Software Design Descriptions
: 22. IEEE 1016, IEEE Recommended Practice for Software Design Descriptions
: 23. IEEE 1074-1995, Standard for Developing software Lifecycle Processes
: 23. IEEE 1074-1995, Standard for Developing software Lifecycle Processes
: 24. IEEE 1008-1987, Standard for Software Unit Testing25. Process Protection System (PPS) Replacement Conceptual Design Document (CDD)26. Process Protection System (PPS) Replacement Functional Requirements Specification (FRS)27. Process Protection System (PPS) Replacement Interface Requirements Specification (IRS)28. PPS System Quality Assurance Plan (SyQAP)29. PPS System Verification and Validation Plan (SyWP)
: 24. IEEE 1008-1987, Standard for Software Unit Testing
PPS Replacement Project Plan Rev 1Page 9 of 2730. PPS Training Plan31. PPS Installation Plan32. PPS Operations Plan33. PPS Maintenance Plan PPS Replacement Project Plan Rev 1Page 10 of 272 Project Organization The PPS Project is to be accomplished by three primary entities;  
: 25. Process Protection System (PPS) Replacement Conceptual Design Document (CDD)
: 1) PG&E/DCPP,  
: 26. Process Protection System (PPS) Replacement Functional Requirements Specification (FRS)
: 2) Invensys/Triconex; and 3) Westinghouse/CS Innovations, LLC. Figure 2-1 illustrates the project organization.
: 27. Process Protection System (PPS) Replacement Interface Requirements Specification (IRS)
2.1. Roles and Responsibilities The following sections outline the roles and responsibilities of the PPS project organization members.2.1.1 PG&E Project ManagerThe PG&E Project Manager has the ultimate responsibility, authority, and accountability for all aspects ofthe project.
: 28. PPS System Quality Assurance Plan (SyQAP)
Responsibilities include quality of design, timely integration with site schedules, vendor qualitymanagement/oversight, quality field implementation, and successful post-installation testing.
: 29. PPS System Verification and Validation Plan (SyWP)
The ProjectManager is also responsible to recommend re-evaluation of the project if he detects changes in theproject that alter the decision to proceed.The PG&E Project Manager shares the responsibility for meeting the software quality goals andobjectives of the project and for the implementation of software quality management throughout theproject.The project manager shall:1. Release the system level V&V plan and reports2. Establish cost controls3. Enter the plan activities into the master project schedule.
 
: 4. Review progress of the SQAP and V&V program5. Evaluate any reported deviations or anomalies for their potential risk and impacts to project cost andschedule.
PPS Replacement Project Plan Rev 1 Page 9 of 27
: 6. Approve corrective  
: 30. PPS Training Plan
: actions, scope changes and resource allocations.
: 31. PPS Installation Plan
: 7. Coordinate the disposition of discrepancy reports generated in the course of verification andvalidation.
: 32. PPS Operations Plan
2.1.2 Engineer of Choice (EoC) Design Change Package TeamThe Engineer of Choice (EoC) Design Change Package Team is responsible for the design changeprocess utilized by DCPP for the design and implementation of modifications to controlled Structures,
: 33. PPS Maintenance Plan
: Systems, and Components.
 
The Engineer of Choice (EoC) Design Change Package Team is alsoresponsible for establishing quality goals and objectives for their organization consistent with those of theproject.2.1.3 PG&E Project Engineering TeamThe PG&E Project Engineering team conducts and ensures quality-related inter-group coordination forsoftware and hardware design engineering activities.
PPS Replacement Project Plan Rev 1 Page 10 of 27 2            Project Organization The PPS Project is to be accomplished by three primary entities; 1) PG&E/DCPP, 2) Invensys/Triconex; and 3) Westinghouse/CS Innovations, LLC. Figure 2-1 illustrates the project organization.
Project engineering is responsible for identifying theprocesses and corresponding standards and procedures to guide project performance.
2.1.         Roles and Responsibilities The following sections outline the roles and responsibilities of the PPS project organization members.
The projectengineering team is further responsible for ensuring work activities are performed in compliance withthese standards and procedures.
2.1.1         PG&E Project Manager The PG&E 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, vendor quality management/oversight, quality field implementation, and successful post-installation testing. The Project Manager is also responsible to recommend re-evaluation of the project if he detects changes in the project that alter the decision to proceed.
2.1.4 10CFR50 Appendix B Supplier(s)
The PG&E Project Manager shares the responsibility for meeting the software quality goals and objectives of the project and for the implementation of software quality management throughout the project.
The 1 OCFR50 Appendix B supplier(s) are responsible for the design, development, integration, and finaldelivery of the respective Class 1E equipment to PG&E. As a 1OCFR50, Appendix B suppliers, Invensys/Triconex and Westinghouse/CS Innovations, LLC provide their respective platforms as Class 1 Eequipment for the PPS Replacement Project.
The project manager shall:
PPS Replacement Project Plan Rev 1Page 11 of 27The 10CFR50 Appendix B supplier personnel play the major role in implementing the SQA program.
: 1. Release the system level V&V plan and reports
It istheir responsibility to build quality into the products they develop or support.
: 2. Establish cost controls
It is also their responsibility to propose process improvements based on their application of the methodology.
: 3. Enter the plan activities into the master project schedule.
The 1 OCFR50 Appendix B supplier personnel are also participants in the inspection and reviewprocesses applied to intermediate products resulting from project work activities.
: 4. Review progress of the SQAP and V&V program
Serving as inspectors or reviewers, they examine the products of their peers to ensure technical soundness and overall qualitybefore proceeding to the next phase of development.
: 5. Evaluate any reported deviations or anomalies for their potential risk and impacts to project cost and schedule.
Another significant responsibility is the performance of independent testing.
: 6. Approve corrective actions, scope changes and resource allocations.
All systems developed ormodified under the Program must be adequately tested before they are delivered or made available foruse. Personnel familiar with the products being validated, but not the developer of the product, typically perform testing.
: 7. Coordinate the disposition of discrepancy reports generated in the course of verification and validation.
The tests ensure new and revised systems meet allocated requirements as well asestablish their overall quality and delivery readiness.
2.1.2         Engineer of Choice (EoC) Design Change Package Team The Engineer of Choice (EoC) Design Change Package 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 Engineer of Choice (EoC) Design Change Package Team is also responsible for establishing quality goals and objectives for their organization consistent with those of the project.
Software Unit Testing may be performed by the SWdeveloper.
2.1.3         PG&E Project Engineering Team The PG&E Project Engineering team conducts and ensures quality-related inter-group coordination for software and hardware design engineering activities. Project engineering is responsible for identifying the processes and corresponding standards and procedures to guide project performance. The project engineering team is further responsible for ensuring work activities are performed in compliance with these standards and procedures.
PPS Replacement Project Plan Rev 1Page 12 of 27Figure 2-1 PPS Replacement Project Organization Diablo CanyonPPS UpgradeProject ManagerScott Patterson I
2.1.4         10CFR50 Appendix B Supplier(s)
PPS Replacement Project Plan Rev 1Page 13 of 273 Development and Licensing Process3.1. Development ProcessThe PPS project development process is structured to follow a traditional waterfall life cycle that includesa top down requirement and specification development, design implementation, and a bottom up V&Veffort at each level of integration.
The 10CFR50 Appendix B supplier(s) are responsible for the design, development, integration, and final delivery of the respective Class 1E equipment to PG&E. As a 10CFR50, Appendix B suppliers, Invensys/Triconex and Westinghouse/CS Innovations, LLC provide their respective platforms as Class 1E equipment for the PPS Replacement Project.
The program development allows prototyping activities.
 
In-process quality assurance efforts are executed integral to the development stages where prototyping is employed.
PPS Replacement Project Plan Rev 1 Page 11 of 27 The 10CFR50 Appendix B supplier personnel play the major role in implementing the SQA program. It is their responsibility to build quality into the products they develop or support. It is also their responsibility to propose process improvements based on their application of the methodology.
Software lifecycle processes are to be developed in accordance with IEEE 1074 [1.7.23]
The 10CFR50 Appendix B supplier personnel are also participants in the inspection and review processes applied to intermediate products resulting from project work activities. Serving as inspectors or reviewers, they examine the products of their peers to ensure technical soundness and overall quality before proceeding to the next phase of development.
per the guidanceof NRC Reg Guide 1.173 [1.7.9].A secure development and operational environment is to be provided and maintained per ISG 06 [1.7.14]Section D.12.A high level description of each phase of the development process is provided below. For details of theV&V activities for each phase, refer to the PPS Project Software Quality Assurance Plan.3.1.1 Project Initiation and Planning PhaseThe Planning phase confirms that the system to be acquired is what is actually needed, and that it will bein compliance with the licensing basis of the plant. This phase also produces procedures for managingthe interface with the supplier, and for managing changes to requirements.
Another significant responsibility is the performance of independent testing. All systems developed or modified under the Program must be adequately tested before they are delivered or made available for use. Personnel familiar with the products being validated, but not the developer of the product, typically perform testing. The tests ensure new and revised systems meet allocated requirements as well as establish their overall quality and delivery readiness. Software Unit Testing may be performed by the SW developer.
A verified and acceptedcontract(s) is a product of this phase.3.1.2 Conceptual Design PhaseThe Conceptual design phase defines the scope of the V&V effort. The initial System V&V Plan, SyQAP,and FRS are products of this phase. As shown in Figure 5-1, the Interface Requirements Specification (IRS, which includes the Input/Output List) is also prepared in this phase.3.1.3 Requirements PhaseIn this phase, a Software Requirements Specification (SRS) or its equivalent will be prepared by the PPSSubsystem Vendors for each applicable software product using the guidance of IEEE Std. 830 [1.7.20]per the guidance of NRC Reg Guide 1.172 [1.7.8].
 
The Requirements Phase Documentation will bedeveloped based on the FRS and IRS as inputs. The outputs of this task are:3.1.3.1 ALS1. System Requirements Specification (SyRS)2. System Design Specification (SyDS)3. Software Requirements Specification (Equivalent to Core Logic Board Specification) 3.1.3.2 Invensys/Triconex
PPS Replacement Project Plan Rev 1 Page 12 of 27 Figure 2-1         PPS Replacement Project Organization Diablo Canyon PPS Upgrade Project Manager Scott Patterson I
: 1. Software Architecture Description (SAD)2. Hardware Architecture Description (HAD)3. Software Requirements Specification (SRS)3.1.4 Design & Implementation PhaseIn this phase of a typical software development  
 
: project, the developer prepares the Software DesignDescription (SDD) for the software product using the guidance of IEEE Std. 1016 [1.7.22].
PPS Replacement Project Plan Rev 1 Page 13 of 27 3            Development and Licensing Process 3.1.         Development Process The PPS project development process is structured to follow a traditional waterfall life cycle that includes a top down requirement and specification development, design implementation, and a bottom up V&V effort at each level of integration. The program development allows prototyping activities. In-process quality assurance efforts are executed integral to the development stages where prototyping is employed.
The SDD isdeveloped based on the Requirements Phase outputs for the project-specific hardware architecture.
Software lifecycle processes are to be developed in accordance with IEEE 1074 [1.7.23] per the guidance of NRC Reg Guide 1.173 [1.7.9].
Atypical SDD consists of two parts: the software and hardware architectural description and the SoftwareDetailed Design.For this project, the design documentation prepared by the subvendors is illustrated in Figure 5-1.
A secure development and operational environment is to be provided and maintained per ISG 06 [1.7.14]
PPS Replacement Project Plan Rev 1Page 14 of 273.1.4.1 ALS1. Hardware Design Specification (HDS)3.1.4.2 Invensys/Triconex
Section D.12.
: 1. Software Design Specification (SDS)2. Hardware Design Specification (HDS)Software Test Plan(s) (STP) are generated by the PPS Subsystem Vendors to evaluate systemperformance based on the SRS and the software/system design documentation.
A high level description of each phase of the development process is provided below. For details of the V&V activities for each phase, refer to the PPS Project Software Quality Assurance Plan.
A three-step approach isused for testing, modified asapplicable for the specific platform and the subvendor procedures:
3.1.1         Project Initiation and Planning Phase 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. A verified and accepted contract(s) is a product of this phase.
: 1. Component (Software Unit) Testing,2. Integration  
3.1.2         Conceptual Design Phase The Conceptual design phase defines the scope of the V&V effort. The initial System V&V Plan, SyQAP, and FRS are products of this phase. As shown in Figure 5-1, the Interface Requirements Specification (IRS, which includes the Input/Output List) is also prepared in this phase.
: Testing, and3. Acceptance Testing (FAT).Software Test Plans will conform to the requirements of IEEE Std. 829 [1.7.19]
3.1.3         Requirements Phase In this phase, a Software Requirements Specification (SRS) or its equivalent will be prepared by the PPS Subsystem Vendors for each applicable software product using the guidance of IEEE Std. 830 [1.7.20]
per the guidance of NRCReg Guide 1.170 [1.7.6] and IEEE Std. 1008 [1.7.24]
per the guidance of NRC Reg Guide 1.172 [1.7.8]. The Requirements Phase Documentation will be developed based on the FRS and IRS as inputs. The outputs of this task are:
per the guidance of Reg Guide 1.171 [1.7.7].Software Test Plans will be reviewed by PG&E. Separate Factory Acceptance Test Plans will bedeveloped by the PPS Subsystem Vendors and will be reviewed by PG&E.3.1.5 Implementation PhaseDuring this phase the executable code is produced and tested, based on the above phase outputs.Depending upon the target system, source code may be developed by the design team/programmers, orautomatic code generators may produce the executable code. In either case, the functions described inthe SRS and design documents are developed in the coding environment to programming standards.
3.1.3.1       ALS
Thecorrect implementation of the SRS and design documents is validated by testing or other means with thesoftware development and simulation tools, and by testing on a test/development system. The RTM willgenerally have no entries for this phase. Software unit testing is performed by the design team during thisphase.The implementation phase is concurrent with the design phase in Figure 5-1.3.1.6 Integration PhaseIntegration Testing is a separate software Lifecycle activity per NUREG-0800 BTP 7-14 and can bemapped to IEEE 1012 [1.7.21]
: 1.       System Requirements Specification (SyRS)
per the guidance of NRC Reg Guide 1.168 [1.7.4] as a continuation of theImplementation Phase. The Software is integrated with the hardware and integration testing is performed in accordance with the test procedures per IEEE Std. 829. Integration test execution results are analyzedto determine if the system implements the requirements and design and that the software components function correctly together.
: 2.       System Design Specification (SyDS)
The integration phase is concurrent with the design phase in Figure 5-1.The RTM is updated to demonstrate traceability from concept documentation through the requirements, design, implementation and integration phases.3.1.7 Test PhaseSystem tests, are performed in accordance with the FAT test procedures.
: 3.       Software Requirements Specification (Equivalent to Core Logic Board Specification) 3.1.3.2       Invensys/Triconex
Tests are analyzed to determine if the system implements the requirements and design and that the software components functioncorrectly together.
: 1.       Software Architecture Description (SAD)
Test results are analyzed to determine if the software satisfies system objectives.
: 2.       Hardware Architecture Description (HAD)
: 3.       Software Requirements Specification (SRS) 3.1.4         Design & Implementation Phase In this phase of a typical software development project, the developer prepares the Software Design Description (SDD) for the software product using the guidance of IEEE Std. 1016 [1.7.22]. The SDD is developed based on the Requirements Phase outputs for the project-specific hardware architecture. A typical SDD consists of two parts: the software and hardware architectural description and the Software Detailed Design.
For this project, the design documentation prepared by the subvendors is illustrated in Figure 5-1.
 
PPS Replacement Project Plan Rev 1 Page 14 of 27 3.1.4.1     ALS
: 1.       Hardware Design Specification (HDS) 3.1.4.2     Invensys/Triconex
: 1.       Software Design Specification (SDS)
: 2.       Hardware Design Specification (HDS)
Software Test Plan(s) (STP) are generated by the PPS Subsystem Vendors to evaluate system performance based on the SRS and the software/system design documentation. A three-step approach is used for testing, modified asapplicable for the specific platform and the subvendor procedures:
: 1. Component (Software Unit) Testing,
: 2. Integration Testing, and
: 3. Acceptance Testing (FAT).
Software Test Plans will conform to the requirements of IEEE Std. 829 [1.7.19] per the guidance of NRC Reg Guide 1.170 [1.7.6] and IEEE Std. 1008 [1.7.24] per the guidance of Reg Guide 1.171 [1.7.7].
Software Test Plans will be reviewed by PG&E. Separate Factory Acceptance Test Plans will be developed by the PPS Subsystem Vendors and will be reviewed by PG&E.
3.1.5         Implementation Phase During this phase the executable code is produced and tested, based on the above phase outputs.
Depending upon the target system, source code may be developed by the design team/programmers, or automatic code generators may produce the executable code. In either case, the functions described in the SRS and design documents are developed in the coding environment to programming standards. The correct implementation of the SRS and design documents is validated by testing or other means with the software development and simulation tools, and by testing on a test/development system. The RTM will generally have no entries for this phase. Software unit testing is performed by the design team during this phase.
The implementation phase is concurrent with the design phase in Figure 5-1.
3.1.6         Integration Phase Integration Testing is a separate software Lifecycle activity per NUREG-0800 BTP 7-14 and can be mapped to IEEE 1012 [1.7.21] per the guidance of NRC Reg Guide 1.168 [1.7.4] as a continuation of the Implementation Phase. The Software is integrated with the hardware and integration testing is performed in accordance with the test procedures per IEEE Std. 829. Integration test execution results are analyzed to determine if the system implements the requirements and design and that the software components function correctly together.
The integration phase is concurrent with the design phase in Figure 5-1.
The RTM is updated to demonstrate traceability from concept documentation through the requirements, design, implementation and integration phases.
3.1.7         Test Phase System tests, are performed in accordance with the FAT test procedures. Tests are analyzed to determine ifthe 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.
Tests pass or fail based on the acceptance criteria stipulated in the SRS and on specific requirements found in the RTM.
PPS Replacement Project Plan Rev 1Page 15 of 27A FAT will be performed by each subvendor at the respective facility.
 
The FAT will validate all functions that are required for licensing the PPS in accordance with the requirements documents and the PPSsubcontracts.
PPS Replacement Project Plan Rev 1 Page 15 of 27 A FAT will be performed by each subvendor at the respective facility. The FAT will validate all functions that are required for licensing the PPS in accordance with the requirements documents and the PPS subcontracts.
The ALS transmits RCS temperature information to the Tricon via 4-20 mA analog signals.
The ALS transmits RCS temperature information to the Tricon via 4-20 mA analog signals. This interface may be validated in the individual subvendor facilities using standalone test equipment.
This interface may be validated in the individual subvendor facilities using standalone test equipment.
Each subvendor will prepare a final Verification & Validation Report describing the results of all V&V activities the subvendor performed on the product.
Each subvendor will prepare a final Verification  
3.1.8         Installation and Checkout Phase The Installation and Checkout phase follows successful completion of the FAT and acceptance of documentation as required by the subvendor contract. The subsystems will be shipped to the PG&E Project Integration & Test (PIT) facility, where they will be staged and assembled with power supplies, cables and other hardware that may not have been included in the FAT. The temperature interface connections will be made between the ALS and Tricon subsystems. Communications hardware required to support the HMI and other interfacing systems (i.e., the Main Annunciator System and Plant Data Network) will be connected.
& Validation Report describing the results of all V&Vactivities the subvendor performed on the product.3.1.8 Installation and Checkout PhaseThe Installation and Checkout phase follows successful completion of the FAT and acceptance ofdocumentation as required by the subvendor contract.
Performance of the site acceptance test (SAT) is conducted at the PIT. The SAT will validate the completed system in an environment very similar to the installed configuration. The SAT will not validate functions required for licensing that were not tested previously by the subvendors.
The subsystems will be shipped to the PG&EProject Integration  
A summary System Verification &Validation Report (SyVVR) will be prepared to describe the results of all V&V activities performed on the system.
& Test (PIT) facility, where they will be staged and assembled with power supplies, cables and other hardware that may not have been included in the FAT. The temperature interface connections will be made between the ALS and Tricon subsystems.
The above activities are illustrated in Figure 5-1.
Communications hardware requiredto support the HMI and other interfacing systems (i.e., the Main Annunciator System and Plant DataNetwork) will be connected.
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 CF3.1D9 [1.7.17] is conducted. PG&E will be responsible for acceptance of the results of the SAT and DVT. The Installation and Checkout V&V activity addresses software installation and software acceptance support.
Performance of the site acceptance test (SAT) is conducted at the PIT. The SAT will validate thecompleted system in an environment very similar to the installed configuration.
3.1.9         Operation Phase 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.
The SAT will not validatefunctions required for licensing that were not tested previously by the subvendors.
3.1.10       Maintenance Phase The maintenance process is initiated 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),
A summary System Verification  
migration, or retirement of the software during the operation process.
& Validation Report (SyVVR) will be prepared to describe the results ofall V&V activities performed on the system.The above activities are illustrated in Figure 5-1.The developed system is then installed in the final target environment/location and performance of thedesign verification testing (DVT) per PG&E plant procedure CF3.1D9 [1.7.17]
Modifications of the software are treated as development processes and are verified and validated in accordance with development process described in the previous sections. Software integrity level assignments are assessed during the maintenance process. The software integrity level assignments may be revised as appropriate to reflect the requirements of the maintenance process.
is conducted.
K
PG&E will beresponsible for acceptance of the results of the SAT and DVT. The Installation and Checkout V&Vactivity addresses software installation and software acceptance support.3.1.9 Operation PhaseThe operation process covers the operation of the developed and installed system by PG&E in the targetenvironment/location, and operational support by the system supplier.
 
PG&E will have primaryresponsibility for V&V activities during this phase (unless contracted out to a software supplier with anapproved and audited 1OCFR50 Appendix B quality program).
PPS Replacement Project Plan Rev 1 Page 16 of 27 3.2.         Licensing Process The licensing process is a significant resource commitment and will be done in a phased approach. The phased approach will follow the guidance provided in NRC ISG-06 "Licensing Process" [1.7.14]. Figure 3-1 provides an overview and flow of the phased licensing approach.
The objectives of Operation V&V tasksare to evaluate new constraints in the system, assess proposed changes and their impact on thesoftware, and evaluate operating procedures for correctness and usability.
The PPS Replacement project is targeting two PPS subsystem vendors who are expected to have an approved Generic Topical Report (TR) for their given platform. The intent for the PPS project is for the vendor TR to completely envelope the scope of the PPS project. Significant portions of the NRR review of the LAR are expected to be confirmatory. Therefore, the PPS Replacement project application will be a Tier 1 submittal to NRR.
3.1.10 Maintenance PhaseThe maintenance process is initiated when the software product undergoes modifications to code andassociated documentation caused by a problem or a need for improvement or adaptation.
Figure 3-1       Digital I&C Licensing Process Flow Chart lqnmrý Phase 0 Phase 1                                                                 -MAgabbb-
TheMaintenance V&V activity addresses modifications (e.g., enhancements, additions, and deletions),
                                                                      -41111111111111*w I-qqwpr-
migration, or retirement of the software during the operation process.Modifications of the software are treated as development processes and are verified and validated inaccordance with development process described in the previous sections.
                            '44r ---
Software integrity levelassignments are assessed during the maintenance process.
                                                                            +
The software integrity level assignments may be revised as appropriate to reflect the requirements of the maintenance process.K PPS Replacement Project Plan Rev 1Page 16 of 273.2. Licensing ProcessThe licensing process is a significant resource commitment and will be done in a phased approach.
Phase 2                           I
Thephased approach will follow the guidance provided in NRC ISG-06 "Licensing Process"  
                                              ..Jý                 I 41p,                   10,14 P
[1.7.14].
Phase 3
Figure3-1 provides an overview and flow of the phased licensing approach.
 
The PPS Replacement project is targeting two PPS subsystem vendors who are expected to have anapproved Generic Topical Report (TR) for their given platform.
PPS Replacement Project Plan Rev 1 Page 17 of 27 3.2.1         Phase 0 Pre-Application The purpose of Phase 0 is to convey critical, fundamental, system information to the NRC prior to submitting an LAR. The NRC staff is encouraging the use of Phase 0 to get the key issues on the table for discussion prior to the licensee engaging on the "full blown" license process. These key issues should include, at a minimum, diversity and defense in depth concepts, security concepts, and communications concepts. Diversity and defense in depth concepts shall include the fact that the ALS incorporates built-in diversity and therefore will not rely on diverse manual actions or diverse actuation systems.
The intent for the PPS project is for thevendor TR to completely envelope the scope of the PPS project.
It is also very important to discuss the timing of Phase 2 items for submittal. Phase 0 should be used to "negotiate" the timing of critical back-end submittals, such as V&V reports, including FAT results.
Significant portions of the NRR review ofthe LAR are expected to be confirmatory.
Phase 0 will include the discussion of the use of the Generic Topical Report for the PPS Subsystems, which will provide the fundamental basis for the overall licensing position of the PPS Replacement.
Therefore, the PPS Replacement project application will be aTier 1 submittal to NRR.Figure 3-1 Digital I&C Licensing Process Flow ChartPhase 0lqnmrýPhase 1-MAgabbb-
-41111111111111*w I -qqwpr-'44r ---IPhase 2..Jý41p,I10,14+PPhase 3 PPS Replacement Project Plan Rev 1Page 17 of 273.2.1 Phase 0 Pre-Application The purpose of Phase 0 is to convey critical, fundamental, system information to the NRC prior tosubmitting an LAR. The NRC staff is encouraging the use of Phase 0 to get the key issues on the tablefor discussion prior to the licensee engaging on the "full blown" license process.
These key issues shouldinclude, at a minimum, diversity and defense in depth concepts, security  
: concepts, and communications concepts.
Diversity and defense in depth concepts shall include the fact that the ALS incorporates built-indiversity and therefore will not rely on diverse manual actions or diverse actuation systems.It is also very important to discuss the timing of Phase 2 items for submittal.
Phase 0 should be used to"negotiate" the timing of critical back-end submittals, such as V&V reports, including FAT results.Phase 0 will include the discussion of the use of the Generic Topical Report for the PPS Subsystems, which will provide the fundamental basis for the overall licensing position of the PPS Replacement.
In summary, Phase 0 is important to get all the keys issues on the table for an open two-way discussion with the staff and too also "negotiate" key dates for submittals in Phase 2, where the timing of available document for submittal is crucial to the overall project schedule.
In summary, Phase 0 is important to get all the keys issues on the table for an open two-way discussion with the staff and too also "negotiate" key dates for submittals in Phase 2, where the timing of available document for submittal is crucial to the overall project schedule.
3.2.2 Phase 1 Initial Application This phase begins the formal review process.
3.2.2         Phase 1 Initial Application This phase begins the formal review process. The License Amendment Request (LAR) will be submitted to initiate this phase. The LAR will include the following key items:
The License Amendment Request (LAR) will be submitted to initiate this phase. The LAR will include the following key items:1. Application-System Architecture
: 1.       Application-System Architecture
: 2. Hardware Development Process3. Software Architecture
: 2.         Hardware Development Process
: 4. Software Development Process5. System Qualifications
: 3.       Software Architecture
: 6. Diversity  
: 4.       Software Development Process
& Defense-in-Depth
: 5.       System Qualifications
: 7. Communications
: 6.         Diversity & Defense-in-Depth
: 8. System, Hardware,  
: 7.       Communications
: Software, and Methodology Modifications
: 8.       System, Hardware, Software, and Methodology Modifications
: 9. IEEE 603 Compliance
: 9.       IEEE 603 Compliance
: 10. IEEE 7-4.3.2 Compliance
: 10.       IEEE 7-4.3.2 Compliance
: 11. Technical Specifications
: 11.     Technical Specifications
: 12. Secure Environment During Phase 1, the NRC staff will draft the SE and issue Requests for Additional Information (RAI) forthe information that is necessary to complete the review of the docketed material.
: 12.       Secure Environment During Phase 1, the NRC staff will draft the SE and issue Requests for Additional Information (RAI) for the information that is necessary to complete the review of the docketed material.
Phase 1 documentation to be submitted to the NRC in addition to the LAR is provided in Figure 3-2.3.2.3 Phase 2 Continued Review and AuditFollowing responses to any Phase 1 RAIs but at least 12 months prior to the requested approval date,additional details of the design/development will be submitted.
Phase 1 documentation to be submitted to the NRC in addition to the LAR is provided in Figure 3-2.
ISG-06 [1.7.14]
3.2.3         Phase 2 Continued Review and Audit Following responses to any Phase 1 RAIs but at least 12 months prior to the requested approval date, additional details of the design/development will be submitted. ISG-06 [1.7.14] identifies what is to be submitted on the docket and what information is to be made available for audit.
identifies what is to besubmitted on the docket and what information is to be made available for audit.Some documentation may not be available 12 months prior to the anticipated issuance of the LAR.Although the plans and other available information should be submitted at early as possible, it isacceptable to submit the results as mutually agreed in the Phase 0 meetings, but prior to the SE.Phase 2 documentation to be submitted and available for audit is provided in Figure 3-3.
Some documentation may not be available 12 months prior to the anticipated issuance of the LAR.
PPS Replacement Project Plan Rev 1Page 18 of 273.2.4 Phase 3 Implementation and Inspection Following the issuance of the SER for the PPS replacement, the installation and testing activities will takeplace. At this point the NRC regional staff may review the start-up testing as an inspection function.
Although the plans and other available information should be submitted at early as possible, it is acceptable to submit the results as mutually agreed in the Phase 0 meetings, but prior to the SE.
Phase 2 documentation to be submitted and available for audit is provided in Figure 3-3.
 
PPS Replacement Project Plan Rev 1 Page 18 of 27 3.2.4       Phase 3 Implementation and Inspection Following the issuance of the SER for the PPS replacement, the installation and testing activities will take place. At this point the NRC regional staff may review the start-up testing as an inspection function.
Phase 3 documentation to be available for inspection after approval is provided in Figure 3-4.
Phase 3 documentation to be available for inspection after approval is provided in Figure 3-4.
PPS Replacement Project Plan Rev 1Page 19 of 27Figure 3-2 Phase 1 Documentation to be submitted to the NRCPhase I -Submitted with LAR PPS Replacement Project Plan Rev 1Page 20 of 27Figure 3-3 Phase 2 Documentation to be submitted to the NRC and available for audit by the NRCPhase 2 -Submitted 12 months prior to requested approvalPhase 2 -Available for Audit 12 months prior to requested approval PPS Replacement Project Plan Rev 1Page 21 of 27Figure 3-4 Phase 3 Documentation to be available for inspection after approvalI Phase 3 -Available for Inspection after Approval PPS Replacement Project Plan Rev 1Page 22 of 274 Schedule, Cost, and Communications This section outlines the methods for providing schedule management, cost management, projectreporting, and communications for the PPS Project.4.1. Schedule Management An initial project schedule is developed for the project to fit within a calendar controlled by events such asplant outages, pre-outages schedule milestone dates, regularity commitments, and resource availability.
 
The original schedule is the baseline to which performance will be monitored.
PPS Replacement Project Plan Rev 1 Page 19 of 27 Figure 3-2     Phase 1 Documentation to be submitted to the NRC Phase I - Submitted with LAR
The Project Manager willmaintain the schedule and shall approve all schedule changes for the PPS project.
 
The initial projecttimeline is provided in Figure 1-2. The PG&E portion of the PPS LAR Phase 1 submittals is shown inTable 4-1. The vendor portions of the PPS LAR Phase 1 Submittals shall be incorporated once theformal schedules are received from each of the vendors.4.2. Cost Management The Project Manager will perform cost management for the PPS Project per AD7.1D8 [1.7.18].
PPS Replacement Project Plan Rev 1 Page 20 of 27 Figure 3-3     Phase 2 Documentation to be submitted to the NRC and available for audit by the NRC Phase 2 - Submitted 12 months prior to requested approval Phase 2 - Available for Audit 12 months prior to requested approval
CostManagement includes the analysis of the variance between actual costs and the original plan as well asthe expectation of the Project Manager to review the production work progress and relate the actual costof performing that work to the planned cost of performing that work.4.3. Cost Estimating and Project ScopingThe Project Manager will perform cost estimating and project scoping to establish the baseline costs forthe project per AD7.1D8.
 
PPS Replacement Project Plan Rev 1Page 23 of 27 PPS Replacement Project Plan Rev 1Page 24 of 27 PPS Replacement Project Plan Rev 1Page 25 of 274.4. Project Reporting and Communications The project team will meet via face-to face or via teleconference on a bi-weekly basis to provide status ofthe individual components of the project, discuss action items, and interact as needed.The Project Manager is responsible for reporting technical,  
PPS Replacement Project Plan Rev 1 Page 21 of 27 Figure 3-4     Phase 3 Documentation to be available for inspection after approval I  Phase 3 - Available for Inspection after Approval
: schedule, and cost status per the following table.Table 4-2 Project Reporting and Communications Information Vehicle Audience When Who OwnsConversation
 
& Sponsor Weekly Project ManagerProject Status Status ReportUpdate Status Reports Project Mgr's Weekly Project ManagerManagerRevisions made to Financial Analyst Monthly Project ManagerCost Projection monthly reportsUpdates Revisions made to Site Monthly Project Managermonthly reports VP/Director/Sponsor Risk Matrix Senior Management With Project Project ManagerAuthorization Project Risks Paperwork Risk Matrix Site VP/Director Monthly Project ManagerRisk Matrix Sponsor Bi-Weekly Project ManagerProduction Team Progress PM and Scheduler Weekly Project TeamSchedule Updates MeetingsNew/Revised Risks Team Meetings PM and Project Weekly PM and ProjectTeam Members Team MembersPlans to Resolve Conversation Managers/Site As Needed SponsorConflicting Priorities VP/Director Affecting Project PPS Replacement Project Plan Rev 1Page 26 of 275Project Initiation and PlanningDuring the Project Initiation and Planning activities the lifecycle documentation needed to support theLAR was identified, and is shown in Figure 5-1. Additional detail regarding each of the illustrated documents will be provided in the System Quality Assurance Plan (SyQAP) and System Verification andValidation Plan (SyWP)Figure 5-1 PPS Replacement Project Lifecycle Document FlowGlossaryCDDFRSIRSSADHADSyRSSyDSSRSHRSHDSSDDSDSFATSATDVTRTMSWRSyWNRConcept (PG&E)Conceptual Design DocumentFunctional Requirements Specification Interface Requirements Specification Software Architecture Requirements Hardware Architecture Requirements System Requirements Specification System Design Specification Software Requirements Specification Hardware Requirements Specification Hardware Design Specification Software Design Description Software Design Specification Factory Acceptance TestSite Acceptance TestDesign Verification TestingRequirements Traceability MatrixSoftware Verification  
PPS Replacement Project Plan Rev 1 Page 22 of 27 4            Schedule, Cost, and Communications This section outlines the methods for providing schedule management, cost management, project reporting, and communications for the PPS Project.
& Validation ReportSystem Verification  
4.1.         Schedule Management An initial project schedule is developed for the project to fit within a calendar controlled by events such as plant outages, pre-outages schedule milestone dates, regularity commitments, and resource availability.
& Validation ReportIFConcept (PG&E)Requirements Definition ALSIAnIFRequirements Definition DesignIFDesignTestTTestInstallation/Checkout PPS Replacement Project Plan Rev 1Page 27 of 276 Supporting PlansThe following process plans are PG&E deliverables to support the PPS Project.
The original schedule is the baseline to which performance will be monitored. The Project Manager will maintain the schedule and shall approve all schedule changes for the PPS project. The initial project timeline is provided in Figure 1-2. The PG&E portion of the PPS LAR Phase 1 submittals is shown in Table 4-1. The vendor portions of the PPS LAR Phase 1 Submittals shall be incorporated once the formal schedules are received from each of the vendors.
The plans are to bedeveloped and implemented per the guidance of BTP 7-14 [1.7.3] and the ISG 06 [1.7.14]
4.2.         Cost Management The Project Manager will perform cost management for the PPS Project per AD7.1D8 [1.7.18]. Cost Management includes the analysis of the variance between actual costs and the original plan as well as the expectation of the Project Manager to review the production work progress and relate the actual cost of performing that work to the planned cost of performing that work.
sections listedin Table 4-1.6.1. System Quality Assurance Plan (SyQAP)The purpose of the System Quality Assurance Plan (SyQAP) [1.7.28]
4.3.         Cost Estimating and Project Scoping The Project Manager will perform cost estimating and project scoping to establish the baseline costs for the project per AD7.1D8.
is to establish the goals, processes, and responsibilities required to implement effective system level quality management for the PPS systemat DCPP, ensure any required system functions perform correctly, and that the required system functions conform to established technical requirements, conventions, rules, and standards Requirements for theSyQAP are provided in CF2.1D9 [1.7.16].
 
6.2. System Verification and Validation Plan (SyWP)The purpose of the System Verification and Validation Plan (SyWP) [1.7.29]
PPS Replacement Project Plan Rev 1 Page 23 of 27
is to define the procedures and requirements for a comprehensive evaluation that assures the replacement controls equipment meetthe requirements for Class 1 E qualified nuclear power plant safety systems.
 
The SyWP provides a planfor producing, evaluating, controlling and maintaining the design for the Class 1E PPS through eachphase of the particular project.6.3. Training PlanThe purpose of the Training Plan [1.7.30]
PPS Replacement Project Plan Rev 1 Page 24 of 27
is to ensure DCPP personnel have the appropriate level oftraining to operate and maintain the PPS Class 1 E equipment.
 
The training plan identifies specific trainingrequired by the vendor(s) for the details of the system installation, operation, and maintenance.
PPS Replacement Project Plan Rev 1 Page 25 of 27 4.4.         Project Reporting and Communications The project team will meet via face-to face or via teleconference on a bi-weekly basis to provide status of the individual components of the project, discuss action items, and interact as needed.
6.4. Installation PlanThe purpose of the Installation Plan [1.7.31) is to provide a general description of the installation process.The installation plan identifies the environment for which the PPS will be installed, as well as a high leveldescription of the roles and responsibilities for the installation activities.
The Project Manager is responsible for reporting technical, schedule, and cost status per the following table.
6.5. Operation PlanThe purpose of the Operation Plan [1.7.32]
Table 4-2       Project Reporting and Communications Information           Vehicle               Audience               When                   Who Owns Conversation &         Sponsor               Weekly                 Project Manager Project Status         Status Report Update                Status Reports         Project Mgr's         Weekly                 Project Manager Manager Revisions made to     Financial Analyst       Monthly               Project Manager Cost Projection       monthly reports Updates                Revisions made to     Site                   Monthly               Project Manager monthly reports       VP/Director/Sponsor Risk Matrix           Senior Management     With Project           Project Manager Authorization Project Risks                                                         Paperwork Risk Matrix           Site VP/Director       Monthly               Project Manager Risk Matrix           Sponsor                 Bi-Weekly             Project Manager Production            Team Progress         PM and Scheduler       Weekly                 Project Team Schedule Updates       Meetings New/Revised Risks     Team Meetings         PM and Project         Weekly               PM and Project Team Members                                 Team Members Plans to Resolve       Conversation           Managers/Site         As Needed             Sponsor Conflicting Priorities                       VP/Director Affecting Project
is to identify the roles and responsibilities of operating theClass 1 E PPS equipment, identify the security requirements for the equipment, and address operational procedures required for the operation of the equipment.
 
6.6. Maintenance PlanThe purpose of the Maintenance Plan [1.7.33]
PPS Replacement Project Plan Rev 1 Page 26 of 27 5                Project Initiation and Planning During the Project Initiation and Planning activities the lifecycle documentation needed to support the LAR was identified, and is shown in Figure 5-1. Additional detail regarding each of the illustrated documents will be provided in the System Quality Assurance Plan (SyQAP) and System Verification and Validation Plan (SyWP)
is to discuss the roles and responsibilities, key projectdeliverables critical to maintenance, implementation characteristics, maintenance procedures, maintenance challenges, and spare components stocked in the warehouse for the Class 1 E PPSequipment at DCPP.6.7. Summary Software Test PlanThe purpose of the Summary Software Test Plan is to provide a summary of the Software Test Plan(s)developed by each of the 1 OCFR50 Appendix B suppliers.
Figure 5-1           PPS Replacement Project Lifecycle Document Flow Glossary                                                                                          Concept (PG&E)
The purpose of the individual Software TestPlan(s) is to prescribe the scope, approach, resources, and schedule of the testing activities; to identifythe items being 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 Software Test Plan(s) should coverall testing done to the software, including unit testing, integration  
CDD      Conceptual Design Document FRS      Functional Requirements Specification IRS      Interface Requirements Specification                       IF SAD      Software Architecture Requirements HAD      Hardware Architecture Requirements SyRS    System Requirements Specification SyDS    System Design Specification SRS      Software Requirements Specification HRS      Hardware Requirements Specification HDS      Hardware Design Specification                                                             Concept (PG&E)
: testing, factory acceptance  
SDD      Software Design Description SDS      Software Design Specification                                                           Requirements Definition ALS                                IAn FAT      Factory Acceptance Test SAT      Site Acceptance Test DVT      Design Verification Testing RTM      Requirements Traceability Matrix SWR      Software Verification &Validation Report                                      IF SyWNR    System Verification & Validation Report Requirements Definition Design IF Design Test T
: testing, siteacceptance
Test Installation/Checkout
: testing, and installation testing.}}
 
PPS Replacement Project Plan Rev 1 Page 27 of 27 6            Supporting Plans The following process plans are PG&E deliverables to support the PPS Project. The plans are to be developed and implemented per the guidance of BTP 7-14 [1.7.3] and the ISG 06 [1.7.14] sections listed in Table 4-1.
6.1.         System Quality Assurance Plan (SyQAP)
The purpose of the System Quality Assurance Plan (SyQAP) [1.7.28] is to establish the goals, processes, and responsibilities required to implement effective system level quality management for the PPS system at DCPP, ensure any required system functions perform correctly, and that the required system functions conform to established technical requirements, conventions, rules, and standards Requirements for the SyQAP are provided in CF2.1D9 [1.7.16].
6.2.         System Verification and Validation Plan (SyWP)
The purpose of the System Verification and Validation Plan (SyWP) [1.7.29] is to define the procedures and requirements for a comprehensive evaluation that assures the replacement controls equipment meet the requirements for Class 1E qualified nuclear power plant safety systems. The SyWP provides a plan for producing, evaluating, controlling and maintaining the design for the Class 1E PPS through each phase of the particular project.
6.3.           TrainingPlan The purpose of the Training Plan [1.7.30] is to ensure DCPP personnel have the appropriate level of training to operate and maintain the PPS Class 1E equipment. The training plan identifies specific training required by the vendor(s) for the details of the system installation, operation, and maintenance.
6.4.           Installation Plan The purpose of the Installation Plan [1.7.31) is to provide a general description of the installation process.
The installation plan identifies the environment for which the PPS will be installed, as well as a high level description of the roles and responsibilities for the installation activities.
6.5.         Operation Plan The purpose of the Operation Plan [1.7.32] is to identify the roles and responsibilities of operating the Class 1E PPS equipment, identify the security requirements for the equipment, and address operational procedures required for the operation of the equipment.
6.6.         Maintenance Plan The purpose of the Maintenance Plan [1.7.33] is to discuss the roles and responsibilities, key project deliverables critical to maintenance, implementation characteristics, maintenance procedures, maintenance challenges, and spare components stocked in the warehouse for the Class 1E PPS equipment at DCPP.
6.7.         Summary Software Test Plan The purpose of the Summary Software Test Plan is to provide a summary of the Software Test Plan(s) developed by each of the 10CFR50 Appendix B suppliers. The purpose of the individual Software Test Plan(s) is to prescribe the scope, approach, resources, and schedule of the testing activities; to identify the items being 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 Software Test Plan(s) should cover all testing done to the software, including unit testing, integration testing, factory acceptance testing, site acceptance testing, and installation testing.}}

Latest revision as of 02:25, 11 November 2019

Attachment 3: Diablo Canyon Power Plant Process Protection System (PPS) Replacement Concept, Requirements, and Licensing Phase 1 Project Plant, Revision 1 (LAR Reference 57)
ML15099A062
Person / Time
Site: Diablo Canyon  Pacific Gas & Electric icon.png
Issue date: 10/26/2011
From:
Altran Solutions Corp, Pacific Gas & Electric Co
To:
Office of Nuclear Reactor Regulation
Shared Package
ML113070457 List:
References
DCL-11-104
Download: ML15099A062 (29)


Text

Enclosure Attachment 3 PG&E Letter DCL-1 1-104 Diablo Canyon Power Plant Process Protection System (PPS) Replacement Concept, Requirements, and Licensing Phase 1 Project Plan, Revision I (LAR Reference 57)

Pacific Gas & Electric Company I

I~I iablo Canyon Power Plant Unitslt & 2 Process Protection System (PPS) Replacement Concept, Requirements, and Licensing Phase I Project Plan Rev I Prepared Sio Date c r t _

PMtI Lest Name Reviewed Sig, \k~r 7~

Print Lvst Name Mor ID f?

C"rd SVLOfg~1L2A Date ý :1 Print Lest5 Name__________ UsertID Approval Sig, ____________ Date _ _ _

Print Last Name UseriD cLTRcj

PPS Replacement Project Plan Rev 1 Page 1 of 27 Revision History Revision Affected Reason for Revision Number Item 0 All Initial Issue 1 Updated per current scope 1.2 Revised to reflect Tier 2 Tricon Submittal Figure 1-2 Updated dates 1.7 Updated items 28, 29 Table 4-1 Updated to reflect current vendor document scope General Minor editorial changes as marked.

PPS Replacement Project Plan Rev 1 Page 2 of 27 Table of Contents SProject Overview ............................................................................................................................................. 4 1 .1 . P u rp os e ...................................................................................................................................................... 4 1.2 . S c o p e ............................... .......................................................................................................................... 4 1.3 . O bjec tiv e .................................................................................................................................................... 4 1.4. Project Organization .................................................................................................................................. 4 1.5 . Ba c kg ro u n d ................................................................................................................................................ 5 1.6. Project Deliverables ................................................................................................................................... 7 1.7 . R e fe re n c e s ................................................................................................................................................. 8 2 Project Organization ..................................................................................................................................... 10 2.1. Roles and Responsibilities ....................................................................................................................... 10 3 Developm ent and Licensing Process .................................................................................................... 13 3.1. Development Process .............................................................................................................................. 13 3.2. Licensing Process .................................................................................................................................... 16 4 Schedule, Cost, and Com m unications .................................................................................................. 22 4.1. Schedule Management ........................................................................................................................... 22 4.2. Cost Management .................................................................................................................................... 22 4.3. Cost Estimating and Project Scoping .................................................................................................. 22 4.4. Project Reporting and Com m unications ............................................................................................. 25 5 Project Initiation and Planning .................................................................................................................... 26 6 Supporting Plans .......................................................................................................................................... 27 6.1. System Quality Assurance Plan (SyQAP) ........................................................................................... 27 6.2. System Verification and Validation Plan (SyW P) ............................................................................. 27 6 .3 . T ra in ing P la n ............................................................................................................................................ 27 6 .4 . Insta lla tio n P la n ........................................................................................................................................ 27 6 .5 . O p e ra tio n P la n ......................................................................................................................................... 27 6.6. Maintenance Plan .................................................................................................................................... 27 6.7. Sum mary Software Test Plan .................................................................................................................. 27

PPS Replacement Project Plan Rev 1 Page 3 of 27 FIGURES Figure 1-1 Existing DCPP Process Protection System ............................................................................... 5 Figure 1-2 Proposed PPS LA R Tim eline .................................................................................................... 6 Figure 2-1 PPS Replacement Project Organization .................................................................................... 12 Figure 3-1 Digital I&C Licensing Process Flow Chart ............................................................................... 16 Figure 3-2 Phase 1 Documentation to be submitted to the NRC ............................................................... 19 Figure 3-3 Phase 2 Documentation to be submitted to the NRC and available for audit by the NRC ........... 20 Figure 3-4 Phase 3 Documentation to be available for inspection after approval .................................... 21 Figure 5-1 PPS Replacement Project Lifecycle Document Flow ............................................................... 26 TABLES Table 4-1 PPS Replacement PG&E Document Submittals ..................................................................... 23 Table 4-2 Project Reporting and Communications ................................................................................... 25

PPS Replacement Project Plan Rev 1 Page 4 of 27 1 Project Overview The Project Plan is the "starting point" for a particular project. The Project Plan identifies specifics about the project, such as the purpose of the project, project scope, project objectives, high-level project schedule, and the project team. This Project Plan provides the high level details of the Process Protection System (PPS) Project. The PPS Project Plan is treated as a living document, and will be updated periodically throughout the project lifecycle or if there is a significant change in the overall project.

1.1. Purpose The purpose of the PPS Replacement Project is to replace the existing digital Eagle 21 Process Protection System (PPS) with a software-based Triconex TRICON platform for the primary PPS functions and incorporate a logic-based Westinghouse/CS Innovations, LLC Advanced Logic System (ALS) for functions which require built-in-diversity. The PPS Replacement Project is schedule to be implemented in the plant during 1R18 and 2R18, in February, 2014 and September, 2014, respectively.

1.2. Scope The new PPS will be supplied by two subvendors: (1) Invensys/Triconex (2) Westinghouse/CS Innovations, LLC. The scope of work includes the design, fabrication, testing, and delivery of a new system. The new PPS will be installed in existing cabinets. It is PG&E's expectation that Invensys will complete generic licensing of the Triconex platform, however the Safety Evaluation Report (SER) is not expected to be issued until after the October 2011 LAR submittal. A Tier 2 review process per ISG-06

[1.7.14] Section C.1 for the Triconex portion of the PPS Replacement License Amendment submittal will be employed. Westinghouse/CSI has submitted Phase 1 documentation for generic licensing of the ALS platform. The TR for the ALS likely will not be completed in time to support the October 2011 LAR submittal, thus requiring Tier 3 documentation for the ALS subsystem.

1.3. Objective The primary objective of the Eagle 21 Replacement Project is to install a new PPS that addresses obsolescence issues on a long term basis, provides Diversity and Defense-in-Depth to automatically mitigate all FSAR Chapter 15 accidents or events concurrent with a CCF where the Chapter 15 analysis currently credits automatic mitigation, and to improve plant availability and safety.

1.4. Project Organization The Eagle 21 PPS Replacement Project is to be accomplished by three primary entities. The entities are:

1) PG&E/DCPP; 2) Invensys/Triconex; and 3) Westinghouse/CS Innovations, LLC. A diagram of the project organization is provided in the Section 3 of this document.

1.4.1 Functionality and Design Basis The Diablo Canyon Power Plant (DCPP) digital Eagle 21 Process Protection System (PPS) is being replaced to address obsolescence and other issues. The PPS comprises Protection Racks 1-16, which in turn comprise the four redundant PPS rack sets shown in Figure 1-1. The PPS monitors plant parameters, compares them against setpoints and provides signals to the Solid State Protection System (SSPS) if setpoints are exceeded. The SSPS evaluates the signals through coincident logic and performs Reactor Trip System (RTS) and Engineered Safety Features Actuation System (ESFAS) command functions to mitigate an event that may be in progress.

PPS Replacement Project Plan Rev 1 Page 5 of 27 Figure 1-1 Existing DCPP Process Protection System Eaagle 21 Prot Set III (R11 R13Eagle 211 --

(RB.RIO Eagle21 To DiverseAMSAC Isolated Outputs to: PR14Se116)

Digital Feedwater Control System Auniliary Feedwater Rod Speed & Direction Control Pressurizer Pressure Pressurizer Level Steam Dump Control Condenser Hotwell Level Control Post-Accident Monitoring Plant Computer Hardvwred Indicators &Recorders SSPS SSPS SSPS SSPS NB NB NB A/B I II III IV 1.4.2 Technical Specification Changes Technical Specification changes will be necessary if Safety Analysis Limits or Nominal Setpoints change as a result of the setpoint study to be performed for this project.

1.5. Background The Diablo Canyon Power Plant (DCPP) digital Eagle 21 Process Protection System (PPS) is being replaced to address obsolescence issues. The PPS monitors plant parameters, compares them against setpoints and provides signals to the Solid State Protection System (SSPS) if setpoints are exceeded.

The SSPS evaluates the signals through coincident logic and performs Reactor Trip System (RTS) and Engineered Safety Features Actuation System (ESFAS) command functions to mitigate an event that may be in progress.

The Eagle 21 PPS comprises Protection Racks 1-16. There are four separate PPS rack sets. The original Westinghouse/Hagen 7100 analog protection sets were replaced in 1 R6 and 2R6 with the existing Westinghouse Eagle 21 PPS.

The proposed PPS will address current regulations and guidance regarding Diversity and Defense-in-Depth. It will implement automatic protective functions in a Class IE software-based Triconex TRICON

[1.7.10] processor to mitigate events for which the Eagle 21 SER [1.7.1] credited available diverse automatic mitigating functions. The proposed PPS will implement automatic protective functions in a logic-based Class IE Westinghouse/CS Innovations, LLC Advanced Logic System (ALS) [1.7.11] with built-in diversity that address software CCF per NRC ISG-02 [1.7.13] Position 1 to automatically mitigate events that otherwise would require manual protective action if the events were to occur with a concurrent software Common Cause Failure (CCF) to the PPS.

A License Amendment Request (LAR) is being prepared and will be submitted to the NRC for replacement of the Eagle 21 PPS.

Figure 1-2 illustrates the proposed PPS LAR timeline.

PPS Replacement Project Plan Rev 1 Page 6 of 27 Figure 1-2 Proposed PPS LAR Timeline DCPP PPS Replacement Project Timeline 4120/2012 5/20/2012 Vendor Phase 2 Items Complete Phase 2 Items 12//2012 2/25 Provided to PG&E Provided to NRC . 5/2013 2/14/2014 vendoor FAS Design Pa ckage Issued 5/20/2013 PPS Installation Complete 4/30/2014 2/1/2011 3/1/2011 4/1/2011 5/1/2011 6/1/2011 7/1/2011 8/1/2011 9/1/2011 10/1/2011 11/1/2011 12/1/2011 11,/2011 LAR Submittal I2/3V2011

PPS Replacement Project Plan Rev 1 Page 7 of 27 1.6. Project Deliverables The project deliverables consists of items from each of the entities participating in the project.

Deliverables include the physical equipment as well as the documentation associated with the design, testing, installation, maintenance, and operation of the equipment.

1.6.1 Deliverables from PPS Subsystem Vendors The PPS subsystem vendors are responsible for the delivery of the physical equipment to be installed in existing PPS cabinets. The physical equipment shall meet the requirements of the PPS Functional Requirements Specification, Interface Requirements Specification, and Purchase Specification(s).

The physical deliverables list for the project will be updated during subsequent project phases as the details of the equipment becomes available.

The documentation deliverables of the project include:

1. ISG-06 Vendor Required Documentation, see Section 4 Development and Licensing Process for ISG-06 Document Submittal Matrix for Phase 1 and Phase 2 document submittals
2. Outline Drawings
3. Functional Logic Diagram
4. Assembly Drawings
5. Wiring Diagrams
6. Equipment Qualification Plan (if not included in vendor Topical Report)
7. Equipment Qualification Report (if not included in vendor Topical Report)
8. Equipment Travelers
9. Certificate of Conformance
10. Instruction and Operating Manuals
11. Resolution of any qualification anomalies 1.6.2 Deliverables from PG&E The documentation deliverables of the project include:
1. ISG-06 Utility Required Documentation; see Section 4 Development and Licensing Process for ISG-06 Document Submittal Matrix for Phase 1 and Phase 2 document submittals
2. Conceptual Design Document (CDD) [1.7.25]
3. Functional Requirements Specification (FRS) [1.7.261
4. Interface Requirements Specification (IRS, including I/O List) [1.7.27]
5. Design Change Package (by Engineer of Choice (EOC))
6. Project Level V&V Documents
a. System Verification and Validation Plan (SyWP)
b. Requirements Traceability Matrix (RTM)
c. Site Acceptance Test (SAT) Procedure and Test Execution
d. System V&V Report (SyWR)

PPS Replacement Project Plan Rev 1 Page 8 of 27 1.7. References

1. NRC, "Safety Evaluation Report Eagle 21 Reactor Protection System Modification With Bypass Manifold Elimination, PG&E, Diablo Canyon Power Plant," October 7, 1993
2. NRC, NUREG-0800, Standard Review Plan, Branch Technical Position (BTP) 7-19, "Guidance for Evaluation of Defense-in-Depth and Diversity in Digital Computer-Based Instrumentation and Control Systems," March 2007
3. NRC, NUREG-0800, Standard Review Plan, BTP 7-14, Guidance on Software Reviews for Digital Computer-Based Instrumentation and Control Systems
4. NRC, Regulatory Guide 1.168, Rev 1, Verification, Validation, Reviews, And Audits For Digital Computer Software Used in Safety Systems of Nuclear Power Plants
5. NRC, Regulatory Guide 1.169, Configuration Management Plans for Digital Computer Software Used in Safety Systems of Nuclear Power Plants
6. NRC, Regulatory Guide 1.170, Software Test Documentation for Digital Computer Software Used in Safety Systems of Nuclear Power Plants
7. NRC, Regulatory Guide 1.171, Software Unit Testing for Digital Computer Software Used in Safety Systems of Nuclear Power Plants
8. NRC, Regulatory Guide 1.172, Software Requirements Specifications for Digital Computer Software Used in Safety Systems of Nuclear Power Plants
9. NRC, Regulatory Guide 1.173, Developing Software Life Cycle Processes for Digital Computer Software Used in Safety Systems of Nuclear Power Plants
10. Letter No. NRC-V1 0-09-01, J. Polcyn (Invensys) to NRC, "Nuclear Safety-Related Qualification of the Tricon TMR Programmable Logic Controller (PLC) - Update to Qualification Summary Report Submittal" and "Application for withholding Proprietary Information from Public Disclosure,"

September 9, 2009

11. Westinghouse/CS Innovations, LLC, Advanced Logic System Topical Report, July 2010
12. PG&E Topical Report: Process Protection System Replacement Diversity & Defense-in-Depth Assessment
13. Digital Instrumentation and Controls DI&C-ISG-02 Task Working Group #2: Diversity and Defense-in-Depth Issues Interim Staff Guidance Revision 2, June 5, 2009
14. Digital Instrumentation and Controls DI&C-ISG-06 Task Working Group #6: Licensing Process, Rev 1 (ADAMS MLl101401030)
15. IDAP CF2.1D2, Software Configuration Management for Computers & Software Used for Plant Operations and Operations Support
16. IDAP CF2.1D9, Software Quality Assurance Plan Software Development
17. IDAP CF3.1D9, [Design Change (Package) Development
18. IDAP AD7.1D8, Project Management
19. IEEE 829-1983, Standard for Software Test Documentation
20. IEEE 830, IEEE Recommended Practice for Software Requirements Specifications
21. IEEE 1012-1998, Standard for Software Verification and Validation
22. IEEE 1016, IEEE Recommended Practice for Software Design Descriptions
23. IEEE 1074-1995, Standard for Developing software Lifecycle Processes
24. IEEE 1008-1987, Standard for Software Unit Testing
25. Process Protection System (PPS) Replacement Conceptual Design Document (CDD)
26. Process Protection System (PPS) Replacement Functional Requirements Specification (FRS)
27. Process Protection System (PPS) Replacement Interface Requirements Specification (IRS)
28. PPS System Quality Assurance Plan (SyQAP)
29. PPS System Verification and Validation Plan (SyWP)

PPS Replacement Project Plan Rev 1 Page 9 of 27

30. PPS Training Plan
31. PPS Installation Plan
32. PPS Operations Plan
33. PPS Maintenance Plan

PPS Replacement Project Plan Rev 1 Page 10 of 27 2 Project Organization The PPS Project is to be accomplished by three primary entities; 1) PG&E/DCPP, 2) Invensys/Triconex; and 3) Westinghouse/CS Innovations, LLC. Figure 2-1 illustrates the project organization.

2.1. Roles and Responsibilities The following sections outline the roles and responsibilities of the PPS project organization members.

2.1.1 PG&E Project Manager The PG&E 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, vendor quality management/oversight, quality field implementation, and successful post-installation testing. The Project Manager is also responsible to recommend re-evaluation of the project if he detects changes in the project that alter the decision to proceed.

The PG&E Project Manager shares the responsibility for meeting the software quality goals and objectives of the project and for the implementation of software quality management throughout the project.

The project manager shall:

1. Release the system level V&V plan and reports
2. Establish cost controls
3. Enter the plan activities into the master project schedule.
4. Review progress of the SQAP and V&V program
5. Evaluate any reported deviations or anomalies for their potential risk and impacts to project cost and schedule.
6. Approve corrective actions, scope changes and resource allocations.
7. Coordinate the disposition of discrepancy reports generated in the course of verification and validation.

2.1.2 Engineer of Choice (EoC) Design Change Package Team The Engineer of Choice (EoC) Design Change Package 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 Engineer of Choice (EoC) Design Change Package Team is also responsible for establishing quality goals and objectives for their organization consistent with those of the project.

2.1.3 PG&E Project Engineering Team The PG&E Project Engineering team conducts and ensures quality-related inter-group coordination for software and hardware design engineering activities. Project engineering is responsible for identifying the processes and corresponding standards and procedures to guide project performance. The project engineering team is further responsible for ensuring work activities are performed in compliance with these standards and procedures.

2.1.4 10CFR50 Appendix B Supplier(s)

The 10CFR50 Appendix B supplier(s) are responsible for the design, development, integration, and final delivery of the respective Class 1E equipment to PG&E. As a 10CFR50, Appendix B suppliers, Invensys/Triconex and Westinghouse/CS Innovations, LLC provide their respective platforms as Class 1E equipment for the PPS Replacement Project.

PPS Replacement Project Plan Rev 1 Page 11 of 27 The 10CFR50 Appendix B supplier personnel play the major role in implementing the SQA program. It is their responsibility to build quality into the products they develop or support. It is also their responsibility to propose process improvements based on their application of the methodology.

The 10CFR50 Appendix B supplier personnel are also participants in the inspection and review processes applied to intermediate products resulting from project work activities. Serving as inspectors or reviewers, they examine the products of their peers to ensure technical soundness and overall quality before proceeding to the next phase of development.

Another significant responsibility is the performance of independent testing. All systems developed or modified under the Program must be adequately tested before they are delivered or made available for use. Personnel familiar with the products being validated, but not the developer of the product, typically perform testing. The tests ensure new and revised systems meet allocated requirements as well as establish their overall quality and delivery readiness. Software Unit Testing may be performed by the SW developer.

PPS Replacement Project Plan Rev 1 Page 12 of 27 Figure 2-1 PPS Replacement Project Organization Diablo Canyon PPS Upgrade Project Manager Scott Patterson I

PPS Replacement Project Plan Rev 1 Page 13 of 27 3 Development and Licensing Process 3.1. Development Process The PPS project development process is structured to follow a traditional waterfall life cycle that includes a top down requirement and specification development, design implementation, and a bottom up V&V effort at each level of integration. The program development allows prototyping activities. In-process quality assurance efforts are executed integral to the development stages where prototyping is employed.

Software lifecycle processes are to be developed in accordance with IEEE 1074 [1.7.23] per the guidance of NRC Reg Guide 1.173 [1.7.9].

A secure development and operational environment is to be provided and maintained per ISG 06 [1.7.14]

Section D.12.

A high level description of each phase of the development process is provided below. For details of the V&V activities for each phase, refer to the PPS Project Software Quality Assurance Plan.

3.1.1 Project Initiation and Planning Phase 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. A verified and accepted contract(s) is a product of this phase.

3.1.2 Conceptual Design Phase The Conceptual design phase defines the scope of the V&V effort. The initial System V&V Plan, SyQAP, and FRS are products of this phase. As shown in Figure 5-1, the Interface Requirements Specification (IRS, which includes the Input/Output List) is also prepared in this phase.

3.1.3 Requirements Phase In this phase, a Software Requirements Specification (SRS) or its equivalent will be prepared by the PPS Subsystem Vendors for each applicable software product using the guidance of IEEE Std. 830 [1.7.20]

per the guidance of NRC Reg Guide 1.172 [1.7.8]. The Requirements Phase Documentation will be developed based on the FRS and IRS as inputs. The outputs of this task are:

3.1.3.1 ALS

1. System Requirements Specification (SyRS)
2. System Design Specification (SyDS)
3. Software Requirements Specification (Equivalent to Core Logic Board Specification) 3.1.3.2 Invensys/Triconex
1. Software Architecture Description (SAD)
2. Hardware Architecture Description (HAD)
3. Software Requirements Specification (SRS) 3.1.4 Design & Implementation Phase In this phase of a typical software development project, the developer prepares the Software Design Description (SDD) for the software product using the guidance of IEEE Std. 1016 [1.7.22]. The SDD is developed based on the Requirements Phase outputs for the project-specific hardware architecture. A typical SDD consists of two parts: the software and hardware architectural description and the Software Detailed Design.

For this project, the design documentation prepared by the subvendors is illustrated in Figure 5-1.

PPS Replacement Project Plan Rev 1 Page 14 of 27 3.1.4.1 ALS

1. Hardware Design Specification (HDS) 3.1.4.2 Invensys/Triconex
1. Software Design Specification (SDS)
2. Hardware Design Specification (HDS)

Software Test Plan(s) (STP) are generated by the PPS Subsystem Vendors to evaluate system performance based on the SRS and the software/system design documentation. A three-step approach is used for testing, modified asapplicable for the specific platform and the subvendor procedures:

1. Component (Software Unit) Testing,
2. Integration Testing, and
3. Acceptance Testing (FAT).

Software Test Plans will conform to the requirements of IEEE Std. 829 [1.7.19] per the guidance of NRC Reg Guide 1.170 [1.7.6] and IEEE Std. 1008 [1.7.24] per the guidance of Reg Guide 1.171 [1.7.7].

Software Test Plans will be reviewed by PG&E. Separate Factory Acceptance Test Plans will be developed by the PPS Subsystem Vendors and will be reviewed by PG&E.

3.1.5 Implementation Phase During this phase the executable code is produced and tested, based on the above phase outputs.

Depending upon the target system, source code may be developed by the design team/programmers, or automatic code generators may produce the executable code. In either case, the functions described in the SRS and design documents are developed in the coding environment to programming standards. The correct implementation of the SRS and design documents is validated by testing or other means with the software development and simulation tools, and by testing on a test/development system. The RTM will generally have no entries for this phase. Software unit testing is performed by the design team during this phase.

The implementation phase is concurrent with the design phase in Figure 5-1.

3.1.6 Integration Phase Integration Testing is a separate software Lifecycle activity per NUREG-0800 BTP 7-14 and can be mapped to IEEE 1012 [1.7.21] per the guidance of NRC Reg Guide 1.168 [1.7.4] as a continuation of the Implementation Phase. The Software is integrated with the hardware and integration testing is performed in accordance with the test procedures per IEEE Std. 829. Integration test execution results are analyzed to determine if the system implements the requirements and design and that the software components function correctly together.

The integration phase is concurrent with the design phase in Figure 5-1.

The RTM is updated to demonstrate traceability from concept documentation through the requirements, design, implementation and integration phases.

3.1.7 Test Phase System tests, are performed in accordance with the FAT test procedures. Tests are analyzed to determine ifthe 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.

PPS Replacement Project Plan Rev 1 Page 15 of 27 A FAT will be performed by each subvendor at the respective facility. The FAT will validate all functions that are required for licensing the PPS in accordance with the requirements documents and the PPS subcontracts.

The ALS transmits RCS temperature information to the Tricon via 4-20 mA analog signals. This interface may be validated in the individual subvendor facilities using standalone test equipment.

Each subvendor will prepare a final Verification & Validation Report describing the results of all V&V activities the subvendor performed on the product.

3.1.8 Installation and Checkout Phase The Installation and Checkout phase follows successful completion of the FAT and acceptance of documentation as required by the subvendor contract. The subsystems will be shipped to the PG&E Project Integration & Test (PIT) facility, where they will be staged and assembled with power supplies, cables and other hardware that may not have been included in the FAT. The temperature interface connections will be made between the ALS and Tricon subsystems. Communications hardware required to support the HMI and other interfacing systems (i.e., the Main Annunciator System and Plant Data Network) will be connected.

Performance of the site acceptance test (SAT) is conducted at the PIT. The SAT will validate the completed system in an environment very similar to the installed configuration. The SAT will not validate functions required for licensing that were not tested previously by the subvendors.

A summary System Verification &Validation Report (SyVVR) will be prepared to describe the results of all V&V activities performed on the system.

The above activities are illustrated in Figure 5-1.

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 CF3.1D9 [1.7.17] is conducted. PG&E will be responsible for acceptance of the results of the SAT and DVT. The Installation and Checkout V&V activity addresses software installation and software acceptance support.

3.1.9 Operation Phase 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.

3.1.10 Maintenance Phase The maintenance process is initiated 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.

Modifications of the software are treated as development processes and are verified and validated in accordance with development process described in the previous sections. Software integrity level assignments are assessed during the maintenance process. The software integrity level assignments may be revised as appropriate to reflect the requirements of the maintenance process.

K

PPS Replacement Project Plan Rev 1 Page 16 of 27 3.2. Licensing Process The licensing process is a significant resource commitment and will be done in a phased approach. The phased approach will follow the guidance provided in NRC ISG-06 "Licensing Process" [1.7.14]. Figure 3-1 provides an overview and flow of the phased licensing approach.

The PPS Replacement project is targeting two PPS subsystem vendors who are expected to have an approved Generic Topical Report (TR) for their given platform. The intent for the PPS project is for the vendor TR to completely envelope the scope of the PPS project. Significant portions of the NRR review of the LAR are expected to be confirmatory. Therefore, the PPS Replacement project application will be a Tier 1 submittal to NRR.

Figure 3-1 Digital I&C Licensing Process Flow Chart lqnmrý Phase 0 Phase 1 -MAgabbb-

-41111111111111*w I-qqwpr-

'44r ---

+

Phase 2 I

..Jý I 41p, 10,14 P

Phase 3

PPS Replacement Project Plan Rev 1 Page 17 of 27 3.2.1 Phase 0 Pre-Application The purpose of Phase 0 is to convey critical, fundamental, system information to the NRC prior to submitting an LAR. The NRC staff is encouraging the use of Phase 0 to get the key issues on the table for discussion prior to the licensee engaging on the "full blown" license process. These key issues should include, at a minimum, diversity and defense in depth concepts, security concepts, and communications concepts. Diversity and defense in depth concepts shall include the fact that the ALS incorporates built-in diversity and therefore will not rely on diverse manual actions or diverse actuation systems.

It is also very important to discuss the timing of Phase 2 items for submittal. Phase 0 should be used to "negotiate" the timing of critical back-end submittals, such as V&V reports, including FAT results.

Phase 0 will include the discussion of the use of the Generic Topical Report for the PPS Subsystems, which will provide the fundamental basis for the overall licensing position of the PPS Replacement.

In summary, Phase 0 is important to get all the keys issues on the table for an open two-way discussion with the staff and too also "negotiate" key dates for submittals in Phase 2, where the timing of available document for submittal is crucial to the overall project schedule.

3.2.2 Phase 1 Initial Application This phase begins the formal review process. The License Amendment Request (LAR) will be submitted to initiate this phase. The LAR will include the following key items:

1. Application-System Architecture
2. Hardware Development Process
3. Software Architecture
4. Software Development Process
5. System Qualifications
6. Diversity & Defense-in-Depth
7. Communications
8. System, Hardware, Software, and Methodology Modifications
9. IEEE 603 Compliance
10. IEEE 7-4.3.2 Compliance
11. Technical Specifications
12. Secure Environment During Phase 1, the NRC staff will draft the SE and issue Requests for Additional Information (RAI) for the information that is necessary to complete the review of the docketed material.

Phase 1 documentation to be submitted to the NRC in addition to the LAR is provided in Figure 3-2.

3.2.3 Phase 2 Continued Review and Audit Following responses to any Phase 1 RAIs but at least 12 months prior to the requested approval date, additional details of the design/development will be submitted. ISG-06 [1.7.14] identifies what is to be submitted on the docket and what information is to be made available for audit.

Some documentation may not be available 12 months prior to the anticipated issuance of the LAR.

Although the plans and other available information should be submitted at early as possible, it is acceptable to submit the results as mutually agreed in the Phase 0 meetings, but prior to the SE.

Phase 2 documentation to be submitted and available for audit is provided in Figure 3-3.

PPS Replacement Project Plan Rev 1 Page 18 of 27 3.2.4 Phase 3 Implementation and Inspection Following the issuance of the SER for the PPS replacement, the installation and testing activities will take place. At this point the NRC regional staff may review the start-up testing as an inspection function.

Phase 3 documentation to be available for inspection after approval is provided in Figure 3-4.

PPS Replacement Project Plan Rev 1 Page 19 of 27 Figure 3-2 Phase 1 Documentation to be submitted to the NRC Phase I - Submitted with LAR

PPS Replacement Project Plan Rev 1 Page 20 of 27 Figure 3-3 Phase 2 Documentation to be submitted to the NRC and available for audit by the NRC Phase 2 - Submitted 12 months prior to requested approval Phase 2 - Available for Audit 12 months prior to requested approval

PPS Replacement Project Plan Rev 1 Page 21 of 27 Figure 3-4 Phase 3 Documentation to be available for inspection after approval I Phase 3 - Available for Inspection after Approval

PPS Replacement Project Plan Rev 1 Page 22 of 27 4 Schedule, Cost, and Communications This section outlines the methods for providing schedule management, cost management, project reporting, and communications for the PPS Project.

4.1. Schedule Management An initial project schedule is developed for the project to fit within a calendar controlled by events such as plant outages, pre-outages schedule milestone dates, regularity commitments, and resource availability.

The original schedule is the baseline to which performance will be monitored. The Project Manager will maintain the schedule and shall approve all schedule changes for the PPS project. The initial project timeline is provided in Figure 1-2. The PG&E portion of the PPS LAR Phase 1 submittals is shown in Table 4-1. The vendor portions of the PPS LAR Phase 1 Submittals shall be incorporated once the formal schedules are received from each of the vendors.

4.2. Cost Management The Project Manager will perform cost management for the PPS Project per AD7.1D8 [1.7.18]. Cost Management includes the analysis of the variance between actual costs and the original plan as well as the expectation of the Project Manager to review the production work progress and relate the actual cost of performing that work to the planned cost of performing that work.

4.3. Cost Estimating and Project Scoping The Project Manager will perform cost estimating and project scoping to establish the baseline costs for the project per AD7.1D8.

PPS Replacement Project Plan Rev 1 Page 23 of 27

PPS Replacement Project Plan Rev 1 Page 24 of 27

PPS Replacement Project Plan Rev 1 Page 25 of 27 4.4. Project Reporting and Communications The project team will meet via face-to face or via teleconference on a bi-weekly basis to provide status of the individual components of the project, discuss action items, and interact as needed.

The Project Manager is responsible for reporting technical, schedule, and cost status per the following table.

Table 4-2 Project Reporting and Communications Information Vehicle Audience When Who Owns Conversation & Sponsor Weekly Project Manager Project Status Status Report Update Status Reports Project Mgr's Weekly Project Manager Manager Revisions made to Financial Analyst Monthly Project Manager Cost Projection monthly reports Updates Revisions made to Site Monthly Project Manager monthly reports VP/Director/Sponsor Risk Matrix Senior Management With Project Project Manager Authorization Project Risks Paperwork Risk Matrix Site VP/Director Monthly Project Manager Risk Matrix Sponsor Bi-Weekly Project Manager Production Team Progress PM and Scheduler Weekly Project Team Schedule Updates Meetings New/Revised Risks Team Meetings PM and Project Weekly PM and Project Team Members Team Members Plans to Resolve Conversation Managers/Site As Needed Sponsor Conflicting Priorities VP/Director Affecting Project

PPS Replacement Project Plan Rev 1 Page 26 of 27 5 Project Initiation and Planning During the Project Initiation and Planning activities the lifecycle documentation needed to support the LAR was identified, and is shown in Figure 5-1. Additional detail regarding each of the illustrated documents will be provided in the System Quality Assurance Plan (SyQAP) and System Verification and Validation Plan (SyWP)

Figure 5-1 PPS Replacement Project Lifecycle Document Flow Glossary Concept (PG&E)

CDD Conceptual Design Document FRS Functional Requirements Specification IRS Interface Requirements Specification IF SAD Software Architecture Requirements HAD Hardware Architecture Requirements SyRS System Requirements Specification SyDS System Design Specification SRS Software Requirements Specification HRS Hardware Requirements Specification HDS Hardware Design Specification Concept (PG&E)

SDD Software Design Description SDS Software Design Specification Requirements Definition ALS IAn FAT Factory Acceptance Test SAT Site Acceptance Test DVT Design Verification Testing RTM Requirements Traceability Matrix SWR Software Verification &Validation Report IF SyWNR System Verification & Validation Report Requirements Definition Design IF Design Test T

Test Installation/Checkout

PPS Replacement Project Plan Rev 1 Page 27 of 27 6 Supporting Plans The following process plans are PG&E deliverables to support the PPS Project. The plans are to be developed and implemented per the guidance of BTP 7-14 [1.7.3] and the ISG 06 [1.7.14] sections listed in Table 4-1.

6.1. System Quality Assurance Plan (SyQAP)

The purpose of the System Quality Assurance Plan (SyQAP) [1.7.28] is to establish the goals, processes, and responsibilities required to implement effective system level quality management for the PPS system at DCPP, ensure any required system functions perform correctly, and that the required system functions conform to established technical requirements, conventions, rules, and standards Requirements for the SyQAP are provided in CF2.1D9 [1.7.16].

6.2. System Verification and Validation Plan (SyWP)

The purpose of the System Verification and Validation Plan (SyWP) [1.7.29] is to define the procedures and requirements for a comprehensive evaluation that assures the replacement controls equipment meet the requirements for Class 1E qualified nuclear power plant safety systems. The SyWP provides a plan for producing, evaluating, controlling and maintaining the design for the Class 1E PPS through each phase of the particular project.

6.3. TrainingPlan The purpose of the Training Plan [1.7.30] is to ensure DCPP personnel have the appropriate level of training to operate and maintain the PPS Class 1E equipment. The training plan identifies specific training required by the vendor(s) for the details of the system installation, operation, and maintenance.

6.4. Installation Plan The purpose of the Installation Plan [1.7.31) is to provide a general description of the installation process.

The installation plan identifies the environment for which the PPS will be installed, as well as a high level description of the roles and responsibilities for the installation activities.

6.5. Operation Plan The purpose of the Operation Plan [1.7.32] is to identify the roles and responsibilities of operating the Class 1E PPS equipment, identify the security requirements for the equipment, and address operational procedures required for the operation of the equipment.

6.6. Maintenance Plan The purpose of the Maintenance Plan [1.7.33] is to discuss the roles and responsibilities, key project deliverables critical to maintenance, implementation characteristics, maintenance procedures, maintenance challenges, and spare components stocked in the warehouse for the Class 1E PPS equipment at DCPP.

6.7. Summary Software Test Plan The purpose of the Summary Software Test Plan is to provide a summary of the Software Test Plan(s) developed by each of the 10CFR50 Appendix B suppliers. The purpose of the individual Software Test Plan(s) is to prescribe the scope, approach, resources, and schedule of the testing activities; to identify the items being 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 Software Test Plan(s) should cover all testing done to the software, including unit testing, integration testing, factory acceptance testing, site acceptance testing, and installation testing.