ML15099A062: Difference between revisions
StriderTol (talk | contribs) (Created page by program invented by StriderTol) |
StriderTol (talk | contribs) (Created page by program invented by StriderTol) |
||
(7 intermediate revisions by the same user not shown) | |||
Line 15: | Line 15: | ||
| page count = 29 | | page count = 29 | ||
}} | }} | ||
=Text= | |||
{{#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) | |||
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.}} |
Latest revision as of 02:25, 11 November 2019
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.