DCL-13-028, Diablo Canyon, Units 1 & 2, Process Protection System (PPS) Replacement System Verification and Validation Plan (Syvvp) Nuclear Safety Related, Revision 1.

From kanterella
(Redirected from ML13093A312)
Jump to navigation Jump to search
Diablo Canyon, Units 1 & 2, Process Protection System (PPS) Replacement System Verification and Validation Plan (Syvvp) Nuclear Safety Related, Revision 1.
ML13093A312
Person / Time
Site: Diablo Canyon  Pacific Gas & Electric icon.png
Issue date: 02/19/2013
From:
Pacific Gas & Electric Co
To:
Office of Nuclear Reactor Regulation
References
DCL-13-028
Download: ML13093A312 (33)
v • d • e


Text

Attachments 9-14 to the Enclosure contain Proprietary Information

-Withhold Under 10 CFR 2.390 Enclosure Attachment 1 PG&E Letter DCL-13-028 PG&E Document "Process Protection System (PPS) Replacement System Verification and Validation Plan (SyWP)," Revision 1 Attachments 9-14 to the Enclosure contain Proprietary Information When separated from Attachments 9-14 to the Enclosure, this document is decontrolled.

Pacific Gas & Electric Company Diablo Canyon Power Plant Units 1 & 2 Process Protection System (PPS) Replacement System Verification and Validation Plan (SyVVP)Nuclear Safety Related Rev 1 Prepared Sig.Print Last Name Reviewed Sig.Print Last Name QA Supv. Sig.Print Last Name Approval Sig.Print Last Name Date User ID Date User ID Date User ID Date User ID 02/18/2013 JWH3 0 aI// 7/Izo01g 07j/Ig 7-013.~kJ PPS Replacement System Verification and Validation Plan (SyWP) Rev 1 Page 1 of 23 REVISION HISTORY Revision Affected Reason for Revision Number Pages 0 All Initial Issue Section 2.2.1.5 Added CF3.1D16 per Section 5.1.1 changes Section 2.2.1.6 Added CF3.1D17 per Section 5.1.1 changes Section 2.2.1.7 Added 0M7.1D1 per NRC 01 #48 Section 2.2.1.9 Added CF7.1D4 per Section 5.1.1 changes Figure 4-1 Revised to match PPS Project Plan Rev 2 per NRC 01 #39 Section 4.1

  • Edited to clarify roles of Project Engineering and EoC per NRC 01 #38* Revised and formatted for consistency with SyQAP discussion of PG&E Roles and Responsibilities Figure 5-1 Updated figure to clarify lifecycle phases per NRC 01 #26 Section 5.1.1 Clarified CDD preparation, development and review per NRC 01#43: 5.1.3 Clarified control procedure used tor O&M phase V&V activities per 5.1.4 NRC 01 #42.Section 6 Added reference to 0M7.1D1 per NRC 01 #48 Section 7 Section 7 Clarified approval of deviations from SyWP per NRC 01 #48 Various Clarified responsibilities of PG&E as DCPP owner and operator.

PPS Replacement System Verification and Validation Plan (SyVVP) Rev 1 Page 2 of 23 Table of Contents 1. PURPO SE ..........................................................................................................................................

3 1 .1 S C O P E .............................................................................................................................................

3 1 .2 G O A L S .............................................................................................................................................

3 2. REFERENCE DO CUM ENTS .....................................................................................................

4 2.1 DEVELOPMENTAL REFERENCES AND STANDARDS

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

4 2.1.1 Regulatory Standards

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

4 2.1.2 Industry Standards

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

4 2.2 CONTROL PROCEDURES

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

6 2.2.1 PG &E Control Procedures

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

6 2.2.2 10 CFR 50 Appendix B Supplier Control Procedures

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

6 3. DEFINITIO NS .....................................................................................................................................

8 4. O RGA NIZATIO N .............................................................................................................................

16 4.1 PG &E ROLES & RESPONSIBILITIES

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

16 4.2 10 CFR 50 APPENDIX B SUPPLIER ROLES AND RESPONSIBILITIES

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

16 5. V&V PRO C ESSES ...........................................................................................................................

17 5.1 PG &E TASKS .................................................................................................................................

17 5.1.1 Concept Phase ......................................................................................................................

17 5.1.2 Installation and Checkout Phase ......................................................................................

18 5.1.3 Operation Phase V& V Tasks ...........................................................................................

20 5.1.4 M aintenance Phase V&V Tasks ......................................................................................

20 5.2 1 OC FR50 APPENDIX B SUPPLIER TASKS .........................................................................................

22 6. V&V REPO RTING REQ UIREM ENTS .........................................................................................

22 7. V&V A DM INISTRA TIVE REQ UIREM ENTS ................................................................................

23 8. V&V DO CUM ENTATIO N REQ UIREM ENTS ..............................................................................

23 PPS Replacement System Verification and Validation Plan (SyWP) Rev 1 Page 3 of 23 1. Purpose The purpose of this System Verification and Validation Plan (SyVVP) is to establish the goals, processes, and responsibilities required to implement effective system level verification and validation for the Process Protection System (PPS) Replacement Project at Diablo Canyon Power Plant (DCPP). This SyWP provides a plan for specifying, evaluating, controlling, and maintaining the overall design for the PPS replacement at Diablo Canyon Power Plant. This plan applies to PG&E Concept Phase activities and to post-FAT activities performed by PG&E prior to the PPS being placed in service, when the Operations and Maintenance Phases begin.The current Eagle 21 PPS is a digital microprocessor-based system. The proposed PPS replacement consists of the microprocessor-based Tricon Programmable Logic Controller (PLC) and the field programmable gate array (FPGA) based Advanced Logic System (ALS). The microprocessor-based Tricon PLC portion of the platform utilizes software to direct the PLC to perform its intended safety-related functions.

The ALS portion of the platform is hardware logic-based and does not utilize software.11.1 Scope Software used in the Triconex portion of the PPS replacement is Nuclear Safety-Related and requires quality controls to meet SIL 4 as defined in IEEE-1012-1998

[2.1.2.25].

The Triconex product development process is specifically tailored to development of software used in designing and maintaining programmable logic devices (PLDs). The FPGA-based ALS does not utilize a microprocessor and does not execute software.

However, the FPGA is configured using software tools;therefore a quality control procedure must be used in the development of the FPGA.This SyWP describes activities performed by the three responsible parties: PG&E, Invensys Operations Management (IOM), and Westinghouse/CS Innovations, LLC (CSI). The Triconex portion of the PPS replacement is provided by IOM. The ALS portion is provided by CSI.Both suppliers have 10 CFR 50 Appendix B QA programs.

Respective V&V activities are governed by the Triconex Nuclear Safety-Related Process Protection System Replacement DCPP Software V&V Plan (SWP) [2.2.2.4], the ALS W Plan [2.2.2.1], the ALS DCPP Management Plan [2.2.2.2], and the ALS DCPP Test Plan [2.2.2.3].

These plans have been reviewed and accepted by PG&E to ensure that the V&V effort is complete.This SyWP implements guidance described in IEEE Standard 1012-1998, Software Verification and Validation Plans [2.1.2.25]

as relevant to the PPS Replacement Project.1.2 Goals PG&E will perform initial Concept phase development activities as described later in this SyVVP. The outputs of this phase will be utilized by the 10 CFR 50 Appendix B suppliers in accordance with their approved procedures to develop, implement, and test the respective systems. The supplier activities and products will be traceable to the PG&E design input documents.

The 10 CFR 50 Appendix B suppliers will verify and validate their respective systems to ensure that all safety functions are traced to their requirements and are acceptable per their respective control procedures.

PG&E will review and accept the products of the 10 CFR 50 Appendix B supplier development and implementation V&V activities and will use the results to complete the overall PPS Replacement Project V&V activities.

