ML15099A062: Difference between revisions
StriderTol (talk | contribs) (Created page by program invented by StriderTol) |
StriderTol (talk | contribs) (Created page by program invented by StriderTol) |
||
| 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 | |||
: 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 | |||
................................................ | |||
Revision as of 02:04, 1 July 2018
Text
Enclosure Attachment 3PG&E Letter DCL-1 1-104Diablo Canyon Power Plant Process Protection System (PPS) Replacement
- 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
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.
The entities are:1) PG&E/DCPP;
- 2) Invensys/Triconex; and 3) Westinghouse/CS Innovations, LLC. A diagram of theproject organization is provided in the Section 3 of this document.
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.
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.
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
& 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.
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.
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]
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.
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.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.
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 thedetails 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 forISG-06 Document Submittal Matrix for Phase 1 and Phase 2 document submittals
- 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
- 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
- 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
- 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 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,"
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,
- 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,"
September 9, 200911. Westinghouse/CS Innovations, LLC, Advanced Logic System Topical Report, July 201012. 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 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)
- 15. IDAP CF2.1D2, Software Configuration Management for Computers
& Software Used for PlantOperations and Operations Support16. 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 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)
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;
- 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 ManagerThe PG&E Project Manager has the ultimate responsibility, authority, and accountability for all aspects ofthe project.
Responsibilities include quality of design, timely integration with site schedules, vendor qualitymanagement/oversight, quality field implementation, and successful post-installation testing.
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.
- 6. Approve corrective
- actions, scope changes and resource allocations.
- 7. Coordinate the disposition of discrepancy reports generated in the course of verification andvalidation.
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,
- 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.
Project engineering is responsible for identifying theprocesses and corresponding standards and procedures to guide project performance.
The projectengineering team is further responsible for ensuring work activities are performed in compliance withthese standards and procedures.
2.1.4 10CFR50 Appendix B Supplier(s)
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.
PPS Replacement Project Plan Rev 1Page 11 of 27The 10CFR50 Appendix B supplier personnel play the major role in implementing the SQA program.
It istheir 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 1 OCFR50 Appendix B supplier personnel are also participants in the inspection and reviewprocesses 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 qualitybefore proceeding to the next phase of development.
Another significant responsibility is the performance of independent testing.
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.
The tests ensure new and revised systems meet allocated requirements as well asestablish their overall quality and delivery readiness.
Software Unit Testing may be performed by the SWdeveloper.
PPS Replacement Project Plan Rev 1Page 12 of 27Figure 2-1 PPS Replacement Project Organization Diablo CanyonPPS UpgradeProject ManagerScott Patterson I
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 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 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.
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
- 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].
The SDD isdeveloped based on the Requirements Phase outputs for the project-specific hardware architecture.
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.
PPS Replacement Project Plan Rev 1Page 14 of 273.1.4.1 ALS1. 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 systemperformance based on the SRS and the software/system design documentation.
A three-step approach isused for testing, modified asapplicable for the specific platform and the subvendor procedures:
- 1. Component (Software Unit) Testing,2. Integration
- Testing, and3. Acceptance Testing (FAT).Software Test Plans will conform to the requirements of IEEE Std. 829 [1.7.19]
per the guidance of NRCReg 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 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.
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]
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.
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.
Tests are analyzed to determine if the system implements the requirements and design and that the software components functioncorrectly 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 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.
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&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.
The subsystems will be shipped to the PG&EProject 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 requiredto support the HMI and other interfacing systems (i.e., the Main Annunciator System and Plant DataNetwork) will be connected.
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.
The SAT will not validatefunctions 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 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]
is conducted.
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).
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.
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.
TheMaintenance 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 inaccordance with development process described in the previous sections.
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.
Thephased approach will follow the guidance provided in NRC ISG-06 "Licensing Process"
[1.7.14].
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.
The intent for the PPS project is for thevendor TR to completely envelope the scope of the PPS project.
Significant portions of the NRR review ofthe LAR are expected to be confirmatory.
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.
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 Process3. Software Architecture
- 4. Software Development Process5. 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) forthe 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.
ISG-06 [1.7.14]
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.
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.
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.
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].
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,
- 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
& Validation ReportSystem Verification
& 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 plans are to bedeveloped and implemented per the guidance of BTP 7-14 [1.7.3] and the ISG 06 [1.7.14]
sections listedin 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 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]
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]
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.
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.
6.5. Operation PlanThe purpose of the Operation Plan [1.7.32]
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]
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.
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
- testing, factory acceptance
- testing, siteacceptance
- testing, and installation testing.