ML15099A063: Difference between revisions

From kanterella
Jump to navigation Jump to search
(Created page by program invented by StriderTol)
(Created page by program invented by StriderTol)
Line 17: Line 17:


=Text=
=Text=
{{#Wiki_filter:}}
{{#Wiki_filter:EnclosureAttachment 4PG&E Letter DCL-1 1-104Diablo Canyon Power Plant Process Protection System (PPS) ReplacementSystem Quality Assurance Plan (SyQAP), Revision 0(LAR Reference 52)
;IPacific Gas ectric CompanyDiablo Canyon ower PantProcess Protection System (PPS) ReplacementSystem Quality Assurance Plan (SyQAP)Nuclear Safety RelatedRev 0C11M IQDIIPrepare" Print Last NamIReviewed SioPrint Last NameCoord SigtOrg.Print Last NameApproval Si9Print Last Narne1~4Of~~4~DateUser IDDateUsor IDDateUsaleUser IDjoil, lei__JE~ £~ L UT I L~
PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 1 of 42REVISION HISTORYRevision Affected Reason for RevisionNumber Pages0 All Initial IssueI. I.
PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 2 of 42Table of Contents1. PURPO SE .......................................................................................................................................... 41 .1 O V E R V IE W ......................................................................................................................................... 41.2 APPLICABILITY .................................................................................................................................. 41 .3 S C O P E ............................................................................................................................................. 52. REFERENCE DO C UM ENTS ..................................................................................................... 52.1 DEVELOPMENTAL REFERENCES AND STANDARDS ........................................................................... 53. M A NAG EM ENT ................................................................................................................................. 93.1 O RGANIZATION ................................................................................................................................. 93.2 1 OCFR50 APPENDIX B SUPPLIER TASKS ..................................................................................... 103.3 PG &E TASKS ................................................................................................................................. 153.4 PG &E ROLES & RESPONSIBILITIES ................................................................................................ 183.5 1 OCFR50 APPENDIX B SUPPLIER ROLES & RESPONSIBILITIES ...................................................... 194. DO CUM ENTATIO N ......................................................................................................................... 214.1 OVERVIEW OF PG &E DOCUMENTS ............................................................................................... 214.2 OVERVIEW OF 1 OCFR50 APPENDIX B SUPPLIER DOCUMENTS ...................................................... 224.3 1 OCFR50 APPENDIX B SUPPLIER SOFTWARE TEST DOCUMENTATION .............................................. 254.4 OTHER DOCUMENTATION ............................................................................................................. 265. STANDARDS, PRACTICES, CONVENTIONS, AND METRICS ................................................ 265.1 DOCUMENTATION STANDARDS ......................................................................................................... 275.2 LOGIC STRUCTURE (DESIGN) STANDARDS ..................................................................................... 275.3 TESTING STANDARDS AND PRACTICES .......................................................................................... 275.4 SELECTED SQA PRODUCT AND PROCESS M ETRICS ..................................................................... 276. SO FTW A RE REVIEW S A ND A UDITS ....................................................................................... 276.1 SOFTW ARE REQUIREMENTS REVIEW (SRR) ................................................................................. 286.2 ARCHITECTURAL DESIGN REVIEW (ADR) ..................................................................................... 286.3 DETAILED DESIGN REVIEW (DDR) .............................................................................................. 286.4 SOFTWARE VERIFICATION AND VALIDATION PLAN REVIEW (SW PR) ............................................ 286.5 FUNCTIONAL AUDIT ......................................................................................................................... 286.6 PHYSICAL AUDIT ............................................................................................................................. 286.7 IN-PROCESS AUDITS ........................................................................................................................ 286.8 M ANAGERIAL REVIEW S .................................................................................................................... 296.9 SOFTWARE CONFIGURATION MANAGEMENT PLAN REVIEW (SCMPR) ............................................... 296.10 POST IMPLEMENTATION REVIEW ............................................................................................... 296.11 USER DOCUMENTATION REVIEW .............................................................................................. 296.12 SOFTW ARE SAFETY REVIEW S ................................................................................................... 296.13 CONFIGURATION M ANAGEMENT REVIEW S .................................................................................. 297. TEST .......... ....................................................................................................................................... 298. PROBLEM REPORTING AND CORRECTIVE ACTION ........................................................... 298.1 ANOMALY RESOLUTION AND REPORTING ....................................................................................... 308.2 TASK ITERATION POLICY ................................................................................................................... 309. TO O LS, TECHNIQ UES, A ND M ETHO DO LO G IES .................................................................... 30 PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 3 of 4210. M EDIA C O NTRO L ........................................................................................................................... 3110.1 M EDIA C ONTROL ......................................................................................................................... 3111. SU PPLIER C O NTRO L ..................................................................................................................... 3112. RECORDS COLLECTION, MAINTENANCE AND RETENTION .............................................. 3113. TRA IN ING .... ..................................................................................................................................... 3214. RIS K M A NA G EM ENT ....................................................................................................................... 3215. G LO SSA RY ..................................................................................................................................... 3315.1 DEFINITIONS ............................................................................................................................... 3316. SYQAP CHANGE PROCEDURE AND HISTORY ...................................................................... 42 PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 4 of 421. Purpose1.1 OverviewThe purpose of this System Quality Assurance Plan (SyQAP) is to establish the goals, processes, andresponsibilities required to implement effective software quality management for the Process ProtectionSet (PPS) system software at Diablo Canyon Power Plant (DCPP), ensure any required softwarefunctions perform correctly, and that the required software functions conform to established technicalrequirements, conventions, rules, and standards. To achieve this goal, software development willproceed in a traceable, planned, and orderly manner. Throughout this document, the term software isused when referring to firmware and logic developed from software based developments systems. Theobjective of this plan is to:* Define the software quality assurance activities to be performed during the lifecycle of the software;" Describe the responsibilities and authorities for accomplishing the planned software quality assuranceactivities;* Identify the required coordination of software quality assurance activities with other activities of theproject;* Identify the tools and the physical and human resources required for the execution of the plan;* Ensure the software solutions necessary to implement the functional requirements, technicalconstraints, system development, configuration control, security, and software maintenance areaccomplished in accordance with the approved methodology, supporting standards, and procedures;* Ensure the products and services produced conform to applicable project requirements;* Detect and eliminate design errors early in the software lifecycle; and* Enhance the quality and reliability of PPS application software.1.2 ApplicabilityPG&E procedure IDAP AD7.1D8 [2.1.3.1], Project Management which includes the Project ManagementPolicies and Procedures, is the primary document describing the management processes and strategiesfor managing projects at Diablo Canyon Power Plant (DCPP). The Project Management Manual directsthe overall project planning function and defines the organization, resources, and methodology formeeting project requirements. IDAP AD7.1D8 establishes measures for assuring that organizationsperforming activities affecting quality perform their responsibilities in a manner which results in safenuclear power production. This SyQAP utilizes PG&E procedure IDAP CF2.1D9 [2.1.3.3], SoftwareQuality Assurance Plan Development for software to be used in the PPS. The IDAP AD7.1D8 proceduredescribes the DCPP Quality program, policies, and procedures. The management approach, policies,and procedures described in this plan are derived from policies, procedures, codes and standards, andregulations applicable to the nuclear industry.This plan applies specifically to the PPS at the Diablo Canyon Power Plant site. This software is NuclearSafety-Related software requiring safety-related quality controls to meet SIL 4, as defined in IEEE 1012-1998 [2.1.2.24].The plan covers the development lifecycle for SIL4 application software: requirements definition, detaileddesign, implementation, test, installation and checkout, operation, and maintenance. This software will beprovided by two third-party suppliers who each have an approved 1 OCFR50 Appendix B QualityAssurance program [2.1.1.1]. This plan will umbrella the supplier's system development process. At aminimum the supplier's scope of supply will extend to the end of Factory Acceptance Testing (FAT). In PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 5 of 42cases beyond the scope of the supplier, further work on the application software will be normallyperformed under the PG&E system quality assurance program.This procedure is valid as of the date of final issue indicated on the title page. This procedure should bereviewed prior to making any changes to the PPS software.1.3 ScopeThis SyQAP applies to all software development and software maintenance activities, including thosetasks performed by contractors and subcontractors. This SyQAP also applies to all applicable softwarelifecycle phases for the PPS not already covered under the suppliers' 1OCFR50 Appendix B programs.This plan is intended for use by all project personnel to understand and perform the quality activitiesapplicable to their responsibilities. Software Quality Assurance requires the project to identify qualityactivities forits currently planned work phase and related releases.Software Quality Assurance for the project is planned along with other project tasks and initiatives.Implementation of and compliance with this SyQAP is the shared responsibility of all project personnel.Both project management and technical staff are thus integrated with and committed to the success ofoverall Software Quality Assurance.The degree of rigor and effort is defined by the Software Integrity Level (SIL) and SoftwareCategorization. Software SIL is defined in IEEE Std. 1012-1998 [2.1.2.24]. Nuclear Regulatory Guide1.168, Verification, Validation, Reviews, and Audits for Digital Computer Software Used in SafetySystems of Nuclear Power Plants [2.1.1.8], provides additional guidance that indicates that nuclearsafety-related software should be assigned a SIL 4 rating.In general, the SyQAP will place special emphasis on the software portion of the project. In addition theSyQAP will monitor, audit, and report on activities related to software safety to ensure no new safetyhazards are introduced by the development process and on those activities related to configurationmanagement. It will also provide traceability to verify that contractual requirements such as hardwarerequirements, the provision of specific system features, and other deliverables not directly related to theapplication software have been met. After successful completion of the Software Quality Assuranceactivities in this plan, the application software will meet the SIL-rating requirements for the software.2. Reference Documents2.1 Developmental References and Standards2.1.1 U.S. Regulatory Guidance2.1.1.1 Title 10 CFR, Part 50, Appendix B, "Quality Assurance Criteria for Nuclear Power, Plants andFuel Reprocessing Plants"2.1.1.2 NUREG-0800 BTP 7-14, Branch Technical Position: Guidance on Software Reviews forDigital Computer-Based Instrumentation and Control Systems, Revision 5, March 2007.2.1.1.3 NUREG/CR-6101, Software Reliability and Safety in Nuclear Reactor Protection Systems,November 1993.2.1.1.4 NUREG/CR-6430, Software Safety Hazards Analysis, February 1996.2.1.1.5 Regulatory Guide 1.118, Periodic Testing of Electric Power and Protection Systems, Revision3, April 19952.1.1.6 Regulatory Guide 1.152, Criteria for Use of Computers in Safety Systems of Nuclear PowerPlants, Revision 3, July 2011.
PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 6 of 422.1.1.7 Regulatory Guide 1.153, Criteria for Safety Systems, Revision 1, June 19962.1.1.8 Regulatory Guide 1.168, Verification, Validation, Reviews, and Audits for Digital ComputerSoftware Used in Safety Systems of Nuclear Power Plants, Revision 1, February 20042.1.1.9 Regulatory Guide 1.169, Configuration Management Plans for Digital Computer SoftwareUsed in Safety Systems of Nuclear Power Plants, September 19972.1.1.10 Regulatory Guide 1.170, Software Test Documentation for Digital Computer Software Used inSafety Systems of Nuclear Power Plants, September 199721.1.11 Regulatory Guide 1.171, Software Unit Testing for Digital Computer Software Used in SafetySystems of Nuclear Power Plants, September 19972.1.1.12 Regulatory Guide 1.172, Software Requirements Specifications for Digital ComputerSoftware Used in Safety Systems of Nuclear Power Plants, September 19972.1.1.13 Regulatory Guide 1.173, Developing Software Life Cycle Processes-for Digital ComputerSoftware Used in Safety Systems of Nuclear Power Plants, September 19972.1.1.14 Regulatory Guide 1.174, An Approach for Using Probabilistic Risk Assessment in Risk-Informed Decisions on Plant-Specific Changes to the Licensing Basis, Revision 1, November20022.1.1.15 Interim Staff Guide DI&C-ISG-01, Cyber Security, Revision 02.1.1.16 Interim Staff Guide DI&C-ISG-02, Diversity and Defense-in-Depth Issues, Revision 2, June20112.1.1.17 Interim Staff Guide DI&C-ISG-04, Highly Integrated Controls Rooms-Communications Issues(HICRc), Revision 1, March 20092.1.1.18 Interim Staff Guide DI&C-ISG-06, Licensing Process, Revision 1, January 20112.1.2 Industry Codes and Standards2.1.2.1 ANSI/IEEE Std. 983-1986, IEEE Guide for Software Quality Assurance Planning2.1.2.2 ANSIIISO/ASQ Q9001-2000, Quality management systems -Requirements2.1.2.3 ANSI/ISO/ASQ Q9004-1-1994, Quality Management and Quality System Elements -Guidelines2.1.2.4 ASME NQA-1-1994, 1997, Quality Assurance Requirements for Nuclear Facility Applications2.1.2.5 EPRI TR-103291, Handbook of Verification and Validation for Digital Systems, Revision 1,December 19982.1.2.6 NEI 08-09, Revision 6, Cyber Security Plan for Nuclear Reactors2.1.2.7 IEEE Std. 7-4.3.2-2003 IEEE Standard Criteria for Digital Computers in Safety Systems ofNuclear Power Generating Stations, Appendix D (Informative) Identification and Resolution ofHazards2.1.2.8 IEEE Std. 279-1971, Criteria for Protection Systems for Nuclear Power Generating Stations2.1.2.9 IEEE Std. 308-1971, Criteria for Class 1E Electric Systems for Nuclear Power GeneratingStations PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 7 of 422.1.2.10 IEEE Std. 323-1974, IEEE Standard for Qualifying Class 1E Equipment for Nuclear PowerGenerating Stations2.1.2.11 IEEE Std. 338-1987, IEEE Standard Criteria for the Periodic Testing of Nuclear PowerGenerating Station Protection Systems2.1.2.12 IEEE Std. 344-1987, Recommended Practices for Seismic Qualification of Class 1 EEquipment for Nuclear Power Generating Stations2.1.2.13 IEEE Std. 379-1977, IEEE Application of Single Failure Criterion to Nuclear PowerGenerating Station Class 1 E Systems2.1.2.14 IEEE Std. 384-1981, IEEE Trial-Use Standard Criteria for Separation of Class 1E Equipmentand Circuits2.1.2.15 IEEE Std. 352-1987, IEEE Guide for General Principles of Reliability Analysis of NuclearPower Generating Station Safety Systems2.1.2.16 IEEE Std. 497-2002, IEEE Standard Criteria for Accident Monitoring Instrumentation forNuclear Power Generating Stations2.1.2.17 IEEE Std. 577-1976, IEEE Standard Requirements for Reliability Analysis in the Design andOperation of Safety Systems for Nuclear Power Generating Stations2.1.2.18 IEEE Std. 603-1991, IEEE Standard Criteria for Safety Systems for Nuclear PowerGenerating Stations2.1.2.19 IEEE Std. 730-2002, Standard for Software Quality Assurance Plans2.1.2.20 IEEE Std. 828-1998, Software Configuration Management Plans2.1.2.21 IEEE Std. 829-1983, Standard for Software Test Documentation2.1.2.22 IEEE Std. 830-1993, Recommended Practice for Software Requirements Specifications2.1.2.23 IEEE Std. 1008-1987, IEEE Standard for Software Unit Testing2.1.2.24 IEEE Std. 1012-1998, Standard for Software Verification and Validation2.1.2.25 IEEE Std. 1016-1997, Recommended Practice for Software Design Descriptions2.1.2.26 IEEE Std. 1028-1997 (reaffirmed 2002), Standard for Software Reviews2.1.2.27 IEEE Std. 1042-1987, ANSI/IEEE Standard Guide to Software Configuration Management2.1.2.28 IEEE Std. 1044-1997, IEEE Standard for Classification of Software Anomalies2.1.2.29 IEEE Std. 1058.1-1991, IEEE Standard for Software Project Management Plans2.1.2.30 IEEE Std. 1058-1998, IEEE Standard for Software Project Management Plans2.1.2.31 IEEE Std. 1061-1998, IEEE Standard for a Software Quality Metrics Methodology2.1.2.32 IEEE Std. 1063-1987, Standard for Software User Documentation2.1.2.33 IEEE Std. 1074-1995, IEEE Standard for Developing Software Life Cycle Processes2.1.2.34 IEEE Std. 1219-1998, Standard for Software Maintenance2.1.2.35 IEEE Std. 1228-1994, IEEE Standard for Software Safety Plans2.1.2.36 IEEE Std. 1233-1998, Guide for Developing System Requirements Specifications2.1.2.37 IEEE Std. 1471-2000. Systems and Software Engineering -Recommended Practice forArchitectural Description of Software-Intensive Systems PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 8 of 422.1.3 DCPP References and Procedures:2.1.3.1 PG&E Procedure, IDAP AD7.1D8, Project Management2.1.3.2 PG&E Procedure, IDAP CF3.1D9, Design Change (Package) Development2.1.3.3 PG&E Procedure, IDAP CF2.1D9, Software Quality Assurance Plan Software Development2.1.3.4 PG&E Procedure, IDAP CF2.1D2, Software Configuration Management for Computers &Software Used for Plant Operations and Operations Support2.1.3.5 PG&E Form 69-20164, Work Group Specific Training Record2.1.3.6 PG&E Procedure, AD10.ID1, Storage and Control of Quality Assurance RecordsNOTE: The various Appendix B software suppliers and the various regulatory agencies do not use thesame terminology for software and software verification and validation. As mentioned in DI&C-ISG-06Rev. 1 [2.1.1.18], an applicant may have different names for similar documents. Regardless of the titlesof the documents submitted, the actual LAR should contain sufficient information to address the criteriadiscussed in the technical evaluation sections... This procedure does not specify that an approvedsoftware supplier meet this particular terminology, only that the intent of this procedure is followed and ahigh quality software product is generated for plant use.NOTE 2: If any part of the software life, cycle process is contracted to an approved supplier with a1 OCFR50 Appendix B program, their SQA processes apply for their product, with PG&E auditing theirprogram, and owner acceptance by PG&E.
PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 9 of 423. Management3.1OrganizationDifferent organizational units, their responsibilities and relationships with regard to Quality are discussedin this SyQAP. The basic organizational structure that influences software quality is shown in Figure 3-1.Quality Management for each of the 1 OCFR50 Appendix B suppliers will be independent of the projectmanagement organization. The basic tenet of Quality Management is to make all employees responsiblefor the quality of their work. This means quality management is the responsibility not only ofmanagement, but also of all project personnel who perform work for, and provide services and productsfor the project.Figure 3-1 PPS Project OrganizationIt is expected of each 1 OCFR50 Appendix B supplier that the Project Manager is responsible for thedevelopment, integration and testing of the application software. The software development tasks areoriginated and supervised by the Responsible Engineer or directly by the Project Manager (or hisdesignee) who leads the engineering team, and reports to the Design Authority. The PG&E Project Teamdetermines the functional requirements of the software while the 1 OCFR50 Appendix B supplier designsthe application software with the aid of engineering and software development tools.The 1 OCFR50 Appendix B supplier will have different test personnel than those personnel involved in thedesign effort. Test personnel design the test plan and test cases, and perform the software testing. Thisorganizational design is intended to promote objectivity, and improve the process of problem resolutionand verification.The respective 1OCFR50 Appendix B supplier's integration team loads the completed software or logiconto the hardware platform, and performs integration testing, including Factory Acceptance Testing. Thisteam is also staffed with individuals who did not participate in the software design effort.
PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 10 of 42The 1 OCFR50 Appendix B supplier's Nuclear Oversight Department, or equivalent, is responsible for theperformance of the reviews, audit, and inspections of the software supplier. V&V Engineers will performthe activities prescribed in this plan. Additionally, V&V personnel have been tasked with verifying that theproject meets nuclear and functional safety requirements per the Failure Modes and Effects Analysis, andReliability Analysis. V&V personnel also ensure that no new software hazards are introduced throughoutthe software lifecycle. Overall responsibility for project safety is the responsibility of the Project Manager.For this project, the Lead Verification Engineer performs the role of the Software Quality AssuranceManager and Project Safety Officer.3.2 10CFR50 Appendix B Supplier TasksBelow is a sequence of the tasks which describes the general development process PG&E expects the10 CFR50 Appendix B [2.1.1.1] suppliers to follow. The specific development process employed by the10CFR50 Appendix B vendors may vary. PG&E will use this SyQAP as a guide for the owner review andapproval of the outputs of the development process employed by the 10CFR50 Appendix B vendor.The tasks describe a complete program, from the requirements definition phase through the integrationand testing phase of the software life cycle. Reviews and audits will be performed as described inSection 6. Software lifecycles are defined per BTP 7-14 [2.1.1.2] using the guidance in IEEE Std. 1074[2.1.2.33]; Tasks meet the minimum requirements contained in RG 1.168 [2.1.1.8] and IEEE 1012-1998[2.1.2.24]Table 2:3.2.1 Project Initiation and Planning Phase TasksThe 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 is a product of this phase.Tasks performed in this phase include:Verify that system requirements (from Request for Proposal or tender, and contract) are consistent andconform to the current licensing basis;* Verify that procedures are documented for managing requirement changes and for identifying themanagement hierarchy to address problems;* Verify procedures for interface and cooperation among the parties are documented, includingownership, warranty, copyright, and confidentiality; and* Verify that acceptance criteria and procedures are documented in accordance with requirements." Plan the interface between the V&V effort and the supplier.* Review the supplier development plans and schedules to coordinate the V&V effort with developmentactivities.* Establish procedures to exchange V&V data and results with the development effort.* The Project Manager should coordinate the plan with the supplier.* Incorporate the project software integrity level scheme into the planning process.A documented process for managing requirements changes and procedures for handling the interfaceamong the parties signifies the end of this phase. The contract verification report will be used as an inputto the preliminary Requirements Traceability Matrix.
PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 11 of 423.2.2 Conceptual Design Phase TasksThe Conceptual design phase defines the scope of the V&V effort. The initial V&V Plan, SyQAP, andFRS are products of this phase. Tasks performed in this phase are:* Review the draft Functional Requirements Specification (FRS) (Concept Documentation Analysis);* Verify SIL Classification(s), criticality, and software category per IEEE 1012 (Criticality Analysis);* Draft and issue project System V&V Plan (SyWP);" Review the System Quality Assurance Plan (SyQAP);* Provide input to the project master schedule;* Analyze system hazards, security, and risks;* Verify the correctness, accuracy, and completeness of the allocation of the requirements to hardware,software, and user interfaces in the conceptual design;" Baseline the system so that subsequent changes can be assessed to determine new hazards andimpact of project risk;* Develop the preliminary Requirements Traceability Matrix (RTM);* Review other management plans if available. These may include the Software Development Plan,Software Installation Plan, Software Integration Plan, Software Safety Plan, and Software Test Plan.These plans may be developed and reviewed in later phases just before they are needed.The responsibilities of the V&V engineer are to publish the project Software V&V Plan (SWP) and theV&V Summary Report documenting V&V activities and Task Reports for this phase. The draft RTM couldbe developed by the V&V team. At a minimum, the V&V engineer is responsible for ensuring that theRTM possesses the attributes needed to support V&V traceability analysis and associated metrics. TheRTM will also be used to document traceability to contractual requirements such as hardwarerequirements, the confirm implementation of specific system features, and confirm compliance with otherdeliverables not directly related to the application software. In addition, the V&V engineer verifies theRequirements Allocation Analysis against user needs to verify correct, accurate, and complete allocationof requirements to hardware, software, and human operators.An approved Functional Requirements Specification (FRS), Software V&V Plan, and SoftwareConfiguration Management Plan signify the end of the Conceptual Design Phase. A Preliminary FailureModes and Effects Analysis (FMEA) may be started in this phase.3.2.3 Requirements Phase V&V TasksIn this phase, a Software Requirements Specification (SRS) will be prepared by the design team for eachapplicable software product using the guidance of IEEE Std. 830 [2.1.2.22]. The SRS will be developedbased on the functional requirement specification and the system interface requirements specification,each of which must be approved by the customer prior to beginning.The output of this task is the approved Software Requirement Specification (SRS). Tasks performed inthis phase are:* Review the Preliminary FMEA if applicable;* Update the Requirements Traceability Matrix (RTM) completed in the Project Initiation andConceptual Phase. The matrix typically will be in the form of a table. Since it will undergo frequent PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 12 of 42change, it will be stored on safe, but readily retrievable computer storage media. RequirementsManagement planning is contained within the RTM document;* Perform a Software Requirements Traceability Analysis by tracing the requirements between the FRSand the SRS. It is expected that requirements be traceable forward from the FRS to the SRS andbackwards from the SRS to the FRS;* Perform a Software Requirements Evaluation by evaluating that the SRS is correct, consistent,complete, accurate, readable, traceable and testable. The requirements will be checked for testabilityfor purposes of validation testing. This ensures that the SRS adequately defines the softwarerequirements necessary to perform the intended function;* Assess software safety by reviewing that the safety requirements are correctly addressed. Thepurpose of this task is to ensure no new hazards have been introduced, ensure that softwareelements that can affect safety have been identified, and to ensure evidence exists that otherelements do not affect safety;* Perform a Software Requirements Interface Analysis by reviewing that requirements for interfaces tohardware, user, operator, and other software are correct, consistent, complete, accurate, traceableand testable;* Verify that the configuration management process is complete and adequate (ConfigurationManagement Assessment);* Assess if there are any changes required to the Criticality Analysis;" Perform a baseline change assessment to assess any changes to risk or security analyses; Issue theBaseline Review Report (BRR);* Review or develop System V&V test plans;* Coordinate resolutions of discrepancies with project management, design team personnel, andquality management;" Produce the Software Requirements Review (SRR) ReportAn approved Software Requirements Specification (SRS), satisfactory resolution of discrepancies, and anapproved Software Requirements Review (SRR) Report containing the appropriate Task Reports andAnomaly Reports signify the end of the requirements phase. The SRS will be approved by prior toproceeding to the Design Phase.3.2.4 Design Phase V&V TasksIn this phase, the design team will prepare the Software Design Description (SDD) for each applicablesoftware product using the guidance of IEEE Std. 1016 [2.1.2.25]. The SDD will be developed based onthe software requirement specification and the software and hardware architecture. The SDD consists oftwo parts: the software and hardware architectural description and the Software Detailed Design. TheHardware Requirements Specification (HRS), Interface Requirements Specification (IRS) and SoftwareRequirements Specification (SRS) should be approved by the customer prior to beginning the designphase to minimize project risk.The output of this task is the approved SDD. Software Test Plan(s) (STP) will be generated by the designteam to evaluate system performance. A three-pronged approach is used for testing:(1) Component (Software Unit) Testing,(2) Integration Testing, and(3) Factory Acceptance Testing (FAT)
PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 13 of 42Software Test Plans conform to the requirements of IEEE Std. 829 [2.1.2.21] and IEEE Std. 1008[2.1.2.23]. Software Test Plans will be reviewed by V&V. A separate Factory Acceptance Test Plan willbe developed.Tasks performed in this phase are:* Perform a Software Design Traceability Analysis by tracing the requirements between the SRS andthe SDD. It is expected that requirements be traceable forward from the SRS to the SDD andbackwards from the SDD to the SRS. The results are recorded in the updated RTM;" Perform a Software Design Evaluation. The SDD will be evaluated for correctness, consistency,completeness, accuracy, readability, and testability. The design will be evaluated for compliance withestablished standards, practices and conventions. Design quality will be assessed;* Perform a Software Design Interface Analysis by reviewing that the software design interfaces tohardware, user, operator, and other software are correct, consistent, complete, accurate, andtestable;* Assess software safety to ensure no new software hazards have been introduced by the design;* Assess if there are any changes required to the Criticality Analysis;* Perform a baseline change assessment to assess any changes to risk or security analyses; Issue theBaseline Review Report (BRR);* Develop Software Test Plan(s) (Component and Integration) related to software and the FAT Plan toensure system test criteria will show compliance with all functional requirements in a systemenvironment, performance at hardware, software and user interfaces, and performance at boundariesunder stress conditions;" Review Component, Integration, System, and Acceptance Test Designs as applicable." Produce the Software Design Review Report;" Coordinate resolutions of discrepancies with project management, design team personnel, andQuality Management.An approved Software Design Description (SDD), satisfactory resolution of discrepancies, approved TestPlan(s) and Design(s), and an approved Software Design Review Report signify the end of the designphase. These activities are required to be completed prior to proceeding to the Implementation Phase.3.2,5 Implementation Phase V&V (Unit/Component Testing)During this phase the executable code is produced and tested. Depending upon the target system,source code may be developed by the design team/programmers, or automatic code generators mayproduce the executable code. In either case, the functions described in the SRS are developed in thecoding environment to programming standards. The correct implementation of the SRS is validatedduring function tests with the software development and simulation tools, and during testing on thetest/development system. The RTM will generally have no entries for this phase. Also during this phase,software unit testing is performed by the design team.Tasks performed in this phase are:* Observe the building and compiling processes; A source code generation evaluation is performed toverify that the source code compiles without and builds without errors;* Perform a Software Implementation Traceability Analysis to ensure that the correct versions andrevisions of function diagrams were used to assemble the code for each subsystem; PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 14 of 42" Verify that the procedure(s) used for software generation and download were followed and that theproper versions of code generators have been used;" Examine the software for completeness to ensure that only qualified system software componentshave been used and that the software was successfully loaded onto the system;" Review Software Unit Test results;" Produce the Software Implementation Review Report;" Coordinate resolutions of discrepancies with project management, design team personnel, andquality management;Perform a baseline change assessment to assess any changes to risk or security analyses; Issue theBaseline Review Report (BRR);Approved FAT Test Procedures, satisfactory resolution of discrepancies, and an approved SoftwareImplementation Review Report signify the end of the implementation phase and readiness to proceed tothe Integration Phase.3.2.6 Integration Phase V&V TasksIntegration Testing is a separate software Lifecycle activity per NUREG-0800 BTP 7-14 [2.1.1.2] and canbe mapped to IEEE 1012-1998 [2.1.2.24]. s a continuation of the Implementation Phase. The Software isintegrated with the hardware and integration testing is performed in accordance with the test proceduresper IEEE Std. 829 [2.1.2.21]. Integration test execution results are analyzed to determine if the systemimplements the requirements and design and that the software components function correctly together.Tasks performed in this phase are:" Confirm that the software shown in the SDD is loaded into the system processors, and that thecorrect software was loaded onto the system;* Develop Factory Acceptance Test (FAT) procedures and verify each functional requirement is tested;* Review the Final FMEA to ensure that testing of failures where practical is included in testprocedures;" Evaluate the quality of user manuals;" Assess software safety to ensure no new software hazards have been introduced by implementationactivities;" Assess if there are any changes required to the Criticality Analysis;* Perform a baseline change assessment to assess any changes to risk or security analyses; Issue theBaseline Review Report (BRR);* Review Integration test results;* Perform requirements tracing between the FAT procedures and the SDD. The relationships betweenthe V&V test plan(s), software designs, tests, and test procedures are analyzed for correctness andcompleteness;* Assess software safety to ensure no new software hazards have been introduced by the integrationactivities;* Produce a V&V Summary Report for the Integration Phase Activities;* Coordinate resolutions of discrepancies with project management, design team personnel and qualitymanagement.
PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 15 of 42At the conclusion of the Integration Phase, the System Integration Review Report will confirm that theconfiguration of the system is complete and ready for FAT testing, and that there are no unresolveddiscrepancies or safety problems. Requirements tracing from the SDD to FAT test procedures should becompleted in this phase to reduce the risk of an incomplete FAT test.3.2.7 Test Phase V&V TasksSystem tests are performed in accordance with the FAT test procedures. Tests are analyzed todetermine if the system implements the requirements and design and that the software componentsfunction correctly together. Test results are analyzed to determine if the software satisfies systemobjectives. Tests pass or fail based on the acceptance criteria stipulated in the SRS and on specificrequirements found in the RTM.Tasks performed in this phase are:* Complete requirements tracing if not already completed in the integration phase to verify a validrelationship between test plans, procedures, and designs;* Witness the FAT test and verify the tests validate that software correctly implements the requirementsand that the expected results conform to the requirements;* Identify discrepancies between actual and expected results;* Produce the final verified and approved RTM;* Produce a V&V Summary Report of the Test Phase Activities;* Coordinate resolutions of discrepancies with project management, design team personnel, andquality management;* Determine the extent of regression testing.Approved FAT Test results as approved by the Project Manager and Customer Representative,satisfactory resolution of all discrepancies, and an approved Software Validation Report signify that thesystem meets it requirements and is ready for delivery to the customer. Each of the 10CFR50 AppendixB suppliers will provide a certificate of conformance at the completion and PG&E acceptance of the FATresults.3.2.8 Final V&V TasksThe final V&V tasks include issuing the Final V&V Report, which summarizes all life cycle V&V tasks andthe task results. It will also summarize the discrepancies and their resolution found during the V&Vevaluation. The report will give an assessment of overall software quality and provide anyrecommendations.Following approval of the final V&V Report, a certificate or letter of conformance will be issued certifyingthe system meets the SIL requirements.Finally a configuration audit is performed to ensure all deliverables have either been previously shippedor are included for shipment to the customer.3.3 PG&E TasksBelow is a sequence of tasks which generally describes the process for PG&E after the final acceptanceof the 1 OCFR50 Appendix B supplier FAT.3.3.1The Installation and Checkout Phase PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 16 of 42The Installation and Checkout phase is when the developed system is first assembled in the ProjectIntegration and Test (PIT) for pre-installation staging and checkout. Performance of the site acceptancetest (SAT), per PG&E plant procedure, is conducted in the PIT. The developed system is then installed inthe final target environment/location and performance of the design verification testing (DVT) per PG&Eplant procedure is conducted. Depending on the complexity of the project, either the supplier or PG&Ewill perform system installation and checkout. Ultimately, PG&E will be responsible for acceptance of theresults of the SAT and DVT. The Installation and Checkout V&V activity addresses software installationand software acceptance support.Tasks performed in this phase:" Audit the installation configuration to verify that all software products required to correctly install andoperate the software are present in the installation package. Validate that all site-dependentparameters or conditions to verify supplied values are correct.* Installation Checkout by V&V; Conduct analyses or tests to verify that the installed softwarecorresponds to the software subjected to V&V. Verify that the software code and databases initialize,execute, and terminate as specified. In the transition from one version of software to the next, theV&V effort will validate that the software can be removed from the system without affecting thefunctionality of the remaining system components. The V&V effort will verify the requirements forcontinuous operation and service during transition, including user notification.* Verify that the installation procedures and installation environment does not introduce new hazards;Update the hazard analysis;" Review and update risk analysis using prior task reports; Provide recommendations to eliminate,reduce, or mitigate the risks; and* Generate the V&V Final Report -Depending upon project scope, either PG&E or the supplier will beresponsible for developing this report; Summarize in the V&V final report the V&V activities, tasks andresults, including status and disposition of anomalies.* Provide an assessment of the overall software quality and provide recommendations.Outputs of this phase are the Operations Manual, the Installation Configuration Tables, Training Manuals,Maintenance Manuals, an Installation Safety Analysis, a V&V Installation Analysis and Test Report, and aCM Installation Report3.3.2 Operation Phase V&V TasksThe 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 1 OCFR50 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.Tasks performed in this phase:* Evaluate new constraints (e.g., operational requirements, platform characteristics, operatingenvironment) on the system or software requirements to verify the applicability of the SWP; Softwarechanges are maintenance activities (see Section 3.2.10 Maintenance Phase, below).* Assess proposed changes (e.g., modifications, enhancements, or additions) to determine the effect ofthe changes on the system. Determine the extent to which V&V tasks would be iterated.* Verify that the operating procedures are consistent with the user documentation and conform to thesystem requirements.
PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 17 of 42" Verify that the operating procedures and operational environment does not introduce new hazards;Update the hazard analysis.* Review and update risk analysis using prior task reports; Provide recommendations to eliminate,reduce, or mitigate the risks.3.3.3 Maintenance Phase V&V TasksThe maintenance process is activated 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 will be treated as development processes and will be verified and validatedin accordance with development process described in the previous sections. Software integrity levelassignments will be assessed during the maintenance process. The software integrity level assignmentswill be revised as appropriate to reflect the requirements of the maintenance process. For SIL3 systems,revising the software integrity level to the SIL4 may require updating the relevant planning documents, orgenerating new planning documents, as appropriate. For SIL4 software that is being downgraded toSIL3, the implications on compliance with the site's current licensing basis as well as compliance withregulatory requirements must be evaluated and document prior to initiating the maintenance activity.System modifications may be derived from requirements specified to correct software errors (e.g.,corrective), to adapt to a changed operating environment (e.g., adaptive), or to respond to additional userrequests or enhancements (e.g., perfective).The Maintenance V&V activity covers modifications (e.g., corrective, adaptive, and perfective), migration,and retirement of software. Migration of software is the movement of software to a new operationalenvironment. The retirement of software is the withdrawal of active support by the operation andmaintenance organization, partial or total replacement by a new system, or installation of an upgradedsystem.The Maintenance V&V activity addresses problem and modification analysis, modificationimplementation, maintenance review/acceptance, migration, and software retirement. The objectives ofV&V are to assess proposed changes and their impact on the software, evaluate anomalies that arediscovered during operation, assess migration requirements, assess retirement requirements, and re-perform V&V tasks.Tasks performed in this phase:* Revise the SyWP to comply with approved changes. When the development documentationrequired by this plan is not available, generate a new SyWP;* Assess proposed changes (i.e., modifications, enhancements, or additions) to determine the effect ofthe changes on the system. Determine the extent to which V&V tasks would be iterated." Evaluate the effect of software operation anomalies." Perform a criticality analysis to determine the software integrity levels for proposed modifications.Validate the integrity levels assigned during development; address any inconsistencies, particularly ifthe SIL level is downgraded. For V&V planning purposes, the highest software integrity levelassigned to the software will be the software system integrity level." Assess whether the software requirements and implementation address 1) specific migrationrequirements, 2) migration tools, 3) conversion of software products and data, 4) software archiving,5) support for the prior environment, and 6) user notification.
PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 18 of 42* For software retirement, assess whether the installation package addresses: 1) software support, 2)impact on existing systems and databases, 3) software archiving, 4) transition to a new softwareproduct, and 5) user notification.* Verify that software modifications correctly implement the critical requirements and introduce no newhazards; Update the hazard analysis.* Review and update risk analysis using prior task reports; Provide recommendations to eliminate,reduce, or mitigate the risks.* Perform V&V tasks, as needed, to ensure that 1) planned changes are implemented correctly; 2)documentation is complete and current; and 3) changes do not cause unacceptable or unintendedsystem behaviors.3.4 PG&E Roles & ResponsibilitiesThe different roles and responsibilities for Software Quality Assurance as they relate to this SyQAP arediscussed below:3.4.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, supplierquality management/oversight, quality field implementation, and successful post-installation testing. TheProject Manager is also responsible to recommend re-evaluation of the project if he detects changes inthe project 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 will:* Release the system level V&V plan and reports* Establish cost controls" Enter the plan activities into the master project schedule." Review progress of the SyQAP and V&V program* Evaluate any reported deviations or anomalies for their potential risk and impacts to project cost andschedule." Approve corrective actions, scope changes and resource allocations.* Coordinate the disposition of discrepancy reports generated in the course of verification andvalidation.3.4.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.
PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 19 of 423.4.3 PG&E Project Engineering TeamThe PG&E Project Engineering Team conducts and ensures quality-related inter-group coordination fordesign and engineering between software and hardware design activities. Project engineering isresponsible for identifying the processes and corresponding standards and procedures to guide projectperformance. The project engineering team is further responsible for ensuring work activities areperformed in compliance with these standards and procedures.3.5 10CFR50 Appendix B Supplier Roles & ResponsibilitiesThe section below is a general description of the 10CFR50 Appendix B supplier's roles andresponsibilities. Detailed roles and responsibilities for each of the 1 OCFR50 Appendix B suppliers areprovided in the respective 1OCFR50 Appendix B supplier SQAP.3.5.1 Supervisor Project QAThe Supervisor Project QA is responsible for monitoring implementation of the quality program throughoutthe project and supports all levels of management. The Supervisor Project QA monitors project activitiesto ensure compliance with the policies reflected in this program manual and the related standards andprocedures throughout all system phases and maintenance activities.Supervisor Project QA supports the Project overseeing implementation of the SQAP program.Responsibilities in this capacity include:* Review the project-specific V&V plan and reports* Ensure the SQAP addresses the quality goals and priorities of the project and client organization, andsatisfies all organization requirements and expectations* Ensure the SQAP is put under configuration management (CM) control and made available to allaffected groups and individuals" Ensure audits of activities for compliance with the SQAP and other applicable requirements* Establish processes and procedures to perform SQAP activities* Report findings to project management, and identify corrective actions related to the product andprocess verifications.3.5.2 Project Manager (PM)The Project Manager (PM) is responsible for providing direction in implementation of the SQAP programdefined by this SQAP and for ensuring adequate resources are allocated to accomplish theimplementation. The 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 will:* Release the project-specific V&V plan and reports* Establish cost controls* Enter the plan activities into the master project schedule." Review progress of the SQAP and V&V program* Evaluate any reported deviations or anomalies for their potential risk and impacts to project cost andschedule.
PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 20 of 42* Approve corrective actions, scope changes and resource allocations.* Coordinate the disposition of discrepancy reports generated in the course of verification andvalidation.3.5.3 Project Lead EngineerThe focus of the Project Lead Engineer is to conduct and ensure quality-related inter-group coordinationfor design and engineering between software and hardware design activities. The Project Lead Engineeris responsible for identifying the processes and corresponding standards and procedures to guide projectperformance. The Project Lead Engineer is further responsible for ensuring work activities are performedin compliance with these standards and procedures.3.5.4 Design TeamThe Design Team interfaces with SQA regularly to review the status of software quality activities and toaddress any quality-related issues identified by SQA. The Design Team is responsible for establishingquality goals and objectives for their organization consistent with those of the project.3.5.5 Testing/lntegration TeamThe Testing/Integration Team is responsible for integration and Factory Acceptance Testing (FAT). TheTesting/Integration Team develops test plans and reports for systems integration and test activities,defines requirements for, develops, and implements test plans for systems integration and FAT. TheTesting/Integration Team may include members of the Design Team.3.5.6 Lead Verification Engineer (SQA Manager)The Lead Verification Engineer is responsible to implement the Software Quality Assurance Program asdefined in the Software Quality Assurance Plan (SQAP) for the project. The Lead Verification Engineeralso manages resources to perform V&V activities, ensures the independence of V&V personnel, andapproves the SWP and V&V reports. The Appendix B software supplier is expected to have a separateQA organization and the Lead Verification Engineer will review and approve all test plans and V&Vreports. Purchase Orders will be written so the SQA Organization is not constrained by either budget orschedule in the performance of their duties.3.5.7 Verification & Validation (V&V) StaffVerification & Validation (V&V) Staff will maintain technical independence, managerial independence, andfinancial independence. The V&V Staff are responsible to perform V&V audits and inspections perapproved V&V Plans, create or verify the traceability of customer and functional requirements using aRequirements Traceability Matrix, review Software Test Plans, verify independently that all items of safetysoftware have been correctly identified and included appropriately in the design documents, review testprocedures as applicable, and produce Software V&V Reports in accordance with V&V Procedures. Inaddition V&V is responsible to evaluate the activities in each software Lifecycle phase to ensure theactivities performed do not introduce new software hazards. Finally V&V will perform audits ofconfiguration management. Project needs may dictate that V&V personnel will develop all software testplans, the FAT plan, and FAT procedures as well as supervise testing of the developed system.3.5.8 Project QA Engineer or EquivalentThe Project QA Engineer is responsible to ensure that nuclear and functional safety objectives are met inaccordance with IEEE 1012 [2.1.2.24].
PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 21 of 424. DocumentationThe NRC has issued Interim Staff Guidance (ISG) in digital instrumentation and control DI&C-ISG-06[2.1.1.18] that describes the licensing process that may be used in the review of License AmendmentRequest (LAR) associated with digital I&C system modifications.DI&C-ISG-06, Enclosure B, lists documents that are typically submitted by the licensee in support of asubmittal during Phases 1 and 2 of review. The Phase 1 documents that are associated with this projectare summarized in a separate attachment to the LAR. A list of Phase 2 documents associated with thisproject will be provided 12 months prior to the requested LAR approval date.The documentation discussed below is a summary of the documents to be provided by PG&E and the1 OCFR50 Appendix B supplier(s). As stated above, specific documents associated with this project arelisted in separate lists provided with the LAR and Phase 2 submittal enclosure.4.1 Overview of PG&E DocumentsThe following is a summary of the documents to be provided by PG&E.4.1.1 Conceptual Design Document (CDD)The CDD will provide a high level description of the overall system to be implemented by the DCPP PPSupgrade project.4.1.2 Functional Requirements Specification (FRS)The FRS will provide a general description of what PG&E expects the system to do. All known customerrequirements will be documented. The FRS should state the specific customer requirements as clearlyand consistently as possible. It will describe the operations the user wants to perform with the softwareand define all the constraints that the customer wishes to impose upon any solution. The FRS willdescribe the external interfaces to the system. IEEE Std. 1233 [2.1.2.36] can be used for guidance inregards to the content, table of contents and details that should be included in the FRS. The FRS is adeliverable from PG&E.4.1.3 Interface Requirements Specification (IRS)The IRS will provide a general description of how PG&E expects the separate deliverables from each ofthe 10CFR50 Appendix B suppliers to interface with one another. Specifically, the IRS will provide:(1) Requirements for the interfaces between external field devices such as process transmitters and the1OCFR50 Appendix B suppliers' equipment;(2) Electrical and communication interfaces between the 1 OCFR50 Appendix B suppliers equipment andtheir associated peripheral devices; and(3) Other interfacing Diablo Canyon Power Plant (DCPP) systems such as the Plant Process Computer(PPC), Main Annunciator System (MAS), Safety Parameter Display System (SPDS) and the Safety-Related 120 Vac and 125 Vdc Power Systems.4.1.4 System Verification & Validation Plan (SyVVP)The System Verification and Validation Plan (SyWP) for the overall system life cycle will be preparedaccording to IEEE Std. 1012 [2.1.2.24]. PG&E will review and approve 1OCFR50 Appendix B supplier lifecycle outputs providing independent V&V activities including review, evaluation, analysis, and inspection.It will include both an assessment of the development process, and independent testing of the softwareand logic products within the Site Acceptance Test (SAT).
PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 22 of 42In accordance with the system verification & validation plan, the overall plan for the verification andvalidation of the system is described. All methods, criteria, and tasks are listed, including required inputsand outputs.4.1.5 Site Acceptance Test (SAT) PlanThe SAT Test Plan will prescribe the scope, approach, resources, and schedule of the testing activities.It identifies the items to be tested, the features to be tested, the testing tasks to be performed, thepersonnel responsible for each task, and the risks associated with the plan. The SAT Plan describes theformal acceptance testing approach, methodology, and acceptance criteria that will enable PG&E toaccept the system for implementation in the plant. Test plans, test cases, and test procedures aredeveloped in accordance with IEEE Std. 829 [2.1.2.21]. See Section 7 for further details about testing.4.1.6 Requirements Traceability Matrix (RTM)The RTM will be used to demonstrate traceability for each function through all phases of the systemdevelopment. Regulatory guidance requires traceability analysis only for software requirements.However, formal requirements management is considered to be a good business practice towarddevelopment of a high-quality digital system. Therefore, it is recommended that the RTM cover hardware,software, and interface requirements of the digital system to the extent practical.A RTM is created to demonstrate that all requirements have been successfully implemented in the designand tested in the testing program. Both forward and reverse paths must exist to be able to trace eachdesign requirement to and from the SAT. During the RTM development there may be some requirementsthat cannot be validated by testing. For these, techniques such as analysis or reviews can be used andnoted in the RTM. More information can be found in the EPRI V&V handbook (TR-103291).4.1.7 System Verification and Validation (SyWR) Final ReportThe System Verification and Validation Final Report summarize all results of the execution of the SyWP.It lists all deficiencies found; provides the results of reviews, audits and tests.4.2 Overview of 10CFR50 Appendix B Supplier DocumentsThe section below is a general description of the 1 OCFR50 Appendix B supplier's documents. A detailedlisting and description of the documents supplied by each of the 1 OCFR50 Appendix B suppliers isprovided in the respective 10CFR50 Appendix B supplier SQAP.4.2.1 System Requirements Specification (SyRS)The System Requirements Specification (SyRS), which includes the I/O list and memory mappingbetween devices, describes the external input/output as well as input and output between modules of thenew system architecture so hardware and software designs can proceed independently. Hardware andSoftware Design will consistently apply naming conventions to avoid confusion.4.2.2 Software Verification & Validation Plan (SVVP)The Software Verification and Validation Plan (SWP) for the software life cycle will be preparedaccording to IEEE Std. 1012 [2.1.2.24]. Independent V&V activities include review, evaluation, analysis,and inspection. It will include both an assessment of the development process, and independent testingof the software products as necessary.In accordance with the software verification & validation plan, the overall plan for the verification andvalidation of the software is described. All methods, criteria, and tasks are listed, including requiredinputs and outputs.
PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 23 of 42The V&V plan will describe the methods for verifying that the generated software implements design asexpressed in the SDD and the requirements of the SRS, and validating that the code, when executed,complies with the expected results of the Software Test Plan(s) (STP).The V&V plan will describe test plans and test cases to validate the capabilities and correct operation ofany third party software, including the operating system and communications protocols, if required.4.2.3 Software Configuration Management Plan (SCMP)The software configuration management plan (SCMP) will be published to document configurationmanagement activities applicable to the portion of the software life cycle covered by the SQAP. TheSCMP will conform to the requirements of IEEE Std. 828 [2.1.2.20]. The configuration managementactivities required by the SCMP will be audited; the audit may be performed by QA, V&V, or by a teamcomposed of both.4.2.4 Software Safety PlanThe Software Safety Plan provides a systematic approach for identifying hazards and reducing softwarerisks and defines the safety goals that are expected to. be achieved by adhering to the plan. The planfollows and complies with BTP-7-14 [2.1.1.2] and the concepts of IEEE 1228 [2.1.2.35] but does not fullycomply with IEEE 1228. The NRC has not endorsed IEEE 1228. The design of the SRS, SDD and codeis potentially subject to constraints arising from the safety analysis. Supplier organizations are expectedto provide documentation on their organization, requirements coupled with the performance of the FMEA,response time analysis and FAR to ensure that there are no safety hazards.4.2.5 Baseline Review ReportThe Baseline Review Report (BRR) documents the results of the Baseline Change Assessment (BCA)performed at the end of each lifecycle phase. The BCA is an evaluation of proposed software changes(e.g., anomaly corrections and requirement changes) for potential effects on previously completed V&Vtasks. Plan iteration of affected tasks or initiate new tasks to address software baseline changes oriterative development processes. The BCA verifies and validates that the change(s) is (are) consistentwith system requirements and does (do) not adversely affect requirements directly or indirectly. Anadverse effect is a change that could create new system hazards and risks or affect previously resolvedhazards and risks adversely.4.2.6 Software Requirements Specification (SRS)The SRS describes all functions accomplished using software that have to be specified during thesoftware development. It is based on the reviewed and released Functional Requirements Specification(FRS). The SRS contains all information, necessary for the specification of function diagrams such as:function descriptions, performance criteria, signal interfaces, ID codes, hardware assignments and designconstraints. Each function within the SRS is uniquely identified, such that its achievement is capable ofbeing objectively verified and validated. The SRS follows the guidance in IEEE Std. 830[2.1.2.22] to theextent practical. The SRS is subject to the Software Requirements Review.4.2.7 Requirements Traceability MatrixThe Requirements Traceability Matrix (RTM) will be used to demonstrate traceability for each functionthrough all phases of the software development. Regulatory guidance requires traceability analysis onlyfor software requirements. However, formal requirements management is considered to be a goodbusiness practice toward development of a high-quality digital system. Therefore, it is recommended thatthe RTM cover hardware, software, and interface requirements of the digital system to the extentpractical.
PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 24 of 42The RTM have been created to demonstrate that all specified requirements have been successfullyimplemented in the design and tested in the testing program. A forward path must exist to be able totrace each design requirement to the FAT and, where applicable, to a user manual dictating how eachrequirement is to be carried out. During the RTM development there may be some requirements thatcannot be validated by testing. For these, techniques such as analysis or reviews can be used and notedin the RTM. More information can be found in the EPRI V&V handbook (TR-1 03291) [2.1.2.5].The requirements traceability matrix is updated at the end of each life-cycle phase to provide forwardsand backwards traceability to and from the HW and SW requirements to ensure that failure modes aredocumented and tested. After the matrix is completed, verification is performed to ensure that thoserequirements that are found not to be testable are validated by other means.4.2.8 Software Requirements Review ReportThe SRR is performed to ensure that the SRS adequately and completely reflects the design demands ofthe functional requirements specification and they are technically feasible. The SRR verifies that the SRSwas created in accordance to the above-mentioned standards and is unambiguous, complete, verifiable,consistent, modifiable, traceable and usable during operation and maintenance.A Software Requirements Review Report will contain information about review activities, reviewparticipants, review results and all found discrepancies. Found discrepancies are reported in the form ofopen items and are subject to the discrepancy reporting process outlined in Section 8.4.2.9 Software Design Description (SDD)The design will specify reduction of the overall structure into physical solutions (algorithms, equations,control logic, and data structures) in a manner that the design can be translated into code. The SoftwareDesign Description (SDD) will contain a technical description of the software and hardware architecture,and the software with respect to the theoretical basis, mathematical model, control flow, data flow, controllogic, and data structure. The SDD will contain a description of the allowable or prescribed ranges forinputs and outputs. For graphical programming environments utilizing function block diagrams to createapplication programs, the SDD of the application software is published by printing the function modulesusing software development tools described in the SVVP. The SDD will follow the guidance in IEEE Std.1016 [2.1.2.25], to the extent practical.4.2.10 User DocumentationThe user documentation consists of manuals describing the hardware, system software and tools to guideusers in installing, operating, and maintaining the system. User documentation will include anintroduction, a description of the system's limitations, the user's interaction with the software, and anyrequired training necessary to use the software. User documentation will also include the procedure forperforming required periodic calibration, tests, and preventive maintenance.User Manuals should describe operation of the overall system, including configurable parameters,options, program limitations, system-specific scripts, procedures for starting, re-starting of the system,exchange of modules, and all other essential information about the applications software as part of theuser documentation to be provided. User Documentation will also be provided that describes I/Ospecifications and formats, user responses to messages resulting from improper input, and how to obtainuser and maintenance support. Refer to IEEE Std. 1063 [2.1.2.32] for further guidance.
PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 25 of 424.2.11 Software V&V ReportsSoftware V&V Reports are published at the end of each software Lifecycle phase per IEEE Std. 1012[2.1.2.24] identifying the anomalies, corrective actions, and recommendations based on the V&Vactivities performed in each phase. Refer to Section 3 for the V&V activities to be performed.4.3 1OCFR50 Appendix B Supplier Software Test DocumentationThe section below is a general description of the 1 OCFR50 Appendix B supplier's test documentation.Details of the software test documentation supplied by each of the 1 OCFR50 Appendix B suppliers areprovided in the respective 1 OCFR50 Appendix B supplier SQAP.Software testing will be developed following the test documentation requirements outlined in IEEE Std.829 [2.1.2.21]. The test documentation will include a Software Test Plan(s) (STP), detailed testspecifications, and test reports. Additional SQA testing requirements are described in Section 7. Failuresin the software detected during testing will be recorded using the problem reporting process described inSection 8.4.3.1 Software Test Plan(s)The Software Test Plan(s) and FAT Test Plan will prescribe the scope, approach, resources, andschedule of the testing activities. It identifies the items to be tested, the features to be tested, the testingtasks to be performed, the personnel responsible for each task, and the risks associated with the plan.The Factory Acceptance Testing (FAT) Plan describes the formal acceptance testing approach,methodology, and acceptance criteria that will enable the customer to accept the system for delivery.Test plans, test cases, and test procedures are developed in accordance with IEEE Std. 829 [2.1.2.21].See Section 7 for further details about testing.4.3.2 Security Test Plan(s)The objective of testing security functions is to ensure that the system security requirements are validatedby the execution of integration, system, and acceptance tests where practical and necessary. Testingincludes system hardware configuration (including all connectivity to other systems, including externalsystems), software integration testing, system integration testing, and system factory acceptance testing.The security requirements and configuration items intended to ensure reliable system operation will bepart of the validation of the overall system requirements and design configuration items. Therefore,security design configuration items will be just one element of the overall system validation. Each systemsecurity feature will be validated to verify that the implemented feature achieves its intended function toprotect against inadvertent access and/or the effects of undesirable behavior of connected systems anddoes not reduce the reliability of system's safety functions.Depending upon the scope of the project, testing will address the system hardware architecture, externalcommunication devices, and configurations for unauthorized pathways and system integrity. Built-inoriginal equipment manufacturer features will also be included for testing.4.3.3 Software Verification and Validation Final ReportThe Software Verification and Validation Final Report (SWR) summarizes all results of the execution ofthe SVVP. It lists all deficiencies found; provides the results of reviews, audits and tests. The result ofthe final report is a certificate of conformance that the software can be released for operational use.
PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 26 of 424.4 Other Documentation4.4.1 Documents" Software Installation Plan provides a general description of the installation process and the goals ofthat process. A general description of the environment (such as temperature, humidity, vibration, andrack space) within which the computer system and software system is required to operate should beincluded in the plan. It describes the organization, roles and responsibilities, and approach requiredto perform the software installation. Software Installation Planning may be included in the SoftwareTest Plan(s).* Software Integration Plan describes the software integration process, the hardware/softwareintegration process, and the goals of the processes. It describes the organization, roles andresponsibilities, and approach required to perform the software integration. Software IntegrationPlanning may be included in the Software Test Plan (s)." Hardware Requirement Specification (HRS) similar to the SRS, the Hardware RequirementsSpecification describes what hardware will be used and what requirements must be met by thehardware to meet the Functional Requirements Specified in the FRS. The HRS is used to define thearchitecture of the system.4.4.2 Design AnalysesThe design of the system is potentially subject to constraints arising from the following analyses:* Reliability Analysis evaluates the failure rates of modules in terms of the probability of system failureon demand, compares the overall system availability to the reliability goal(s) specified in the FRS.Reliability analyses are performed per the guidance of IEEE Std. 577 [2.1.2.17] and may be includedin the FMEA.* Failure Modes and Effects Analysis (FMEA) the detailed FMEA will specifically consider systematicrandom single failures based on the hardware design and architecture of the integrated system.Particular attention is paid to safety functions and software failures. The analysis is typicallyextended to include common mode failures. Recommendations are made based on potential failures,severity, and risks involved, which could result in design changes to the system. The FMEA will beperformed following the guidance of IEEE Std. 352 [2.1.2.15].* Response Time Analysis this analysis calculates the overall Response Time of the system, whichshould be lower than the shortest required response time, described in the FRS.5. Standards, Practices, Conventions, and MetricsThis project adheres to regulatory guidance and ANSI/IEEE, and International standards consideredacceptable for software used in nuclear plant safety systems. In particular, NUREG-0800, BTP 7-14[2.1.1.2], IEEE 603-1991 [2.1.2.18], IEEE 7-4.3.2-2003 [2.1.2.7], and IEEE 1012-1998 [2.1.2.24] are usedas the basis for the overall V&V process to be applied to SIL-4 systems. The design of the PPS is.intended to meet the requirements of IEEE Standards that are currently endorsed by various NRCRegulatory Guides at the time of the design.Monitoring of compliance and adherence to these standards is ensured through the reviews and auditsconducted (see section 6) by the V&V team under the direction of thel OCFR50 Appendix B supplier LeadVerification Engineer. Moreover, the 10CFR50 Appendix B supplier Lead Verification Engineer willapprove, and document in future versions of this 1 OCFR50 Appendix B supplier SQAP, necessarypractices, conventions, metrics and deviations from the standards, decided by the 10CFR50 Appendix B PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 27 of 42supplier Project Manager and/or 10CFR50 Appendix B supplier Responsible Engineer. Deviations fromstandards should be clearly justified and documented in the respective SQAP.5.1 Documentation standardsThe documentation standards defined in the 1 OCFR50 Appendix B supplier SWP, this SyQAP, and the1OCFR50 Appendix B supplier SQAP will be followed. See sections 4 and 6 for implementation ofstandards and monitoring of adherence.5.2 Logic structure (design) standardsIEEE standards will be used for the overall organization of the SRS, SAD and SDD. Function logicdiagrams and SAMA diagrams are predefined by the software development tools and cannot be alteredby the user.5.3 Testing Standards and PracticesTest procedures, test scripts and the results of the test are part of the documentation described in Section7. The structure of test procedures and test scripts is in conformance with IEEE Std. 829 [2.1.2.21] andIEEE Std. 1008 [2.1.2.23] as verified as part of the V&V testing activities described in the 10CFR50Appendix B supplier SWP.5.4 Selected SQA Product and Process MetricsA minimum set of quality metrics should be defined in each of the 10CFR50 Appendix B supplier SWP.A required metric is the requirements coverage ratio, defined as the fraction of requirements specified inthe SRS that are traceable into the SDD and testing program.6. Software Reviews and AuditsReviews and audits are part of the Verification and Validation (V&V) activity. Accordingly, all reviews andaudits, as well as the necessary arrangements and methods for these reviews and audits will be specifiedin the SyWP as well as each of the 1 OCFR50 Appendix B supplier SWPs. The procedures for softwarereviews are based closely on the ANSI/IEEE Std. 1028 [2.1.2.26]. In general, technical reviews evaluatespecific software elements to verify requirements and conformance to regulations, codes, and standards;a code walkthrough is a method used for the early evaluation of documents, models, designs, and code;inspections are performed to evaluate documents and code before technical review or testing, andindependent reviews and audits are performed to assess compliance with software requirements,specifications, baselines, standards, procedures, instructions, codes, and contractual and licensingrequirements.Verification reviews will be documented identifying the participants and their specific responsibilitiesduring the review. Review documentation will include review comments and their disposition, which willbe retained until they are incorporated into the updated software. Comments and dispositions notincorporated will be retained in accordance with established procedures. Following incorporation ofcomments, reviewed documents will be updated and placed under configuration control. Founddiscrepancies are reported in the form of open items and are subject to the discrepancy reporting processoutlined in Section 8.The following IEEE-730 [2.1.2.19] reviews and audits or their equivalents are used in the process ofperforming V&V:
PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 28 of 426.1 Software Requirements Review (SRR)The Software Requirements Review is held to ensure adequacy of the requirements stated in the SRS.The SRS will be reviewed each time it is updated. The output from the review will consist of verificationreview comments, which will be documented in an SRR Report and transmitted to the developmentorganization. The report will identify all deficiencies discovered during the review. The review processmay require several iterations. This review is described further in Section 4.6.2 Architectural Design Review (ADR)An Architectural Design Review is a preliminary review to verify the technical adequacy of the basicdesign, and check the compatibility of the functional and performance requirements for the system. TheADR verifies consistency of the interfaces between the software and hardware. The basic designconcepts are verified for consistency and technical feasibility.6.3 Detailed Design Review (DDR)A Detailed Design Review is held to determine the acceptability of the detailed software designs asdepicted in the detailed design description in satisfying the requirements of the SRS to include: allfunctions, specified in the FRS are implemented; the described interface is completely implemented; andtest requirements are implemented. The software design review will verify that the software design istraceable to the requirements.6.4 Software Verification and Validation Plan Review (SVVPR)The SWPR is held to evaluate the adequacy and completeness of the verification and validationmethods defined in the SWP. This review is completed by the Project Manager with support from theLead Verification Engineer and is signified by approval of the SWP. The SWP should be reviewed andupdated at the end of each phase of the software development life cycle to consider any new or differentV&V activities for the next life cycle based on lessons learned from previous lessons learned andoperating experience.6.5 Functional AuditThis audit is held prior to the software delivery to verify that all requirements specified in the SRS havebeen met. Functional Audits are held together with the system design team prior to the system deliveryduring FAT testing. The Project Manager's and Customer or Customer Representative's approval of FATTest Results signify acceptance of the system for delivery.6.6 Physical AuditThis audit is held to verify that the software and documentation are internally consistent and ready fordelivery.6.7 In-process AuditsIn-process audits of a sample of the design are held to verify consistency of the design, including code-versus design documentation, interface specifications of the hardware and software, implementation ofthe design versus functional requirements, and functional requirements versus test descriptions. For thisproject, this will be accomplished by performing forward and backwards traceability analyses from thefunctional requirements through testing using a RTM.
PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 29 of 426.8 Managerial ReviewsManagerial reviews are held periodically to assess the execution of all of the actions and items identifiedin the SQAP. These reviews will be held by the Project Manager or his designee. Additionally SQA willattend project and staff meetings as feasible to assess and report on organizational effectiveness.Observations, both positive and negative, will be included in monthly activities reports.6.9 Software Configuration Management Plan Review (SCMPR)The SCMPR is held to evaluate the adequacy and completeness of the configuration managementmethods defined in the SCMP. This review is performed by the Project Manager with support from theLead Verification Engineer and is signified by their approval of the SCMP.6.10 Post Implementation ReviewA review will be held at the conclusion of the project to assess the development activities performedduring the project and to provide recommendations for improvement and to develop lessons-learned.The Post Implementation review will be conducted by the Project Manager with input from SQApersonnel, project technical personnel, and the system design team.6.11 User Documentation ReviewA review of user documentation will be performed to assess the adequacy of user documentation inregards to completeness, clarity, correctness, and usability.6.12 Software Safety ReviewsAn assessment will be made at the end of each software lifecycle phase to confirm that the activitiesperformed during that phase did not introduce any new software hazards. This assessment will beperformed by independent V&V personnel.6.13 Configuration Management ReviewsThe effectiveness of configuration management will be evaluated at the end of each software Lifecyclephase by SQA personnel.7. TestAll software verification and validation activities will be documented as required by each of the 10CFR50Appendix B [2.1.1.1] suppliers Software Verification and Validation Plan (SWP). The content related totesting in the 1OCFR50 Appendix B SVVP will be derived from the IEEE Standard for Verification andValidation Plans (IEEE Std. 1012 [2.1.2.24]) and the IEEE Standard for Software Test Documentation(IEEE Std. 829 [2.1.2.21]). Software Test Plan(s) (STP) will be created per IEEE Std. 829 to define thescope, approach, resources, and schedule of testing activities. A separate FAT Plan will be developed.8. Problem Reporting and Corrective ActionProblem reporting and corrective action procedures are part of the SCM activity and documentedaccordingly in the SCMP as well as the individual 1 OCFR50 Appendix B suppliers' SCMP.The actual implementation of the procedures is under the responsibility of each of the individual ProjectManagers, while the 1 OCFR50 Appendix B supplier Lead Verification Engineer is in charge of ensuringand monitoring the policy. Moreover, the 1OCFR50 Appendix B Lead Verification Engineer will recordproblem statistics and observe their trends.
PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 30 of 42Software anomalies can be reported at any stage in the life cycle. Anomalies can fall into a number ofclassifications according to the degree of regression in the life cycle. Selection of the problemclassification defines the phase of the life cycle at which corrective action needs to start.The 1OCFR50 Appendix B suppliers' SWP will describe the method of reporting and resolvinganomalies, including the criteria for reporting an anomaly, the anomaly report distribution list, and theauthority and time lines for resolving anomalies. The section will define the anomaly criticality levels.Classification for software anomalies may be found in IEEE Std. 1044[2.1.2.28].8.1 Anomaly Resolution and ReportingAnomalies are software discrepancies discovered by the V&V team, either during independent testing orobservation of testing by the design and testing organizations. Anomalies can be compliance problemsor simply enhancement suggestions. V&V anomalies identified by the V&V team must be reported to thedesign team. The V&V team will use the normal, applicable discrepancy reporting process of the project.Either the 1 OCFR50 Appendix B suppliers' corrective action process or the PG&E corrective actionprocess may be used; in either case a tracking mechanism must be used.The tracking system must include a flag or other means to identify open items that are V&V discoveriesand anomalies. Anomalies will be classified and assessed for project risk, in accordance with therequirements of this SyQAP.8.2 Task Iteration PolicyThe 1 OCFR50 Appendix B suppliers' SVVP will describe the criteria used to determine the extent to whicha V&V task will be repeated when its input is changed or task procedure is changed. These criteria mayinclude assessments of change, software integrity level, and effects on budget, schedule, and quality.Each V&V task performed, using designer-supplied documentation, will be assessed for possible re-performance whenever that documentation is revised. For instance, the release of a revised SRS wouldtrigger assessment not only of those activities in which the SRS itself was evaluated, but also of thoseactivities that used the SRS as a reference for the evaluation of other documentation (i.e., SDD).V&V personnel will conduct such assessments based on the extent of the changes, the criticality of thefunctions affected, and the anticipated impact on the software quality. Their findings will be documentedand V&V tasks re-performed to the extent required. This typically requires a revision of the report for thatphase.9. Tools, Techniques, and MethodologiesTools, techniques and methods for software production will be defined at the project level, anddocumented in the relevant 1 OCFR50 Appendix B suppliers' documents. It is an SQA activity, under theresponsibility of each of the 1 OCFR50 Appendix B supplier Lead Verification Engineers, to check thatappropriate tools, techniques and methods are selected and to monitor their correct application.Each of the 10CFR50 Appendix B supplier Lead Verification Engineers may decide that additional tools,techniques and methods are required to support the respective monitoring activity. These will bedocumented and described in that particular 1OCFR50 Appendix B supplier's SQAP.Each of the 10CFR50 Appendix B supplier's SWPs will describe documents, hardware and softwareV&V tools, techniques, methods, and operating and test environment to be used in the V&V process.Acquisition, training, support, and qualification information for each tool, technology, and method will beincluded. Tools that insert code into the software will be verified and validated to the same rigor as thehighest software integrity level of the software. Tools that do not insert code will be verified and validatedto assure that they meet their operational requirements. If partitioning of tool functions can be PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 31 of 42demonstrated, only those functions that are used in the V&V processes will be verified to demonstratethat they perform correctly for their intended use.Methods/tools require a description of the methods, equipment, instrumentation and tools used to carryout each V&V task. Test methods should be specified for unit, integration, validation, installation andregression testing. The plan should specify a process for selecting tools. The hardware and softwareenvironment within which the V&V tools are to be applied and any necessary controls should bedescribed. V&V methods include document reviews, design reviews, requirements traceability analysis,independent testing and validation, problem identification, risk assessment, and metrics performance.10. Media ControlSoftware configuration management (SCM), i.e. methods and facilities used to maintain, store, secureand document controlled versions of the identified software during all phases of the software life cycle)will be implemented according to the SCMP and the individual 1 OCFR50 Appendix B supplier SCMP(s).All software items, for example documentation, source code, executable code, files, tools, test softwareand data, will be subjected to configuration management procedures. The configuration managementprocedures will establish methods for identifying, storing and changing software items throughdevelopment, integration and transfer.10.1 Media ControlThe media for storing each deliverable work product and the associated documentation will be defined bythe Appendix B suppliers SCMP(s). The 10CFR50 Appendix B supplier SCMP(s) will define requirementsfor code control and have a disaster recovery plan. The 1OCFR 50 Appendix B supplier SCMP(s) willdelineate the standards and procedures that will conform with the applicable security policies to ensurethe system design products (hardware and software) do not contain dead code, undocumented code(e.g., back door coding), malicious code (e.g., intrusions, viruses, worms, Trojan horses, or bomb codes),and other unwanted or undocumented functions or applications.11. Supplier ControlSupplier control will be maintained by PG&E performing reviews, inspections, and audits. All projectdocuments developed by the suppliers will undergo PG&E review prior to final approval. Inspections canbe performed to monitor the execution of any testing. PG&E I&C Project(s) Engineering will perform areview and approve the 1 OCFR50 Appendix B suppliers SQAP(s).Tools and support software for system software or programmable logic will be confirmed to have beenimplemented in accordance with an appropriate Quality Assurance program for the whole life cycle of thesoftware, e.g., an approved 10 CFR Part 50 Appendix B program. The system software or programmablelogic should be evaluated to determine that it is adequate in terms of both the documentation andavailable supplier support during the Operation and Maintenance lifecycle phases.12. Records Collection, Maintenance and RetentionThe project manager is responsible for ensuring all documentation and records will be maintained inaccordance with AD10.01D [2.1.3.6]. This includes, as a minimum the following:* All final approved documents listed in Section 4 of this SyQAP.* All formal Review and Comment Resolution Sheets.* All Audits will be stored per lAW applicable QV requirements.* Problem Reports and Log.
PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 32 of 42" All written Project Correspondence (Incoming and Outgoing)* All final approved Supplier Documentation* Issued Purchase Orders and any subsequent Change Orders* Records of performance of any TrainingAll software documentation, formal correspondence, or other documents required by this plan will bearchived in the following location:NPG Library/Engineering/Strategic Projects/Project Management/ICOM/Current ApprovedProjects/RPS -Eagle 2113. TrainingThe PG&E PPS Project Engineering Team will conduct Project Specific Training for PG&E PPS ProjectEngineering team members on Project administration to include (but not be limited to):* Project formal correspondence (Incoming and Outgoing)" Software control (including version control)* LAN Access and File Storage location* Project Administration -Project Problem Reporting* Selected PG&E Procedures (AD10.ID1 [2.1.3.6], CF2.1D9 [2.1.3.3], etc.)* Other Training to be determined by I&C Project(s) Engineering as required.The PG&E PM will ensure that all team members have been trained on the elements of this SyQAP asoutlined above. The training will be documented on Form 69-20164, Work Group Specific Training.The 1OCFR50 Appendix B suppliers will ensure the following:* The personnel assigned will be qualified in accordance with appropriate codes and standards.* The overall management of training is the responsibility of the Project Manager. Training can beconsidered as a means to reduce risk levels due to the technical experience and skills of the humanresources for the project. If a risk factor due to training or skill deficiency is actually identified, thisshould be documented.* The Project Manager will verify that training needs have been properly assessed and documented,and monitor the implementation of training plans.14. Risk ManagementRisk Management requires specification of the methods used to identify and manage risks associatedwith the V&V process.Risk management includes identification of risk factors that may cause the V&V task to fail to perform itsfunctions, and methods to recover from any such failure. These plans may range from doing nothing (i.e.live with the risk) to redesign. Redesign options can include eliminating the software feature ifacceptable.
PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 33 of 42The plan should provide procedures for evaluating the risks associated with each project developmentactivity. Risk evaluation will be documented as a V&V activity report. The V&V engineer will brief theProject Manager of project management (cost and schedule) risks. The V&V engineer will, also brief theProject Manager of the software safety risks.Risk is defined as the probability of an adverse event or outcome multiplied by the cost or impact of itsoccurrence. Risk evaluation can therefore be done using probabilistic or risk-informed methods, such asare recommended in RG 1.174 [2.1.1.14].However, estimates of software reliability are considered questionable, and the use of quantitativereliability goals for computer-based safety systems is predicated on deterministic criteria for the computersystem in its entirety (i.e., hardware, system software, firmware, application, and interconnections).The V&V engineer for each of the 1 OCFR50 Appendix B suppliers should publish a list of the open itemsbelieved to pose the greatest project and/or safety risks; in order that they are kept visible for projectmanagement until a satisfactory risk mitigation strategy is devised. It is expected that these open itemswill be worked aggressively by the design and V&V organizations.15. Glossary15.1 DefinitionsAcceptance Official recognition that a product (usually hardware or software CI) meetscontractual and project requirements.Acceptance Test A Formal test conducted in an operational environment to determine whetheror not the system satisfies its acceptance criteria and to enable the customerto determine whether or not to accept the system.Accuracy The degree of freedom from error of sensor and operator input, the degree ofexactness exhibited by an approximation or measurement, and the degree offreedom from error of actuator output.Anomaly Any condition that deviates from the expected based on requirements,specifications, design, documents, user documents, standards, etc.Application Software Software designed to fulfill specific needs of a user; for example, software fornavigation, or process control.Approval Official recognition of product validity.ArchitectureThe organizational structure of a system or component.
BaselineBaseline LoadBuildPPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 34 of 42* A specification or product that has been formally reviewed and agreedupon, and thereafter serves as the basis for further development. It ischanged only through formal change- control procedures" A complete and documented set of design requirements and systemcomponents (hardware and software) placed under configuration controlthat identifies the applicable version/revision level of each of theserequirement documents and system components." Work products (e.g., document and/or software) that have been officiallyapproved or accepted and used to judge the acceptability of a system,Subsystem, or CI. (A baseline is subject to configuration control and isupdated to reflect approved changes to the Cl throughout its life cycle.)For software, a complete software package stored in a designated locationthat is capable of running on its own from a system reboot. A load will haveall software code, all local area network (LAN) code, all human machineinterfaces (HMI) code, and any databases required for software functionality.Intermediate version of a system or Cl that provides a demonstrable subsetof capabilities needed to meet requirements allocated to the system or Cl.Those attributes of the planning documents, implementation processdocuments and design outputs that provide full implementation of thefunctions required of the software. The functions that the software is requiredto perform are derived from the general functional requirements of the safetysystem and the assignment of functional requirements to the software in theoverall system design.The degree to which a design output is free from faults in its Specification,design, and implementation. There is considerable overlap betweencorrectness properties and properties of other characteristics such asaccuracy and completeness.Encompasses those activities that are necessary to produce the basic designand functional requirements for the project or system. The conceptual phaseidentifies the idea or need for a software application including feasibilitystudies. It establishes the scope, basic design criteria, required effort, cost,functionality, and classification of the software.Form, fit, and functions of a system or Cl as defined in baselinedocumentation.In the context of an audit for delivery of a product, a configuration auditincludes both a functional configuration audit and a physical configurationaudit.CompletenessCorrectnessConcept PhaseConfigurationConfiguration Audit Configuration Item (CI)ConfigurationManagementCorrective ActionCritical CharacteristicsCriticalityPPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 35 of 42* An aggregation of hardware, software, or both, that is designated forconfiguration management and treated as a single entity in theconfiguration management process. The collection of Cis shouldencompass all data, code, drawings, and other information that is usedto configure, maintain, or define the operation or configuration of thedesignated equipment and the project application." Developed or purchased item, controlled, accepted, and maintainedseparately from other items. (A CI can be composed of hardware orsoftware or, for major Cis, an aggregation of both.)A discipline that involves identifying, controlling, and tracking theconfiguration of a system or product.Corrective action is taken to eliminate the causes of an existingnonconformity, defect, or other undesirable situation in order to preventrecurrence.Those important design, material, and performance characteristics of acommercial grade item that, once verified, will provide reasonable assurancethat the item will perform its intended critical non-safety function.A subjective description of the intended use and application of the system.Software criticality properties may include safety, security, complexity,reliability, performance, or other characteristics.A structured evaluation of the software characteristics (e.g., safety, security,complexity, performance) for severity of impact of system failure, systemdegradation, or failure to meet software requirements or system objectives.* Software code that is not required or specified by the software designdocuments (SRS and SDD) that has the potential to adversely impact asafety significant function. Examples of software that would beconsidered Dead Code:" Test functions that were not specified in the SRS or SDD; and ifactivated, the test function could adversely impact a safety significantfunction." Programs that have been installed (possibly for future use) and thendisabled; and if enabled, this software code could have an adverseimpact on a safety significant function.* Any code that is not intended to be challenged or tested during the V&Vprocess.Examples of software that would not be considered Dead Code:* A tag-name inserted into the code for monitoring purposes only.* The insertion of non-executable comments or notes.* The use of a validated function or function block that may or may notexecute internal code based on input conditions.Criticality AnalysisDead Code DeliverableDesign PhaseDesign StepFactory AcceptanceTesting (FAT)AdministratorFault ToleranceFirmwareFunctional RequirementFunctional TestingFunctionalityHardwarePPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 36 of 42'A work product or service given to the client for review and acceptance. Itfrequently has contractual implications.Encompasses those activities that are necessary to produce the SoftwareDesign Description for the project or system. The primary activity is encodingthe application information and function definitions of the SoftwareRequirements Specification into function diagrams. Design Descriptions arethe translation of the Requirements Specification into the design anddevelopment of the software.A defined activity of the design process.Final customer-witnessed or customer-performed testing at supplier's sitewhich demonstrates that the designed system meets the purchaser'sfunctional and performance requirements and/or industry and regulatoryrequirements.Individual responsible for controlling the test process and performing otherduties as set forth in this plan.The quality of fault tolerance that is achieved when a system has the ability tocomplete critical functions within its required performance characteristics inspite of power or equipment failures and software faults.Computer programs and data loaded in a class of memory that cannot bedynamically modified by the computer during processing, e.g., EPROM.Requirement on the I&C system from point of view of the process function.The functional requirements usually are given in the form of writtendescriptions (customer functional specifications) and information flowdiagrams.Tests whether the functions of the I&C system fulfill the softwarerequirements. In the case of safety-related I&C equipment these tests areperformed by simulating the measurement signals that prevail during normalor accident conditions in order to check that protective actions are initiatedcorrectly.The operations, which must be carried out by the software. Functionsgenerally transform input information into output information. Inputs may beobtained from sensors, operators, other equipment, or other software.Outputs may be directed to actuators, operators, other equipment, or othersoftware.Physical equipment (components) that typically provide a specific functionand is assembled with other equipment to create a system; certaincomponents host the various types of Software or Firmware Hazards AnalysisI&C FunctionIdentity CheckImplementation PhaseIndependencePPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 37 of 42A systematic qualitative or quantitative evaluation of software for undesirableoutcomes resulting from the development or operation of a system. Theseoutcomes may include injury, illness, death, mission failure, economic loss,property loss, environmental loss, or adverse social impact. This evaluationmay include screening or analysis methods to categorize, eliminate, reduce,or mitigate hazards.The formal specification of the functional behavior of the I&C equipment, asderived from the functional requirements. I&C functions are specified anddescribed in the SRS, as information flow diagrams and data tables, and formthe basis for automatic software generation in application software.development.A check of software to confirm the correct version is loaded. This comprisesprimarily of a comparison of specific checksums.Encompasses those activities that are necessary to generate the code fromthe completed function diagrams or source code and load it onto theprocessors. This includes documenting the steps and matching specificchecksums for identity checking.Organization whose personnel maintain independence from a Technical,Managerial, and Financial perspective:* Technical Independence is defined as personnel who are not involved inthe development of the software.* Managerial Independence is defined as an organization separate fromthe development and program management organizations. Managerialindependence also means that the independent organization selects thesegments of the software and the system to analyze and test, choosetechniques, defines testing schedule, and selects the specific technicalissues and problems to act upon. The independent organization effortmust be allowed to submit to program management the testing results,anomalies, and findings without restrictions or adverse pressure, director indirect, from the development group.* Financial Independence is defined as an organization that is financiallyindependent from the development organization. This independenceprevents situations where independent activities cannot be completedbecause funds have been diverted or adverse financial pressures orinfluences have been exerted by the development organization.A detailed line by line technical verification of a document by a competentindividual other than the preparer. The independence and technicalcompetence of the reviewer is certified by the cognizant technical manager.This is performed by the design group personnel, is not part of the softwareverification and validation process, and may also be referred to asIndependent Review.Evaluation technique in which intermediate development products areexamined in detail by a person or group other than the author to detecttechnical deficiencies or violations of standards.Independent DesignReviewInspection Integration TestingIntegrity LevelInterfaceInterface ControlPPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 38' of 42An orderly progression of testing in which software elements, hardwareelements or both are combined and tested until the entire system has beenintegrated. The final set of testing, completed successfully, before the FATwhich demonstrates that the system (integrated hardware and software) isready for FAT.The assigned integer value from 0 to 4 that indicates the degree ofverification and validation that is applied to the system during thedevelopment life cycle, subsequent to an evaluation of a combination of thecriticality of the system function to the owner's mission, and the importanceand likelihood of a system failure. For larger systems, this level may beapplied to specific subsystems or sub-modules.A shared boundary across which information is passed.A Hardware or Software component that connects two or more othercomponents for passing information from one to the other.* Identification of all functional and physical characteristics relevant to theinterfacing of two or more Configuration Items provided by one or moreorganizations* Ensuring that proposed changes to these characteristics are evaluatedand approved prior to implementation.Lessons learned are guidance that enhance the practitioner's understandingof a process, clarify a process' applicability to a particular application, provideguidance for special cases, highlight issues, or convey supplier advice. Thelessons learned come from a variety of sources including, but not limited to,operation experience, experiences in the use of tools and techniques, andpublished best practices from other organizations.For the purposes of this SyQAP the term Locked Down is referring tosoftware that is completed and ready for V&V testing. Any additionalchanges to software that has been Locked Down requires a formal changeprocess lAW CF21D9 form 8.5.Software code that is intended to breakdown or bypass security barriers; orsoftware code that is intended to adversely impact proper systemperformance or function.An expression of possibility, a permissive choice to act or not, asdistinguished from shall, which is a requirement or action that must beperformed.A measure is any quantitative group. Examples of measures are estimatedcost, actual cost, ratio of actual to estimated cost, number of defects, defectdensity, mean time between failures, average length of support call, andnumber of peer reviews performed.Lessons LearnedLocked DownMalicious SoftwareMayMeasureMeasurement DataData made up of value instances of measures.
Open ItemPeer ReviewPreventive ActionProcess AuditProduct ReviewProject ManagerQualityPPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 39 of 42A notation of a characteristic, datum, detail, etc. which constitutes an error ordiscrepancy, or deviation, from the required status or condition of a properlycompleted project. Open Items are each given a record in a database with aunique (to the project) identifier and maintained by the project manager orproject engineer. The entry contains information to track the cycle of the itemfrom discovery of the item until final resolution.An examination of a product by the creators' peers to identify defects andareas where changes are needed. It uses the capabilities of independentreviewers, individually or in a group, to identify the improvements needed in aproduct and to agree on which improvements should be made.Preventive action is action taken to eliminate the causes of a potentialnonconformity, defect, or other undesirable situation in order to preventoccurrence.Process Audit determines whether planned activities are being performed,designated products are being developed, and specified standards andprocedures are being followed. At an intermediate point in each life cyclephase, Quality Management conducts a Process Audit and reports findings toproject management.An examination of a product to identify errors before the product is formallypassed forward in the development process.Individual responsible to coordinate all aspects of the assigned project(s).Primary customer interface responsible for coordinating implementation of theproject, quality control, customer invoicing and tracking project performanceagainst as- sold estimates.Degree to which a system or CI satisfies its requirements.Quality ManagementRegression analysis andtestingReleaseReliabilityConsists of the management responsibilities and actions that determine andimplement quality policies. It includes obtaining the commitment of theorganization, marshaling resources, and ensuring that quality managementprocesses are used and supported effectively.Determine the extent of V&V analyses and tests that must be repeated whenchanges are made to any previously examined software products. Assessthe nature of the change to determine potential ripple or side effects andimpacts on other aspects of the system. Rerun test cases based onchanges, error corrections, and impact assessment, to detect errors spawnedby software modifications.A build that will be delivered to the customer. A release may include anintegrated set of builds.The degree to, which a software system or component operates withoutfailure. This definition does not consider the consequences of failure, onlythe existence of failure.
PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 40 of 42Requirements PhaseRequirementsTraceabilityRequirementsTraceability Matrix(RTM)ReviewSafetySecurityShallEncompasses those activities that are necessary to produce the SoftwareRequirements Specification (SRS) for the project or system. These are theprimary software design activities wherein customer requirements areidentified and described, and documented in a manner necessary for thespecification of function diagrams. The Requirements Specification is thebuilding block for the development, procurement, and maintenance ofsoftware and data. As such it is important the Requirements Specification iscreated considering all the requirements for the software/data.The process of verifying that each specified requirement for a system hasbeen implemented into the design, that all aspects of the design have theirbases in the specification requirements (forwards and backwards traceability,respectively), and that testing produces results compatible with the specifiedrequirements. The completed steps of the verification process are typicallyrecorded in a Requirements Traceability Matrix (RTM). This usually takes theform of a table that lists requirements and the corresponding sections ofdocuments that indicate how the particular requirement is satisfied.A Requirements Matrix provides a method that can be used to trace anddocument that requirements have been met. It provides a complete view ofrequirements to be tested, and traces specific requirements through allphases of development to verify that the requirement was met. Additionally,the RTM formally documents the process and provides documented evidencethat can be useful in auditing that safety requirements and licensingcommitments were met.An expert analysis and evaluation of the results of a task, a step, or a phase.It is implemented either globally, or in detail on random samples (e.g., in thecase of code inspection).Those properties and characteristics of the software system that directlyaffect or interact with system safety considerations. The safety characteristicis primarily concerned with the effect of the software on system hazards andthe measures taken to control those hazards.The ability to prevent unauthorized, undesired, and unsafe intrusions.Security is a safety concern insofar as such intrusions can affect the safety-related functions of the software."Shall" denotes a requirement or action that must be performed."Should" denotes a requirement or action that would be beneficial toSUPPLIER or OWNER but is not mandatory within the PPS scope of work.The programs, procedures and any associated documentation pertaining tothe operation of a data processing or computing system. Software is anintellectual creation, independent of the medium on which it is stored.Software includes firmware and logic developed from software baseddevelopments systems.ShouldSoftware Software ComponentSoftware LifecycleSoftware RequirementsSoftware ToolSurveillanceSystemPPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 41 of 42Software components are a constituent element of a software system. Forapplication software, this usually means the modules, sub-modules, or I&Cfunctions as described in the SRS. A specific collection of SoftwareComponents is assembled to form a System Component.The period of time that starts when a software product is conceived and endswhen the software product is no longer available for routine use. Includes thefollowing phases: preliminary engineering (conceptual), requirements,detailed design, implementation, integration, testing, installation andcheckout, operations & maintenance, and sometimes a retirement phase.Software requirements are those that must be met by the software to satisfy acontract, standard, specification, procedure, or user need. The set of allsoftware requirements form the basis for subsequent development of thesoftware. Requirements include, but are not limited to: identification ofneeded software functions, the inputs, processes, and outputs required foreach function, the design constraints and attributes of the software,performance requirements, interface requirements, and developmentstandards. Each requirement is defined such that its achievement can beverified and validated objectively.A computer program used in the development, testing, analysis, ormaintenance of a program or its documentation. Examples includecomparator, cross-reference generator, decompiler, driver, editor,flowcharter, monitor, test case generator, and timing analyzer.A formal review of a process implementation against a documented standardor process. Surveillance is a planned activity that focuses on a project or afunctional area.The hardware and software required for solving a complex task. It consists ofseveral subsystems or components which have different performancecharacteristics but which are suitable for use together to accomplish therequired functions.System components are the equivalent of a subsystem. that can be usedseparately and performs a self-contained function. They consist of one ormore modules, which are suitable for use together in an overall system. Inthe documentation, emphasis is placed on functionality, communicationrelationships, sequences, inputs/outputs and common resources.System tests are used to determine whether the specified systemcharacteristics of equipment (behavior on failure, behavior on start-up,testability, etc.) have been implemented. These types of test are performedwithout regard to the specific I&C function.The repeat of a V&V task which occurs as a result of identification of ananomaly, its resolution, and the verification by the V&V team that theresolution is complete.System ComponentSystem TestTask Iteration PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 42 of 42Test Sequence of events designed to verify that a system or CI satisfiesrequirements or to identify differences between expected and actual results.Test Phase Encompasses those activities that are necessary during the applicationsoftware production process to assemble and integrate the complete system,and to perform required testing. These are the primary software designactivities wherein system performance is checked and documented to ensurethe required functions are correctly and completely implemented.Timing The ability of the software system to achieve its timing objectives within thehardware constraints imposed by the computing system being used.Traceability The degree to which each element of one life cycle product can be tracedforward to one or more elements of a successor life cycle product, and canbe traced backwards to one or more elements of a predecessor life cycleproduct. Traceability is central to the production of complex systems toensure all requirements are implemented, checked and tested.Unit Smallest replaceable element in a Cl also referred to as a configuration unit(CU). For software, a unit is typically a subroutine; for hardware, a unit maybe a board that is fabricated as a separate item.Validation The evaluation of a product at the end of the development process to ensurethe product complies with previously specified software requirements. Thisprocess is usually performed by testing. Validation involves evaluating theoverall system and software behavior under conditions representative of itsintended use.Verification The process of determining whether or not the products of a givendevelopment phase fulfill the requirements imposed at the start of the phase.Verification includes detailed review and testing at each phase anddetermines whether the project is ready to proceed to the next phase.Verification and The systematic program of review and testing activities performed throughValidation the software lifecycle to ensure that the software satisfies its intended useand user needs. V&V activities are performed by persons who are differentand independent from those who accomplish the design and integration.Verifiability The degree to, which a software planning document, implementation processdocument or design output is stated or provided in such a way as to facilitatethe establishment of verification criteria and the performance of analyses,reviews, or tests to determine whether those criteria have been met.Will "Will" means that an action or activity can be assumed to be completed bythe subject of the sentence whether the subject is SUPPLIER, OWNER orothers.16. SyQAP Change Procedure and HistoryThis section is not applicable. Page two contains a Revision History Page per PG&E procedures.}}