Upon completion of all V&V activities PG&E will issue a final System Verification and Validation Report (SyWR).

PPS Replacement System Verification and Validation Plan (SyWP) Rev 1 Page 4 of 23 2. Reference Documents 2.1 Developmental References and Standards 2.1.1 Regulatory Standards 2.1.1.1 U.S. Regulatory GuidanceNUREG-0800 BTP 7-14, Branch Technical Position:

Guidance on Software Reviews for Digital Computer-Based Instrumentation and Control Systems, Revision 5, March 2007.2.1.1.2 NUREG/CR-6101, Software Reliability and Safety in Nuclear Reactor Protection Systems, November 1993.2.1.1.3 NUREG/CR-6430, Software Safety Hazards Analysis, February 1996.2.1.1.4 Regulatory Guide 1.118, Periodic Testing of Electric Power and Protection Systems, Revision 3, April 1995 2.1.1.5 Regulatory Guide 1.152, Criteria for Use of Computers in Safety Systems of Nuclear Power Plants, Revision 3, July 2011.2.1.1.6 Regulatory Guide 1.153, Criteria for Safety Systems, Revision 1, June 1996 2.1.1.7 Regulatory Guide 1.168, Verification, Validation, Reviews, and Audits for Digital Computer Software Used in Safety Systems of Nuclear Power Plants, Revision 1, February 2004 2.1.1.8 Regulatory Guide 1.169, Configuration Management Plans for Digital Computer Software Used in Safety Systems of Nuclear Power Plants, September 1997 2.1.1.9 Regulatory Guide 1.170, Software Test Documentation for Digital Computer Software Used in Safety Systems of Nuclear Power Plants, September 1997 2.1.1.10 Regulatory Guide 1.171, Software Unit Testing for Digital Computer Software Used in Safety Systems of Nuclear Power Plants, September 1997 2.1.1.11 Regulatory Guide 1.172, Software Requirements Specifications for Digital Computer Software Used in Safety Systems of Nuclear Power Plants, September 1997 2.1.1.12 Regulatory Guide 1.173, Developing Software Life Cycle Processes for Digital Computer Software Used in Safety Systems of Nuclear Power Plants, September 1997 2.1.1.13 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, November 2002 2.1.1.14 Interim Staff Guide DI&C-ISG-01, Cyber Security, Revision 0 2.1.1.15 Interim Staff Guide DI&C-ISG-02, Diversity and Defense-in-Depth Issues, Revision 2, June 2011 2.1.1.16 Interim Staff Guide DI&C-ISG-04, Highly Integrated Controls Rooms-Communications Issues (HICRc), Revision 1, March 2009 2.1.1.17 Interim Staff Guide DI&C-ISG-06, Licensing Process, Revision 1, January 2011 2.1.2 Industry Standards 2.1.2.1 ANSI/IEEE Std. 983-1986, IEEE Guide for Software Quality Assurance Planning 2.1.2.2 ANSII/ISO/ASQ Q9001-2000, Quality management systems -Requirements PPS Replacement System Verification and Validation Plan (SyWP) Rev 1 Page 5 of 23 2.1.2.3 ANSI/ISO/ASQ Q9004-1-1994, Quality Management and Quality System Elements -Guidelines 2.1.2.4 ASME NQA-1-1994, 1997, Quality Assurance Requirements for Nuclear Facility Applications 2.1.2.5 EPRI TR-103291, Handbook of Verification and Validation for Digital Systems, Revision 1, December 1998 2.1.2.6 EPRI TR-108831, Requirements Engineering for Digital Upgrades 2.1.2.7 NEI 08-09, Revision 6, Cyber Security Plan for Nuclear Reactors 2.1.2.8 IEEE Std. 7-4.3.2-2003 IEEE Standard Criteria for Digital Computers in Safety Systems of Nuclear Power Generating Stations, Appendix D (Informative)

Identification and Resolution of Hazards 2.1.2.9 IEEE Std. 279-1971, Criteria for Protection Systems for Nuclear Power Generating Stations 2.1.2.10 IEEE Std. 308-1971, Criteria for Class 1E Electric Systems for Nuclear Power Generating Stations 2.1.2.11 IEEE Std. 323-1974, IEEE Standard for Qualifying Class 1E Equipment for Nuclear Power Generating Stations 2.1.2.12 IEEE Std. 338-1987, IEEE Standard Criteria for the Periodic Testing of Nuclear Power Generating Station Protection Systems 2.1.2.13 IEEE Std. 344-1987, Recommended Practices for Seismic Qualification of Class 1 E Equipment for Nuclear Power Generating Stations 2.1.2.14 IEEE Std. 379-1977, IEEE Application of Single Failure Criterion to Nuclear Power Generating Station Class 1E Systems 2.1.2.15 IEEE Std. 384-1981, IEEE Trial-Use Standard Criteria for Separation of Class 1E Equipment and Circuits 2.1.2.16 IEEE Std. 352-1987, IEEE Guide for General Principles of Reliability Analysis of Nuclear Power Generating Station Safety Systems 2.1.2.17 IEEE Std. 497-2002, IEEE Standard Criteria for Accident Monitoring Instrumentation for Nuclear Power Generating Stations 2.1.2.18 IEEE Std. 577-1976, IEEE Standard Requirements for Reliability Analysis in the Design and Operation of Safety Systems for Nuclear Power Generating Stations 2.1.2.19 IEEE Std. 603-1991, IEEE Standard Criteria for Safety Systems for Nuclear Power Generating Stations 2.1.2.20 IEEE Std. 730-2002, Standard for Software Quality Assurance Plans 2.1.2.21 IEEE Std. 828-1998, Software Configuration Management Plans 2.1.2.22 IEEE Std. 829-1983, Standard for Software Test Documentation 2.1.2.23 IEEE Std. 830-1993, Recommended Practice for Software Requirements Specifications 2.1.2.24 IEEE Std. 1008-1987, IEEE Standard for Software Unit Testing 2.1.2.25 IEEE Std. 1012-1998, Standard for Software Verification and Validation 2.1.2.26 IEEE Std. 1016-1997, Recommended Practice for Software Design Descriptions 2.1.2.27 IEEE Std. 1028-1997 (reaffirmed 2002), Standard for Software Reviews 2.1.2.28 IEEE Std. 1042-1987, ANSI/IEEE Standard Guide to Software Configuration Management PPS Replacement System Verification and Validation Plan (SyWP) Rev 1 Page 6 of 23 2.1.2.29 IEEE Std. 1044-1997, IEEE Standard for Classification of Software Anomalies 2.1.2.30 IEEE Std. 1058.1-1991, IEEE Standard for Software Project Management Plans 2.1.2.31 IEEE Std. 1058-1998, IEEE Standard for Software Project Management Plans 2.1.2.32 IEEE Std. 1061-1998, IEEE Standard for a Software Quality Metrics Methodology 2.1.2.33 IEEE Std. 1063-1987, Standard for Software User Documentation 2.1.2.34 IEEE Std. 1074-1995, IEEE Standard for Developing Software Life Cycle Processes 2.1.2.35 IEEE Std. 1219-1998, Standard for Software Maintenance 2.1.2.36 IEEE Std. 1228-1994, IEEE Standard for Software Safety Plans 2.1.2.37 IEEE Std. 1233-1998, Guide for Developing System Requirements Specifications 2.1.2.38 IEEE Std. 1471-2000.

Systems and Software Engineering

-Recommended Practice for Architectural Description of Software-Intensive Systems 2.2 Control Procedures 2.2.1 PG&E Control Procedures 2.2.1.1 DCPP Procedure, IDAP AD7.1D8, Project Management 2.2.1.2 DCPP Procedure, IDAP CF3.1D9, Design Change (Package)

Development 2.2.1.3 DCPP Procedure, IDAP CF2.1D9, Software Quality Assurance Plan Software Development 2.2.1.4 DCPP Procedure, IDAP CF2.1D2, Software Configuration Management for Computers

