DCL-13-061, PG&E Document, Scm 36-01, Revision 1, Process Protection System Replacement Software Configuration Management Plan (Scmp), Enclosure, Attachment 1

PG&E Document, Scm 36-01, Revision 1, Process Protection System Replacement Software Configuration Management Plan (Scmp), Enclosure, Attachment 1

ML13154A047
Person / Time
Site:	Diablo Canyon
Issue date:	03/18/2013
From:	Hefler J N Pacific Gas & Electric Co
To:	Office of Nuclear Reactor Regulation
Shared Package
ML131540159	List: DCL-13-061, CS Innovations - Application for Witholding Proprietary Information from Public Disclosure, Enclosure, Attachment 2 DCL-13-061, Diablo Canyon, Units 1 and 2 - Submittal of CS Innovations Documents and Revised Software Configuration Management Plan for the License Amendment Request for Digital Process Protection System Replacement DCL-13-061, PG&E Document, Scm 36-01, Revision 1, Process Protection System Replacement Software Configuration Management Plan (Scmp), Enclosure, Attachment 1 ML13154A047 ML13154A049
References
DCL-13-061 SCM 36-01, Rev. 1
Download: ML13154A047 (34)

Text

Attachments 3-7 to the Enclosure contain Proprietary Information

-Withhold Under 10 CFR 2.390 Enclosure Attachment 1 PG&E Letter DCL-13-061 PG&E Document, "SCM 36-01, Revision 1, Process Protection System Replacement Software Configuration Management Plan (SCMP)" Attachments 3-7 to the Enclosure contain Proprietary Information When separated from Attachments 3-7 to the Enclosure, this document is decontrolled.

Pacific Gas & Electric Company Diablo Canyon Power Plant Units 1 & 2 Process Protection System Replacement Software Configuration Management Plan (SCMP) Nuclear Safety Related SCM 36-01 Rev 1 Prepared by: Date Print Last Name l-fefler User ID Reviewed by It..fl Date Print Last Name S C h V"t1.. J. e r . User ID Tech Coord: o Date Print Last Name User 10 QA Supv: Date Print Last Name j E.f: F User 10 Cyber Sec Lead: Date User 10 PPS Proj. Mgr: Date Print Last Name User ID 03/18/2013 JWH3 tJS/03/