Revision as of 10:14, 14 June 2018

Attachment 4: Rev. 0 to Diablo Canyon Power Plant Units 1 & 2, Process Protection System (PPS) Replacement System Quality Assurance Plan (Syqap) Nuclear Safety Related.
ML15099A063
Person / Time
Site: Diablo Canyon  Pacific Gas & Electric icon.png
Issue date: 10/26/2011
From:
Altran Solutions Corp, Pacific Gas & Electric Co
To:
Office of Nuclear Reactor Regulation
Shared Package
ML113070457 List:
References
DCL-11-104
Download: ML15099A063 (44)
v • d • e


Text

EnclosureAttachment 4PG&E Letter DCL-1 1-104Diablo Canyon Power Plant Process Protection System (PPS) ReplacementSystem Quality Assurance Plan (SyQAP), Revision 0(LAR Reference 52)

IPacific Gas ectric CompanyDiablo Canyon ower PantProcess Protection System (PPS) ReplacementSystem Quality Assurance Plan (SyQAP)Nuclear Safety RelatedRev 0C11M IQDIIPrepare" Print Last NamIReviewed SioPrint Last NameCoord SigtOrg.Print Last NameApproval Si9Print Last Narne1~4Of~~4~DateUser IDDateUsor IDDateUsaleUser IDjoil, lei__JE~ £~ L UT I L~

PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 1 of 42REVISION HISTORYRevision Affected Reason for RevisionNumber Pages0 All Initial IssueI. I.

PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 2 of 42Table of Contents1. PURPO SE .......................................................................................................................................... 41 .1 O V E R V IE W ......................................................................................................................................... 41.2 APPLICABILITY .................................................................................................................................. 41 .3 S C O P E ............................................................................................................................................. 52. REFERENCE DO C UM ENTS ..................................................................................................... 52.1 DEVELOPMENTAL REFERENCES AND STANDARDS ........................................................................... 53. M A NAG EM ENT ................................................................................................................................. 93.1 O RGANIZATION ................................................................................................................................. 93.2 1 OCFR50 APPENDIX B SUPPLIER TASKS ..................................................................................... 103.3 PG &E TASKS ................................................................................................................................. 153.4 PG &E ROLES & RESPONSIBILITIES ................................................................................................ 183.5 1 OCFR50 APPENDIX B SUPPLIER ROLES & RESPONSIBILITIES ...................................................... 194. DO CUM ENTATIO N ......................................................................................................................... 214.1 OVERVIEW OF PG &E DOCUMENTS ............................................................................................... 214.2 OVERVIEW OF 1 OCFR50 APPENDIX B SUPPLIER DOCUMENTS ...................................................... 224.3 1 OCFR50 APPENDIX B SUPPLIER SOFTWARE TEST DOCUMENTATION .............................................. 254.4 OTHER DOCUMENTATION ............................................................................................................. 265. STANDARDS, PRACTICES, CONVENTIONS, AND METRICS ................................................ 265.1 DOCUMENTATION STANDARDS ......................................................................................................... 275.2 LOGIC STRUCTURE (DESIGN) STANDARDS ..................................................................................... 275.3 TESTING STANDARDS AND PRACTICES .......................................................................................... 275.4 SELECTED SQA PRODUCT AND PROCESS M ETRICS ..................................................................... 276. SO FTW A RE REVIEW S A ND A UDITS ....................................................................................... 276.1 SOFTW ARE REQUIREMENTS REVIEW (SRR) ................................................................................. 286.2 ARCHITECTURAL DESIGN REVIEW (ADR) ..................................................................................... 286.3 DETAILED DESIGN REVIEW (DDR) .............................................................................................. 286.4 SOFTWARE VERIFICATION AND VALIDATION PLAN REVIEW (SW PR) ............................................ 286.5 FUNCTIONAL AUDIT ......................................................................................................................... 286.6 PHYSICAL AUDIT ............................................................................................................................. 286.7 IN-PROCESS AUDITS ........................................................................................................................ 286.8 M ANAGERIAL REVIEW S .................................................................................................................... 296.9 SOFTWARE CONFIGURATION MANAGEMENT PLAN REVIEW (SCMPR) ............................................... 296.10 POST IMPLEMENTATION REVIEW ............................................................................................... 296.11 USER DOCUMENTATION REVIEW .............................................................................................. 296.12 SOFTW ARE SAFETY REVIEW S ................................................................................................... 296.13 CONFIGURATION M ANAGEMENT REVIEW S .................................................................................. 297. TEST .......... ....................................................................................................................................... 298. PROBLEM REPORTING AND CORRECTIVE ACTION ........................................................... 298.1 ANOMALY RESOLUTION AND REPORTING ....................................................................................... 308.2 TASK ITERATION POLICY ................................................................................................................... 309. TO O LS, TECHNIQ UES, A ND M ETHO DO LO G IES .................................................................... 30 PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 3 of 4210. M EDIA C O NTRO L ........................................................................................................................... 3110.1 M EDIA C ONTROL ......................................................................................................................... 3111. SU PPLIER C O NTRO L ..................................................................................................................... 3112. RECORDS COLLECTION, MAINTENANCE AND RETENTION .............................................. 3113. TRA IN ING .... ..................................................................................................................................... 3214. RIS K M A NA G EM ENT ....................................................................................................................... 3215. G LO SSA RY ..................................................................................................................................... 3315.1 DEFINITIONS ............................................................................................................................... 3316. SYQAP CHANGE PROCEDURE AND HISTORY ...................................................................... 42 PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 4 of 421. Purpose1.1 OverviewThe purpose of this System Quality Assurance Plan (SyQAP) is to establish the goals, processes, andresponsibilities required to implement effective software quality management for the Process ProtectionSet (PPS) system software at Diablo Canyon Power Plant (DCPP), ensure any required softwarefunctions perform correctly, and that the required software functions conform to established technicalrequirements, conventions, rules, and standards. To achieve this goal, software development willproceed in a traceable, planned, and orderly manner. Throughout this document, the term software isused when referring to firmware and logic developed from software based developments systems. Theobjective of this plan is to:* Define the software quality assurance activities to be performed during the lifecycle of the software;" Describe the responsibilities and authorities for accomplishing the planned software quality assuranceactivities;* Identify the required coordination of software quality assurance activities with other activities of theproject;* Identify the tools and the physical and human resources required for the execution of the plan;* Ensure the software solutions necessary to implement the functional requirements, technicalconstraints, system development, configuration control, security, and software maintenance areaccomplished in accordance with the approved methodology, supporting standards, and procedures;* Ensure the products and services produced conform to applicable project requirements;* Detect and eliminate design errors early in the software lifecycle; and* Enhance the quality and reliability of PPS application software.1.2 ApplicabilityPG&E procedure IDAP AD7.1D8 [2.1.3.1], Project Management which includes the Project ManagementPolicies and Procedures, is the primary document describing the management processes and strategiesfor managing projects at Diablo Canyon Power Plant (DCPP). The Project Management Manual directsthe overall project planning function and defines the organization, resources, and methodology formeeting project requirements. IDAP AD7.1D8 establishes measures for assuring that organizationsperforming activities affecting quality perform their responsibilities in a manner which results in safenuclear power production. This SyQAP utilizes PG&E procedure IDAP CF2.1D9 [2.1.3.3], SoftwareQuality Assurance Plan Development for software to be used in the PPS. The IDAP AD7.1D8 proceduredescribes the DCPP Quality program, policies, and procedures. The management approach, policies,and procedures described in this plan are derived from policies, procedures, codes and standards, andregulations applicable to the nuclear industry.This plan applies specifically to the PPS at the Diablo Canyon Power Plant site. This software is NuclearSafety-Related software requiring safety-related quality controls to meet SIL 4, as defined in IEEE 1012-1998 [2.1.2.24].The plan covers the development lifecycle for SIL4 application software: requirements definition, detaileddesign, implementation, test, installation and checkout, operation, and maintenance. This software will beprovided by two third-party suppliers who each have an approved 1 OCFR50 Appendix B QualityAssurance program [2.1.1.1]. This plan will umbrella the supplier's system development process. At aminimum the supplier's scope of supply will extend to the end of Factory Acceptance Testing (FAT). In PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 5 of 42cases beyond the scope of the supplier, further work on the application software will be normallyperformed under the PG&E system quality assurance program.This procedure is valid as of the date of final issue indicated on the title page. This procedure should bereviewed prior to making any changes to the PPS software.1.3 ScopeThis SyQAP applies to all software development and software maintenance activities, including thosetasks performed by contractors and subcontractors. This SyQAP also applies to all applicable softwarelifecycle phases for the PPS not already covered under the suppliers' 1OCFR50 Appendix B programs.This plan is intended for use by all project personnel to understand and perform the quality activitiesapplicable to their responsibilities. Software Quality Assurance requires the project to identify qualityactivities forits currently planned work phase and related releases.Software Quality Assurance for the project is planned along with other project tasks and initiatives.Implementation of and compliance with this SyQAP is the shared responsibility of all project personnel.Both project management and technical staff are thus integrated with and committed to the success ofoverall Software Quality Assurance.The degree of rigor and effort is defined by the Software Integrity Level (SIL) and SoftwareCategorization. Software SIL is defined in IEEE Std. 1012-1998 [2.1.2.24]. Nuclear Regulatory Guide1.168, Verification, Validation, Reviews, and Audits for Digital Computer Software Used in SafetySystems of Nuclear Power Plants [2.1.1.8], provides additional guidance that indicates that nuclearsafety-related software should be assigned a SIL 4 rating.In general, the SyQAP will place special emphasis on the software portion of the project. In addition theSyQAP will monitor, audit, and report on activities related to software safety to ensure no new safetyhazards are introduced by the development process and on those activities related to configurationmanagement. It will also provide traceability to verify that contractual requirements such as hardwarerequirements, the provision of specific system features, and other deliverables not directly related to theapplication software have been met. After successful completion of the Software Quality Assuranceactivities in this plan, the application software will meet the SIL-rating requirements for the software.2. Reference Documents2.1 Developmental References and Standards2.1.1 U.S. Regulatory Guidance2.1.1.1 Title 10 CFR, Part 50, Appendix B, "Quality Assurance Criteria for Nuclear Power, Plants andFuel Reprocessing Plants"2.1.1.2 NUREG-0800 BTP 7-14, Branch Technical Position: Guidance on Software Reviews forDigital Computer-Based Instrumentation and Control Systems, Revision 5, March 2007.2.1.1.3 NUREG/CR-6101, Software Reliability and Safety in Nuclear Reactor Protection Systems,November 1993.2.1.1.4 NUREG/CR-6430, Software Safety Hazards Analysis, February 1996.2.1.1.5 Regulatory Guide 1.118, Periodic Testing of Electric Power and Protection Systems, Revision3, April 19952.1.1.6 Regulatory Guide 1.152, Criteria for Use of Computers in Safety Systems of Nuclear PowerPlants, Revision 3, July 2011.

PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 6 of 422.1.1.7 Regulatory Guide 1.153, Criteria for Safety Systems, Revision 1, June 19962.1.1.8 Regulatory Guide 1.168, Verification, Validation, Reviews, and Audits for Digital ComputerSoftware Used in Safety Systems of Nuclear Power Plants, Revision 1, February 20042.1.1.9 Regulatory Guide 1.169, Configuration Management Plans for Digital Computer SoftwareUsed in Safety Systems of Nuclear Power Plants, September 19972.1.1.10 Regulatory Guide 1.170, Software Test Documentation for Digital Computer Software Used inSafety Systems of Nuclear Power Plants, September 199721.1.11 Regulatory Guide 1.171, Software Unit Testing for Digital Computer Software Used in SafetySystems of Nuclear Power Plants, September 19972.1.1.12 Regulatory Guide 1.172, Software Requirements Specifications for Digital ComputerSoftware Used in Safety Systems of Nuclear Power Plants, September 19972.1.1.13 Regulatory Guide 1.173, Developing Software Life Cycle Processes-for Digital ComputerSoftware Used in Safety Systems of Nuclear Power Plants, September 19972.1.1.14 Regulatory Guide 1.174, An Approach for Using Probabilistic Risk Assessment in Risk-Informed Decisions on Plant-Specific Changes to the Licensing Basis, Revision 1, November20022.1.1.15 Interim Staff Guide DI&C-ISG-01, Cyber Security, Revision 02.1.1.16 Interim Staff Guide DI&C-ISG-02, Diversity and Defense-in-Depth Issues, Revision 2, June20112.1.1.17 Interim Staff Guide DI&C-ISG-04, Highly Integrated Controls Rooms-Communications Issues(HICRc), Revision 1, March 20092.1.1.18 Interim Staff Guide DI&C-ISG-06, Licensing Process, Revision 1, January 20112.1.2 Industry Codes and Standards2.1.2.1 ANSI/IEEE Std. 983-1986, IEEE Guide for Software Quality Assurance Planning2.1.2.2 ANSIIISO/ASQ Q9001-2000, Quality management systems -Requirements2.1.2.3 ANSI/ISO/ASQ Q9004-1-1994, Quality Management and Quality System Elements -Guidelines2.1.2.4 ASME NQA-1-1994, 1997, Quality Assurance Requirements for Nuclear Facility Applications2.1.2.5 EPRI TR-103291, Handbook of Verification and Validation for Digital Systems, Revision 1,December 19982.1.2.6 NEI 08-09, Revision 6, Cyber Security Plan for Nuclear Reactors2.1.2.7 IEEE Std. 7-4.3.2-2003 IEEE Standard Criteria for Digital Computers in Safety Systems ofNuclear Power Generating Stations, Appendix D (Informative) Identification and Resolution ofHazards2.1.2.8 IEEE Std. 279-1971, Criteria for Protection Systems for Nuclear Power Generating Stations2.1.2.9 IEEE Std. 308-1971, Criteria for Class 1E Electric Systems for Nuclear Power GeneratingStations PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 7 of 422.1.2.10 IEEE Std. 323-1974, IEEE Standard for Qualifying Class 1E Equipment for Nuclear PowerGenerating Stations2.1.2.11 IEEE Std. 338-1987, IEEE Standard Criteria for the Periodic Testing of Nuclear PowerGenerating Station Protection Systems2.1.2.12 IEEE Std. 344-1987, Recommended Practices for Seismic Qualification of Class 1 EEquipment for Nuclear Power Generating Stations2.1.2.13 IEEE Std. 379-1977, IEEE Application of Single Failure Criterion to Nuclear PowerGenerating Station Class 1 E Systems2.1.2.14 IEEE Std. 384-1981, IEEE Trial-Use Standard Criteria for Separation of Class 1E Equipmentand Circuits2.1.2.15 IEEE Std. 352-1987, IEEE Guide for General Principles of Reliability Analysis of NuclearPower Generating Station Safety Systems2.1.2.16 IEEE Std. 497-2002, IEEE Standard Criteria for Accident Monitoring Instrumentation forNuclear Power Generating Stations2.1.2.17 IEEE Std. 577-1976, IEEE Standard Requirements for Reliability Analysis in the Design andOperation of Safety Systems for Nuclear Power Generating Stations2.1.2.18 IEEE Std. 603-1991, IEEE Standard Criteria for Safety Systems for Nuclear PowerGenerating Stations2.1.2.19 IEEE Std. 730-2002, Standard for Software Quality Assurance Plans2.1.2.20 IEEE Std. 828-1998, Software Configuration Management Plans2.1.2.21 IEEE Std. 829-1983, Standard for Software Test Documentation2.1.2.22 IEEE Std. 830-1993, Recommended Practice for Software Requirements Specifications2.1.2.23 IEEE Std. 1008-1987, IEEE Standard for Software Unit Testing2.1.2.24 IEEE Std. 1012-1998, Standard for Software Verification and Validation2.1.2.25 IEEE Std. 1016-1997, Recommended Practice for Software Design Descriptions2.1.2.26 IEEE Std. 1028-1997 (reaffirmed 2002), Standard for Software Reviews2.1.2.27 IEEE Std. 1042-1987, ANSI/IEEE Standard Guide to Software Configuration Management2.1.2.28 IEEE Std. 1044-1997, IEEE Standard for Classification of Software Anomalies2.1.2.29 IEEE Std. 1058.1-1991, IEEE Standard for Software Project Management Plans2.1.2.30 IEEE Std. 1058-1998, IEEE Standard for Software Project Management Plans2.1.2.31 IEEE Std. 1061-1998, IEEE Standard for a Software Quality Metrics Methodology2.1.2.32 IEEE Std. 1063-1987, Standard for Software User Documentation2.1.2.33 IEEE Std. 1074-1995, IEEE Standard for Developing Software Life Cycle Processes2.1.2.34 IEEE Std. 1219-1998, Standard for Software Maintenance2.1.2.35 IEEE Std. 1228-1994, IEEE Standard for Software Safety Plans2.1.2.36 IEEE Std. 1233-1998, Guide for Developing System Requirements Specifications2.1.2.37 IEEE Std. 1471-2000. Systems and Software Engineering -Recommended Practice forArchitectural Description of Software-Intensive Systems PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 8 of 422.1.3 DCPP References and Procedures:2.1.3.1 PG&E Procedure, IDAP AD7.1D8, Project Management2.1.3.2 PG&E Procedure, IDAP CF3.1D9, Design Change (Package) Development2.1.3.3 PG&E Procedure, IDAP CF2.1D9, Software Quality Assurance Plan Software Development2.1.3.4 PG&E Procedure, IDAP CF2.1D2, Software Configuration Management for Computers &Software Used for Plant Operations and Operations Support2.1.3.5 PG&E Form 69-20164, Work Group Specific Training Record2.1.3.6 PG&E Procedure, AD10.ID1, Storage and Control of Quality Assurance RecordsNOTE: The various Appendix B software suppliers and the various regulatory agencies do not use thesame terminology for software and software verification and validation. As mentioned in DI&C-ISG-06Rev. 1 [2.1.1.18], an applicant may have different names for similar documents. Regardless of the titlesof the documents submitted, the actual LAR should contain sufficient information to address the criteriadiscussed in the technical evaluation sections... This procedure does not specify that an approvedsoftware supplier meet this particular terminology, only that the intent of this procedure is followed and ahigh quality software product is generated for plant use.NOTE 2: If any part of the software life, cycle process is contracted to an approved supplier with a1 OCFR50 Appendix B program, their SQA processes apply for their product, with PG&E auditing theirprogram, and owner acceptance by PG&E.

PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 9 of 423. Management3.1OrganizationDifferent organizational units, their responsibilities and relationships with regard to Quality are discussedin this SyQAP. The basic organizational structure that influences software quality is shown in Figure 3-1.Quality Management for each of the 1 OCFR50 Appendix B suppliers will be independent of the projectmanagement organization. The basic tenet of Quality Management is to make all employees responsiblefor the quality of their work. This means quality management is the responsibility not only ofmanagement, but also of all project personnel who perform work for, and provide services and productsfor the project.Figure 3-1 PPS Project OrganizationIt is expected of each 1 OCFR50 Appendix B supplier that the Project Manager is responsible for thedevelopment, integration and testing of the application software. The software development tasks areoriginated and supervised by the Responsible Engineer or directly by the Project Manager (or hisdesignee) who leads the engineering team, and reports to the Design Authority. The PG&E Project Teamdetermines the functional requirements of the software while the 1 OCFR50 Appendix B supplier designsthe application software with the aid of engineering and software development tools.The 1 OCFR50 Appendix B supplier will have different test personnel than those personnel involved in thedesign effort. Test personnel design the test plan and test cases, and perform the software testing. Thisorganizational design is intended to promote objectivity, and improve the process of problem resolutionand verification.The respective 1OCFR50 Appendix B supplier's integration team loads the completed software or logiconto the hardware platform, and performs integration testing, including Factory Acceptance Testing. Thisteam is also staffed with individuals who did not participate in the software design effort.

PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 10 of 42The 1 OCFR50 Appendix B supplier's Nuclear Oversight Department, or equivalent, is responsible for theperformance of the reviews, audit, and inspections of the software supplier. V&V Engineers will performthe activities prescribed in this plan. Additionally, V&V personnel have been tasked with verifying that theproject meets nuclear and functional safety requirements per the Failure Modes and Effects Analysis, andReliability Analysis. V&V personnel also ensure that no new software hazards are introduced throughoutthe software lifecycle. Overall responsibility for project safety is the responsibility of the Project Manager.For this project, the Lead Verification Engineer performs the role of the Software Quality AssuranceManager and Project Safety Officer.3.2 10CFR50 Appendix B Supplier TasksBelow is a sequence of the tasks which describes the general development process PG&E expects the10 CFR50 Appendix B [2.1.1.1] suppliers to follow. The specific development process employed by the10CFR50 Appendix B vendors may vary. PG&E will use this SyQAP as a guide for the owner review andapproval of the outputs of the development process employed by the 10CFR50 Appendix B vendor.The tasks describe a complete program, from the requirements definition phase through the integrationand testing phase of the software life cycle. Reviews and audits will be performed as described inSection 6. Software lifecycles are defined per BTP 7-14 [2.1.1.2] using the guidance in IEEE Std. 1074[2.1.2.33]; Tasks meet the minimum requirements contained in RG 1.168 [2.1.1.8] and IEEE 1012-1998[2.1.2.24]Table 2:3.2.1 Project Initiation and Planning Phase TasksThe 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 is a product of this phase.Tasks performed in this phase include:Verify that system requirements (from Request for Proposal or tender, and contract) are consistent andconform to the current licensing basis;* Verify that procedures are documented for managing requirement changes and for identifying themanagement hierarchy to address problems;* Verify procedures for interface and cooperation among the parties are documented, includingownership, warranty, copyright, and confidentiality; and* Verify that acceptance criteria and procedures are documented in accordance with requirements." Plan the interface between the V&V effort and the supplier.* Review the supplier development plans and schedules to coordinate the V&V effort with developmentactivities.* Establish procedures to exchange V&V data and results with the development effort.* The Project Manager should coordinate the plan with the supplier.* Incorporate the project software integrity level scheme into the planning process.A documented process for managing requirements changes and procedures for handling the interfaceamong the parties signifies the end of this phase. The contract verification report will be used as an inputto the preliminary Requirements Traceability Matrix.

PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 11 of 423.2.2 Conceptual Design Phase TasksThe Conceptual design phase defines the scope of the V&V effort. The initial V&V Plan, SyQAP, andFRS are products of this phase. Tasks performed in this phase are:* Review the draft Functional Requirements Specification (FRS) (Concept Documentation Analysis);* Verify SIL Classification(s), criticality, and software category per IEEE 1012 (Criticality Analysis);* Draft and issue project System V&V Plan (SyWP);" Review the System Quality Assurance Plan (SyQAP);* Provide input to the project master schedule;* Analyze system hazards, security, and risks;* Verify the correctness, accuracy, and completeness of the allocation of the requirements to hardware,software, and user interfaces in the conceptual design;" Baseline the system so that subsequent changes can be assessed to determine new hazards andimpact of project risk;* Develop the preliminary Requirements Traceability Matrix (RTM);* Review other management plans if available. These may include the Software Development Plan,Software Installation Plan, Software Integration Plan, Software Safety Plan, and Software Test Plan.These plans may be developed and reviewed in later phases just before they are needed.The responsibilities of the V&V engineer are to publish the project Software V&V Plan (SWP) and theV&V Summary Report documenting V&V activities and Task Reports for this phase. The draft RTM couldbe developed by the V&V team. At a minimum, the V&V engineer is responsible for ensuring that theRTM possesses the attributes needed to support V&V traceability analysis and associated metrics. TheRTM will also be used to document traceability to contractual requirements such as hardwarerequirements, the confirm implementation of specific system features, and confirm compliance with otherdeliverables not directly related to the application software. In addition, the V&V engineer verifies theRequirements Allocation Analysis against user needs to verify correct, accurate, and complete allocationof requirements to hardware, software, and human operators.An approved Functional Requirements Specification (FRS), Software V&V Plan, and SoftwareConfiguration Management Plan signify the end of the Conceptual Design Phase. A Preliminary FailureModes and Effects Analysis (FMEA) may be started in this phase.3.2.3 Requirements Phase V&V TasksIn this phase, a Software Requirements Specification (SRS) will be prepared by the design team for eachapplicable software product using the guidance of IEEE Std. 830 [2.1.2.22]. The SRS will be developedbased on the functional requirement specification and the system interface requirements specification,each of which must be approved by the customer prior to beginning.The output of this task is the approved Software Requirement Specification (SRS). Tasks performed inthis phase are:* Review the Preliminary FMEA if applicable;* Update the Requirements Traceability Matrix (RTM) completed in the Project Initiation andConceptual Phase. The matrix typically will be in the form of a table. Since it will undergo frequent PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 12 of 42change, it will be stored on safe, but readily retrievable computer storage media. RequirementsManagement planning is contained within the RTM document;* Perform a Software Requirements Traceability Analysis by tracing the requirements between the FRSand the SRS. It is expected that requirements be traceable forward from the FRS to the SRS andbackwards from the SRS to the FRS;* Perform a Software Requirements Evaluation by evaluating that the SRS is correct, consistent,complete, accurate, readable, traceable and testable. The requirements will be checked for testabilityfor purposes of validation testing. This ensures that the SRS adequately defines the softwarerequirements necessary to perform the intended function;* Assess software safety by reviewing that the safety requirements are correctly addressed. Thepurpose of this task is to ensure no new hazards have been introduced, ensure that softwareelements that can affect safety have been identified, and to ensure evidence exists that otherelements do not affect safety;* Perform a Software Requirements Interface Analysis by reviewing that requirements for interfaces tohardware, user, operator, and other software are correct, consistent, complete, accurate, traceableand testable;* Verify that the configuration management process is complete and adequate (ConfigurationManagement Assessment);* Assess if there are any changes required to the Criticality Analysis;" Perform a baseline change assessment to assess any changes to risk or security analyses; Issue theBaseline Review Report (BRR);* Review or develop System V&V test plans;* Coordinate resolutions of discrepancies with project management, design team personnel, andquality management;" Produce the Software Requirements Review (SRR) ReportAn approved Software Requirements Specification (SRS), satisfactory resolution of discrepancies, and anapproved Software Requirements Review (SRR) Report containing the appropriate Task Reports andAnomaly Reports signify the end of the requirements phase. The SRS will be approved by prior toproceeding to the Design Phase.3.2.4 Design Phase V&V TasksIn this phase, the design team will prepare the Software Design Description (SDD) for each applicablesoftware product using the guidance of IEEE Std. 1016 [2.1.2.25]. The SDD will be developed based onthe software requirement specification and the software and hardware architecture. The SDD consists oftwo parts: the software and hardware architectural description and the Software Detailed Design. TheHardware Requirements Specification (HRS), Interface Requirements Specification (IRS) and SoftwareRequirements Specification (SRS) should be approved by the customer prior to beginning the designphase to minimize project risk.The output of this task is the approved SDD. Software Test Plan(s) (STP) will be generated by the designteam to evaluate system performance. A three-pronged approach is used for testing:(1) Component (Software Unit) Testing,(2) Integration Testing, and(3) Factory Acceptance Testing (FAT)

PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 13 of 42Software Test Plans conform to the requirements of IEEE Std. 829 [2.1.2.21] and IEEE Std. 1008[2.1.2.23]. Software Test Plans will be reviewed by V&V. A separate Factory Acceptance Test Plan willbe developed.Tasks performed in this phase are:* Perform a Software Design Traceability Analysis by tracing the requirements between the SRS andthe SDD. It is expected that requirements be traceable forward from the SRS to the SDD andbackwards from the SDD to the SRS. The results are recorded in the updated RTM;" Perform a Software Design Evaluation. The SDD will be evaluated for correctness, consistency,completeness, accuracy, readability, and testability. The design will be evaluated for compliance withestablished standards, practices and conventions. Design quality will be assessed;* Perform a Software Design Interface Analysis by reviewing that the software design interfaces tohardware, user, operator, and other software are correct, consistent, complete, accurate, andtestable;* Assess software safety to ensure no new software hazards have been introduced by the design;* Assess if there are any changes required to the Criticality Analysis;* Perform a baseline change assessment to assess any changes to risk or security analyses; Issue theBaseline Review Report (BRR);* Develop Software Test Plan(s) (Component and Integration) related to software and the FAT Plan toensure system test criteria will show compliance with all functional requirements in a systemenvironment, performance at hardware, software and user interfaces, and performance at boundariesunder stress conditions;" Review Component, Integration, System, and Acceptance Test Designs as applicable." Produce the Software Design Review Report;" Coordinate resolutions of discrepancies with project management, design team personnel, andQuality Management.An approved Software Design Description (SDD), satisfactory resolution of discrepancies, approved TestPlan(s) and Design(s), and an approved Software Design Review Report signify the end of the designphase. These activities are required to be completed prior to proceeding to the Implementation Phase.3.2,5 Implementation Phase V&V (Unit/Component Testing)During this phase the executable code is produced and tested. Depending upon the target system,source code may be developed by the design team/programmers, or automatic code generators mayproduce the executable code. In either case, the functions described in the SRS are developed in thecoding environment to programming standards. The correct implementation of the SRS is validatedduring function tests with the software development and simulation tools, and during testing on thetest/development system. The RTM will generally have no entries for this phase. Also during this phase,software unit testing is performed by the design team.Tasks performed in this phase are:* Observe the building and compiling processes; A source code generation evaluation is performed toverify that the source code compiles without and builds without errors;* Perform a Software Implementation Traceability Analysis to ensure that the correct versions andrevisions of function diagrams were used to assemble the code for each subsystem; PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 14 of 42" Verify that the procedure(s) used for software generation and download were followed and that theproper versions of code generators have been used;" Examine the software for completeness to ensure that only qualified system software componentshave been used and that the software was successfully loaded onto the system;" Review Software Unit Test results;" Produce the Software Implementation Review Report;" Coordinate resolutions of discrepancies with project management, design team personnel, andquality management;Perform a baseline change assessment to assess any changes to risk or security analyses; Issue theBaseline Review Report (BRR);Approved FAT Test Procedures, satisfactory resolution of discrepancies, and an approved SoftwareImplementation Review Report signify the end of the implementation phase and readiness to proceed tothe Integration Phase.3.2.6 Integration Phase V&V TasksIntegration Testing is a separate software Lifecycle activity per NUREG-0800 BTP 7-14 [2.1.1.2] and canbe mapped to IEEE 1012-1998 [2.1.2.24]. s a continuation of the Implementation Phase. The Software isintegrated with the hardware and integration testing is performed in accordance with the test proceduresper IEEE Std. 829 [2.1.2.21]. Integration test execution results are analyzed to determine if the systemimplements the requirements and design and that the software components function correctly together.Tasks performed in this phase are:" Confirm that the software shown in the SDD is loaded into the system processors, and that thecorrect software was loaded onto the system;* Develop Factory Acceptance Test (FAT) procedures and verify each functional requirement is tested;* Review the Final FMEA to ensure that testing of failures where practical is included in testprocedures;" Evaluate the quality of user manuals;" Assess software safety to ensure no new software hazards have been introduced by implementationactivities;" Assess if there are any changes required to the Criticality Analysis;* Perform a baseline change assessment to assess any changes to risk or security analyses; Issue theBaseline Review Report (BRR);* Review Integration test results;* Perform requirements tracing between the FAT procedures and the SDD. The relationships betweenthe V&V test plan(s), software designs, tests, and test procedures are analyzed for correctness andcompleteness;* Assess software safety to ensure no new software hazards have been introduced by the integrationactivities;* Produce a V&V Summary Report for the Integration Phase Activities;* Coordinate resolutions of discrepancies with project management, design team personnel and qualitymanagement.

PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 15 of 42At the conclusion of the Integration Phase, the System Integration Review Report will confirm that theconfiguration of the system is complete and ready for FAT testing, and that there are no unresolveddiscrepancies or safety problems. Requirements tracing from the SDD to FAT test procedures should becompleted in this phase to reduce the risk of an incomplete FAT test.3.2.7 Test Phase V&V TasksSystem tests are performed in accordance with the FAT test procedures. Tests are analyzed todetermine if the system implements the requirements and design and that the software componentsfunction correctly together. Test results are analyzed to determine if the software satisfies systemobjectives. Tests pass or fail based on the acceptance criteria stipulated in the SRS and on specificrequirements found in the RTM.Tasks performed in this phase are:* Complete requirements tracing if not already completed in the integration phase to verify a validrelationship between test plans, procedures, and designs;* Witness the FAT test and verify the tests validate that software correctly implements the requirementsand that the expected results conform to the requirements;* Identify discrepancies between actual and expected results;* Produce the final verified and approved RTM;* Produce a V&V Summary Report of the Test Phase Activities;* Coordinate resolutions of discrepancies with project management, design team personnel, andquality management;* Determine the extent of regression testing.Approved FAT Test results as approved by the Project Manager and Customer Representative,satisfactory resolution of all discrepancies, and an approved Software Validation Report signify that thesystem meets it requirements and is ready for delivery to the customer. Each of the 10CFR50 AppendixB suppliers will provide a certificate of conformance at the completion and PG&E acceptance of the FATresults.3.2.8 Final V&V TasksThe final V&V tasks include issuing the Final V&V Report, which summarizes all life cycle V&V tasks andthe task results. It will also summarize the discrepancies and their resolution found during the V&Vevaluation. The report will give an assessment of overall software quality and provide anyrecommendations.Following approval of the final V&V Report, a certificate or letter of conformance will be issued certifyingthe system meets the SIL requirements.Finally a configuration audit is performed to ensure all deliverables have either been previously shippedor are included for shipment to the customer.3.3 PG&E TasksBelow is a sequence of tasks which generally describes the process for PG&E after the final acceptanceof the 1 OCFR50 Appendix B supplier FAT.3.3.1The Installation and Checkout Phase PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 16 of 42The Installation and Checkout phase is when the developed system is first assembled in the ProjectIntegration and Test (PIT) for pre-installation staging and checkout. Performance of the site acceptancetest (SAT), per PG&E plant procedure, is conducted in the PIT. The developed system is then installed inthe final target environment/location and performance of the design verification testing (DVT) per PG&Eplant procedure is conducted. Depending on the complexity of the project, either the supplier or PG&Ewill perform system installation and checkout. Ultimately, PG&E will be responsible for acceptance of theresults of the SAT and DVT. The Installation and Checkout V&V activity addresses software installationand software acceptance support.Tasks performed in this phase:" Audit the installation configuration to verify that all software products required to correctly install andoperate the software are present in the installation package. Validate that all site-dependentparameters or conditions to verify supplied values are correct.* Installation Checkout by V&V; Conduct analyses or tests to verify that the installed softwarecorresponds to the software subjected to V&V. Verify that the software code and databases initialize,execute, and terminate as specified. In the transition from one version of software to the next, theV&V effort will validate that the software can be removed from the system without affecting thefunctionality of the remaining system components. The V&V effort will verify the requirements forcontinuous operation and service during transition, including user notification.* Verify that the installation procedures and installation environment does not introduce new hazards;Update the hazard analysis;" Review and update risk analysis using prior task reports; Provide recommendations to eliminate,reduce, or mitigate the risks; and* Generate the V&V Final Report -Depending upon project scope, either PG&E or the supplier will beresponsible for developing this report; Summarize in the V&V final report the V&V activities, tasks andresults, including status and disposition of anomalies.* Provide an assessment of the overall software quality and provide recommendations.Outputs of this phase are the Operations Manual, the Installation Configuration Tables, Training Manuals,Maintenance Manuals, an Installation Safety Analysis, a V&V Installation Analysis and Test Report, and aCM Installation Report3.3.2 Operation Phase V&V TasksThe 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 1 OCFR50 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.Tasks performed in this phase:* Evaluate new constraints (e.g., operational requirements, platform characteristics, operatingenvironment) on the system or software requirements to verify the applicability of the SWP; Softwarechanges are maintenance activities (see Section 3.2.10 Maintenance Phase, below).* Assess proposed changes (e.g., modifications, enhancements, or additions) to determine the effect ofthe changes on the system. Determine the extent to which V&V tasks would be iterated.* Verify that the operating procedures are consistent with the user documentation and conform to thesystem requirements.

PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 17 of 42" Verify that the operating procedures and operational environment does not introduce new hazards;Update the hazard analysis.* Review and update risk analysis using prior task reports; Provide recommendations to eliminate,reduce, or mitigate the risks.3.3.3 Maintenance Phase V&V TasksThe maintenance process is activated 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 will be treated as development processes and will be verified and validatedin accordance with development process described in the previous sections. Software integrity levelassignments will be assessed during the maintenance process. The software integrity level assignmentswill be revised as appropriate to reflect the requirements of the maintenance process. For SIL3 systems,revising the software integrity level to the SIL4 may require updating the relevant planning documents, orgenerating new planning documents, as appropriate. For SIL4 software that is being downgraded toSIL3, the implications on compliance with the site's current licensing basis as well as compliance withregulatory requirements must be evaluated and document prior to initiating the maintenance activity.System modifications may be derived from requirements specified to correct software errors (e.g.,corrective), to adapt to a changed operating environment (e.g., adaptive), or to respond to additional userrequests or enhancements (e.g., perfective).The Maintenance V&V activity covers modifications (e.g., corrective, adaptive, and perfective), migration,and retirement of software. Migration of software is the movement of software to a new operationalenvironment. The retirement of software is the withdrawal of active support by the operation andmaintenance organization, partial or total replacement by a new system, or installation of an upgradedsystem.The Maintenance V&V activity addresses problem and modification analysis, modificationimplementation, maintenance review/acceptance, migration, and software retirement. The objectives ofV&V are to assess proposed changes and their impact on the software, evaluate anomalies that arediscovered during operation, assess migration requirements, assess retirement requirements, and re-perform V&V tasks.Tasks performed in this phase:* Revise the SyWP to comply with approved changes. When the development documentationrequired by this plan is not available, generate a new SyWP;* Assess proposed changes (i.e., modifications, enhancements, or additions) to determine the effect ofthe changes on the system. Determine the extent to which V&V tasks would be iterated." Evaluate the effect of software operation anomalies." Perform a criticality analysis to determine the software integrity levels for proposed modifications.Validate the integrity levels assigned during development; address any inconsistencies, particularly ifthe SIL level is downgraded. For V&V planning purposes, the highest software integrity levelassigned to the software will be the software system integrity level." Assess whether the software requirements and implementation address 1) specific migrationrequirements, 2) migration tools, 3) conversion of software products and data, 4) software archiving,5) support for the prior environment, and 6) user notification.

PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 18 of 42* For software retirement, assess whether the installation package addresses: 1) software support, 2)impact on existing systems and databases, 3) software archiving, 4) transition to a new softwareproduct, and 5) user notification.* Verify that software modifications correctly implement the critical requirements and introduce no newhazards; Update the hazard analysis.* Review and update risk analysis using prior task reports; Provide recommendations to eliminate,reduce, or mitigate the risks.* Perform V&V tasks, as needed, to ensure that 1) planned changes are implemented correctly; 2)documentation is complete and current; and 3) changes do not cause unacceptable or unintendedsystem behaviors.3.4 PG&E Roles & ResponsibilitiesThe different roles and responsibilities for Software Quality Assurance as they relate to this SyQAP arediscussed below:3.4.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, supplierquality management/oversight, quality field implementation, and successful post-installation testing. TheProject Manager is also responsible to recommend re-evaluation of the project if he detects changes inthe project 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 will:* Release the system level V&V plan and reports* Establish cost controls" Enter the plan activities into the master project schedule." Review progress of the SyQAP and V&V program* Evaluate any reported deviations or anomalies for their potential risk and impacts to project cost andschedule." Approve corrective actions, scope changes and resource allocations.* Coordinate the disposition of discrepancy reports generated in the course of verification andvalidation.3.4.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.

PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 19 of 423.4.3 PG&E Project Engineering TeamThe PG&E Project Engineering Team conducts and ensures quality-related inter-group coordination fordesign and engineering between software and hardware design activities. Project engineering isresponsible for identifying the processes and corresponding standards and procedures to guide projectperformance. The project engineering team is further responsible for ensuring work activities areperformed in compliance with these standards and procedures.3.5 10CFR50 Appendix B Supplier Roles & ResponsibilitiesThe section below is a general description of the 10CFR50 Appendix B supplier's roles andresponsibilities. Detailed roles and responsibilities for each of the 1 OCFR50 Appendix B suppliers areprovided in the respective 1OCFR50 Appendix B supplier SQAP.3.5.1 Supervisor Project QAThe Supervisor Project QA is responsible for monitoring implementation of the quality program throughoutthe project and supports all levels of management. The Supervisor Project QA monitors project activitiesto ensure compliance with the policies reflected in this program manual and the related standards andprocedures throughout all system phases and maintenance activities.Supervisor Project QA supports the Project overseeing implementation of the SQAP program.Responsibilities in this capacity include:* Review the project-specific V&V plan and reports* Ensure the SQAP addresses the quality goals and priorities of the project and client organization, andsatisfies all organization requirements and expectations* Ensure the SQAP is put under configuration management (CM) control and made available to allaffected groups and individuals" Ensure audits of activities for compliance with the SQAP and other applicable requirements* Establish processes and procedures to perform SQAP activities* Report findings to project management, and identify corrective actions related to the product andprocess verifications.3.5.2 Project Manager (PM)The Project Manager (PM) is responsible for providing direction in implementation of the SQAP programdefined by this SQAP and for ensuring adequate resources are allocated to accomplish theimplementation. The 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 will:* Release the project-specific V&V plan and reports* Establish cost controls* Enter the plan activities into the master project schedule." Review progress of the SQAP and V&V program* Evaluate any reported deviations or anomalies for their potential risk and impacts to project cost andschedule.

PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 20 of 42* Approve corrective actions, scope changes and resource allocations.* Coordinate the disposition of discrepancy reports generated in the course of verification andvalidation.3.5.3 Project Lead EngineerThe focus of the Project Lead Engineer is to conduct and ensure quality-related inter-group coordinationfor design and engineering between software and hardware design activities. The Project Lead Engineeris responsible for identifying the processes and corresponding standards and procedures to guide projectperformance. The Project Lead Engineer is further responsible for ensuring work activities are performedin compliance with these standards and procedures.3.5.4 Design TeamThe Design Team interfaces with SQA regularly to review the status of software quality activities and toaddress any quality-related issues identified by SQA. The Design Team is responsible for establishingquality goals and objectives for their organization consistent with those of the project.3.5.5 Testing/lntegration TeamThe Testing/Integration Team is responsible for integration and Factory Acceptance Testing (FAT). TheTesting/Integration Team develops test plans and reports for systems integration and test activities,defines requirements for, develops, and implements test plans for systems integration and FAT. TheTesting/Integration Team may include members of the Design Team.3.5.6 Lead Verification Engineer (SQA Manager)The Lead Verification Engineer is responsible to implement the Software Quality Assurance Program asdefined in the Software Quality Assurance Plan (SQAP) for the project. The Lead Verification Engineeralso manages resources to perform V&V activities, ensures the independence of V&V personnel, andapproves the SWP and V&V reports. The Appendix B software supplier is expected to have a separateQA organization and the Lead Verification Engineer will review and approve all test plans and V&Vreports. Purchase Orders will be written so the SQA Organization is not constrained by either budget orschedule in the performance of their duties.3.5.7 Verification & Validation (V&V) StaffVerification & Validation (V&V) Staff will maintain technical independence, managerial independence, andfinancial independence. The V&V Staff are responsible to perform V&V audits and inspections perapproved V&V Plans, create or verify the traceability of customer and functional requirements using aRequirements Traceability Matrix, review Software Test Plans, verify independently that all items of safetysoftware have been correctly identified and included appropriately in the design documents, review testprocedures as applicable, and produce Software V&V Reports in accordance with V&V Procedures. Inaddition V&V is responsible to evaluate the activities in each software Lifecycle phase to ensure theactivities performed do not introduce new software hazards. Finally V&V will perform audits ofconfiguration management. Project needs may dictate that V&V personnel will develop all software testplans, the FAT plan, and FAT procedures as well as supervise testing of the developed system.3.5.8 Project QA Engineer or EquivalentThe Project QA Engineer is responsible to ensure that nuclear and functional safety objectives are met inaccordance with IEEE 1012 [2.1.2.24].

PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 21 of 424. DocumentationThe NRC has issued Interim Staff Guidance (ISG) in digital instrumentation and control DI&C-ISG-06[2.1.1.18] that describes the licensing process that may be used in the review of License AmendmentRequest (LAR) associated with digital I&C system modifications.DI&C-ISG-06, Enclosure B, lists documents that are typically submitted by the licensee in support of asubmittal during Phases 1 and 2 of review. The Phase 1 documents that are associated with this projectare summarized in a separate attachment to the LAR. A list of Phase 2 documents associated with thisproject will be provided 12 months prior to the requested LAR approval date.The documentation discussed below is a summary of the documents to be provided by PG&E and the1 OCFR50 Appendix B supplier(s). As stated above, specific documents associated with this project arelisted in separate lists provided with the LAR and Phase 2 submittal enclosure.4.1 Overview of PG&E DocumentsThe following is a summary of the documents to be provided by PG&E.4.1.1 Conceptual Design Document (CDD)The CDD will provide a high level description of the overall system to be implemented by the DCPP PPSupgrade project.4.1.2 Functional Requirements Specification (FRS)The FRS will provide a general description of what PG&E expects the system to do. All known customerrequirements will be documented. The FRS should state the specific customer requirements as clearlyand consistently as possible. It will describe the operations the user wants to perform with the softwareand define all the constraints that the customer wishes to impose upon any solution. The FRS willdescribe the external interfaces to the system. IEEE Std. 1233 [2.1.2.36] can be used for guidance inregards to the content, table of contents and details that should be included in the FRS. The FRS is adeliverable from PG&E.4.1.3 Interface Requirements Specification (IRS)The IRS will provide a general description of how PG&E expects the separate deliverables from each ofthe 10CFR50 Appendix B suppliers to interface with one another. Specifically, the IRS will provide:(1) Requirements for the interfaces between external field devices such as process transmitters and the1OCFR50 Appendix B suppliers' equipment;(2) Electrical and communication interfaces between the 1 OCFR50 Appendix B suppliers equipment andtheir associated peripheral devices; and(3) Other interfacing Diablo Canyon Power Plant (DCPP) systems such as the Plant Process Computer(PPC), Main Annunciator System (MAS), Safety Parameter Display System (SPDS) and the Safety-Related 120 Vac and 125 Vdc Power Systems.4.1.4 System Verification & Validation Plan (SyVVP)The System Verification and Validation Plan (SyWP) for the overall system life cycle will be preparedaccording to IEEE Std. 1012 [2.1.2.24]. PG&E will review and approve 1OCFR50 Appendix B supplier lifecycle outputs providing independent V&V activities including review, evaluation, analysis, and inspection.It will include both an assessment of the development process, and independent testing of the softwareand logic products within the Site Acceptance Test (SAT).

PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 22 of 42In accordance with the system verification & validation plan, the overall plan for the verification andvalidation of the system is described. All methods, criteria, and tasks are listed, including required inputsand outputs.4.1.5 Site Acceptance Test (SAT) PlanThe SAT Test Plan will prescribe the scope, approach, resources, and schedule of the testing activities.It identifies the items to be tested, the features to be tested, the testing tasks to be performed, thepersonnel responsible for each task, and the risks associated with the plan. The SAT Plan describes theformal acceptance testing approach, methodology, and acceptance criteria that will enable PG&E toaccept the system for implementation in the plant. Test plans, test cases, and test procedures aredeveloped in accordance with IEEE Std. 829 [2.1.2.21]. See Section 7 for further details about testing.4.1.6 Requirements Traceability Matrix (RTM)The RTM will be used to demonstrate traceability for each function through all phases of the systemdevelopment. Regulatory guidance requires traceability analysis only for software requirements.However, formal requirements management is considered to be a good business practice towarddevelopment of a high-quality digital system. Therefore, it is recommended that the RTM cover hardware,software, and interface requirements of the digital system to the extent practical.A RTM is created to demonstrate that all requirements have been successfully implemented in the designand tested in the testing program. Both forward and reverse paths must exist to be able to trace eachdesign requirement to and from the SAT. During the RTM development there may be some requirementsthat cannot be validated by testing. For these, techniques such as analysis or reviews can be used andnoted in the RTM. More information can be found in the EPRI V&V handbook (TR-103291).4.1.7 System Verification and Validation (SyWR) Final ReportThe System Verification and Validation Final Report summarize all results of the execution of the SyWP.It lists all deficiencies found; provides the results of reviews, audits and tests.4.2 Overview of 10CFR50 Appendix B Supplier DocumentsThe section below is a general description of the 1 OCFR50 Appendix B supplier's documents. A detailedlisting and description of the documents supplied by each of the 1 OCFR50 Appendix B suppliers isprovided in the respective 10CFR50 Appendix B supplier SQAP.4.2.1 System Requirements Specification (SyRS)The System Requirements Specification (SyRS), which includes the I/O list and memory mappingbetween devices, describes the external input/output as well as input and output between modules of thenew system architecture so hardware and software designs can proceed independently. Hardware andSoftware Design will consistently apply naming conventions to avoid confusion.4.2.2 Software Verification & Validation Plan (SVVP)The Software Verification and Validation Plan (SWP) for the software life cycle will be preparedaccording to IEEE Std. 1012 [2.1.2.24]. Independent V&V activities include review, evaluation, analysis,and inspection. It will include both an assessment of the development process, and independent testingof the software products as necessary.In accordance with the software verification & validation plan, the overall plan for the verification andvalidation of the software is described. All methods, criteria, and tasks are listed, including requiredinputs and outputs.

PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 23 of 42The V&V plan will describe the methods for verifying that the generated software implements design asexpressed in the SDD and the requirements of the SRS, and validating that the code, when executed,complies with the expected results of the Software Test Plan(s) (STP).The V&V plan will describe test plans and test cases to validate the capabilities and correct operation ofany third party software, including the operating system and communications protocols, if required.4.2.3 Software Configuration Management Plan (SCMP)The software configuration management plan (SCMP) will be published to document configurationmanagement activities applicable to the portion of the software life cycle covered by the SQAP. TheSCMP will conform to the requirements of IEEE Std. 828 [2.1.2.20]. The configuration managementactivities required by the SCMP will be audited; the audit may be performed by QA, V&V, or by a teamcomposed of both.4.2.4 Software Safety PlanThe Software Safety Plan provides a systematic approach for identifying hazards and reducing softwarerisks and defines the safety goals that are expected to. be achieved by adhering to the plan. The planfollows and complies with BTP-7-14 [2.1.1.2] and the concepts of IEEE 1228 [2.1.2.35] but does not fullycomply with IEEE 1228. The NRC has not endorsed IEEE 1228. The design of the SRS, SDD and codeis potentially subject to constraints arising from the safety analysis. Supplier organizations are expectedto provide documentation on their organization, requirements coupled with the performance of the FMEA,response time analysis and FAR to ensure that there are no safety hazards.4.2.5 Baseline Review ReportThe Baseline Review Report (BRR) documents the results of the Baseline Change Assessment (BCA)performed at the end of each lifecycle phase. The BCA is an evaluation of proposed software changes(e.g., anomaly corrections and requirement changes) for potential effects on previously completed V&Vtasks. Plan iteration of affected tasks or initiate new tasks to address software baseline changes oriterative development processes. The BCA verifies and validates that the change(s) is (are) consistentwith system requirements and does (do) not adversely affect requirements directly or indirectly. Anadverse effect is a change that could create new system hazards and risks or affect previously resolvedhazards and risks adversely.4.2.6 Software Requirements Specification (SRS)The SRS describes all functions accomplished using software that have to be specified during thesoftware development. It is based on the reviewed and released Functional Requirements Specification(FRS). The SRS contains all information, necessary for the specification of function diagrams such as:function descriptions, performance criteria, signal interfaces, ID codes, hardware assignments and designconstraints. Each function within the SRS is uniquely identified, such that its achievement is capable ofbeing objectively verified and validated. The SRS follows the guidance in IEEE Std. 830[2.1.2.22] to theextent practical. The SRS is subject to the Software Requirements Review.4.2.7 Requirements Traceability MatrixThe Requirements Traceability Matrix (RTM) will be used to demonstrate traceability for each functionthrough all phases of the software development. Regulatory guidance requires traceability analysis onlyfor software requirements. However, formal requirements management is considered to be a goodbusiness practice toward development of a high-quality digital system. Therefore, it is recommended thatthe RTM cover hardware, software, and interface requirements of the digital system to the extentpractical.

PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 24 of 42The RTM have been created to demonstrate that all specified requirements have been successfullyimplemented in the design and tested in the testing program. A forward path must exist to be able totrace each design requirement to the FAT and, where applicable, to a user manual dictating how eachrequirement is to be carried out. During the RTM development there may be some requirements thatcannot be validated by testing. For these, techniques such as analysis or reviews can be used and notedin the RTM. More information can be found in the EPRI V&V handbook (TR-1 03291) [2.1.2.5].The requirements traceability matrix is updated at the end of each life-cycle phase to provide forwardsand backwards traceability to and from the HW and SW requirements to ensure that failure modes aredocumented and tested. After the matrix is completed, verification is performed to ensure that thoserequirements that are found not to be testable are validated by other means.4.2.8 Software Requirements Review ReportThe SRR is performed to ensure that the SRS adequately and completely reflects the design demands ofthe functional requirements specification and they are technically feasible. The SRR verifies that the SRSwas created in accordance to the above-mentioned standards and is unambiguous, complete, verifiable,consistent, modifiable, traceable and usable during operation and maintenance.A Software Requirements Review Report will contain information about review activities, reviewparticipants, review results and all found discrepancies. Found discrepancies are reported in the form ofopen items and are subject to the discrepancy reporting process outlined in Section 8.4.2.9 Software Design Description (SDD)The design will specify reduction of the overall structure into physical solutions (algorithms, equations,control logic, and data structures) in a manner that the design can be translated into code. The SoftwareDesign Description (SDD) will contain a technical description of the software and hardware architecture,and the software with respect to the theoretical basis, mathematical model, control flow, data flow, controllogic, and data structure. The SDD will contain a description of the allowable or prescribed ranges forinputs and outputs. For graphical programming environments utilizing function block diagrams to createapplication programs, the SDD of the application software is published by printing the function modulesusing software development tools described in the SVVP. The SDD will follow the guidance in IEEE Std.1016 [2.1.2.25], to the extent practical.4.2.10 User DocumentationThe user documentation consists of manuals describing the hardware, system software and tools to guideusers in installing, operating, and maintaining the system. User documentation will include anintroduction, a description of the system's limitations, the user's interaction with the software, and anyrequired training necessary to use the software. User documentation will also include the procedure forperforming required periodic calibration, tests, and preventive maintenance.User Manuals should describe operation of the overall system, including configurable parameters,options, program limitations, system-specific scripts, procedures for starting, re-starting of the system,exchange of modules, and all other essential information about the applications software as part of theuser documentation to be provided. User Documentation will also be provided that describes I/Ospecifications and formats, user responses to messages resulting from improper input, and how to obtainuser and maintenance support. Refer to IEEE Std. 1063 [2.1.2.32] for further guidance.

PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 25 of 424.2.11 Software V&V ReportsSoftware V&V Reports are published at the end of each software Lifecycle phase per IEEE Std. 1012[2.1.2.24] identifying the anomalies, corrective actions, and recommendations based on the V&Vactivities performed in each phase. Refer to Section 3 for the V&V activities to be performed.4.3 1OCFR50 Appendix B Supplier Software Test DocumentationThe section below is a general description of the 1 OCFR50 Appendix B supplier's test documentation.Details of the software test documentation supplied by each of the 1 OCFR50 Appendix B suppliers areprovided in the respective 1 OCFR50 Appendix B supplier SQAP.Software testing will be developed following the test documentation requirements outlined in IEEE Std.829 [2.1.2.21]. The test documentation will include a Software Test Plan(s) (STP), detailed testspecifications, and test reports. Additional SQA testing requirements are described in Section 7. Failuresin the software detected during testing will be recorded using the problem reporting process described inSection 8.4.3.1 Software Test Plan(s)The Software Test Plan(s) and FAT Test Plan will prescribe the scope, approach, resources, andschedule of the testing activities. It identifies the items to be tested, the features to be tested, the testingtasks to be performed, the personnel responsible for each task, and the risks associated with the plan.The Factory Acceptance Testing (FAT) Plan describes the formal acceptance testing approach,methodology, and acceptance criteria that will enable the customer to accept the system for delivery.Test plans, test cases, and test procedures are developed in accordance with IEEE Std. 829 [2.1.2.21].See Section 7 for further details about testing.4.3.2 Security Test Plan(s)The objective of testing security functions is to ensure that the system security requirements are validatedby the execution of integration, system, and acceptance tests where practical and necessary. Testingincludes system hardware configuration (including all connectivity to other systems, including externalsystems), software integration testing, system integration testing, and system factory acceptance testing.The security requirements and configuration items intended to ensure reliable system operation will bepart of the validation of the overall system requirements and design configuration items. Therefore,security design configuration items will be just one element of the overall system validation. Each systemsecurity feature will be validated to verify that the implemented feature achieves its intended function toprotect against inadvertent access and/or the effects of undesirable behavior of connected systems anddoes not reduce the reliability of system's safety functions.Depending upon the scope of the project, testing will address the system hardware architecture, externalcommunication devices, and configurations for unauthorized pathways and system integrity. Built-inoriginal equipment manufacturer features will also be included for testing.4.3.3 Software Verification and Validation Final ReportThe Software Verification and Validation Final Report (SWR) summarizes all results of the execution ofthe SVVP. It lists all deficiencies found; provides the results of reviews, audits and tests. The result ofthe final report is a certificate of conformance that the software can be released for operational use.

PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 26 of 424.4 Other Documentation4.4.1 Documents" Software Installation Plan provides a general description of the installation process and the goals ofthat process. A general description of the environment (such as temperature, humidity, vibration, andrack space) within which the computer system and software system is required to operate should beincluded in the plan. It describes the organization, roles and responsibilities, and approach requiredto perform the software installation. Software Installation Planning may be included in the SoftwareTest Plan(s).* Software Integration Plan describes the software integration process, the hardware/softwareintegration process, and the goals of the processes. It describes the organization, roles andresponsibilities, and approach required to perform the software integration. Software IntegrationPlanning may be included in the Software Test Plan (s)." Hardware Requirement Specification (HRS) similar to the SRS, the Hardware RequirementsSpecification describes what hardware will be used and what requirements must be met by thehardware to meet the Functional Requirements Specified in the FRS. The HRS is used to define thearchitecture of the system.4.4.2 Design AnalysesThe design of the system is potentially subject to constraints arising from the following analyses:* Reliability Analysis evaluates the failure rates of modules in terms of the probability of system failureon demand, compares the overall system availability to the reliability goal(s) specified in the FRS.Reliability analyses are performed per the guidance of IEEE Std. 577 [2.1.2.17] and may be includedin the FMEA.* Failure Modes and Effects Analysis (FMEA) the detailed FMEA will specifically consider systematicrandom single failures based on the hardware design and architecture of the integrated system.Particular attention is paid to safety functions and software failures. The analysis is typicallyextended to include common mode failures. Recommendations are made based on potential failures,severity, and risks involved, which could result in design changes to the system. The FMEA will beperformed following the guidance of IEEE Std. 352 [2.1.2.15].* Response Time Analysis this analysis calculates the overall Response Time of the system, whichshould be lower than the shortest required response time, described in the FRS.5. Standards, Practices, Conventions, and MetricsThis project adheres to regulatory guidance and ANSI/IEEE, and International standards consideredacceptable for software used in nuclear plant safety systems. In particular, NUREG-0800, BTP 7-14[2.1.1.2], IEEE 603-1991 [2.1.2.18], IEEE 7-4.3.2-2003 [2.1.2.7], and IEEE 1012-1998 [2.1.2.24] are usedas the basis for the overall V&V process to be applied to SIL-4 systems. The design of the PPS is.intended to meet the requirements of IEEE Standards that are currently endorsed by various NRCRegulatory Guides at the time of the design.Monitoring of compliance and adherence to these standards is ensured through the reviews and auditsconducted (see section 6) by the V&V team under the direction of thel OCFR50 Appendix B supplier LeadVerification Engineer. Moreover, the 10CFR50 Appendix B supplier Lead Verification Engineer willapprove, and document in future versions of this 1 OCFR50 Appendix B supplier SQAP, necessarypractices, conventions, metrics and deviations from the standards, decided by the 10CFR50 Appendix B PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 27 of 42supplier Project Manager and/or 10CFR50 Appendix B supplier Responsible Engineer. Deviations fromstandards should be clearly justified and documented in the respective SQAP.5.1 Documentation standardsThe documentation standards defined in the 1 OCFR50 Appendix B supplier SWP, this SyQAP, and the1OCFR50 Appendix B supplier SQAP will be followed. See sections 4 and 6 for implementation ofstandards and monitoring of adherence.5.2 Logic structure (design) standardsIEEE standards will be used for the overall organization of the SRS, SAD and SDD. Function logicdiagrams and SAMA diagrams are predefined by the software development tools and cannot be alteredby the user.5.3 Testing Standards and PracticesTest procedures, test scripts and the results of the test are part of the documentation described in Section7. The structure of test procedures and test scripts is in conformance with IEEE Std. 829 [2.1.2.21] andIEEE Std. 1008 [2.1.2.23] as verified as part of the V&V testing activities described in the 10CFR50Appendix B supplier SWP.5.4 Selected SQA Product and Process MetricsA minimum set of quality metrics should be defined in each of the 10CFR50 Appendix B supplier SWP.A required metric is the requirements coverage ratio, defined as the fraction of requirements specified inthe SRS that are traceable into the SDD and testing program.6. Software Reviews and AuditsReviews and audits are part of the Verification and Validation (V&V) activity. Accordingly, all reviews andaudits, as well as the necessary arrangements and methods for these reviews and audits will be specifiedin the SyWP as well as each of the 1 OCFR50 Appendix B supplier SWPs. The procedures for softwarereviews are based closely on the ANSI/IEEE Std. 1028 [2.1.2.26]. In general, technical reviews evaluatespecific software elements to verify requirements and conformance to regulations, codes, and standards;a code walkthrough is a method used for the early evaluation of documents, models, designs, and code;inspections are performed to evaluate documents and code before technical review or testing, andindependent reviews and audits are performed to assess compliance with software requirements,specifications, baselines, standards, procedures, instructions, codes, and contractual and licensingrequirements.Verification reviews will be documented identifying the participants and their specific responsibilitiesduring the review. Review documentation will include review comments and their disposition, which willbe retained until they are incorporated into the updated software. Comments and dispositions notincorporated will be retained in accordance with established procedures. Following incorporation ofcomments, reviewed documents will be updated and placed under configuration control. Founddiscrepancies are reported in the form of open items and are subject to the discrepancy reporting processoutlined in Section 8.The following IEEE-730 [2.1.2.19] reviews and audits or their equivalents are used in the process ofperforming V&V:

PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 28 of 426.1 Software Requirements Review (SRR)The Software Requirements Review is held to ensure adequacy of the requirements stated in the SRS.The SRS will be reviewed each time it is updated. The output from the review will consist of verificationreview comments, which will be documented in an SRR Report and transmitted to the developmentorganization. The report will identify all deficiencies discovered during the review. The review processmay require several iterations. This review is described further in Section 4.6.2 Architectural Design Review (ADR)An Architectural Design Review is a preliminary review to verify the technical adequacy of the basicdesign, and check the compatibility of the functional and performance requirements for the system. TheADR verifies consistency of the interfaces between the software and hardware. The basic designconcepts are verified for consistency and technical feasibility.6.3 Detailed Design Review (DDR)A Detailed Design Review is held to determine the acceptability of the detailed software designs asdepicted in the detailed design description in satisfying the requirements of the SRS to include: allfunctions, specified in the FRS are implemented; the described interface is completely implemented; andtest requirements are implemented. The software design review will verify that the software design istraceable to the requirements.6.4 Software Verification and Validation Plan Review (SVVPR)The SWPR is held to evaluate the adequacy and completeness of the verification and validationmethods defined in the SWP. This review is completed by the Project Manager with support from theLead Verification Engineer and is signified by approval of the SWP. The SWP should be reviewed andupdated at the end of each phase of the software development life cycle to consider any new or differentV&V activities for the next life cycle based on lessons learned from previous lessons learned andoperating experience.6.5 Functional AuditThis audit is held prior to the software delivery to verify that all requirements specified in the SRS havebeen met. Functional Audits are held together with the system design team prior to the system deliveryduring FAT testing. The Project Manager's and Customer or Customer Representative's approval of FATTest Results signify acceptance of the system for delivery.6.6 Physical AuditThis audit is held to verify that the software and documentation are internally consistent and ready fordelivery.6.7 In-process AuditsIn-process audits of a sample of the design are held to verify consistency of the design, including code-versus design documentation, interface specifications of the hardware and software, implementation ofthe design versus functional requirements, and functional requirements versus test descriptions. For thisproject, this will be accomplished by performing forward and backwards traceability analyses from thefunctional requirements through testing using a RTM.

PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 29 of 426.8 Managerial ReviewsManagerial reviews are held periodically to assess the execution of all of the actions and items identifiedin the SQAP. These reviews will be held by the Project Manager or his designee. Additionally SQA willattend project and staff meetings as feasible to assess and report on organizational effectiveness.Observations, both positive and negative, will be included in monthly activities reports.6.9 Software Configuration Management Plan Review (SCMPR)The SCMPR is held to evaluate the adequacy and completeness of the configuration managementmethods defined in the SCMP. This review is performed by the Project Manager with support from theLead Verification Engineer and is signified by their approval of the SCMP.6.10 Post Implementation ReviewA review will be held at the conclusion of the project to assess the development activities performedduring the project and to provide recommendations for improvement and to develop lessons-learned.The Post Implementation review will be conducted by the Project Manager with input from SQApersonnel, project technical personnel, and the system design team.6.11 User Documentation ReviewA review of user documentation will be performed to assess the adequacy of user documentation inregards to completeness, clarity, correctness, and usability.6.12 Software Safety ReviewsAn assessment will be made at the end of each software lifecycle phase to confirm that the activitiesperformed during that phase did not introduce any new software hazards. This assessment will beperformed by independent V&V personnel.6.13 Configuration Management ReviewsThe effectiveness of configuration management will be evaluated at the end of each software Lifecyclephase by SQA personnel.7. TestAll software verification and validation activities will be documented as required by each of the 10CFR50Appendix B [2.1.1.1] suppliers Software Verification and Validation Plan (SWP). The content related totesting in the 1OCFR50 Appendix B SVVP will be derived from the IEEE Standard for Verification andValidation Plans (IEEE Std. 1012 [2.1.2.24]) and the IEEE Standard for Software Test Documentation(IEEE Std. 829 [2.1.2.21]). Software Test Plan(s) (STP) will be created per IEEE Std. 829 to define thescope, approach, resources, and schedule of testing activities. A separate FAT Plan will be developed.8. Problem Reporting and Corrective ActionProblem reporting and corrective action procedures are part of the SCM activity and documentedaccordingly in the SCMP as well as the individual 1 OCFR50 Appendix B suppliers' SCMP.The actual implementation of the procedures is under the responsibility of each of the individual ProjectManagers, while the 1 OCFR50 Appendix B supplier Lead Verification Engineer is in charge of ensuringand monitoring the policy. Moreover, the 1OCFR50 Appendix B Lead Verification Engineer will recordproblem statistics and observe their trends.

PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 30 of 42Software anomalies can be reported at any stage in the life cycle. Anomalies can fall into a number ofclassifications according to the degree of regression in the life cycle. Selection of the problemclassification defines the phase of the life cycle at which corrective action needs to start.The 1OCFR50 Appendix B suppliers' SWP will describe the method of reporting and resolvinganomalies, including the criteria for reporting an anomaly, the anomaly report distribution list, and theauthority and time lines for resolving anomalies. The section will define the anomaly criticality levels.Classification for software anomalies may be found in IEEE Std. 1044[2.1.2.28].8.1 Anomaly Resolution and ReportingAnomalies are software discrepancies discovered by the V&V team, either during independent testing orobservation of testing by the design and testing organizations. Anomalies can be compliance problemsor simply enhancement suggestions. V&V anomalies identified by the V&V team must be reported to thedesign team. The V&V team will use the normal, applicable discrepancy reporting process of the project.Either the 1 OCFR50 Appendix B suppliers' corrective action process or the PG&E corrective actionprocess may be used; in either case a tracking mechanism must be used.The tracking system must include a flag or other means to identify open items that are V&V discoveriesand anomalies. Anomalies will be classified and assessed for project risk, in accordance with therequirements of this SyQAP.8.2 Task Iteration PolicyThe 1 OCFR50 Appendix B suppliers' SVVP will describe the criteria used to determine the extent to whicha V&V task will be repeated when its input is changed or task procedure is changed. These criteria mayinclude assessments of change, software integrity level, and effects on budget, schedule, and quality.Each V&V task performed, using designer-supplied documentation, will be assessed for possible re-performance whenever that documentation is revised. For instance, the release of a revised SRS wouldtrigger assessment not only of those activities in which the SRS itself was evaluated, but also of thoseactivities that used the SRS as a reference for the evaluation of other documentation (i.e., SDD).V&V personnel will conduct such assessments based on the extent of the changes, the criticality of thefunctions affected, and the anticipated impact on the software quality. Their findings will be documentedand V&V tasks re-performed to the extent required. This typically requires a revision of the report for thatphase.9. Tools, Techniques, and MethodologiesTools, techniques and methods for software production will be defined at the project level, anddocumented in the relevant 1 OCFR50 Appendix B suppliers' documents. It is an SQA activity, under theresponsibility of each of the 1 OCFR50 Appendix B supplier Lead Verification Engineers, to check thatappropriate tools, techniques and methods are selected and to monitor their correct application.Each of the 10CFR50 Appendix B supplier Lead Verification Engineers may decide that additional tools,techniques and methods are required to support the respective monitoring activity. These will bedocumented and described in that particular 1OCFR50 Appendix B supplier's SQAP.Each of the 10CFR50 Appendix B supplier's SWPs will describe documents, hardware and softwareV&V tools, techniques, methods, and operating and test environment to be used in the V&V process.Acquisition, training, support, and qualification information for each tool, technology, and method will beincluded. Tools that insert code into the software will be verified and validated to the same rigor as thehighest software integrity level of the software. Tools that do not insert code will be verified and validatedto assure that they meet their operational requirements. If partitioning of tool functions can be PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 31 of 42demonstrated, only those functions that are used in the V&V processes will be verified to demonstratethat they perform correctly for their intended use.Methods/tools require a description of the methods, equipment, instrumentation and tools used to carryout each V&V task. Test methods should be specified for unit, integration, validation, installation andregression testing. The plan should specify a process for selecting tools. The hardware and softwareenvironment within which the V&V tools are to be applied and any necessary controls should bedescribed. V&V methods include document reviews, design reviews, requirements traceability analysis,independent testing and validation, problem identification, risk assessment, and metrics performance.10. Media ControlSoftware configuration management (SCM), i.e. methods and facilities used to maintain, store, secureand document controlled versions of the identified software during all phases of the software life cycle)will be implemented according to the SCMP and the individual 1 OCFR50 Appendix B supplier SCMP(s).All software items, for example documentation, source code, executable code, files, tools, test softwareand data, will be subjected to configuration management procedures. The configuration managementprocedures will establish methods for identifying, storing and changing software items throughdevelopment, integration and transfer.10.1 Media ControlThe media for storing each deliverable work product and the associated documentation will be defined bythe Appendix B suppliers SCMP(s). The 10CFR50 Appendix B supplier SCMP(s) will define requirementsfor code control and have a disaster recovery plan. The 1OCFR 50 Appendix B supplier SCMP(s) willdelineate the standards and procedures that will conform with the applicable security policies to ensurethe system design products (hardware and software) do not contain dead code, undocumented code(e.g., back door coding), malicious code (e.g., intrusions, viruses, worms, Trojan horses, or bomb codes),and other unwanted or undocumented functions or applications.11. Supplier ControlSupplier control will be maintained by PG&E performing reviews, inspections, and audits. All projectdocuments developed by the suppliers will undergo PG&E review prior to final approval. Inspections canbe performed to monitor the execution of any testing. PG&E I&C Project(s) Engineering will perform areview and approve the 1 OCFR50 Appendix B suppliers SQAP(s).Tools and support software for system software or programmable logic will be confirmed to have beenimplemented in accordance with an appropriate Quality Assurance program for the whole life cycle of thesoftware, e.g., an approved 10 CFR Part 50 Appendix B program. The system software or programmablelogic should be evaluated to determine that it is adequate in terms of both the documentation andavailable supplier support during the Operation and Maintenance lifecycle phases.12. Records Collection, Maintenance and RetentionThe project manager is responsible for ensuring all documentation and records will be maintained inaccordance with AD10.01D [2.1.3.6]. This includes, as a minimum the following:* All final approved documents listed in Section 4 of this SyQAP.* All formal Review and Comment Resolution Sheets.* All Audits will be stored per lAW applicable QV requirements.* Problem Reports and Log.

PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 32 of 42" All written Project Correspondence (Incoming and Outgoing)* All final approved Supplier Documentation* Issued Purchase Orders and any subsequent Change Orders* Records of performance of any TrainingAll software documentation, formal correspondence, or other documents required by this plan will bearchived in the following location:NPG Library/Engineering/Strategic Projects/Project Management/ICOM/Current ApprovedProjects/RPS -Eagle 2113. TrainingThe PG&E PPS Project Engineering Team will conduct Project Specific Training for PG&E PPS ProjectEngineering team members on Project administration to include (but not be limited to):* Project formal correspondence (Incoming and Outgoing)" Software control (including version control)* LAN Access and File Storage location* Project Administration -Project Problem Reporting* Selected PG&E Procedures (AD10.ID1 [2.1.3.6], CF2.1D9 [2.1.3.3], etc.)* Other Training to be determined by I&C Project(s) Engineering as required.The PG&E PM will ensure that all team members have been trained on the elements of this SyQAP asoutlined above. The training will be documented on Form 69-20164, Work Group Specific Training.The 1OCFR50 Appendix B suppliers will ensure the following:* The personnel assigned will be qualified in accordance with appropriate codes and standards.* The overall management of training is the responsibility of the Project Manager. Training can beconsidered as a means to reduce risk levels due to the technical experience and skills of the humanresources for the project. If a risk factor due to training or skill deficiency is actually identified, thisshould be documented.* The Project Manager will verify that training needs have been properly assessed and documented,and monitor the implementation of training plans.14. Risk ManagementRisk Management requires specification of the methods used to identify and manage risks associatedwith the V&V process.Risk management includes identification of risk factors that may cause the V&V task to fail to perform itsfunctions, and methods to recover from any such failure. These plans may range from doing nothing (i.e.live with the risk) to redesign. Redesign options can include eliminating the software feature ifacceptable.

PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 33 of 42The plan should provide procedures for evaluating the risks associated with each project developmentactivity. Risk evaluation will be documented as a V&V activity report. The V&V engineer will brief theProject Manager of project management (cost and schedule) risks. The V&V engineer will, also brief theProject Manager of the software safety risks.Risk is defined as the probability of an adverse event or outcome multiplied by the cost or impact of itsoccurrence. Risk evaluation can therefore be done using probabilistic or risk-informed methods, such asare recommended in RG 1.174 [2.1.1.14].However, estimates of software reliability are considered questionable, and the use of quantitativereliability goals for computer-based safety systems is predicated on deterministic criteria for the computersystem in its entirety (i.e., hardware, system software, firmware, application, and interconnections).The V&V engineer for each of the 1 OCFR50 Appendix B suppliers should publish a list of the open itemsbelieved to pose the greatest project and/or safety risks; in order that they are kept visible for projectmanagement until a satisfactory risk mitigation strategy is devised. It is expected that these open itemswill be worked aggressively by the design and V&V organizations.15. Glossary15.1 DefinitionsAcceptance Official recognition that a product (usually hardware or software CI) meetscontractual and project requirements.Acceptance Test A Formal test conducted in an operational environment to determine whetheror not the system satisfies its acceptance criteria and to enable the customerto determine whether or not to accept the system.Accuracy The degree of freedom from error of sensor and operator input, the degree ofexactness exhibited by an approximation or measurement, and the degree offreedom from error of actuator output.Anomaly Any condition that deviates from the expected based on requirements,specifications, design, documents, user documents, standards, etc.Application Software Software designed to fulfill specific needs of a user; for example, software fornavigation, or process control.Approval Official recognition of product validity.ArchitectureThe organizational structure of a system or component.

BaselineBaseline LoadBuildPPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 34 of 42* A specification or product that has been formally reviewed and agreedupon, and thereafter serves as the basis for further development. It ischanged only through formal change- control procedures" A complete and documented set of design requirements and systemcomponents (hardware and software) placed under configuration controlthat identifies the applicable version/revision level of each of theserequirement documents and system components." Work products (e.g., document and/or software) that have been officiallyapproved or accepted and used to judge the acceptability of a system,Subsystem, or CI. (A baseline is subject to configuration control and isupdated to reflect approved changes to the Cl throughout its life cycle.)For software, a complete software package stored in a designated locationthat is capable of running on its own from a system reboot. A load will haveall software code, all local area network (LAN) code, all human machineinterfaces (HMI) code, and any databases required for software functionality.Intermediate version of a system or Cl that provides a demonstrable subsetof capabilities needed to meet requirements allocated to the system or Cl.Those attributes of the planning documents, implementation processdocuments and design outputs that provide full implementation of thefunctions required of the software. The functions that the software is requiredto perform are derived from the general functional requirements of the safetysystem and the assignment of functional requirements to the software in theoverall system design.The degree to which a design output is free from faults in its Specification,design, and implementation. There is considerable overlap betweencorrectness properties and properties of other characteristics such asaccuracy and completeness.Encompasses those activities that are necessary to produce the basic designand functional requirements for the project or system. The conceptual phaseidentifies the idea or need for a software application including feasibilitystudies. It establishes the scope, basic design criteria, required effort, cost,functionality, and classification of the software.Form, fit, and functions of a system or Cl as defined in baselinedocumentation.In the context of an audit for delivery of a product, a configuration auditincludes both a functional configuration audit and a physical configurationaudit.CompletenessCorrectnessConcept PhaseConfigurationConfiguration Audit Configuration Item (CI)ConfigurationManagementCorrective ActionCritical CharacteristicsCriticalityPPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 35 of 42* An aggregation of hardware, software, or both, that is designated forconfiguration management and treated as a single entity in theconfiguration management process. The collection of Cis shouldencompass all data, code, drawings, and other information that is usedto configure, maintain, or define the operation or configuration of thedesignated equipment and the project application." Developed or purchased item, controlled, accepted, and maintainedseparately from other items. (A CI can be composed of hardware orsoftware or, for major Cis, an aggregation of both.)A discipline that involves identifying, controlling, and tracking theconfiguration of a system or product.Corrective action is taken to eliminate the causes of an existingnonconformity, defect, or other undesirable situation in order to preventrecurrence.Those important design, material, and performance characteristics of acommercial grade item that, once verified, will provide reasonable assurancethat the item will perform its intended critical non-safety function.A subjective description of the intended use and application of the system.Software criticality properties may include safety, security, complexity,reliability, performance, or other characteristics.A structured evaluation of the software characteristics (e.g., safety, security,complexity, performance) for severity of impact of system failure, systemdegradation, or failure to meet software requirements or system objectives.* Software code that is not required or specified by the software designdocuments (SRS and SDD) that has the potential to adversely impact asafety significant function. Examples of software that would beconsidered Dead Code:" Test functions that were not specified in the SRS or SDD; and ifactivated, the test function could adversely impact a safety significantfunction." Programs that have been installed (possibly for future use) and thendisabled; and if enabled, this software code could have an adverseimpact on a safety significant function.* Any code that is not intended to be challenged or tested during the V&Vprocess.Examples of software that would not be considered Dead Code:* A tag-name inserted into the code for monitoring purposes only.* The insertion of non-executable comments or notes.* The use of a validated function or function block that may or may notexecute internal code based on input conditions.Criticality AnalysisDead Code DeliverableDesign PhaseDesign StepFactory AcceptanceTesting (FAT)AdministratorFault ToleranceFirmwareFunctional RequirementFunctional TestingFunctionalityHardwarePPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 36 of 42'A work product or service given to the client for review and acceptance. Itfrequently has contractual implications.Encompasses those activities that are necessary to produce the SoftwareDesign Description for the project or system. The primary activity is encodingthe application information and function definitions of the SoftwareRequirements Specification into function diagrams. Design Descriptions arethe translation of the Requirements Specification into the design anddevelopment of the software.A defined activity of the design process.Final customer-witnessed or customer-performed testing at supplier's sitewhich demonstrates that the designed system meets the purchaser'sfunctional and performance requirements and/or industry and regulatoryrequirements.Individual responsible for controlling the test process and performing otherduties as set forth in this plan.The quality of fault tolerance that is achieved when a system has the ability tocomplete critical functions within its required performance characteristics inspite of power or equipment failures and software faults.Computer programs and data loaded in a class of memory that cannot bedynamically modified by the computer during processing, e.g., EPROM.Requirement on the I&C system from point of view of the process function.The functional requirements usually are given in the form of writtendescriptions (customer functional specifications) and information flowdiagrams.Tests whether the functions of the I&C system fulfill the softwarerequirements. In the case of safety-related I&C equipment these tests areperformed by simulating the measurement signals that prevail during normalor accident conditions in order to check that protective actions are initiatedcorrectly.The operations, which must be carried out by the software. Functionsgenerally transform input information into output information. Inputs may beobtained from sensors, operators, other equipment, or other software.Outputs may be directed to actuators, operators, other equipment, or othersoftware.Physical equipment (components) that typically provide a specific functionand is assembled with other equipment to create a system; certaincomponents host the various types of Software or Firmware Hazards AnalysisI&C FunctionIdentity CheckImplementation PhaseIndependencePPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 37 of 42A systematic qualitative or quantitative evaluation of software for undesirableoutcomes resulting from the development or operation of a system. Theseoutcomes may include injury, illness, death, mission failure, economic loss,property loss, environmental loss, or adverse social impact. This evaluationmay include screening or analysis methods to categorize, eliminate, reduce,or mitigate hazards.The formal specification of the functional behavior of the I&C equipment, asderived from the functional requirements. I&C functions are specified anddescribed in the SRS, as information flow diagrams and data tables, and formthe basis for automatic software generation in application software.development.A check of software to confirm the correct version is loaded. This comprisesprimarily of a comparison of specific checksums.Encompasses those activities that are necessary to generate the code fromthe completed function diagrams or source code and load it onto theprocessors. This includes documenting the steps and matching specificchecksums for identity checking.Organization whose personnel maintain independence from a Technical,Managerial, and Financial perspective:* Technical Independence is defined as personnel who are not involved inthe development of the software.* Managerial Independence is defined as an organization separate fromthe development and program management organizations. Managerialindependence also means that the independent organization selects thesegments of the software and the system to analyze and test, choosetechniques, defines testing schedule, and selects the specific technicalissues and problems to act upon. The independent organization effortmust be allowed to submit to program management the testing results,anomalies, and findings without restrictions or adverse pressure, director indirect, from the development group.* Financial Independence is defined as an organization that is financiallyindependent from the development organization. This independenceprevents situations where independent activities cannot be completedbecause funds have been diverted or adverse financial pressures orinfluences have been exerted by the development organization.A detailed line by line technical verification of a document by a competentindividual other than the preparer. The independence and technicalcompetence of the reviewer is certified by the cognizant technical manager.This is performed by the design group personnel, is not part of the softwareverification and validation process, and may also be referred to asIndependent Review.Evaluation technique in which intermediate development products areexamined in detail by a person or group other than the author to detecttechnical deficiencies or violations of standards.Independent DesignReviewInspection Integration TestingIntegrity LevelInterfaceInterface ControlPPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 38' of 42An orderly progression of testing in which software elements, hardwareelements or both are combined and tested until the entire system has beenintegrated. The final set of testing, completed successfully, before the FATwhich demonstrates that the system (integrated hardware and software) isready for FAT.The assigned integer value from 0 to 4 that indicates the degree ofverification and validation that is applied to the system during thedevelopment life cycle, subsequent to an evaluation of a combination of thecriticality of the system function to the owner's mission, and the importanceand likelihood of a system failure. For larger systems, this level may beapplied to specific subsystems or sub-modules.A shared boundary across which information is passed.A Hardware or Software component that connects two or more othercomponents for passing information from one to the other.* Identification of all functional and physical characteristics relevant to theinterfacing of two or more Configuration Items provided by one or moreorganizations* Ensuring that proposed changes to these characteristics are evaluatedand approved prior to implementation.Lessons learned are guidance that enhance the practitioner's understandingof a process, clarify a process' applicability to a particular application, provideguidance for special cases, highlight issues, or convey supplier advice. Thelessons learned come from a variety of sources including, but not limited to,operation experience, experiences in the use of tools and techniques, andpublished best practices from other organizations.For the purposes of this SyQAP the term Locked Down is referring tosoftware that is completed and ready for V&V testing. Any additionalchanges to software that has been Locked Down requires a formal changeprocess lAW CF21D9 form 8.5.Software code that is intended to breakdown or bypass security barriers; orsoftware code that is intended to adversely impact proper systemperformance or function.An expression of possibility, a permissive choice to act or not, asdistinguished from shall, which is a requirement or action that must beperformed.A measure is any quantitative group. Examples of measures are estimatedcost, actual cost, ratio of actual to estimated cost, number of defects, defectdensity, mean time between failures, average length of support call, andnumber of peer reviews performed.Lessons LearnedLocked DownMalicious SoftwareMayMeasureMeasurement DataData made up of value instances of measures.

Open ItemPeer ReviewPreventive ActionProcess AuditProduct ReviewProject ManagerQualityPPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 39 of 42A notation of a characteristic, datum, detail, etc. which constitutes an error ordiscrepancy, or deviation, from the required status or condition of a properlycompleted project. Open Items are each given a record in a database with aunique (to the project) identifier and maintained by the project manager orproject engineer. The entry contains information to track the cycle of the itemfrom discovery of the item until final resolution.An examination of a product by the creators' peers to identify defects andareas where changes are needed. It uses the capabilities of independentreviewers, individually or in a group, to identify the improvements needed in aproduct and to agree on which improvements should be made.Preventive action is action taken to eliminate the causes of a potentialnonconformity, defect, or other undesirable situation in order to preventoccurrence.Process Audit determines whether planned activities are being performed,designated products are being developed, and specified standards andprocedures are being followed. At an intermediate point in each life cyclephase, Quality Management conducts a Process Audit and reports findings toproject management.An examination of a product to identify errors before the product is formallypassed forward in the development process.Individual responsible to coordinate all aspects of the assigned project(s).Primary customer interface responsible for coordinating implementation of theproject, quality control, customer invoicing and tracking project performanceagainst as- sold estimates.Degree to which a system or CI satisfies its requirements.Quality ManagementRegression analysis andtestingReleaseReliabilityConsists of the management responsibilities and actions that determine andimplement quality policies. It includes obtaining the commitment of theorganization, marshaling resources, and ensuring that quality managementprocesses are used and supported effectively.Determine the extent of V&V analyses and tests that must be repeated whenchanges are made to any previously examined software products. Assessthe nature of the change to determine potential ripple or side effects andimpacts on other aspects of the system. Rerun test cases based onchanges, error corrections, and impact assessment, to detect errors spawnedby software modifications.A build that will be delivered to the customer. A release may include anintegrated set of builds.The degree to, which a software system or component operates withoutfailure. This definition does not consider the consequences of failure, onlythe existence of failure.

PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 40 of 42Requirements PhaseRequirementsTraceabilityRequirementsTraceability Matrix(RTM)ReviewSafetySecurityShallEncompasses those activities that are necessary to produce the SoftwareRequirements Specification (SRS) for the project or system. These are theprimary software design activities wherein customer requirements areidentified and described, and documented in a manner necessary for thespecification of function diagrams. The Requirements Specification is thebuilding block for the development, procurement, and maintenance ofsoftware and data. As such it is important the Requirements Specification iscreated considering all the requirements for the software/data.The process of verifying that each specified requirement for a system hasbeen implemented into the design, that all aspects of the design have theirbases in the specification requirements (forwards and backwards traceability,respectively), and that testing produces results compatible with the specifiedrequirements. The completed steps of the verification process are typicallyrecorded in a Requirements Traceability Matrix (RTM). This usually takes theform of a table that lists requirements and the corresponding sections ofdocuments that indicate how the particular requirement is satisfied.A Requirements Matrix provides a method that can be used to trace anddocument that requirements have been met. It provides a complete view ofrequirements to be tested, and traces specific requirements through allphases of development to verify that the requirement was met. Additionally,the RTM formally documents the process and provides documented evidencethat can be useful in auditing that safety requirements and licensingcommitments were met.An expert analysis and evaluation of the results of a task, a step, or a phase.It is implemented either globally, or in detail on random samples (e.g., in thecase of code inspection).Those properties and characteristics of the software system that directlyaffect or interact with system safety considerations. The safety characteristicis primarily concerned with the effect of the software on system hazards andthe measures taken to control those hazards.The ability to prevent unauthorized, undesired, and unsafe intrusions.Security is a safety concern insofar as such intrusions can affect the safety-related functions of the software."Shall" denotes a requirement or action that must be performed."Should" denotes a requirement or action that would be beneficial toSUPPLIER or OWNER but is not mandatory within the PPS scope of work.The programs, procedures and any associated documentation pertaining tothe operation of a data processing or computing system. Software is anintellectual creation, independent of the medium on which it is stored.Software includes firmware and logic developed from software baseddevelopments systems.ShouldSoftware Software ComponentSoftware LifecycleSoftware RequirementsSoftware ToolSurveillanceSystemPPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 41 of 42Software components are a constituent element of a software system. Forapplication software, this usually means the modules, sub-modules, or I&Cfunctions as described in the SRS. A specific collection of SoftwareComponents is assembled to form a System Component.The period of time that starts when a software product is conceived and endswhen the software product is no longer available for routine use. Includes thefollowing phases: preliminary engineering (conceptual), requirements,detailed design, implementation, integration, testing, installation andcheckout, operations & maintenance, and sometimes a retirement phase.Software requirements are those that must be met by the software to satisfy acontract, standard, specification, procedure, or user need. The set of allsoftware requirements form the basis for subsequent development of thesoftware. Requirements include, but are not limited to: identification ofneeded software functions, the inputs, processes, and outputs required foreach function, the design constraints and attributes of the software,performance requirements, interface requirements, and developmentstandards. Each requirement is defined such that its achievement can beverified and validated objectively.A computer program used in the development, testing, analysis, ormaintenance of a program or its documentation. Examples includecomparator, cross-reference generator, decompiler, driver, editor,flowcharter, monitor, test case generator, and timing analyzer.A formal review of a process implementation against a documented standardor process. Surveillance is a planned activity that focuses on a project or afunctional area.The hardware and software required for solving a complex task. It consists ofseveral subsystems or components which have different performancecharacteristics but which are suitable for use together to accomplish therequired functions.System components are the equivalent of a subsystem. that can be usedseparately and performs a self-contained function. They consist of one ormore modules, which are suitable for use together in an overall system. Inthe documentation, emphasis is placed on functionality, communicationrelationships, sequences, inputs/outputs and common resources.System tests are used to determine whether the specified systemcharacteristics of equipment (behavior on failure, behavior on start-up,testability, etc.) have been implemented. These types of test are performedwithout regard to the specific I&C function.The repeat of a V&V task which occurs as a result of identification of ananomaly, its resolution, and the verification by the V&V team that theresolution is complete.System ComponentSystem TestTask Iteration PPS Replacement System Quality Assurance Plan (SyQAP) Rev 0Page 42 of 42Test Sequence of events designed to verify that a system or CI satisfiesrequirements or to identify differences between expected and actual results.Test Phase Encompasses those activities that are necessary during the applicationsoftware production process to assemble and integrate the complete system,and to perform required testing. These are the primary software designactivities wherein system performance is checked and documented to ensurethe required functions are correctly and completely implemented.Timing The ability of the software system to achieve its timing objectives within thehardware constraints imposed by the computing system being used.Traceability The degree to which each element of one life cycle product can be tracedforward to one or more elements of a successor life cycle product, and canbe traced backwards to one or more elements of a predecessor life cycleproduct. Traceability is central to the production of complex systems toensure all requirements are implemented, checked and tested.Unit Smallest replaceable element in a Cl also referred to as a configuration unit(CU). For software, a unit is typically a subroutine; for hardware, a unit maybe a board that is fabricated as a separate item.Validation The evaluation of a product at the end of the development process to ensurethe product complies with previously specified software requirements. Thisprocess is usually performed by testing. Validation involves evaluating theoverall system and software behavior under conditions representative of itsintended use.Verification The process of determining whether or not the products of a givendevelopment phase fulfill the requirements imposed at the start of the phase.Verification includes detailed review and testing at each phase anddetermines whether the project is ready to proceed to the next phase.Verification and The systematic program of review and testing activities performed throughValidation the software lifecycle to ensure that the software satisfies its intended useand user needs. V&V activities are performed by persons who are differentand independent from those who accomplish the design and integration.Verifiability The degree to, which a software planning document, implementation processdocument or design output is stated or provided in such a way as to facilitatethe establishment of verification criteria and the performance of analyses,reviews, or tests to determine whether those criteria have been met.Will "Will" means that an action or activity can be assumed to be completed bythe subject of the sentence whether the subject is SUPPLIER, OWNER orothers.16. SyQAP Change Procedure and HistoryThis section is not applicable. Page two contains a Revision History Page per PG&E procedures.

Retrieved from "https://kanterella.com/w/index.php?title=ML15099A063&oldid=712188"