&Software Used for Plant Operations and Operations Support 2.2.1.5 DCPP Procedure CF3.1D16, Specifications 2.2.1.6 DCPP Procedure IDAP CF3.1D17, Design and Analysis Documents Prepared by External Contractors 2.2.1.7 DCPP Procedure IDAP OM7.ID1, Problem Identification and Resolution 2.2.1.8 DCPP SCM 36-01 Process Protection System Replacement Software Configuration Management Plan 2.2.1.9 DCPP Procedure IDAP CF7.1D4 Processing of Documents Received from Suppliers 2.2.2 10 CFR 50 Appendix B Supplier Control Procedures 2.2.2.1 CS Innovations Document No. 6002-00003, "ALS W Plan" 2.2.2.2 CS Innovations Document No. 6116-00000, "DCPP Management Plan" 2.2.2.3 CS Innovations Document No. 6116-00005, "DCPP Test Plan" 2.2.2.4 Triconex Document No. 993754-1-802, Nuclear Safety-Related Process Protection System Replacement DCPP Software V&V Plan (SWP)NOTE: The various 10 CFR 50 Appendix B software suppliers and the various regulatory agencies do not use the same terminology for software and software verification and validation.

As mentioned in DI&C-ISG-06 Rev. 1 [2.1.1.17], an applicant may have different names for similar documents.

Regardless of the titles of the documents submitted, the actual LAR should contain sufficient information to address the PPS Replacement System Verification and Validation Plan (SyWP) Rev 1 Page 7 of 23 criteria discussed in the technical evaluation section. This procedure does not specify that an approved software supplier meet this particular terminology, only that the intent of this procedure is followed and a high 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 a 1 OCFR50 Appendix B program, their SQA processes apply for their product, with PG&E auditing their program, and owner acceptance by PG&E.

PPS Replacement System Verification and Validation Plan (SyWP) Rev 1 Page 8 of 23 3.Definitions Acceptance Acceptance Test Accuracy Anomaly Application Software Official recognition that a product (usually hardware or software configuration item) meets contractual and project requirements.

A Formal test conducted inan operational environment to determine whether or not the system satisfies its acceptance criteria and to enable the customer to determine whether or not to accept the system.The degree of freedom from error of sensor and operator input, the degree of exactness exhibited by an approximation or measurement, and the degree of freedom from error of actuator output.Any condition that deviates from the expected based on requirements, specifications, design, documents, user documents, standards, etc.Software designed to fulfill specific needs of a user; for example, software for navigation, or process control.Approval Official recognition of product validity.Architecture Baseline The organizational structure of a system or component." A specification or product that has been formally reviewed and agreed upon, and thereafter serves as the basis for further development.

It is changed only through formal change-control procedures;

  • A complete and documented set of design requirements and system components (hardware and software) placed under configuration control that identifies the applicable version/revision level of each of these requirement documents and system components;
  • Work products (e.g., document and/or software) that have been officially approved or accepted and used to judge the acceptability of a system, Subsystem, or configuration item. A baseline is subject to configuration control and is updated to reflect approved changes to the configuration item throughout its life cycle.Intermediate version of a system or configuration item that provides a demonstrable subset of capabilities needed to meet requirements allocated to the system or configuration item.Those attributes of the planning documents, implementation process documents and design outputs that provide full implementation of the functions required of the software.

The functions that the software is required to perform are derived from the general functional requirements of the safety system and the assignment of functional requirements to the software in the overall system design.Testing conducted to verify the correct implementation of the design and compliance with program requirements for one software element (e.g., function block) or a collection of software elements Build Completeness Component Testing PPS Replacement System Verification and Validation Plan (SyVVP) Rev 1 Page 9 of 23 Correctness Conceptual Phase Configuration Configuration Audit Configuration Item The degree to which a design output is free from faults in its Specification, design, and implementation.

There is considerable overlap between correctness properties and properties of other characteristics such as accuracy and completeness.

Encompasses those activities that are necessary to produce the basic design and functional requirements for the project or system. The conceptual phase identifies the idea or need for a software application including feasibility studies. It establishes the scope, basic design criteria, required effort, cost, functionality, and classification of the software.Form, fit, and functions of a system or configuration item as defined in baseline documentation.

In the context of an audit for delivery of a product, a configuration audit includes both a functional configuration audit and a physical configuration audit.* An aggregation of hardware, software, or both, that is designated for configuration management and treated as a single entity in the configuration management process. The collection of configuration items should encompass all data, code, drawings, and other information that is used to configure, maintain, or define the operation or configuration of the designated equipment and the project application;" Developed or purchased item, controlled, accepted, and maintained separately from other items. A configuration item can be composed of hardware or software or, for major configuration items, an aggregation of both.A discipline that involves identifying, controlling, and tracking the configuration of a system or product.Corrective action is taken to eliminate the causes of an existing nonconformity, defect, or other undesirable situation in order to prevent recurrence.

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, system degradation, or failure to meet software requirements or system objectives.

A work product or service given to the client for review and acceptance.

It frequently has contractual implications.

Configuration Management Corrective Action Criticality Criticality Analysis Deliverable PPS Replacement System Verification and Validation Plan (SyVVP) Rev 1 Page 10 of 23 Design Phase Factory Acceptance Testing (FAT)Firmware Functional Requirement Functional Testing Functionality Hardware Hazards Analysis Encompasses those activities that are necessary to produce the Software Design Description for the project or system. The primary activity is encoding the application information and function definitions of the Software Requirements Specification into function diagrams.

Design Descriptions are the translation of the Requirements Specification into the design and development of the software.Final customer-witnessed or customer-performed testing at supplier's site which demonstrates that the designed system meets the purchaser's functional and performance requirements and/or industry and regulatory requirements.

Computer programs and data loaded in a class of memory that cannot be dynamically 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 written descriptions (customer functional specifications) and information flow diagrams.Tests whether the functions of the I&C system fulfill the software requirements.

In the case of safety-related I&C equipment these tests are performed by simulating the measurement signals that prevail during normal or accident conditions in order to check that protective actions are initiated correctly.

The operations, which must be carried out by the software.

Functions generally transform input information into output information.

Inputs may be obtained from sensors, operators, other equipment, or other software.Outputs may be directed to actuators, operators, other equipment, or other software.Physical equipment (components) that typically provide a specific function and is assembled with other equipment to create a system; certain components host the various types of Software or Firmware A systematic qualitative or quantitative evaluation of software for undesirable outcomes resulting from the development or operation of a system. These outcomes may include injury, illness, death, mission failure, economic loss, property loss, environmental loss, or adverse social impact. This evaluation may include screening or analysis methods to categorize, eliminate, reduce, or mitigate hazards.The formal specification of the functional behavior of the I&C equipment, as derived from the functional requirements.

I&C functions are specified and described in the SRS, as information flow diagrams and data tables, and form the basis for automatic software generation in application software development.

I&C Function PPS Replacement System Verification and Validation Plan (SyWP) Rev 1 Page 11 of 23 Implementation Phase Independence Encompasses those activities that are necessary to generate the code from the completed function diagrams or source code and load it onto the processors.

This includes documenting the steps and matching specific checksums 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 in the development of the software;* Managerial Independence is defined as an organization separate from the development and program management organizations.

Managerial independence also means that the independent organization selects the segments of the software and the system to analyze and test, choose techniques, defines testing schedule, and selects the specific technical issues and problems to act upon. The independent organization effort must be allowed to submit to program management the testing results, anomalies, and findings without restrictions or adverse pressure, direct or indirect, from the development group;* Financial Independence is defined as an organization that is financially independent from the development organization.

This independence prevents situations where independent activities cannot be completed because funds have been diverted or adverse financial pressures or influences have been exerted by the development organization.