1(. iTS E Osj,#ZO/3 "1?!(:i/ 5 ) 8 /-z.o 13 'JBkl 7 /f1a , (! 2t; ( 3 3 d//l. r-liJ.)o/3 I I Sllfl REVISION HISTORY Revision Affected Reason for Revision Number Pages 0 All Initial Issue Cover Added QA Supervisor, System Coordinator, and Cyber Security Lead signoffs per NRC 01 #31 1.1.1 Clarified purpose of document is to establish change control through 1.1.2 operations and maintenance phases per NRC 01 #42 1.2.1 Moved to Section 1.1.2 1.2.2 Deleted -Not applicable.

1.2.4 Updated to describe location of DCPP-specific implementation databases (part of response to NRC 01 #51 1.2.5.1 Revised to list and describe configuration items covered by the SCMP, 1.2.5.2 including KVM switch per NRC 01 #72 (Note: unused ports are controlled by 1.2.5.3 CSP, not SCMP) Clarified NVRAM configuration to be performed by PG&E using an approved procedure per NRC 01 #51.1 a and 01 #51.1 b Clarified application alterations to be performed by ALS and Triconex per NRC 01#42 1.3.1 Replaced table of definitions with reference to IEEE 610.12 1.3.2 Deleted unused acronyms; added Core Logic Board, Cyber Security Plan and Physical Security Plan 1.4 Deleted Reference 26, 30, 32 and 33; not appropriate for this Plan Added References 34 and 35 2.0 Revised title 2.1 Clarified organization with respect to CF2.ID2 per NRC 01 #51.2 1 2.2 2.2.4 Clarified problem reporting and tracking per NRC 01 #51.3a 2.3.3 Clarified SourceSafe access restrictions per NRC 01 #51.4b Clarified that DCPP FileNET is the repository for PPS Replacement documentation whereas SourceSafe is the software repository per NRC 01 #51.4a 2.4 Referred security items to Cyber Security Plan and Physical Security Plan 3.1.2 Deleted references to SC-I-36-M.

Depending on the parameter, there are several Scaling Calcs. 3.1.4.2 Updated SCM Manual requirements 3.2.2.1 Deleted references to SC-I-36-M.

Depending on the parameter, there are several Scaling Calcs. 3.2.2.2 Clarified Level 2 changes -include setpoint changes; do not affect safety function 3.2.2.3 Clarified Level 3 modifications.

After delivery to PG&E, modifications to the ALS and Tricon safety applications must be performed by the Appendix B suppliers, not b)' PG&E. 3.2.2.4 New Section -Tricon Circuit Board Replacement 3.2.2.5 New Section -ALS Circuit Board Replacement 3.2.4.3 Clarified modifications to the ALS and Tricon safety applications must be performed by the Appendix B suppliers, not by PG&E Revision Affected Reason for Revision Number Pages 3.2.4.7 Clarified work authorizations per NRC 01 #51.3b. Clarified that RMS is used for permanent storage, rather than tracking per NRC 01 51.3b. 3.2.5.5 Clarified that DCPP FileNET is the repository for PPS Replacement documentation whereas SourceSafe is the software repository per NRC 01 #51.4a Figure 3-1 URdated.per LAR Supplement 3.2.7.1 Deleted references to SC-I-36-M.

Depending on the parameter, there are several Scaling Calcs. 3.2.9 Deleted references to SC-I-36-M.

Depending on the parameter, there are several Scaling Calcs. 3.2.9 Clarified that the scaling calculations list tunable database parameters (vs. 1,cont. data files) per NRC 01 #51.4a 3.2.12.1 Updated SCM Manual requirements 3.2.12.2 Deleted references to SC-I-36-M.

Depending on the parameter, there are several Scaling Calcs. 3.3 Clarified change tracking and permanent record storage with respect to Configuration Status Accounting per NRC 01 # 51.3b. 3.4 Clarified frequency of audit performance 5.1 Clarified use of TS1131 Developer's Workbench for maintenance as part of response to NRC 01 #69 5.3 Clarified training requirements Attachment 1 Item 7 Disaster Recovery added backup file location SCMP 36-01 Software Configuration Management Planfor PPS Replacement Rev 1 TABLE OF CONTENTS 1 Introduction

............................................................................................................

1 1.1 Purpose .................................................................................................................

1 1.2 Scope ....................................................................................................................

2 1.3 Glossary ................................................................................................................

6 1.4 References

............................................................................................................

7 2 Configuration Management.

...................................................................................

9 2.1 Organization

..........................................................................................................

9 2.2 Responsibilities

......................................................................................................

9 2.3 Risks .....................................................................................................................

11 2.4 Security .................................................................................................................

12 3 SCM Activities

.......................................................................................................

13 3.1 Configuration Identification

...................................................................................

13 3.2 Configuration Control ............................................................................................

15 3.3 Configuration Status Accounting

...........................................................................

23 3.4 Configuration Auditing ...........................................................................................

23 4 SCM Schedules

....................................................................................................

24 4.1 Project Milestones

................................................................................................

24 4.2 Audit Acceptance Criteria .....................................................................................

25 5 SCM Resources

....................................................................................................

25 5.1 Software Tools ......................................................................................................

25 5.2 Equipment and Techniques

..................................................................................

26 5.3 Personnel and Training .........................................................................................

27 6 SCM Plan Maintenance

........................................................................................

27 6.1 Oversight ......................................................

'" .....................................................

27 41 ATTACHMENT 1: SCM Manual Outline ...................................................................................

28 TABLE OF FIGURES Figure 1-1 Tricon Triple Modular Redundant Architecture

.......................................................

1 Figure 1-2 Generic ALS FPGA Architecture

............................................................................

2 Figure 1-3 PPS Replacement Architecture

..............................................................................

5 Figure 3-1 PPS Communications (Simplified)

.......................................................................

20 SCNfP 36-01 Software Corifiguration Management Planfor PPS Replacement Rev 1 This page left blank by intent ii SCMP 36-01 Software Configuration Management Planfor PPS Replacement Rev 1 1 Introduction 1.1 Purpose 1.1.1 The purpose of this Configuration Management Plan is to establish and document a process of change control and software configuration management for the replacement Process Protection System (PPS) Operations and Maintenance Phases; i.e., from the time the equipment arrives at PG&E through Site Acceptance Test (SAT), Installation, Post Modification Test, and for the remainder of its life cycle at DCPP. 1.1.2 This Plan is required by DCPP Program Directive CF2 [2] and is implemented in accordance with DCPP procedure CF2.ID2 [3]. This Plan covers configuration control of the system software and defines individuals and organizations responsible for various aspects of the Plan's implementation.

1.1.3 The Process Protection System (PPS) monitors plant parameters, compares them against setpoints and provides signals to the Solid State Protection System (SSPS) if the setpoints are exceeded.

The SSPS evaluates the signals and performs Reactor Trip System (RTS) and Engineered Safety Feature Actuation System (ESFAS) functions to mitigate the event that is in progress.

1.1.4 The replacement PPS replaces the Westinghouse Eagle 21 process protection sets currently housed in Protection Racks 1 -16. Replacement architecture is illustrated in Figure 1-3. 1.1.5 Replacement PPS protective functions will be implemented in four (4) redundant protection sets, each using a software-based Triconex Tricon processor

[Figure 1-1] to mitigate events where the NRC-approved PPS Replacement Diversity and Defense in Depth Evaluation

[28] determined that diverse and independent automatic mitigating functions are available to mitigate the effects of postulated Common Cause Failure (CCF) concurrent with FSAR Chapter 15 events Figure 1-1 Tricon Triple Modular Redundant Architecture Auto Spare Auto$pare Input 1---t-+-..t Leg 1--+-+----1 Output Leg B Voter B Output Leg C Output Termination 1.1.6 For the events where the evaluation determined that diverse and independent automatic mitigating functions were not available and mitigation otherwise would require manual SCMP 36-01 Software Configuration Management Planfor PPS Replacement Re v 1 action, automatic protective functions will be performed in a diverse safety-related Westinghouse CS Innovations, LLC Advanced Logic System (ALS) [Figure 1-2]. Refer to the approved PPS Replacement Diversity and Defense in Depth Topical Report [28] for additional information regarding replacement diversity and defense in depth. Figure 1-2 1.2 Scope 1.2.1 Moved to Section 1.1.2 1.2.2 Deleted Generic ALS FPGA Architecture To ElIlernal Systillll S ASU O UT P UT BO A RD 1.2.3 This document specifies the software configuration management (SCM) activities that are to be done, who is responsible for doing specific activities, when they are to happen, and what resources are required.

It provides general instruction for developing and maintaining configuration control of replacement PPS hardware, firmware, software, interfaces and documentation.

This document establishes the basis for a uniform and concise standard of practice for the software configuration management process, based in part on I EEE Standard 828. This document will be updated as needed. 1.2.4 The Diablo Canyon specific implementation database resides in battery-backed memory in the Tricon and in non-volatile random access memory (NVRAM) in the ALS. The database consists of setpoints, tuning constants, gains, offsets, time delays, etc. The database is entered and updated in the respective PPS subsystems per approved plant procedures.

This Plan covers (1) the operating system firmware and the application programs of the Tricon PLC-based PPS subsystem; and (2) the FPGA and NVRAM configuration of the ALS FPGA-based PPS subsystem at DCPP. The plan includes the Diablo Canyon specific implementation database; i.e., tunable constants.

2 SCMP 36-01 Software Configuration Management Planfor PPS Replacement Rev 1 1.2.5 Configuration Items Controlled by this Plan 1.2.5.1 Tricon Subsystem The Tricon operating system comprises firmware that resides in the Tricon PPS subsystem processors.

The Tricon firmware is controlled and maintained solely by Triconex and any functional upgrades to the systems must be initiated through Invensys Operations Management (10M) per Section 3.2.2.3. The Tricon application program is developed by Triconex under their 10 CFR 50 Appendix 8 [1] QA program. Changes to the Tricon application program must be initiated through and performed by 10M. Tricon Subsystem Configuration Items controlled by this Plan include, but are not limited to the following: . 1. Release versions of Main Processor Units (MPU), Tricon Communication Module (TCM), and 110 boards 2. Application software versions including but not limited to the application program (PT2 File) that is unique to the Protection set in which it is installed.

3. Fiberoptic/Ethernet media converter (dipswitch settings) reference

4. NetOptics Port Aggregator Network Tap (dipswitch settings) reference 1.2.5.2 ALS Subsystem The FPGA-based ALS does not utilize software in the usual sense. The specific application is permanently "burned in" to the FPGA devices to create the PPS logic. The ALS configuration is controlled and maintained solely by Westinghouse/CSI and any functional changes or upgrades to the system must be initiated through and performed by Westinghouse/CSI per Section 3.2.2.3 of this SCMP. Each ALS board has two sets of NVRAM. The first NVRAM set contains data such as setpoints and tuning constants that can be altered by the technician using the ALS Service Unit (ASU) under an approved DCPP procedure.

The second NVRAM set contains the configuration for the particular ALS board. The configuration NVRAM can be changed only by removing the subject board from the ALS chassis and inserting it into a special test fixture. The test fixture will be used to configure the ALS boards for a specific protection set under an approved DCPP procedure.

ALS Subsystem Configuration Items controlled by this Plan include, but are not limited to the following:

1. Release versions( as applicable) for Chassis "A" and "8" Core Logic 80ard (CL8) and 110 boards 2. Core "A" and Core "8" CL8 FPGA versions (as applicable).

Each ALS chassis in each Protection Set contains a set of Core "A" or Core "8" CL8 and 110 boards as determined by the FPGA programming on that board. All Core "A" CL8 FPGA are identically programmed, and all Core "A" 110 boards of a given type have identically programmed FPGA. Similarly, All Core "8" CL8 FPGA are identically programmed, and all Core "8" 110 boards of a given type have identically programmed FPGA. Within a chassis, a Core "A" or Core "8" CL8 or 110 board is 3 SCMP 36-01 Software Configuration Nianagement Planfor PPS Replacement configured for its specific function within the chassis by its NVRAM as described above. 3. CLB and 1/0 Board NVRAM versions and contents (as applicable)

4. TAB configuration (as applicable)

5. Transmit Bus (TxB1 and TxB2) configuration (as applicable) 1.2.5.3 PG&E Supply Rev 1 PG&E-supplied Configuration Items controlled by this Plan include, but are not limited to the following:

1. Tricon MWS unmanaged Ethernet switch 2. Tricon and ALS MWS computer 3. Port aggregator network tap 4. KVM Switch 5. MWS keyboards

6. MWS mice 7. MWS video 8. Touchscreen

9. Printer 4 SCMP 36-01 Software Configuration Management Plan for PPS Replacement Rev 1 Isolated (independent) 4*20 mAdc analog output signals:

• Steam line Pressure

• Steamflow

• SfG Level

• PZR Level

• PZR Pressure

• Turbine Impulse Pressure

• Wide Range Pressure For:

• Post Accident Monitoring

• Control Board Recorders

& Indicators

• Control Systems i Replacement

.!

Prot Set I Sensors RTS ESF To SSPS TrainA Input Chassis I To SSPS TrainS Input Chassis I Figure 1 .. 3 PPS Replacement Architecture Prot Set II Sensors RTS ESF TrainA Input Chassis II EXisting SSPS Logic Cabinet A (RNSLA) SSPS Output Cabinet A ESF"A" Actuators TrainS Input Chassis II RNSLA RNSLB ManTripMS" Shunt Trip Prot Set III Sensors RTS ESF "' "' To To SSPS SSPS Train A Train B Input Chassis Input Chassis Reactor Trip BreakerRTA UVCoil Bypass Breaker BYB UVCoil III III Existing Reactor Trip Breakers (to Rod Control Cabinets) (from M-G Set) 5 RNSLB Man Trip Shunt Trip RNSLA Man Trip "A" Shunt Trip Prot Set IV Sensors RTS ESF To SSPS TrainA Input Chassis IV Existing SSPS Logic Cabinet B (RNSLB) SSPS Output Cabinet B ESF"B" Actuators To SSPS TrainS Input Chassis IV Separately Isolated (Independent) 4-20 mAde analog output signals for AMSAC: Narrow Range Steam Generator Level (4) Main Turbine First Stage Pressure (2) EXisting Diverse AMSAC AMSAC

• A" AMSAC "B Actuations Actuations Reactor Trip Breaker RTB UVCoil Bypass BreakerBYA UVCoil SCNfP 36-01 Software Configuration Management Planfor PPS Replacement Rev 1 1.3 Glossary 1.3.1 Definition of Terms Refer to IEEE 610.12-1990

[34] IEEE Standard Glossary of Software Engineering Terminology for definition of terms used in this document.

1.3.2 Abbreviations and Acronyms Term Definition ALS Advanced Logic System AS Application Sponsor ASU ALS Service Unit CCF Common Cause Failure CCP Configuration Change Package CI Configuration Item CLB Core Logic Board COTS Commercial Off-the-Shelf CSA Configuration Status Accounting CSI CS Innovations, Inc. CSP Cyber Security Plan DCP Design Change Package DCPP Diablo Canyon Power Plant DLAP Department Level Administrative Procedure EPROM Electrically Programmable Read Only Memory FCA Functional Configuration Audit FPGA Field Programmable Gate Array FRS Functional Requirements Specification I&C Instrumentation and Control ICE Instrument

& Controls Engineering IDAP Interdepartmental Administrative Procedure 10M Invensys Operations Management lOS Input Output System IRS Interface Requirements Specification LAN Local Area Network LBIE Licensing Basis Impact Evaluation MWS Maintenance Workstation 6

SCMP 36-01 Software Configuration Management Planfor PPS Replacement Rev 1 1.4 NVRAM Non-Volatile Random Access Memory PCA Physical Configuration Audit PO Program Directive PDN Plant Data Network PG&E Pacific Gas & Electric Company PLC Programmable Logic Controller PLS Precautions, Limitations, and Setpoints PMT Post Modification Testing PPS Process Protection System PSP Physical Security Plan SC System Coordinator RMS Records Management System SCM Software Configuration Management SCMP Software Configuration Management Plan SCP Software Change Package SOD Software Design Description SQA Software Quality Assurance SRS Software Requirements Specification SQAP Software Quality Assurance Plan V&V Verification

& Validation References

1. Title 10 Code of Federal Regulations Part 50, Appendix B, "Quality Assurance Criteria for Nuclear Power, Plants and Fuel Reprocessing Plants" 2. PG&E CF2 Computer Hardware, Software, and Database Control 3. PG&E CF2.ID2 Configuration Management for Computers and Software Used for Plant Operations and Operations Support 4. PG&E CF2.ID9 Software Quality Assurance Plan for Software Development

5. PG&E CF2.ID10 Administrative Controls for Access and Interface with Plant Digital Systems and Components

6. PG&E CF2.ID11 Cyber Security Assessment of Critical Digital Assets 7. PG&E CF3, Design Control Program Directive

8. PG&E CF3.ID9, Design Change Development

9. PG&E CF3.ID16, Specifications

10. PG&E CF3.ID13, Replacement Parts Evaluation and CITE 11. PG&E CF4, Modification Control Program Directive

12. PG&E CF4.ID1, Modification Request and Authorization 7

SCMP 36-01 Software Corifiguration Management Planfor PPS Replacement Rev 1 13. PG&E CF4.ID3, Modification Implementation

14. PG&E CF6.ID1 Setpoint Control Program 15. PG&E OM7.ID1 Problem Identification and Resolution

-Action Requests 16. PG&E TS3.ID2 Licensing Basis Impact Evaluations

17. PG&E AD7. DC8, Work Control 18. PG&E AD1 0.101 Storage and Control of Quality Assurance Records 19. NEI 01-01: Nuclear Energy Institute, "Guideline on Licensing Digital Upgrades:

EPRI TR-102348, Revision 1: A Revision of EPRI TR-120348 to Reflect Changes to the 10 CFR 50.59 Rule" 20. NEI-08-09, Rev 6, Nuclear Energy Institute, "Cyber Security Plan for Nuclear Reactors" 21. PG&E SCM 99-1, SCM Plan for I&C Digital Assets 22. PG&E SQA 99-5 Software Quality Assurance Plan for I&C Digital Assets 23. PG&E 663195-44, Process Protection System (PPS) Replacement Functional Requirements Specification (FRS) 24. PG&E PPS Interface Requirements Specification (IRS) 25. PG&E 1 011S-J-NPG, Controller Transfer Functions Design Input Specification

26. Deleted 27. PG&E 663229-47, Precautions, Limitations, and Setpoints

28. U.S. Nuclear Regulatory Commission, Letter "Diablo Canyon Power Plant, Unit Nos. 1 and 2 -Safety Evaluation for Topical Report, "Process Protection System Replacement Diversity

& Defense-In-Depth Assessment" (TAC Nos. ME4094 and ME409S)," April 19, 2011 (ADAMS Accession No. ML 110480845)

29. U.S. Nuclear Regulatory Commission, Letter, "Diablo Canyon Power Plant, Units* Nos. 1 and 2 -Issuance of Amendments RE: Approval of Cyber Security Plan (TAC Nos. ME4290 and ME4291), July 15, 2011, including approved Cyber Security Plan 30. Deleted 31. PG&E Diablo Canyon Power Plant Technical Specifications

32. Deleted 33. Deleted 34. IEEE Std. 610.12-1990 -IEEE Standard Glossary of Software Engineering Terminology.

35. U.S. Nuclear Regulatory Commission, Letter, "Diablo Canyon Power Plant, Unit Nos. 1 and 2 -Administrative Change to Facility Operating License in Conjunction with the Commission Order EA-06-037 and Revisions To Physical Security Plan, Training and Qualification Plan, and Safeguards Contingency Plan (TAC Nos. MD2219 and MD2220)," December 11,2006 (ADAMS Accession No. ML063480188) 8 SCMP 36-01 Software Configuration Management Planfor PPS Replacement Rev 1 2 Configuration Management The objective of managing configuration control is to assure the reliability of nuclear generation equipment.

Controlling configuration requires controlling change; i.e., all changes shall be auditable and authorized, and that all unauthorized changes shall be investigated.

2.1 Organization Overall DCPP Configuration Management organization and responsibilities for plant operations and operations support computers and software are described in PG&E CF2.ID2 [3]. This Plan describes more specific responsibilities as needed for PPS Replacement configuration management.

2.1.1 Application Sponsor (AS) The AS is the individual assigned by plant management that is the owner of the functional requirements for a system. For plant systems, an AS is not usually required or assigned as the functional requirements are a part of the plant design and are controlled via CF3. For data acquisition, test, and data retrieval applications, the AS is an individual that represents the users of the system, and is knowledgeable of what is required of the system [CF2.ID2 Section 4.1]. 2.1.2 System Coordinator (SC) The SC is the individual that coordinate(s) activities related to procurement, development, maintenance, and operation of a plant computer system [CF2.ID2 Section 4.1]. 2.1.3 System Team comprises the following DCPP engineering groups:

• Design Engineering

• Project Engineering

• Digital Systems Engineering

• Post Modification Testing (PMT) Engineering 2.2 Responsibilities 2.2.1 Technical Oversight

1. The Application Sponsor (AS) shall be responsible for implementing and updating this SCMP and the SOAP, overseeing development of and approving any required documentation, establishing access controls, approving configuration changes, and ensuring other related administrative tasks are performed.

The Application Sponsor is responsible for:

• Coordination of required DCPP SOA activities

• Self-assessments of SOA implementation

• Evaluating any maintenance or other activities that may lead to hardware or software changes

• Evaluating all new software releases from the vendor to determine if and when the software will be installed 9

SCMP 36-01 Software Configuration Management Planfor PPS Replacement Rev 1

• Evaluating, coordinating, implementation and documenting of software change requests by other plant departments

• Classifying software changes per the levels defined in Section 3.2.2. 2. The System Coordinator (SC) shall be responsible for the technical aspects of development and maintenance of the system and its associated peripherals and software.

The SC shall be qualified to perform a LBIE screen-related technical review of system change requests and packages, in accordance with TS3.ID2 [16]. The SC is responsible for the technical aspects of how system development and maintenance affect the Simulator system. The SC normally takes on the role of AS for applications installed on the system per plant design for changes that do not result in a change to the Functional Requirements Specification (FRS) of the application

[23]. Specifically, the System Coordinator is responsible for:

• Software design and modification

• Control of software documentation

• Evaluating the impact of hardware changes on system software.

• Ensuring modifications maintain the design bases of the PPS. 3. The System Team facilitates effective overall management of the PPS. System Team responsibilities include overall direction and management to ensure the PPS is operating properly and fulfilling its requirements.

System Team responsibilities include:

• Evaluation of PPS problems or failures

• Analysis of impact of industry events

• Monitoring material condition and problems within the system

• Supporting major audit activities

• Addressing nonconformances within the system

• Assisting prioritization of system work backlog

• Operability Evaluations

• System Walkdowns The AS, SC, and the System Team are responsible for classifying changes per Section 3.2.2. 2.2.2 Functional Changes The AS shall be responsible for implementing functional changes; i.e., changes that require modification to the FRS [23], IRS [24], or Controller Transfer Function Specification

[25] as described in Section 3.2.2. The AS shall have Qualification ENGDRI per Section 5.1 of CF3.ID9 [8]. Functional changes shall be documented with a Design Change Package (DCP) of sufficient detail 10 SClvfP 36-01 Software Configuration Management Planfor PPS Replacement to ensure baseline configuration is ascertainable at any time. Approved functional changes shall be installed in conformance with existing DCPP design change procedures.

2.2.3 Configuration Control Rev 1 The SC shall maintain configuration control. Application software and configuration (firmware, FPGA, NVRAM) modifications shall be performed by or under the direction of the SC and shall be documented with a Software Change Package (SCP) or Configuration Change Package (CCP) of sufficient detail to ensure baseline configuration is ascertainable at any time. Refer to SQA 99-5 [22] for further detail and instructions for developing SCP and CCP documentation.

Offsite vendors and other support personnel shall comply with this SCMP or a similarly approved plan when providing outsourced services on the system. 2.2.4 Problem Identification Software, hardware and configuration problems with the system shall be reported and documented per OM7.ID1 [15]. All problems are required by OM7.ID1 to be entered into an SAP (electronic business management software) notification (electronic tracking document).

Notifications can be identified as different Work Types in order to categorize the type of problem, the priority of the problem, and to facilitate routing the problem to appropriate personnel needed to review and resolve the problem. A "PROG PDCM" type notification is a program (PROG) plant digital configuration management (PDCM) type of problem. Software and configuration problems would typically be assigned a Work Type of "PROG PDCM" in the notification.

Plant hardware problems are typically assigned a Work Type of "EQPR" to identify the problem as an equipment problem. 2.3 Risks 2.3.1 Deploying Changes Testing and setup of configuration and software changes shall be performed on an asset that is not in service; i.e., the maintenance training system provided for this purpose. Comprehensive regression testing on an off-line development test platform shall be performed to the extent appropriate to the complexity of the change. 2.3.2 Contingency Planning In the event of emergencies, system failures or disaster, recovery of each component vital to the system shall be facilitated.

Software/Configuration backups shall be made at the discretion of the SC based on the frequency at which critical data and configurations are changing.

2.3.3 Media Control Valid backups shall be available to support recovery of any software-based portion of the PPS; that is, the Tricon and Maintenance Workstation (MWS). Installation media, license keys, backups, logical network diagrams and configuration information (such as ALS NVRAM images) shall be stored in a safe location, such as Source Safe. 11 SCNfP 36-01 Software Configuration Management Planfor PPS Replacement Rev 1 The Digital Systems Engineering SourceSafe is the repository for all committed project software, except the documentation listed in Section 3.2.4, which is contained in DCPP FileNET. The software repository contains the following typical file types 1:

• Executables

• Source code

• PLC and HMI program code

• lOS Kernel

• Setup and configuration files

• Database files

• Input files for software testing, verification testing and validation testing

• Test Case data files used for validation testing

• Scripts and post-processing utilities used for software testing

• ALS NVRAM images Microsoft SourceSafe requires special permissions to access the appropriate directory and then requires a login and special software to access the files. Where magnetic or optical media are used for storage of essential PPS files, the media shall be labeled and maintained by the SC such that the current version is readily identifiable.

To provide redundancy and data integrity, copies of media should be created and stored in physically separate locations, as appropriate.

The SC shall document and maintain local copies of restoration procedures for backup and disaster recovery.

2.4 Security 2.4.1 Physical Security Access to digital assets, system components, software libraries, portable devices, and removable media shall be controlled in accordance with the DCPP Physical Security Plan [35]. 2.4.2 Cyber Security User authentication and access to configuration, software and data shall be controlled in accordance with the DCPP Cyber Security Plan [29]. 1 This is a list of typical file types that reside in the SourceSafe.

The PPS may not use all file types listed. 12 SCMP 36-01 Software Corifiguration Management Plan/or PPS Replacement Rev 1 3 SCM Activities 3.1 Configuration Identification Configuration identification is the process of identifying and describing system elements in terms of its common and site-specific component parts, to include all hardware, firmware, software and associated documentation.

3.1.1 Configuration Items (Cis) Cis are an aggregation of reasonably mature hardware, software, Commercial Shelf (COTS) or database components that combine together to perform a specific function or functions.

Each CI is designated for configuration management control. 3.1.1.1 COTS Hardware COTS hardware products are identified by vendor names, part numbers, serial numbers, and drawing numbers. 3.1.1.2 COTS Software COTS software products are identified by vendor names, part numbers, version/revision numbers, serial numbers, installed locations, and any applicable installation parameters.

Configuration files developed for COTS software shall be maintained and controlled by the SC. 3.1.1.3 Databases Databases are defined by both their schema and their contents.

The database schema is managed and controlled as software.

The database contents are managed and controlled as configured articles, which can be categorized either as static parameters or dynamic data generated by the system. Static database parameters are controlled.

The contents of dynamic database files are not controlled.

3.1.2 Baselines A baseline is a logical grouping of configuration items that constitute the system. Baselines provide a fixed reference to specify the configuration items at a particular milestone event or point in time. The PPS baseline is the operating system, firmware, applications software, FPGA configuration, and database(s) prepared by the vendors (10M and Westinghouse/CSI) which define the system at specific milestones; i.e., at the time it is shipped, installed, and maintained in the plant. The baseline establishes an approved standard upon which subsequent work can be made. After the initial PPS baseline is established, changes to the baseline can only be performed through a formal change request process. The PPS database listing of all tunable constants will be maintained in the appropriate scaling calculation.

The current values of parameters updated by surveillance tests are obtained from, and documented by, the respective surveillance test procedure.

13 SCMP 36-01 Software Configuration Management Planfor PPS Replacement Rev 1 3.1.3 Backup and Disaster Recovery Libraries The Digital Systems Engineering SourceSafe is the repository for all committed project software.

Digital assets use magnetic and optical media for storage of files. Media shall be labeled and maintained by the SC such that the current version is readily identifiable.

To provide redundancy and data integrity, copies of media should be created and stored in physically separate locations, as appropriate.

The SC shall document and maintain local copies of restoration procedures for backup and disaster recovery.

3.1.4 Configuration Identification Documents Configuration identification documents support the configuration and development of a CI. These technical documents are used to establish baselines at specific milestones throughout the Iifecycle of the system. 3.1.4.1 Technical Documentation Types of technical documentation include:

• Functional and technical specifications (FRS, IRS, SRS, SDD, etc.)

• Drawings and parts lists

• Technical manuals (Users Manual, System Maintenance Manual, etc.)

• Management plans and procedures (SCMP, SQAP, etc.) 3.1.4.2 Software Configuration Manuals System-specific SCM information for the PPS shall be captured in the following SCM Manuals: a. The Tricon baseline configuration described in Section 1.2.5.1 for all four protection sets shall be captured and recorded in a specific Tricon SCM Manual that shall be prepared per the guidance of Section 6.0 of SCM 99-1 [21]. b. The ALS baseline configuration described in Section 1.2.5.2 for all four protection sets shall be captured and recorded in a specific ALS SCM Manual that shall be prepared per the guidance of Section 6.0 of SCM 99-1. c. The Tricon and ALS Maintenance Workstation (MWS) baseline configuration and other items described in Section 1.2.5.3 for all four protection sets shall be captured and recorded in a specific SCM Manual or manuals that shall be prepared per the guidance of Section 6.0 of SCM 99-1. Information to be captured in the SCM Manual shall include the detailed system baseline configuration, and specific installation and disaster recovery instructions for that system, in compliance with configuration identification and management expectations in Sections 3.1 and 3.2 of this document.

Guidance for preparation of SCM Manuals is provided in SCM 99-1 [21]. 14 SCMP 36-01 Software Configuration Management Planfor PPS Replacement Rev 1 3.2 Configuration Control Configuration control is a formal process for which a change to the specification of a CI is systematically proposed, evaluated, approved or disapproved, and implemented.

Configuration control is the means of ensuring that system baselines are accurate and known throughout the lifecycle of the system. 3.2.1 Requesting Changes All PPS modification requests shall be initiated and tracked per plant procedures or CF4.ID1 [12], as judged appropriate by the SC and AS for the level of modification.

3.2.2 Evaluating Changes (Classification of Modifications)

This Plan recognizes that modifications will be made to the System over its lifecycle.

It is expected that the modifications will vary in scope and complexity.

It is necessary, therefore, to assign a level to the various types of modifications.

The SC shall be responsible for assigning the levels to the modifications.

These levels are defined in the following paragraphs.

As defined below, Level 1 changes are minor software/configuration changes that do not modify system functionality.

Change package documentation, per CF2.ID2 [3], shall be generated for Level 1 minor software/configuration changes. The software change process is detailed in the Digital Systems Engineering SQA Plan for I&C Digital Assets [22]. Level 2 and Level 3 modifications are major software changes that require a 10 CFR 50.59 evaluation.

An in-depth potential software failure analysis shall be performed, per NEI 01-01 [19] guidance, to determine whether the proposed software change meets the evaluation criteria or poses potential consequences and risks that are significantly different than previously associated with the software.

If the analysis shows that any of the 10 CFR 50.59 criteria are not met, the licensee must submit a license amendment request to the NRC and needs to receive approval prior to implementation.

An approved Change Package is required prior to implementing any changes that modify the documented system baseline.

The Change Package documentation shall describe the issue being addressed by the change, the primary component(s) affected by the change and a brief summary of the approved changes. An SAP Notification and Order shall be utilized as the work authorization, per AD7.DC8 "Work Control" [17]. Modification information is recorded in the requesting SAP Notification.

The implementation of the change is documented in the associated Change Package and SAP Order. All records generated per this procedure shall be entered in the Record Management System (RMS) and handled as "Quality Records" per AD10.ID1 [18]. 15 SCNfP 36-01 Software Configuration Management Planfor PPS Replacement Rev 1 3.2.2.1 Level 1 Modification Level 1 modifications to the DCPP PPS database are controlled by plant procedures.

In general, such changes are parameter updates that are the result of surveillance tests or maintenance procedures, and specifically exclude any parameters controlled by the Technical Specifications, the Precautions, Limitations, and Setpoints (PLS) document [27], Engineering-Controlled Setpoints, or other plant design bases. These parameters include, but are not limited to the following:

1. NR and WR RTD coefficients and IRTD 2. PZR Vapor Temp RTD Coefficients and IRTD 3. NI current IBIAS 4. NR RTD Scan Status 5. OTDT and OPDT Turbine Runback Settings (within PLS Limits is a Level 1 change) 6. OTDT and OPDT Tuning Constants Full Load Loop DT (DELTA TO) and Full Load Tavg (T AVGO FULL OTSP, T AVG 1 FULL OPSP) 7. Streaming Factors (S1 STREAMING, S2 STREAMING, S3 STREAMING)

8. Hot and Cold Leg Deviation Check Setting (DEL T AH RSA, DEL T AC RSA) 9. Reactor Power Distribution Factor (SCAL FLUX CALlB) 10. Threshold for Application of Streaming Factors (PLOW BIAS CAL THR) 11. Steam Pressure Density Compensation Constants (a STM DENSITY COMP, b STM DENSITY COMP, STEAM DENSITY REF) 12. Trip Time Delay (TTD) Power Limit (TTD POWER HI LIMIT) (within Tech Spec Limits is a Level 1 change), and Full Power Delta-T (DELTA TO) 13. Comparator Deadbands

14. Streaming Factor Calc Lag (TAU8 STREAM LAG) 15. RCS Flow ranges (mx+b) 16. Steam Flow ranges (mx+b) 17. Calibration gains and offsets (Determined during Surveillance Test) 18. Steam flow cutoff threshold (SF DP LOW THRESHOLD)

Level 1 changes shall be made per the applicable plant procedure or program, and documented in the appropriate scaling calculations, with the exception of calibration gains and offsets. 3.2.2.2 Level 2 Modification A Level 2 modification to the System database, including but not limited to setpoint changes, the PLS, or other plant design bases. Level 2 modifications require a design change vehicle per CF4.ID1 [12] unless another procedure takes precedence.

Level 2 changes do not affect the safety function.

A design change vehicle per CF4.ID1 [12] is required for any modification to the PPS which will result in a revision to approved Drawings, design classification, functional requirements, installation specifications, test procedures, supplier drawings or 16 SCMP 36-01 Software Configuration Management Planfor PPS Replacement Rev 1 approved instruction manuals, and any other baseline documents, except for Level 1 modifications as discussed above. Level 2 modifications shall be made per CF4.ID1 [12], CF4.ID3 [13], and CF3.ID9 [8], unless the System Team agrees upon another, more appropriate design change vehicle. 3.2.2.3 Level 3 Modification A Level 3 modification installs revised PPS firmware, or FPGA release, which may in turn affect the application software or PPS configuration.

Tricon functional software alteration must be performed by Invensys Operations Management using approved 10M 10 CFR 50 Appendix B procedures.

ALS application changes must be performed by WestinghousefCSI using approved WestinghousefCSI 10 CFR 50 Appendix B procedures.

PG&E will not possess the hardware or software tools required to reprogram the ALS FPGA. Level 3 modifications shall be evaluated for Licensing Basis Impact per TS3.ID2 [16]. Should the manufacturer recommend a firmware or FPGA upgrade, the System Team shall coordinate the evaluation of the new releases per CF4.ID1 [12]. A determination shall be made as to whether or not to install the new firmware or FPGA release per CF4.ID1. Level 3 modifications shall be made per CF4.ID1 [12], CF4.ID3 [13], and CF3.ID9 [8]. 3.2.2.4 Tricon Circuit Board Replacement A Tricon MPU, TCM, or I/O board may be replaced with an identical board (i.e., same firmware release) per an approved DCPP procedure without a design change vehicle. 3.2.2.5 ALS Circuit Board Replacement The Core Logic Board (CLB) and I/O board Core "A" FPGA logic in Chassis "A" is the same for all four Protection Sets, as is the Core "B" logic in Chassis "B". Core "A" logic is not the same as Core "B" logic. The CLB and I/O boards are configured for the specific Protection Set through the on-board non-volatile RAM (NVRAM) outside the ALS chassis using specific hardware and software provided by WestinghousefCSI.

If a CLB or I/O board must be replaced, PG&E will configure the replacement board using an approved DCPP procedure before installing the new board in the ALS chassis. Like-for-like circuit board replacement is a maintenance activity that does not require a design change vehicle. Replacement of an ALS board requires configuration of the NVRAM on the board. The board may be replaced using an approved DCPP procedure without a design change vehicle provided that the FPGA logic has not been altered and both sets of NVRAM on the replacement board are configured identically to the NVRAM of the board being replaced.

3.2.3 Approving or Disapproving Changes The System Coordinator shall evaluate proposed changes and recommend approval or disapproval to DCPP management via approved procedures.

17 SCMP 36-01 Software Configuration Management Planfor PPS Replacement Rev 1 Implementing Changes 3.2.3.1 The SC shall determine when the modification will be installed (outage or during plant operation).

The SC shall be responsible for coordinating performance of the work with the Work Planning Center. The System Team may elect to have a vendor representative install modifications depending on the complexity.

If so, the SC will be the responsible work supervisor.

3.2.3.2 The SC will coordinate the implementation of the software changes. A temporary plant procedure may be used to implement, verify, and test the software changes. For minor changes, order instructions may be used to implement software changes provided that all changes are verified by a second qualified individual.

3.2.3.3 PPS application program and FPGA changes are performed by the manufacturers and are therefore subject to verification and validation (V&V) per manufacturer's procedures.

The manufacturers are responsible for preparing the necessary Verification and Validation Test Plan, and the V&V Test Report upon completion of V&V activities in accordance with their 10 CFR 50 Appendix B [1] software development procedures.

3.2.3.4 Level 1 and Level 2 changes shall be implemented using appropriate plant procedures with verification by a second qualified individual that the changes are consistent with the design. 3.2.3.5 The SC shall evaluate whether the software changes impact the Simulator.

If so, the Learning Services Simulator Group shall be notified by SAP Task, as appropriate.

3.2.3.6 An approved Change Package is required prior to implementing any changes that modify the documented system baseline.

The Change Package documentation shall describe the issue being addressed by the change, the primary component(s) affected by the change and a brief summary of the approved changes. 3.2.3.7 A SAP Notification and Order shall be utilized as the work authorization, per AD7.DC8 "Work Control" [17]. Modification information is recorded in the requesting SAP Notification.

The implementation of the change is documented in the associated Change Package and SAP Order. All records generated per this procedure shall be entered in the Record Management System (RMS) and handled as "Quality Records" per AD1 0.101 [18]. The RMS is used for permanent storage rather than change tracking.

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

3.2.4 Document Identification and Control 3.2.4.1 Document identification and control consists of placing all project documentation and drawings in a central location and maintaining a record of changes to those files. The NPG Library is the repository of project documents.

The DCPP/HBPP Drawing Library 18 SCMP 36-01 So/Mare Configuration Management Plan/or PPS Replacement is the repository of project drawings.

These repositories maintain a record of the document version number when a specific file was last changed. Rev 1 3.2.4.2 Documentation shall be generated for all firmware, software, and FPGA configuration changes that modify the functionality of the system, as required per procedure CF2.ID9 [4], and Program Directives CF3 [7] and CF4 [11]. The functionality of the PPS is defined in the FRS [23], IRS [24], and the Controller Transfer Function Specification

[25], ,f 3.2.4.3 Software Change Package (SCP) documentation is developed by the SC responsible for the software.

The SCP tracks completion of all tasks required to transition from one baseline to another. The SC shall update the SCM records with the revised CI baseline.

See SQA 99-5 [22] for further detail and instructions for developing SCP documentation.

3.2.4.4 Configuration Change Package (CCP) documentation is developed by the SC responsible for maintaining system hardware configuration.

This is used solely for changes in the configuration of equipment and not to initiate changes to compiled software.

The CCP details the requirements of the change, scope, specifications, testing and implementation.

The SC may update the SCM records with the revised configuration baseline, as appropriate.

See SQA 99-5 [22] for further detail and instructions for developing CCP documentation.

3.2.4.5 DCPP FileNET is the repository for the documentation listed in this section. Alllibrary users are allowed read access to the repository.

Only the project SC, AS or their designees may commit changes to files retained in the repository.

The software repository is SourceSafe per Section 2.3.3. 3.2.5 Interface Control Figure 3-1 provides a simplified illustration of PPS communications with external plant systems. Data products that flow between systems are subject to configuration management.

The SC of the source of the data (output) and the SC of each receiving system (input) are equally responsible for ensuring the continuity of the interface.

Interface management is captured in the Triconex SRS [1] and the ALS System Design Specification

[26] as well as the replacement PPS Interface Requirements Specification (IRS) [24] document.

Changes to an interface must be coordinated and agreed to by the SCs of all systems participating in that interface, whether provider or end user. 19 SCMP 36-01 Sofnvare Configuration Management Planfor PPS Replacement Class II Class I Triplicated RS-485 110 Bus (Copper) PratSet I Tricon Prot Set 1 Primary RXM Figure 3-1 PPS Communications (Simplified)

Not in PPS RElplaceme.nt Project Scope 100BaseT (Copper) s.xisting Gate'Yay C;omputer(s)

By PCS Project From From Prot Set II Port Prot Set III Port Aggregator Tap AggregatorTap (Typof2) (Typof2) RS-422 Cu from ALS _ ****** -/ Prot Set I ALS "A" ******* / Prot Set II ALS"A" ****** -/ Prot Set III ALS"A" ****** -/ Prot SetiV ALS "A" ******* -/ Prot Set I ALS "B" ******* -/ Prot Set II ALS"B" ******** -/ Prot Set III ALS "B" *********

-/ Prot Set IV ALS "B" From Prot Set IV Port Aggregator Tap (Typ of2) III [ I . ',00,," . D Prot Set I MWS* Video Display . _ HMI periPherals:

1 ! Printer f .. *j KVM Switch 12 .... 1 Analog/uSB

1 .: Copper ..--...,...L_-.:

...................

' 100BaseT (Copper) (Typ of 2) Optical Fiber I TCM1 (7L)fTCM2 (7R) _I. NET2 , (Typ of 2) Class II TCM1 (7L) TCM2(7R) NET1 (Not Used) Class I 4-20 mA Analog RTD Signals (Typ for ALS

• A" andALS "B") TxB2 RS-422 : (Typfor ALS "A" 1

! I TestALS Bus (TAB) Physically disconnected when not in use I -.

\ . i RS-485 \ .' !:::;::: .. / TxB1 RS-422 to Existing ;..........................

Gateway Computer : (Typ for ALS "A" and ALS "B') ,: I. R8-422 Class II (Except TAB) Class I L .. 0000000000000 IIIDIIll mom Prot Set I ALS Prot Set 1 Remote RXM Class I Class II 20 Legend: MWS NIC Multi*Mode Optical Fiber RS*422JRS-485 Serial or 100BaseT Copper 4*20 mA Analog Copper Maintenance Workstation Network Interface Card Rev 1 SCMP 36-01 Software Configuration Management Planfor PPS Replacement Rev 1 3.2.6 Testing 3.2.6.1 Post Modification Testing a. For Level 1 modifications, the applicable plant procedure should include appropriate documentation of steps performed.

Changes are documented by a performer and verified by a second qualified individual that changes have been entered correctly, and successful completion of the appropriate surveillance or maintenance test, if required.

b. For Level 2 modifications, the PMT requirements of CF3.ID9 [8] are sufficient.

Determination of PMT requirements shall include an evaluation of impact on Technical Specifications, PLS, or other plant design bases. All applicable surveillance tests shall be completed successfully.

c. For Level 3 modifications, guidance shall be obtained from the manufacturers and such guidance shall be included in the PMT requirements for the DCP. d. Following a like-for-like EPROM, FPGA, or NVRAM replacement, PMT shall include the performance of at least one surveillance test on a channel affected by the replacement.

PMT shall also include verification that the database is consistent with the controlled database in the appropriate scaling calculations.

3.2.6.2 Surveillance Testing Prior to being placed in service and declared OPERABLE and at all times thereafter when required to be OPERABLE, the PPS shall pass all applicable surveillance tests required to meet Technical Specifications

[31]. 3.2.7 Code Control 3.2.7.1 Triconex Code Control The Triconex PPS subsystem operating system, firmware, and PPS application source code is strictly under 10M control. PG&E cannot make any changes to the operating system, firmware, or application source code. The Tricon application source code is documented in accordance with the Tricon SRS [1] and SOD [33], which are provided to PG&E for review and approval.

3.2.7.2 ALS Code Control The ALS PPS subsystem FPGA configuration is strictly under Westinghouse/CSI control. PG&E cannot make any changes to the FPGA configuration.

The FPGA configuration is provided in the ALS System Design Specification

[26]. 3.2.8 Disaster Recovery Maintaining the PPS database listing in the appropriate scaling calculations per Section 3.2.11.2, and spare parts availability discussed in Section 3.2.11.3 ensure that means exist to recover software, data and documentation after it has been damaged (e.g., fire, loss of power, earthquake, etc.). The object is to quickly and efficiently recreate the baseline that was present just prior to the loss. 3.2.9 Problem Reporting and Corrective Action All identified problems and their corrective action shall be tracked to completion using a notification.

The System Team shall follow the requirements contained in OM7.ID1 [15]. 21 SCMP 36-01 Software Configuration Nfanagement Planfor PPS Replacement Rev 1 3.2.10 Supplier Control 3.2.10.1 The Tricon and ALS hardware, software, FPGA and future releases are produced in accordance with the respective manufacturer 10 CFR 50 Appendix 8 [1] QA program. 3.2.10.2 The evaluation, purchase and installation of PPS hardware and firmware releases after those shipped with the system shall be the responsibility of the SC. 3.2.11 PPS Configuration Management 3.2.11.1 PPS Hardware and Firmware/Operating System Configuration

a. The Tricon baseline configuration described in Section 1.2.5.1 for all four protection sets shall be captured and recorded in a specific Tricon SCM Manual that shall be prepared per the guidance of Section 6.0 of SCM 99-1 [21]. b. The ALS baseline configuration described in Section 1.2.5.2 for all four protection sets shall be captured and recorded in a specific ALS SCM Manual that shall be prepared per the guidance of Section 6.0 of SCM 99-1. c. The Tricon and ALS Maintenance Workstation (MWS) baseline configuration and for other items described in Section 1.2.5.3 for all four protection sets shall be captured and recorded in a specific SCM Manual or manuals that shall be prepared per the guidance of Section 6.0 of SCM 99-1. 3.2.11.2 PPS Database The current PPS database listing of all tunable constants shall be maintained by the SC in the appropriate scaling calculations.

3.2.11.3 Spare Parts The System Coordinator shall be responsible for ensuring that a supply of spare parts is available in the warehouse at all times. The SC shall coordinate with the DCPP Materials Department to ensure that the proper stock codes are assigned to replacement parts. 3.2.11.4 Replacement Parts Evaluation Replacement PPS components which are different from those shipped with the system would normally be considered to be Level 2 modifications.

As described in Section 3.2.2.2, such Level 2 modifications require a Design Change Vehicle to be prepared per CF4.ID1 [12]. If the replacement parts meet the following criteria, use of the Replacement Parts Evaluation process per CF3.ID13 [10] is an acceptable design change vehicle: a. The replacement parts are equivalent to the original in form, fit, and function; and b. The replacement parts do not affect PPS safety function; and c. The replacement parts do not modify the PPS application program or FPGA or DCPP specific database.

22 SClYfP 36-01 Software Configuration Management Planfor PPS Replacement Rev 1 3.2.11.5 System Hardware Modifications

a. The SC shall be responsible at all times to ensure that changes to the physical characteristics and installed configuration of the PPS are accurately documented, as discussed in previous sections of this procedure.

b. If modifications are required due to replacement parts, and are equivalent to the original configuration in form, fit, and function, the RPE process may provide an acceptable design change vehicle. See Section 3.2.11.4.

3.3 Configuration Status Accounting Configuration Status Accounting (CSA) is a means by which enhancements/changes and new versions/revisions of configuration items are identified, recorded and tracked. Configuration status accounting activities collect data that can be used to measure various aspects of program effectiveness and to assess product completeness and quality. A CSA system is already established with existing Program Directives (PDs), Departmental Administrative Procedures (lDAPs) and Department-Level Administrative Procedures (DLAPs). The status of proposed changes will be progressively tracked through approval and implementation in Change Package documentation.

These records* provide traceability between Configuration Item versions and associated documentation.

Section 3.2.3.7 describes the process and procedures for initiating and tracking changes and for entry of quality records into the Record* Management System for permanent storage. 3.3.1 Software Release Process Every approved new software release shall be tagged with a specific version number and committed to the Digital Systems Engineering SourceSafe repository

[Section 2.3.3]. Revisions will be tagged with an incremented version number. 3.3.2 SCM Metrics Reports The purpose of SCM metrics is to measure SCM and system status and performance.

Data from metrics may also be used to understand problems and inefficiencies in processes, and to provide insight for making necessary corrections and improvements.

The types of metrics reports that portray system health and status include the following:

• Baseline Elements / Device Inventory

/ Software Version Levels

• Change Request Reporting

/ Aging / Trends

• Change Process Compliance

• Change Rate / Change Variance / Changes by Severity

• Changed Elements (Cis) / Detailed Changes / Frequently Changed Elements

• CI Compliance History 3.4 Configuration Auditing Configuration auditing ensures that the technical and administrative integrity of the system is being maintained throughout the lifecycle of the system. Configuration management assessments and internal reviews will be conducted on a periodic basis to determine to what 23 SCMP 36-01 Software Configuration Management Planfor PPS Replacement Rev 1 extent the actual hardware, firmware, software and documentation reflect the required physical and functional characteristics of the system. These activities are formal examinations of the built system compared to the as-required system. The SC shall participate in all baseline assessments and reviews, report any resulting discrepancies, and track any advised corrective actions. Compliance is demonstrated by audit results. The SC may conduct audits at defined project milestones, such as new product releases and phase upgrades.

The SC may also periodically conduct targeted spot check audits, as initiated by complaint or event. 3.4.1 Functional Configuration Audit (FCA) Per Section 3.5.1 of SCM 99-1 [21], the FCA verifies that the performance of the installed PPS meets the approved requirements specifications.

This formal audit is required at the end of all testing just before deployment into a production environment.

Test results may serve as validation of functional compliance.

The Surveillance Testing that is performed periodically on the PPS to ensure that it is performing the safety functions mandated by Technical Specifications together with Post Modification Testing per Section 3.2.6.1 are equivalent to the FCA described above. A formal FCA need not be performed.

3.4.2 Physical Configuration Audit (PCA) The PCA verifies that the actual configuration of the installed PPS matches the documented PPS configuration design. The resulting report of this formal audit may be used to establish the baseline.

The SCM Manuals required by Sections 3.1.4.2 and 3.2.11.1 contain the documented PPS configuration.

The SCM Manuals should be audited periodically, to compare the as-built PPS configuration to the documented configuration as described in Section 3.4, above. Discrepancies should be resolved by updating the SCM Manual or correcting the configuration per approved procedures.

3.4.3 Audit Reports Audit findings detailing the compliance posture of the system are reported to management and communicated to appropriate system team members. Audited items that are not in compliance with the configuration management standards within the SCM Plan are tracked in SAP until they are resolved.

Once all discrepancies have been resolved, the audit will be closed. Audit records shall be retained for at least three calendar years. 4 SCM Schedules Configuration management activities will occur iteratively throughout the product lifecycle for each system increment and release. 4.1 Project Milestones

• Initial production delivery to operations

• Phased upgrades

• Repairs/Replacement 24 SCMP 36-01 Software Configuration Management Planfor PPS Replacement

• Obsolescence/Decommission 4.2 Audit Acceptance Criteria

• SCM policies, procedures and practices are being followed

• Approved changes to hardware, software and documentation are properly implemented Rev 1

• The as-built documentation of each CI agrees with the as deployed configuration, or that adequate records of differences are available at all times.

• The as-built configuration compares directly with the documented configuration identification represented by the detailed CI specifications.

• Test results verify that each product meets its specified performance requirements to the extent determinable by testing.

• The as-built configuration being installed compares with the final tested configuration.

Any differences between the audited configuration and the final tested configuration are documented.

• When not verified by test, the compatibility of products with interfacing products or equipment is established by comparison of documentation with the interface specifications which apply.

• COTS software products are included in formal audit as integral parts of the system baseline.

• A post-audit report is written outlining the specific items audited, audit findings, and corrective actions to be taken. All action items are tracked to closure. 5 SCM Resources 5.1 Software Tools The following tools are used to manage system configurations at DCPP:

• Microsoft Visual SourceSafe

-Archive, retrieval and release of source code, configuration files, backups, disaster recovery files

• Triconex TriStation 1131 Developer's Workbench With respect to configuration management the TS1131 may be used for verification of application version, downloading a new application or downloading the current version for disaster recovery.

The TS1131 Developer's Workbench may only be used to alter the application resident in the Tricon as a Level 2 or Level 3 modification.

All the above activities require the work to be performed by trained personnel using an approved DCPP process. The manufacturers may utilize other tools during application development.

Such tools are not documented in this Plan because they are not used by PG&E. 25 SCMP 36-01 Software Configuration Management Planfor PPS Replacement Rev 1 5.1.1 Vendor Products Per CF3.ID16 [9], vendor products selected for implementation must show evidence through test results that they meet functional and physical requirements.

Additionally, all vendor products must show a history of reliability, availability and supportability, as required by the project. The vendor will supply a plan specifying how license agreements, leased products, warranties and vendor support will be transferred to adequately provide for continued maintenance and support of all vendor products throughout the lifecycle of the system. Problems associated with COTS software products are recorded, dispositioned, and corrected with vendor assistance as required.

5.1.1.1 Unmodified COTS Software Unmodified COTS software is delivered with the vendor's standard documentation package, including historical change data. COTS software upgrades initiated by the vendor are reviewed for acceptability by the responsible SC before they are implemented.

Media and licenses for unmodified COTS software are physically stored in the computer program library. Unmodified COTS software is released by the SC to users in accordance with the provisions of the licensing agreement.

5.1.1.2 Vendor-Modified COTS Software In some cases, the COTS software vendor is contracted to incorporate changes into COTS software in accordance with Project specifications.

COTS software modified by the vendor is delivered with addendum documentation describing the changes from the off-the-shelf product. Media and licenses for COTS software modified by the vendor are physically stored in the computer program library. Vendor-modified COTS software is released by the SC to users in accordance with the provisions of the licensing agreement.

5.1.1.3 Project-Modified COTS Software In some cases, the Project will secure the license to modify COTS software and obtain rights to the source code to permit the responsible development organization to modify the COTS software.

Project-modified COTS software is maintained by the SC and documented by addendum documentation as necessary to define the changes from the off-the-shelf product. Media and licenses are physically stored in the computer program library. modified COTS software is released by the SC to users in accordance with the provi$ions of the licensing agreement.

5.2 Equipment and Techniques 5.2.1 Development/Operating Environments The Learning Services Simulator Group maintains a training simulator environment and the Digital Systems Engineering Group maintains a development test lab. Software for the training simulator is controlled by the training section. Software for the development test lab is controlled by the SC. 26 SCAlP 36-01 Software Configuration Management Planfor PPS Replacement Rev 1 The SC shall distribute copies of all hardware and software modification packages to the training section for their information and use. There are no procedural controls on the software for the Training Unit. Configuration of the Training Unit software will be the responsibility of the training section. 5.2.2 Supporting Infrastructure The Diablo Canyon file server has a partitioned area on the S-drive reserved for use by Engineering Services.

Electronic documentation and drawing libraries are hosted in the DCPP/HBPP Drawing Library. Change request notifications and orders are hosted in SAP. The system software library is hosted on the Digital Systems Engineering Group's SourceSafe server 5.3 Personnel and Training The system coordinator shall ensure that all individuals who will be using the system software have received the level of training necessary to perform the required task. This will include cognizant engineers and technicians.

6 SCM Plan Maintenance SCMP maintenance is necessary to document software configuration management activities throughout the software lifecycle.

If any requirements defined in this document are changed, those changes shall be updated in the SCMP as needed. Reviews of the SCM Manual shall occur periodically throughout the software lifecycle.

At a minimum, an update shall occur concurrently with every major product change. As part of the document review process, a physical walkdown of the system shall be performed to verify and validate the accuracy of the baseline configuration.

All changes to the SCMP and SCM Manuals shall be disseminated to the appropriate user community in a timely manner. 6.1 Oversight The SC is responsible for monitoring compliance and ensuring that changes and updates are reflected in this Plan and the SCM Manuals as required.

27 SCMP 36-01 Software Configuration Management Planfor PPS Replacement Rev 1 ATTACHMENT 1: SCM Manual Outline This outline is intended as a guideline.

The SCM Manual may be tailored to accommodate the needs of the specific system as long as the content is in compliance with the requirements of this document.

Distinctions between Unit 1 and Unit 2 shall be clearly indicated.

Refer to SCM-23-01-SR as an example of a completed SCM Manual. 1. System Overview

• Block diagram of basic architecture, such as: o Communications o Externallnterfaces

• Drawings and/or photos of physical cabinets/system panels

• Identification of safety-related vs. non-safety-related components

• Applicability to Unit 1 and/or Unit 2 2. Reference Documents

• Requirement Specifications

• Design Specifications

• Applicable ECG & Tech Specs

• Drawings

• User Manuals 3. Hardware Configuration Baseline

• Module model numbers

• Chassis slot positions

• Switch settings

• Network/Communications settings 4. 1/0 Configuration Baseline

• I/O type, module, slot, channel

• Signal range

• Scaling S. Software Configuration Baseline

• OS and Application filenames, version, patch levels

• Operation parameters

6. Installation Instructions

• OS services enabled/disabled

• Application custom settings

• Network/Communications setup 7. Disaster Recovery Instructions

• Time-ordered sequence of steps

• Backup file location 28