A detailed line by line technical verification of a document by a competent individual other than the preparer.

The independence and technical competence of the reviewer is certified by the cognizant technical manager.This is performed by the design group personnel, is not part of the software verification and validation process, and may also be referred to as Independent Review.Evaluation technique in which intermediate development products are examined in detail by a person or group other than the author to detect technical deficiencies or violations of standards.

An orderly progression of testing in which software elements, hardware elements or both are combined and tested until the entire system has been integrated.

The final set of testing, completed successfully, before the FAT which demonstrates that the system (integrated hardware and software) is ready for FAT.The assigned integer value from 0 to 4 per IEEE-1012

[2.1.2.25]

that indicates the degree of verification and validation that is applied to the system during the development life cycle, subsequent to an evaluation of a combination of the criticality of the system function to the owner's mission, and the importance and likelihood of a system failure. For larger systems, this level may be applied to specific subsystems or sub-moduiles.

Independent Design Review Inspection Integration Testing Integrity Level.

PPS Replacement System Verification and Validation Plan (SyVVP) Rev 1 Page 12 of 23 A shared boundary across which information is passed.A Hardware or Software component that connects two or more other components for passing information from one to the other.Interface Interface Control Lessons Learned Malicious Software May Measure Peer Review Product Review Project Manager Quality Quality Management

  • Identification of all functional and physical characteristics relevant to the interfacing of two or more Configuration Items provided by one or more organizations;
  • Ensuring that proposed changes to these characteristics are evaluated and approved prior to implementation.

Lessons learned are guidance that enhance the practitioner's understanding of a process, clarify a process' applicability to a particular application, provide guidance for special cases, highlight issues, or convey supplier advice. The lessons learned come from a variety of sources including, but not limited to, operation experience, experiences in the use of tools and techniques, and published best practices from other organizations.

Software code that is intended to break down or bypass security barriers; or software code that is intended to adversely impact proper system performance or function.An expression of possibility, a permissive choice to act or not, as distinguished from shall, which is a requirement or action that must be performed.

A measure is any quantitative group. Examples of measures are estimated cost, actual cost, ratio of actual to estimated cost, number of defects, defect density, mean time between failures, average length of support call, and number of peer reviews performed.

An examination of a product by the creators' peers to identify defects and areas where changes are needed. It uses the capabilities of independent reviewers, individually or in a group, to identify the improvements needed in a product and to agree on which improvements should be made.An examination of a product to identify errors before the product is formally passed forward in the development process.Individual responsible to coordinate all aspects of the assigned project(s).

Primary customer interface responsible for coordinating implementation of the project, quality control, customer invoicing and tracking project performance against as-sold estimates.

Degree to which a system or configuration item satisfies its requirements.

Consists of the management responsibilities and actions that determine and implement quality policies.

It includes obtaining the commitment of the organization, marshaling resources, and ensuring that quality management processes are used and supported effectively.

Release Reliability PPS Replacement System Verification and Validation Plan (SyWP) Rev 1 Page 13 of 23 A build that will be delivered to the customer.

A release may include an integrated set of builds.The degree to, which a software system or component operates without failure. This definition does not consider the consequences of failure, only the existence of failure.Requirements Phase Requirements Traceability Requirements Traceability Matrix (RTM)Review Safety Security Shall Encompasses those activities that are necessary to produce the Software Requirements Specification (SRS) for the project or system. These are the primary software design activities wherein customer requirements are identified and described, and documented in a manner necessary for the specification of function diagrams.

The Requirements Specification is the building block for the development, procurement, and maintenance of software and data. As such it is important the Requirements Specification is created considering all the requirements for the software/data.

The process of verifying that each specified requirement for a system has been implemented into the design, that all aspects of the design have their bases in the specification requirements (forwards and backwards traceability, respectively), and that testing produces results compatible with the specified requirements.

The completed steps of the verification process are typically recorded in a Requirements Traceability Matrix (RTM). This usually takes the form of a table that lists requirements and the corresponding sections of documents that indicate how the particular requirement is satisfied.

A Requirements Matrix provides a method that can be used to trace and document that requirements have been met. It provides a complete view of requirements to be tested, and traces specific requirements through all phases of development to verify that the requirement was met. Additionally, the RTM formally documents the process and provides documented evidence that can be useful in auditing that safety requirements and licensing commitments 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 the case of code inspection).

Those properties and characteristics of the software system that directly affect or interact with system safety considerations.

The safety characteristic is primarily concerned with the effect of the software on system hazards and the 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 to SUPPLIER or OWNER but is not mandatory within the PPS scope of work.Should.3 PPS Replacement System Verification and Validation Plan (SyVVP) Rev 1 Page 14 of 23 The programs, procedures and any associated documentation pertaining to the operation of a data processing or computing system. Software is an intellectual creation, independent of the medium on which it is stored.Software includes firmware and logic developed from software based developments systems.Software Software Component Software Lifecycle Software Requirements Software Tool Surveillance System Software components are a constituent element of a software system. For application software, this usually means the modules, sub-modules, or I&C functions as described in the SRS. A specific collection of Software Components is assembled to form a System Component.

The period of time that starts when a software product is conceived and ends when the software product is no longer available for routine use. Includes the following phases: preliminary engineering (conceptual), requirements, detailed design, implementation, integration, testing, installation and checkout, operations

& maintenance, and sometimes a retirement phase.Software requirements are those that must be met by the software to satisfy a contract, standard, specification, procedure, or user need. The set of all software requirements form the basis for subsequent development of the software.

Requirements include, but are not limited to: identification of needed software functions, the inputs, processes, and outputs required for each function, the design constraints and attributes of the software, performance requirements, interface requirements, and development standards.

Each requirement is defined such that its achievement can be verified and validated objectively.

A computer program used in the development, testing, analysis, or maintenance of a program or its documentation.

Examples include comparator, cross-reference generator, decompiler, driver, editor, flowcharter, monitor, test case generator, and timing analyzer.A formal review of a process implementation against a documented standard or process. Surveillance is a planned activity that focuses on a project or a functional area.The hardware and software required for solving a complex task. It consists of several subsystems or components which have different performance characteristics but which are suitable for use together to accomplish the required functions.

System components are the equivalent of a subsystem that can be used.separately and performs a self-contained function.

They consist of one or more modules, which are suitable for use together in an overall system. In the documentation, emphasis is placed on functionality, communication relationships, sequences, inputs/outputs and common resources.

System tests are used to determine whether the specified system characteristics of equipment (behavior on failure, behavior on start-up, testability, etc.) have been implemented.

These types of test are performed without regard to the specific I&C function.System Component System Test PPS Replacement System Verification and Validation Plan (SyWP) Rev 1 Page 15 of 23 Task Iteration The repeat of a V&V task which occurs as a result of identification of an anomaly, its resolution, and the verification by the V&V team that the resolution is complete.Test Sequence of events designed to verify that a system or configuration item satisfies requirements or to identify differences between expected and actual results.Test Phase Encompasses those activities that are necessary during the application software production process to assemble and integrate the complete system, and to perform required testing. These are the primary software design activities wherein system performance is checked and documented to ensure the required functions are correctly and completely implemented.

Timing The ability of the software system to achieve its timing objectives within the hardware constraints imposed by the computing system being used.Traceability The degree to which each element of one life cycle product can be traced forward to one or more elements of a successor life cycle product, and can be traced backwards to one or more elements of a predecessor life cycle product. Traceability is central to the production of complex systems to ensure all requirements are implemented, checked and tested.Unit Smallest replaceable element in a configuration item also referred to as a configuration unit (CU). For software, a unit is typically a subroutine; for hardware, a unit may be a board that is fabricated as a separate item.Validation The evaluation of a product at the end of the development process to ensure the product complies with previously specified software requirements.

This process is usually performed by testing. Validation involves evaluating the overall system and software behavior under conditions representative of its intended use.Verification The process of determining whether or not the products of a given development phase fulfill the requirements imposed at the start of the phase.Verification includes detailed review and testing at each phase and determines whether the project is ready to proceed to the next phase.Verification and The systematic program of review and testing activities performed through Validation the software lifecycle to ensure that the software satisfies its intended use and user needs. V&V activities are performed by persons who are different and independent from those who accomplish the design and integration.

Verifiability The degree to, which a software planning document, implementation process document or design output is stated or provided in such a way as to facilitate the 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 by the subject of the sentence whether the subject is SUPPLIER, OWNER or others.

PPS Replacement System Verification and Validation Plan (SyWP) Rev 1 Page 16 of 23 4. Organization Different organizational units, their responsibilities and relationships with regard to Verification and Validation are discussed in this SyWP. The basic organizational structure for the PPS Replacement System project is shown in Figure 4-1.Figure 4-1 PPS Project Organization Diablo Canyon Diablo Canyon PPS Upgrade Supervisor Project Manager Supplier Quality I I I I I I I Pro emDGPP PmoDCPCt 4.1 PG&E Roles & Responsibilities Detailed DCPP roles and responsibilities are defined in control procedures listed in Section 2.2.4.1.1 Project Manager The Project Manager has the ultimate responsibility, authority, and accountability for all aspects of the project. Responsibilities include quality of design, timely integration with site schedules, supplier quality management/oversight, quality field implementation, and successful post-installation testing. The Project Manager is also responsible to recommend re-evaluation of the project if he detects changes in the project that alter the decision to proceed.The Project Manager shares the responsibility for meeting the software quality goals and objectives of the project and for the implementation of software quality management throughout the project.The project manager 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 and schedule;.Approve corrective actions, scope changes and resource allocations; PPS Replacement System Verification and Validation Plan (SyVVP) Rev 1 Page 17 of 23 Coordinate the disposition of discrepancy reports generated in the course of verification and validation.

4.1.2 Supervisor, Supplier Quality The Supervisor, Supplier Quality is responsible for implementing the requirements of the DCPP Quality Program as defined in Chapter 17 of the FSAR Update.4.1.3 Project Team The Project Team conducts and ensures quality-related inter-group coordination for design and engineering between software and hardware design activities.

The project team is responsible for identifying the processes and corresponding standards and procedures to guide project performance.

The project team is further responsible for ensuring work activities are performed in compliance with these standards and procedures.

4.1.4 Altran Altran is a subcontractor providing engineering support to the PG&E Project Team.4.1.5 Project Engineering Team The Project Engineering Team is responsible for the design change process utilized by PG&E at DCPP for the design and implementation of modifications to controlled Structures, Systems, and Components.

The Project Engineering Team is also responsible for establishing quality goals and objectives for their organization consistent with those of the project. The Project Engineering Team utilizes an Engineer of Choice (EoC) for the work associated with the design change package development, review, and issuance.4.2 10 CFR 50 Appendix B Supplier Roles and Responsibilities Detailed roles and responsibilities for each of the 1 OCFR50 Appendix B suppliers are provided in the respective 1OCFR50 Appendix B supplier control procedures listed in Section 2.2.1.5.The 10 CFR 50 Appendix B Supplier Project Manager (PM) is responsible for providing direction in implementation of the V&V activities to ensure that they are performed per the respective control procedures listed in Section 2.2.1.5. The Project manager is responsible for overall project safety in the respective organization.

The 1 OCFR50 Appendix B supplier produces documentation and is responsible for the performance of the reviews, audits, and inspections as described in the control documents.

PG&E will review the documents and products produced and witness testing activities.

PG&E will accept the documents and reports after the 10 CFR 50 Appendix B suppliers resolve anomalies and PG&E comments.5. V&V Processes The PG&E SyVVP and 1 OCFR50 Appendix B supplier SWP describe documents, hardware and software V&V tools, techniques, methods, and operating and test environment to be used in the respective V&V process.During the Project Initiation and Planning activities the lifecycle documentation needed to support the LAR was identified, and is shown in Figure 5-1. Additional detail regarding each of the illustrated documents will be provided in the System Quality Assurance Plan (SyQAP) and System Verification and Validation Plan (SyWP).5.1 PG&E V&V Tasks PPS Replacement System Verification and Validation Plan (SyVVP) Rev 1 Page 18 of 23 5.1.1 Concept Phase V&V During the Concept phase, the system architecture is selected, and system requirements are allocated to hardware, software, and user interface components.

Development of concept documentation and allocation of resources for the PPS Replacement Project was performed collaboratively by Altran and PG&E per PG&E procedure CF2.1D9 [2.2.1.3], which includes verification of the Concept phase documents through the stakeholder signature process described below. PG&E considers these documents to be the products of PG&E design activity, and inputs to 10 CFR 50 Appendix B supplier development process rather than V&V activity.

There are no specific V&V products for this phase.The outputs of the Concept phase, shown in Figure 5-1 are: 1. Conceptual Design Document (CDD)The PPS Replacement Conceptual Design Document is a PG&E document prepared per DCPP Procedure CF2.1D9. PG&E stakeholder signatures on the CDD cover sheet constitute verification of interface requirements per CF2.1D9. PG&E considers the CDD to be a descriptive document, not a design input document.

Traceability from the CDD to the FRS and IRS is not required.2. Functional Requirements Specification (FRS -includes Function Block Diagrams)The PPS Replacement FRS is an Altran document prepared under the Altran Appendix B QA program with guidance from DCPP procedure CF3.1D16 [2.2.1.5].

PG&E accepted the FRS under CF3.1D17 [2.2.1.6]

or CF7.1D4 [2.2.1.9]

as applicable, which constituted verification of system requirements per CF2.1D9.3. Interface Requirements Specification (IRS -includes Input/Output List)The PPS Replacement IRS is a PG&E document prepared per DCPP Procedure CF2.1D9. PG&E coordination and approval signatures on the IRS cover sheet constitute verification of interface requirements per CF2.1D9.4. Controller Transfer Function Design Input Specification The Controller Transfer Function Design Input Specification is a PG&E document prepared by Altran per DCPP Procedure CF3.1D16.

PG&E approval signatures on the specification constitute verification of requirements per CF3.1D16 and CF2.1D9.5.1.2 Installation and Checkout Phase V&V The Installation and Checkout phase begins after PG&E has reviewed and accepted all development phase documentation and V&V reports, including the 10 CFR 50 Appendix B supplier Software (or System) V&V Report ( SWR), that have been prepared per the control documents listed in Section 2.2.1.5.5.1.2.1 Project Integration The 10 CFR 50 Appendix B supplier FAT will verify that the respective systems correctly process all safety-related and non-safety-related analog and discrete inputs and outputs. The FAT will verify that all safety functions specified in the PG&E design documents (FRS and IRS) perform in accordance with specified requirements.

The FAT will also verify operation of the non-safety-related Maintenance Workstation (MWS) functions associated with each platform per specified requirements.

However, the 10 CFR 50 Appendix B suppliers will implement their respective systems in different facilities with different physical locations, and without access to external PG&E non-safety-related.

systems, such as the Plant Process Computer Gateway. Necessarily, the FAT will not include end-to-end tests of functions that involve such dependencies.

The completed systems will be assembled in the PG&E Project Integration and Test (PIT) facility for pre-installation staging and checkout of the integrated system.

PPS Replacement System Verification and Validation Plan (SyWP) Rev I Page 19 of 23 The ALS processes Reactor Coolant System and Pressurizer Vapor Space temperatures and provides scaled analog 4-20 mA signals corresponding to Engineering Units to the Tricon. The ALS FAT will verify that the ALS processes the temperature signals correctly and produces properly scaled 4-20 mA analog outputs per specified requirements.

The Tricon FAT will verify that all safety functions utilizing the 4-20 mA analog signals perform per specified requirements using simulated signals. The SAT will test the integrated PPS replacement system using the transmission of live 4-20 mA analog Reactor Coolant System temperatures from the ALS to the Tricon.5.1.2.2 Site Acceptance Test The PG&E Site Acceptance Testing (SAT) will test the fully integrated system prior to installation.

The SAT does not retest safety functions.

All specified safety functions will be tested in the 10 CFR 50 Appendix B suppliers FAT. As described above, the SAT will test the transmission of live analog data from the ALS to the Tricon and will also include V&V of the non-safety-related communication interfaces with the MWS and external systems as specified in the IRS.Tasks performed in this phase: " Audit the installation configuration to verify that all products required to integrate the system have been delivered by the 10 CFR 50 Appendix B suppliers and that all ancillary components are available;

-For the software based Tricon portion of the PPS replacement, verify that the installed software corresponds to the software subjected to V&V. Verify that the system initializes, execute, and terminates as specified.

Verify the requirements for continuous operation and service, including user notification of errors.-For the hardware based ALS portion of the PPS replacement, verify that the installed FPGA logic corresponds to the logic subjected to V&V. Verify that the system initializes, executes, and terminates as specified.

Verify the requirements for continuous operation and service, including user notification of errors.* Validate that all site-dependent parameters or conditions to verify supplied values are correct;* Conduct the SAT per approved DCPP procedure.

5.1.2.3 Installation and Design Verification Test The Design Verification Test (DVT) is performed on the system once it is fully installed in the final target environment and location.

The DVT is performed per DCPP procedure CF3.1D9 [2.2.1.2].

PG&E is responsible for acceptance of the results of the SAT and DVT.Tasks performed in this phase:* Audit the installation configuration to verify that all software products required to correctly install and operate the completed system are present in the installation package;* Validate that all site-dependent parameters or conditions to verify supplied values are correct.* Conduct the DVT per approved DCPP procedure;

  • Verify that the installation procedures and installation environment do not introduce new hazards;Update the hazard analysis;* Generate the V&V Final Report;PG&E will review and accept the products of the Appendix B supplier development and implementation V&V activities and will use the results to ensure that the overall PPS Replacement Project V&V activities are complete.

Upon completion of all V&V activities, tasks, and results, PPS Replacement System Verification and Validation Plan (SyWP) Rev 1 Page 20 of 23 including status and disposition of anomalies, PG&E will issue a final System Verification and Validation Report (SyWR).5.1.2.4 Traceability Analysis PG&E will prepare a Requirements Traceability Matrix (RTM) to document the verification and validation of specified requirements that were not included in the respective 10 CFR 50 Appendix B supplier V&V scope.5.1.2.5 Outputs of this phase are:* Site Acceptance Test Report;* V&V Installation Analysis;* Design Verification Test Report;* RTM for items not in 10 CFR 50 Appendix B supplier V&V scope;* SyWR;5.1.3 Operation Phase V&V Tasks Subsequent to FAT, modifications to the Tricon and ALS configurations will be controlled by the Process Protection System Replacement Software Configuration Management Plan, SCM 36-01 [2.2.1.8].

If an application software or logic modification is determined to be required per the SCMP, the modification will be performed by the respective 10 CFR 50 Appendix B supplier, Invensys Operations Management or CS Innovations, in accordance with their approved procedures.

5.1.4 Maintenance Phase V&V Tasks Refer to Section 5.1.3.

PPS Replacement System Verification and Validation Plan (SyWP) Rev 1 Page 21 of 23 Figure 5-1 PPS Replacement Project Lifecycle Document Flow Concept (PG&E)Concept (PG&E)*V Concept (PG&E)Concept (PG&E)Requirements (IOM)Planning (CSI)CS1 Sym rcht .n dHýrdeion Jfidu&AýZSet-nd H.,ýcn, Development

&Manufacturing (CSI)T Requirements (1OM)Design &Implementation (10M)Design &Implementation (10M)Test (10M)Development

&Manufacturing (CSI)m ( ....................

System Test (CSI)V T 0 9 IF System Test (CSI)InstallationlCheclrout (PG&E)T*Glossary CDD FRS IRS SAD HAD SyRS SyDS SRS HRS HDS SDD FAT SAT DVT RTM SWR SyWR Test (10M)InstallationiCheckout (PG&E Conceptual Design Document Functional Requirements Specification Interface Requirements Specrfication Software Architecture Requirements Hardware Architecture Requirements System Requirements Specification System Design Specification Software Requirements Specification Hardware Requirements Specification Hardware Design Specification Software Design Description Factory Acceptance Test Site Acceptance Test Design Verification Testing Requirements Traceability Matrix Software Verification

& Validation Report System Verification

& Validation Report V PPS Replacement System Verification and Validation Plan (SyWP) Rev 1 Page 22 of 23 5.2 10CFR50 Appendix B Supplier Tasks Respective V&V activities are governed by the Triconex Nuclear Safety-Related Process Protection System Replacement DCPP Software V&V Plan (SWP) [2.2.2.4], the ALS W Plan [2.2.2.11, the ALS DCPP Management Plan [2.2.2.2], and the ALS DCPP Test Plan [2.2.2.3].

These plans have been reviewed and accepted by PG&E to ensure that the V&V effort is complete.During requirements definition, design and implementation activities, the 10 CFR 50 Appendix B suppliers will issue reports for the results of V&V activities.

PG&E will review and accept the reports after comments and any anomalies have been resolved according to the 10 CFR 50 Appendix B supplier procedures.

The 10 CFR 50 Appendix B suppliers will prepare traceability documentation and analyses starting from the FRS and IRS and continuing through Factory Acceptance Testing (FAT) per their respective control procedures.

The 10 CFR 50 Appendix B suppliers will verify and validate their respective systems to ensure that all safety functions are traced to their requirements and perform per the specified requirements in accordance with the respective control procedures.

This process ensures that all safety requirements specified in the FRS and IRS are properly implemented and tested at the FAT.The 10 CFR 50 Appendix B suppliers will issue a final V&V Report, (SWR) which summarizes all life cycle V&V tasks and the task results. It will also summarize the discrepancies and their resolution found during the V&V evaluation.

The report will give an assessment of overall software quality and provide any recommendations.

The SWR will be prepared per the respective control procedures.

6. V&V Reporting Requirements V&V reporting shall consist of Task Reports, V&V Activity Summary Reports, Anomaly Reports, and the V&V Final Report. Task report(s), V&V activity summary report(s), and anomaly report(s) are provided as feedback to the software development process regarding the technical quality of each software product and process.Task Reports shall document V&V task results and status, and shall be in a format appropriate for technical disclosure.

Task Report requirements are defined in the respective 10 CFR 50 Appendix B supplier control procedure.

An Activity Summary Report shall summarize the results of V&V tasks performed for each of the V&V activities.

V&V Activity Summary Report requirements are defined in the respective 10 CFR 50 Appendix B supplier control procedure, An Anomaly Report shall document the identification and resolution of all anomalies detected by the V&V effort. Anomaly reporting and resolution requirements are defined in DCPP Procedure OM7.ID1[Reference 2.2.1.7] or the respective 10CFR 50 Appendix B supplier control procedures, depending upon which entity identifies the anomaly.The V&V Final Report, consisting of the System V&V Report (SyWR), will be issued by PG&E at the end of the installation and checkout phase. The V&V Final Report will include the following, as a minimum:* Summary of all life cycle V&V activities within PG&E and 10 CFR 50 Appendix B supplier scope;* Summary of anomalies and resolutions;" Assessment of overall software quality;* A copy of or reference to all completed V&V documents and reports; PPS Replacement System Verification and Validation Plan (SyWP) Rev 1 Page 23 of 23 7. V&V Administrative Requirements Anomaly Resolution and Reporting shall be performed per DCPP Procedure OM7.ID1 [Reference 2.2.1.7]or the respective 10CFR 50 Appendix B supplier control procedures depending upon which entity identifies the anomaly.Task iteration evaluation and disposition shall be performed in accordance with the PG&E and 10CFR50 Appendix B supplier control procedures.

V&V Task Reports shall be generated to document the results of regression testing per the PG&E and 1OCFR50 Appendix B supplier control procedures.

The procedures and criteria used to deviate from this SyWP are defined as follows. The information required for disposition of deviations shall include task identification, rationale, and potential effect on software quality. The authority responsible for approving deviations is the PG&E Project Manager. The responsible PG&E Project Manager will document approval in the SAP notification that identifies the deviation.

Disposition of the deviation shall be incorporated into the SyVVP as a revision at the first practical opportunity.

The responsible PG&E Project Manager will document approval in an SAP notification.

This will be included in the revision of the SyWP currently in progress.

It is noted that Section 7 of the SyWP states the deviation shall be incorporated into the SyWP as a revision at the first practical opportunity.

Control Procedures:

Refer to Section 2.2.1 (PG&E) and Section 2.2.1.5 (10 CFR 50 Appendix B suppliers)

Standards, Practices and Conventions:

Refer to Section 2.1.8. V&V Documentation Requirements V&V documentation shall be prepared in accordance with the PG&E and 10 CFR 50 Appendix B supplier control procedures.

Attachments 9-14 to the Enclosure contain Proprietary Information

-Withhold Under 10 CFR 2.390 Enclosure Attachment 2 PG&E Letter DCL-1 3-028 Invensys Operations Management Affidavit No. 993754-AFF-52T Attachments 9-14 to the Enclosure contain Proprietary Information When separated from Attachments 9-14 to the Enclosure, this document is decontrolled.

993754-AFF-52T AFFIDAVIT No. 993754-AFF-52T Re: Request for Withholding from Public Disclosure per I OCFR2.390 STATE OF CALIFORNIA

)) ss COUNTY OF ORANGE )1, Roman Shaffer, being duly sworn, hereby say and depose: 1. I am the Diablo Canyon PPS Replacement Project Manager for Invensys Operations Management, and as such I have been specifically delegated the function of reviewing company proprietary information sought to be withheld from public disclosure in connection with nuclear I E qualification and application of the TRICON Programmable Logic Controller (PLC) and am authorized to apply for its withholding on behalf of the Nuclear Delivery Unit of Invensys Operations Management.

2. The information sought to be withheld is contained in the document(s) described below: (1) Software V& V' Plan, 993754-1-802, Rev 3 (2) Verification Test Plan, 993 754-1-813, Rev 2 (3ý) Project Management Plan, 993 754-1-905, Rev 3 (4) Software Develolpment Plan, 993 754-1-906, Rev 2 (5) Software Con fignration Mfanaagement Plan, 993 754-1-909, Rev 1 The indicated documents contain information considered to be proprietary.

Proprietary material in the enclosed documents is indicated by brackets [ ] or other similar markings as required by I OCFR2.390(b

' )(1)(i)(1B).

As indicated in the associated transmittal letter, non-proprietary versions of the documents are being provided, consistent with the level of proprietary content.This information is associated with the Diablo Canyon Power Plant (DCPP) Process Protection System Replacement Project, which incorporates Invensys Operations Management TRICON systems and delegated digital application project integration services.

This will allow the NRC to verify compliance with current regulatory requirements for certain Invensys Operations Management activities in support of the DCPP PPS Replacement Project.3. I am making this affidavit in conformance with the provisions of I OCFR Part 2.390 of the Commission's regilations and in conjunction with the Invensvs Operations Management application for withholding accompanying this affidavit.

4. I have personal knowledge of the criteria and procedures utilized by the Nuclear Delivery Unit of lnvensys Operations Management in designating information as a trade secret, privileged, or as confidential commercial or financial information.

Some examples of categories of information which fit into the definition of proprietary information are: a) Information which discloses process, method, or apparatus, including supporting data and analyses, where prevention of its use by Invensys Operations Management's competitors without license or contract from Invensys constitutes a competitive economic advantage over other companies in the industry.b) Information, which if used by competitors, would reduce their expenditure of resources or improve their competitive position in the design, manufacture, shipment, application, installation, assurance of quality, or licensing of a similar product.Page I of 3 993754-AFF-52T c) Information which reveals cost or price information, production capacities, budget levels, or commercial strategies of Invensys Operations Management, its customers, its partners, or its suppliers.

d) Information which reveals aspects of past, present, or future Invensys Operation Management customer-funded development plans or programs., of potential commercial value to Invensys.e.) Information which discloses patentable subject matter for which it may be desirable to obtain patent protection.) Information obtained through Invensys Operation Management actions which could reveal additional insights into nuclear equipment qualification processes, customer applications, and regulatory proceedings, and which are not otherwise readily obtainable by a competitor.

Infornation to be withheld is considered to be proprietary based on IOCFR2.390(a)(4), with consideration of the reasons set forth above.5. These documents describe the details of a program to qualify invensys Triconex equipment for I E application, product design details, and/or customer application approaches.

Invensys Triconex is the first manufacturer of a PLC to fully implement the requirements set forth in the EPRI TR- 107330, which has been endorsed by the Commission in an SER. Invensys Triconex has expended a significant amount of money and effort involving numerous contractors over more than 10 years to develop and implement an ongoing successful approach to its test programs and nuclear applications.

Information developed relating to test plans, approaches, equipment, specific problems encountered, licensing perspectives, application approaches, and lessons learned has significant value because of the resources expended to successfully accomplish this process and the usefulness of this knowledge to potential competitors.

Specific data showing compliance with requirements and demonstrating technical capability of the equipment has substantial commercial value because it provides the basis for qualifying Invensys Triconex equipment and implementing safety-related digital upgrades to nuclear plants. Existing options for digital upgrades in the nuclear industry are limited. We believe that ongoing successful I E qualification upgrades of the TRICON PLC products and implementation of plant application projects will continue to give Invensys Operations Management a competitive advantage in this field.Disclosure of information in these documents would cause substantial harm to the competitive position of the Invensys Operations Management, as there are other competing companies who wish to qualify digital PLC controllers and apply them in safety related applications in nuclear power plants. Competing firms could use our experience, successful approaches, and teclmical informnation to facilitate their own equipment qualification efforts, application approaches, and/or product design without compensating Invensys Operations Management.

6. Pursuant to the provisions of paragraph (b)(4) of Section 2.390 of the Commission's regulations, the following is furnished for consideration by the Commission in determining whether the information sought to be withheld firom public disclosure should be withheld.(i) The information sought to be withheld firom public disclosure is owned and has been held in confidence by Invensys Operations Management.(ii) The information is of a type customarily held in confidence by Invensys Operations Management and not customarily disclosed to the public. Invensys Operations Management has a rational basis for determining the types of information customarily held in confidence by it and, in that connection, utilizes a system to determine when and whether to hold certain types of information in confidence.

The application of that system and the substance of that system constitute Invensys Operations Management policy and provide the rational basis required.(iii) The information is being transmitted to the Commission in confidence and, under the provisions of IOCFR Part 2.390, it is to be received in confidence by the Commission.(iv) This information is not readily available in public sources.(v) Public disclosure of this proprietary information is likely to cause substantial harm to the competitive position of Invensys Operations Management because it would enhance the ability of competitors to provide similar design and qualification of PLC systems and associated applications using similar project methods, equipment, testing approach, contractors, or licensing approaches.

As Page 2 of 3 993754-AFF-52T described in section 5, this information is the result of considerable expense to Invensys and has great value in that it will assist Invensys in providing Invensys Triconex digital upgrade equipment and services to a new, expanding markets not currently served by the company.7. The foregoing statements are true and correct to the best of my knowledge, information, and belief.ko'an Shafer J Project Manager, DCPP PPS Replacement Project hnvensys Operations Management State of California County of ___-____c___

Subscribed and sworn to (or affirmed) before me on this c--)_0 dayof be .4 ,2012by Date Month V. MATHESON a SCOMM. # 1862131 7 NOTARY PUBLIC.CALIFORNA X SORANGE COUNTY I My Cornrils T~A'G 211 X431 Name of Signer (1 1,/proved to me on the basis of satisfactory evidence to be the person who appeared before me.Signature Sigoa of Notary Pu Place Notary Seat Ab,'rc Page 3 of 3 Attachments 9-14 to the Enclosure contain Proprietary Information

-Withhold Under 10 CFR 2.390 Enclosure Attachment 3 PG&E Letter DCL-13-028 Invensys Operations Management Affidavit No. 993754-AFF-54T Attachments 9-14 to the Enclosure contain Proprietary Information When separated from Attachments 9-14 to the Enclosure, this document is decontrolled.

993754-AFF-54T AFFIDAVIT No. 993754-AFF-54T Re: Request for Withholding from Public Disclosure per 1OCFR2.390 STATE OF CALIFORNIA) ss COUNTY OF ORANGE )I, Roman Shaffer, being duly sworn, hereby say and depose: I am the Diablo Canyon PPS Replacement Project Manager for Invensys Operations Management, and as such I have been specifically delegated the function of reviewing company proprietary information sought to be withheld from public disclosure in connection with nuclear lE qualification and application of the TRICON Programmable Logic Controller (PLC) and am authorized to apply for its withholding on behalf of the Nuclear Delivery Unit of Invensys Operations Management.

2. The information sought to be withheld is contained in the document(s) described below: (1) Software Design Description, PSI, 993 754-11-810, Rev 0 The indicated document(s) contain information considered to be proprietary.

Proprietary material in the enclosed documents is indicated by brackets [ ] or other similar markings as required by IOCFR2.390(b)(1)(i)(B).

As indicated in the associated transmittal letter, non-proprietary versions of the document(s) may or may not be provided, consistent with the level of proprietary content.This information is associated with the Diablo Canyon Power Plant (DCPP) Process Protection System Replacement Project, which incorporates Invensys Operations Management TRICON systems and delegated digital application project integration services.

This will allow the NRC to verify compliance with current regulatory requirements for certain Invensys Operations Management activities in support of the DCPP PPS Replacement Project.3. I am making this affidavit in conformance with the provisions of IOCFR Part 2.390 of the Commission's regulations and in conjunction with the Invensys Operations Management application for withholding accompanying this affidavit.

4. I have personal knowledge of the criteria and procedures utilized by the Nuclear Delivery Unit of Invensys Operations Management in designating information as a trade secret, privileged, or as confidential commercial or financial information.

Some examples of categories of information which fit into the definition of proprietary information are: a) Information which discloses process, method, or apparatus, including supporting data and analyses, where prevention of its use by Invensys Operations Management's competitors without license or contract from Invensys constitutes a competitive economic advantage over other companies in the industry.b) Information, which if used by competitors, would reduce their expenditure of resources or improve their competitive position in the design, manufacture, shipment, application, installation, assurance of quality, or licensing of a similar product.c) Information which reveals cost or price information, production capacities, budget levels, or conmnercial strategies of Invensys Operations Management, its customers, its partners, or its suppliers.

Page I of 3 993754-AFF-54T d) Information which reveals aspects of past, present, or future Invensys Operation Management customer-funded development plans or programs, of potential commercial value to Invensys.e) Information which discloses patentable subject matter for which it may be desirable to obtain patent protection.

f) Information obtained through Invensys Operation Management actions which could reveal additional insights into nuclear equipment qualification processes, customer applications, and regulatory proceedings, and which are not otherwise readily obtainable by a competitor.

Information to be withheld is considered to be proprietary based on lOCFR2.390(a)(4), with consideration of the reasons set forth above.5. These documents describe the details of a program to qualify Invensys Triconex equipment for 1E application, product design details, and/or customer application approaches.

Invensys Triconex is the first manufacturer of a PLC to fully implement the requirements set forth in the EPRI TR-107330, which has been endorsed by the Commission in an SER. Invensys Triconex has expended a significant amount of money and effort involving numerous contractors over more than 10 years to develop and implement an ongoing successful approach to its test programs and nuclear applications.

Information developed relating to test plans, approaches, equipment, specific problems encountered, licensing perspectives, application approaches, and lessons learned has significant value because of the resources expended to successfully accomplish this process and the usefulness of this knowledge to potential competitors.

Specific data showing compliance with requirements and demonstrating technical capability of the equipment has substantial commercial value because it provides the basis for qualifying Invensys Triconex equipment and implementing safety-related digital upgrades to nuclear plants. Existing options for digital upgrades in the nuclear industry are limited. We believe that ongoing successful IE qualification upgrades of the TRICON PLC products and implementation of plant application projects will continue to give Invensys Operations Management a competitive advantage in this field.Disclosure of information in these documents would cause substantial harm to the competitive position of the Invensys Operations Management, as there are other competing companies who wish to qualify digital PLC controllers and apply them in safety related applications in nuclear power plants. Competing firms could use our experience, successful approaches, and technical information to facilitate their own equipment qualification efforts, application approaches, and/or product design without compensating Invensys Operations Management.

6. Pursuant to the provisions of paragraph (b)(4) of Section 2.390 of the Commission's regulations, the following is furnished for consideration by the Commission in determining whether the information sought to be withheld from public disclosure should be withheld.(i) The information sought to be withheld from public disclosure is owned and has been held in confidence by Invensys Operations Management.(ii) The information is of a type customarily held in confidence by Invensys Operations Management and not customarily disclosed to the public. Invensys Operations Management has a rational basis for determining the types of information customarily held in confidence by it and, in that connection, utilizes a system to determine when and whether to hold certain types of information in confidence.

The application of that system and the substance of that system constitute Invensys Operations Management policy and provide the rational basis required.(iii) The information is being transmitted to the Commission in confidence and, under the provisions of IOCFR Part 2.390, it is to be received in confidence by the Commission.(iv) This information is not readily available in public sources.(v) Public disclosure of this proprietary information is likely to cause substantial harm to the competitive position of Invensys Operations Management because it would enhance the ability of competitors to provide similar design and qualification of PLC systems and associated applications using similar project methods, equipment, testing approach, contractors, or licensing approaches.

As described in section 5, this information is the result of considerable expense to Invensys and has great value in that it will assist Invensys in providing Invensys Triconex digital upgrade equipment and services to a new, expanding markets not currently served by the company.Page 2 of 3 993754-AFF-54T

7. The foregoing statements are true and correct to the best of my knowledge, information, and belief.oman Shaffer I Project Manager, DCPP PPS Replacement Project Invensys Operations Management

State of California County ofo --' 7 Subscribed and sworn to (or affirmed) before me on this: day of F"c- ._ , 2013 by Date Month I " V. Mi ' ESONCOMM. # 1862131 X NOTARY PUBLKCOALIFORNLA X ORANGE COUNTY 0~'VCommr E'ý 6UG 21, 2013 Place Notary Seal Above Name of Signer proved to me on the basis of satisfactory evidence to be thhe person whoaperdbf6em.

Stoaedbforeme jj Signature-" --c SiAdture of Notary Publi~/f-------------------------------------------------------------------------------------------------------------------------------------------

Page 3 of 3

Retrieved from "https://kanterella.com/w/index.php?title=DCL-13-028,_Diablo_Canyon,_Units_1_%26_2,_Process_Protection_System_(PPS)_Replacement_System_Verification_and_Validation_Plan_(Syvvp)_Nuclear_Safety_Related,_Revision_1.&oldid=900592"