ML11318A030

in v'e. n s'.9 s" i nv e. n s-.
w s"
Operations Management Triconex

Project: PG&E PROCESS PROTECTION SYSTEM REPLACEMENT
Purchase Order No.: 3500897372
Project Sales Order: 993754
PACIFIC GAS & ELECTRIC

COMPANY
NUCLEAR SAFETY-RELATED
PROCESS PROTECTION SYSTEM
REPLACEMENT
DIABLO CANYON POWER PLANT
SOFTWARE VERIFICATION AND VALIDATION

PLAN (SVVP)
Document No. 993754-1-802 (-NP)
Revision I
October 13, 2011
Non -Proprietary copy per 1OCFR2.390

- Areas of Invensys Operations Management proprietary
information, marked as [P], have been redacted based
on 10CFR2.390(a)(4).
Name Signature Title

Author: Son Phan IV&V Engineer
Reviewer: Hoan Nguyen - OIV&V Engineer
Approval: Kevin Vu IV&V Manager
in v'e. n s'.ý s" i n V e. n s. s

Document: 1993754-1-802 I Title: I Software Verification And Validation Plan
Revision: 1 Page: 2 of 46 Date: 10/13/2011
Document Change History

Revision Date Change Author
0 08/17/11 Initial Release S. Phan
1 10/13/11 Revise the Figure 3. PPS Replacement Project S. Phan
Organization Structure.
Revise the Figure 2 Tricon Protection Set Architecture for
the PPS Replacement System.
n V, e. n S..ý=J S. i n V e.n s-.L-.o s-

Document: 993754-1-802 Title: S are Verification And Validation Plan
Revision: I Page: 3 of 46 -Date: 10/13/2011
Table of Contents
L ist of T ables ............................................................................................................5
L ist of F igures ...........................................................................................................6
1. Introd uction .................................................................................................... 7

1.1. 7
Purp ose .............................................................................
1.2 . Scope.............................................................................. 8
1.3. Verification and Validation Program Implementation ................................................
10
2. R eferences ...................................................................................................... 11
2.1. Industry Documents .....................................................................
11
2.2. NRC Documents .......................................................................
11
2.3. 12
PG&E Documents ......................................................................
2.4. Invensys Triconex Docum ents ..............................................................
12
3. Definition and Acronym s ............................................................................. 13

3.1. D efin itio n s...........................................................................
13
3.2. A cro n y ms ...........................................................................
14
4. V & V O verview .............................................................................................. 16

4 .1. O rg an izatio n ..........................................................................
16
4.1.1. V&V Organization ...............................................................
16
4.1.2. V&V Responsibilities .............................................................
17
4.2. Project Schedule .......................................................................
19
4.3. Software Integrity Level (SIL) ..............................................................
19
4.4. Resource Surru-nary .....................................................................
19
4.5. Tools, Techniques, and M ethods .............................................................
20
4 .5 .1. T o o ls .......................................................................
20
4.5.2. Techniques and m ethods ...........................................................
21
5. V &V P rocess ................................................................................................. 23

5.1. V& V M anagement - General ...............................................................
25
5.2. 25
System Life Cycle Verification ..............................................................
5.2.1. Planning Phase .................................................................
25
5.2.2. Requirements Phase ..............................................................
26
5.2.3. Design Phase ...................................................................
28
5.2.4. Implementation Phase .............................................................
30
5.2.5. Test Phase ....................................................................
32
5.3. Post Test/Pre-Ship Checkout ...............................................................
34
5.4. Risks and Assumptions ...................................................................
34
n v* e. n s-.!ý-4 s- i n V e.n s-

I Document: 1993754-1-802 1 Title: I So are Verification And Validat ion Plan
Revision: I I I Page: 1 4 of 46 1 Date: 1 10/13/2011
6. V & V Reporting .............................................................................................35

6.1. 35
V &V A ctivity Sum m ary R eport ..............................................................
6 .2 . 35
T est R ep o rts ..........................................................................
6 .3. 35
A n om aly Repo rts .......................................................................
6 .4 . 35
V &V F in al R ep ort ......................................................................
7. V & V A dm inistrative Requirem ents ........................................................... 37

7.1. 37
A nom aly R eporting and Resolution ...........................................................
7.2 . 37
T ask Iteration P o licy ....................................................................
7 .3. 37
D ev iatio n Po licy .......................................................................
7.4 . 37
C ontro l P rocedures ......................................................................
7.5. 37
Software Standards, Practices, and Conventions ...................................................
8. Appendices .................................................................................................... 40
41
Appendix A - Typical Verification and Validation Flow Chart ..............................................
42
Appendix B - T ask R eport L og ..................................................................
44
Appendix C - T ask R eport Forin .................................................................
i r 7 V "e . n s '.4 s " in v'e. nvs '. s "

E Document: 1993754-1-802
Revision: 1
1 Title:
Page:
I Software Verification And Validation Plan
5 of 46 1 Date: 10/13/2011 I
List of Tables
T able 1. L ifecycle M apping ..................................................................................................... 23

inv'e. ns'.• s"
inV'e. n s'., s"
Document: 1993754-1-802 Tite: I Software Verification And Validation Plan
Revision: 1 Page: 6 of 46 1 Date: 10/13/2011
List of Figures
Figure 1. Westinghouse PWR Reactor Protection Concept ...................................................... 7
Figure 2. Tricon Protection Set Architecture for the PPS Replacement System ................. ...*....... 9
Figure 3. PPS Replacement Project Organization Structure ..................................................... 16
inv e.n s'.b s
in v'e. n s'.j s"
I Document: 993754-1-802 Title: Software Verification And Validation Plan
Revision: I Page: 7 of 46 1 Date: 1 10/13/2011
1. Introduction
1.1. Purpose
The purpose of this Software Verification and Validation Plan (SVVP) is to establish the
requirements for the Verification and Validation (V&V) process to be applied to the TriStation
Application Project (TSAP) software developed for the Process Protection System (PPS)
Replacement Project, running on the Safety-Related V10 Tricon platform hardware. This SVVP
is described in the Software Quality Assurance Plan (SQAP) [Ref 2.4.8]. This SVVP includes
the TSAP software and V 10 Tricon system hardware interface with Advanced Logic System
(ALS) (but not the ALS functions themselves), and Maintenance Workstation (MWS).
®PWR Protection Concept ] ~~~Rod [•1e
Control
Power
Cabinet •
WReactor Control
a aed dd o Trip M-G
i Sets
uon tcts e
...- •[State
NIS Protection
Racks and-impleme
ThePis and
clVPalssidfineds Nucear Saey-eatd(CasE proec
activities
allhmspcii b shall
erormply
with the applicable requirements of the Invensys Operation Management Nuclear Quality
in v'e. n s , " in ve. n s.t s

Document: 1993754-1-802 Title: I Software Verification And Validation Plan
Revision: 1 Page: 8 of 46 1 Date: 1 10/13/2011
Assurance Manual (IOM-Q2) [Ref 2.4.1] and any additional quality requirements specified in
the Project Quality Plan (PQP) [Ref 2.4.7].
This SVVP is prepared in accordance with PPM 7.0 [Ref 2.4.4], Application Program
Development, and follows the guidelines described in IEEE 10 12-1998 "IEEE Standard for
Software Verification and Validation" [Ref 2.1.6], IEEE 1074-1995, "IEEE Standard for
Developing Software Life Cycle Processes" [Ref 2.1.9], and Branch Technical Position 7-14,
"Guidance on Software Reviews for Digital Computer-Based Instrumentation and Control
Systems", [Ref 2.2.6].
The goals of this SVVP are to:

1) Provide an integrated solution that will improve V10 Tricon Protection Set reliability and
availability.
2) Reduce costs by detecting system errors as early as possible.
3) Provide objective evidence for system performance evaluation.
4) Demonstrate compliance with customer requirements and the Invensys QA Program.
5) This SVVP describes the verification and validation requirements for the PPS
Replacement Project.
1.2. Scope
The V&V activities described in this SVVP apply to VI10 Tricon Protection Set software,
documents, and other items that are produced during implementation of this project. The
boundaries of the V&V activities include I/O inputs from ALS and data link inputs via the TCM
for the MWS. These ALS inputs to the V10 Tricon will be simulated during the factory
acceptance test, as discussed in Invensys document 993754-1-813, Validation Test Plan. This
SVVP does not include V&V of the software running on ALS and the MWS as shown in Figure
2. This V&V process does not include operating systems, software, or firmware other than the
TSAP generated by the TriStation 1131 (TS 1131). This SVVP does not include V&V of the
TS 1131 programming tool, which will be used to develop the TSAP software. Software
generated by Vendors other than Invensys Operations Management are verified and validated by
the originating organization under separate programs. This SVVP addresses the attributes of
third-party software only to the extent of verifying that the inputs, outputs, and displays are
correct as specified.
i n \e.V n s ' s"
in vae. n s'.y s"
Figure 2. Tricon Protection Set Architecture for the PPS Replacement System.
in v"e, S" .- ineve. ns'.u s"
Document: 993754-1-802 Title: Software Verification And Validation Plan
Revision: 1 Page: 10 of 46 I Date: 10/13/2011
1.3. Verification and Validation Program Implementation

V&V activities are integrated into the project activities from beginning to end and include
Planning, Requirements, Design, Implementation, and Test Phases of the system software life
cycle. During the Planning Phase the SVVP is developed to describe Nuclear IV&V activities,
and also define when, how and by whom specific IV&V activities that are to be performed,
includes various V&V methodologies used. The Requirements Phase entails the review of the
Software Requirements Specification (SRS) developed based on customer design inputs [Ref
2.3]. Verification of each of these documents is performed to ensure that the applicable customer
requirements have been adequately and accurately translated. The Design Phase is development
of the Software Design Description (SDD). Again, verification of the SDD is performed to
ensure that the applicable customer requirements have been adequately and accurately translated.
The Implementation Phase addresses the implementation of the SDD. The Implementation Phase
activities are verified throughout the implementation process to ensure that the design has been
correctly implemented. When all Implementation Phase activities have been completed, the
system validation Test Phase activities are performed. These activities yield objective evidence
that the operation of the system is consistent with the specified system requirements.
Traceability is critical to the success of the project. Traceability is achieved through the
development of a Project Traceability Matrix (PTM). Traceability shall be determined sufficient
if one is able to trace requirements from design inputs to design outputs and to trace requirement
from design outputs back to design inputs (forward and backward traceability).
The PTM has shared responsibility. The Requirement and Design Phase PTM are prepared by
Nuclear Delivery, where the Implementation and Test Phase PTM are prepared by Nuclear
IV&V.
Refer to Appendix A of this SVVP for a typical V&V Flow Chart.

in v'e. n s -. inV'e. nVs'.t- s'

Document: I993754-1-802 I Title: I Software Verification And Validation Plan
2. References
2.1. Industry Documents

2.1.1 IEEE 7 - 4.3.2 - 2003, Standard Criteria for Digital Computers in Safety Systems of
Nuclear Power Generating Stations.
2.1.2 IEEE 730- 1998, Software Quality Assurance Plans.
2.1.3 IEEE 829 - 1998, Standard for Software Test Documentation.
2.1.4 IEEE 830 - 1998, Recommended Practice for Software Requirements Specifications.
2.1.5 IEEE 1008 - 1987, Standard for Software Unit Testing.
2.1.6 IEEE 1012 - 1998, Standard for Software Verification and Validation.
2.1.7 IEEE 1028 - 1997, Standard for Software Reviews and Audits.
2.1.8 IEEE 1059 - 1993, Guide for Software Verification and Validation Plans.
2.1.9 IEEE 1074 - 1995, Standard for Developing Software Life Cycle Processes.
2.1.10 IEEE 1228 - 1994, IEEE Standard for Software Safety Plans.
2.1.11 IEEE 828 - 1998, IEEE Standard for Software Configuration Management Plans.
2.2. NRC Documents

2.2.1 U.S. NRC Regulatory Guide (RG) 1.168, Rev. 1, Verification, Validation, Reviews, and
Audits for Digital Computer Software Used in Safety Systems of Nuclear Power Plants.
2.2.2 U.S. NRC RG-1.169, Configuration Management Plans for Digital Computer Software
Used in Safety Systems of Nuclear Power Plants.
2.2.3 U.S. NRC RG-1.172, Software Requirements Specifications for Digital Computer
Software Used in Safety Systems of Nuclear Power Plants.
2.2.4 U.S. NRC Digital Instrumentation and Controls Interim Staff Guidance (ISG6), DI&C-
ISG-06.
2.2.5 NUREG-0800, Standard Review Plan, Standard Review Plan for the Review of Safety
Analysis Reports for Nuclear Power Plants: LWR Edition, Chapter 7 - Instrumentation
and Controls, Revision 4, U.S. Nuclear Regulatory Commission, dated June 1997.
2.2.6 DI&C-ISG-01, Digital Instrumentation and Controls Task Working Group #1: Cyber
Security Interim Staff Guidance, Revision 0, U.S. Nuclear Regulatory Commission, dated
December 31, 2007.
2.2.6 Branch Technical Position 7-14, Guidance on Software Reviews for Digital Computer-
Based Instrumentation and Control Systems, Revision 5, U.S. Nuclear Regulatory
Commission, dated March 2007.
2.2.7 U.S. NUREG/CR-6430, Software Safety Hazard Analysis.
2.2.8 U.S. NRC RG-1.170, Software Test Documentation for Digital Computer Software Used
in Safety Systems of Nuclear Power Plans.
2.2.9 U.S. NRC RG-1.171, Software Unit Testing for Digital Computer Software Used in
Safety Systems of Nuclear Power Plants.
i nve. ns'. " in Ve. nfs'.t s

2.3. PG&E Documents

2.3.1 PG&E Purchase Order # 3500897372.
2.3.2 Master Service Agreement # 4600016720.
2.3.3 PG&E 08-0015-SP-001, Function Requirements Specification (FRS).
2.3.4 PG&E Process Protection System (PPS) Replacement Conceptual Design Document.
2.3.5 PG&E Process Protection System (PPS) Replacement Interface Requirements
Specification.
2.3.6 PG&E Process Protection System Controller Transfer Functions Design Input
Specification, 101 15-J-NPG.
2.3.7 PG&E Process Protection System (PPS) Function Block Diagram (FBD) 08-0015-D
Series.
2.4. Invensys Triconex Documents

2.4.1 IOM-Q2, Invensys Operation Management Nuclear Quality Assurance Manual.
2.4.2 NSIPM, Nuclear Systems Integration Program Manual, NTX-SER-09-21.
2.4.3 Quality Procedure Manual (QPM).
2.4.4 Invensys Project Procedures Manual (PPMs).
2.4.5 Invensys 9100150-001, Tricon Vl0 Nuclear Qualified Equipment List (NQEL).
2.4.6 Project Management Plan (PMP), 993754-1-905.
2.4.7 Project Quality Plan (PQP), 993754-1-900.
2.4.8 Software Quality Assurance Plan (SQAP), 993754-1-801.
2.4.9 V1O Tricon Topical Report, 7286-1-545, Revision 4, Invensys Operations Management
(ADAMS Accession Number ML1 10140443), dated December 20, 2010.
2.4.10 Tricon V 10 Conformance to Regulatory Guide 1.152, NTX-SER- 10-14.
2.4.11 RG1.152 Conformance Report, 993754-1-913.
i n V e. n s-.t:ý s-
n v* e. n s-.ýj s-
I Document: 1993754-1-802 1 Title: I Software Verification And Validation Plan
Revision: I I I Page: 13 of 46 Date: 10/13/2011
3. Derinition and Acronyms
3.1. Definitions
Acceptance Testing: Formal testing conducted to deten-nine whether or not a system satisfies
its acceptance criteria and to enable the customer to determine whether or not to accept the
system.
Anomaly: A condition observed in the documentation or operation of hardware and software
that deviates from expectations based on previously verified hardware/software products or
reference documents. A critical anomaly is one that must be resolved before the V&V effort
proceeds to the next phase.
Baseline: A work product that has been formally reviewed and accepted by the involved parties
as the revision level approved for the Implementation Phase of the project. A baseline should be
changed only through formal configuration management procedures. Some baselines may be the
project deliverables, while others provide the basis for further work.
Component Testing: Testing conducted to verify the implementation of the design for a system
hardware/software element (e.g., unit, module, function block etc,).
Criticality: A subjective description of the intended use and application of the system. Software
and hardware criticality properties may include: safety, security, complexity, reliability,
performance, or other characteristics.
Criticality Analysis: 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.
Deliverable: Document or product submitted to satisfy a requirement of the contract.
Demonstration: This is the life cycle activity where customer Factory Acceptance Testing
occurs.
Detailed Design: This life cycle activity contains typical work packages used during the design
stages of the project, such as: review design input, prepare P&IDs, define design control
strategies, develop design reports, etc.
Hazard Analysis: 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, environmental loss, or adverse
social impact. This evaluation may include screening or analysis methods to categorize,
eliminate, reduce, or mitigate hazards.
Implementation: This life cycle activity contains typical work packages used during the
hardware staging and software installation phase of the project. Typical work packages include:
review detailed implementation input, procure materials, configure control strategies, and
prepare test procedures and cases.
Inspection: A static analysis technique that relies on visual examination of development or
purchased products to detect errors, violations of development standards, specifications, and
other problems.
Integration Testing: An orderly progression of testing of incremental pieces of the software
program in which software elements, hardware elements, or both are combined and tested until
in ve. n s" s inV'e. n s. s"
Document: 1 993754-1-802 1 Title: I Softare Verification And Validation Plan
the entire system has been integrated to show compliance with the programs design, and
capabilities and requirements of the system. Typical work packages include verification of
control strategies, document verification and resolution of discrepancies. Verification is
performed during this activity.
Integrity level: A denotation of a range of values of a property of an item necessary to maintain
system risks within acceptable limits. For items that perform mitigating functions, the property is
the reliability with which the item must perform the mitigating function. For items whose failure
can lead to a threat, the property is the limit on the frequency of that failure.
Life Cycle Activity: A set of interrelated activities or processes that result in the development
or assessment of software and hardware products. For V&V purposes, no process is concluded
until its development products are verified and validated according to the defined tasks in the
SVVP.
Management Activity: This life cycle activity contains the generic activities and tasks, which
may be employed by any party that manages its respective processes. Examples of tasks are 1)
prepare plans for execution; 2) initiate the plans, etc. This activity is applicable to all life cycle
phases.
Phase: Defined for this document as a step in life cycle activity.
Preliminary Design: This life cycle activity contains typical work packages used in the
preliminary stages of a project, such as: contract review, define control strategies, develop
Project Plans, and describe change management.
Project Traceability Matrix: A documented matrix indicating the origin of the requirements,
their implementing design output documentation and the corresponding testing requirements.
Unit: An assembly of interconnected components that constitutes an identifiable device,
instrument, or piece of equipment. A unit can be disconnected, removed as a single piece, and
replaced by a spare. It has definable performance characteristics that permit it to be tested as a
single assembly. Software functions that meet the requirements of this definition are also defined
as a unit. By this definition, the words "unit" and "module" (hardware/software) are
interchangeable.
Verification: The process of evaluating a system or component to determine whether the
products of a given development phase satisfy the conditions imposed at the start of that phase.
Validation: The process of evaluating a system or component during or at the end of the
development process to determine whether it satisfies specified requirements.
3.2. Acronyms
ALS Advanced Logic System
DRCS Document Review Comment Sheet
FAT Factory Acceptance Test
FMEA Failure Modes and Effects Analysis
HRS Hardware Requirements Specification
HVT Hardware Validation Test
10 Input/Output
IV&V Independent Verification and Validation
M&TE Measurement and Test Equipment
inn V' . n • , s-
.,Lj inV'e. nfs'.tS.Ys"

Document: 1993754-1-802 1 Title: I Software Verification And Validation Plan
I Revision: 1 Page: 1 15 of 46 1 Date: 110/13/2011
MWS Maintenance Workstation

ND Nuclear Delivery
NQA Nuclear Quality Assurance
NRC Nuclear Regulatory Commission
NIST National Institute of Standards and Technology
PE Project Engineer
PQAE Project Quality Assurance Engineer
PQP Project Quality Plan
PLC Programmable Logic Controller
PM Project Manager
PPM Project Procedures Manual
PPS Process Protect System
PS Protection Set
PTM Project Traceability Matrix
QA Quality Assurance
QPM Quality Procedures Manual
SDC Software Development Checklist
SDD Software Design Description
SIDR System Integration Deficiency Report
SIL Software Integrity Level
SQAP System Quality Assurance Plan
SRS Software Requirements Specification
SVVP Software Verification and Validation Plan
Tricon Programmable Logic Process Controller by Triconex
TS 1131 TriStation 1131 Developer's Workbench
TSAP TriStation Application Project
V&V Verification and Validation
n v'e. n s>. Trcoe r"in ve. n s'.Y s"

Document: 1993754-1-802 I itle: I Software Verification And Validation Plan
4. V&V Overview
The V&V approach as described in IEEE 10 12-1998 will be used for conducting project V&V
activities. These activities will be planned and scheduled per the project schedule, the applicable
PPMs [Ref 2.4.4], and the PQP.
The V&V efforts shall be accomplished using a Nuclear Independent Verification & Validation
organization not associated with the Nuclear Delivery organization as identified in the PQP. This
independent V&V process is consistent with the process described in Annex C.4.1 of IEEE
1012-1998.
4.1. Organization
4.1.1. V&V Organization

The V&V organization for the Invensys Operations Management V&V team is shown in Figure
3. The figure shows the organizations involved in the PPS Replacement Project: Nuclear
Independent Verification and Validation (IV&V); Nuclear Delivery (ND); and Nuclear Quality
Assurance (NQA).
Figure 3. PPS Replacement Project Organization Structure

n v'e. n s sin" v e.n s.s. s

Document: I 993754-1-802 I Title: I Software Verification And Validation Plan
The Nuclear IV&V group shall be responsible for performing independent design document
review, software design verification, generating and verifying the V&V documents, and
performing V&V test executions. The Nuclear IV&V group will define its own schedule for the
V&V activities without any restrictions or influence from the Nuclear Delivery group.
The PPS Replacement Project team members from Nuclear IV&V include the IV&V Team Lead
and three IV&V Engineers.
During day-to-day V&V execution, the Nuclear IV&V team will interface with ND engineers
and the PQAE as needed. When anomalies have been identified during the project lifecycle,
cases may arise that require escalating the resolution to higher levels of management within
Invensys Operations Management. In Figure 3, the lines of communication between the
organizations at the Management and Director levels are shown by the dashed lines. As shown,
issues requiring escalation can be escalated up separate and independent reporting chains up to
the Director level. In those rare cases that the Director level is not sufficient, IOM-Q2 allows
escalation to the Regional and Global Director levels and still maintain the necessary managerial,
technical, and financial independence necessary for compliance with NRC requirements
contained in, for example, Regulatory Guide 1.168 [Ref 2.2.1].
4.1.2. V&V Responsibilities

Invensys Operations Management will assign a core group of engineers and support staff to the
PPS Replacement Project. As project needs change, assigned personnel will be added or
removed. The following individuals will be involved in the PPS Replacement Project:
Director- 77]
The Nuclear IV&V Director reports to the Global Director of Quality, and is responsible for
providing resources and expertise to V&V operations.
Manager - I L
The Nuclear IV&V Manager reports to the Director, Nuclear IV&V, and is responsible for
implementation of the nuclear IV&V activities conducted at the Invensys Operations
Management Lake Forest Facility. The IV&V Manager has the authority and organizational
freedom to ensure that V&V activities are managerially, technically, and financially independent
of the development organization. The IV&V Manager approves Project IV&V documents, e.g.,
Software Verification and Validation Plan (SVVP), IV&V Phase Reports, etc.
Staff -
The Nuclear IV&V Staff reports to the Nuclear IV&V Manager. Some of the major functions
and responsibilities for the IV&V Staff are listed below.
" Prepare the Software Verification and Validation Plan (SVVP).
" Prepare the Software Safety Plan (SSP).
" Prepare the Safety Analysis (Criticality/Hazards/Risk/Interface).
" Prepare the Validation and Verification Test Plans.
i n v'e.n" in V e. n s .t s
Operations ManagemenTt riconex
I Document: 1993754-1-802 Title: I Software Verification And Validation Plan
Revision: 1 Page: 18 of 46 I Date: 1 10/13/2011
" Perform independent review/verification of software design documents.

" Generate and execute Verification and Validation test procedures, and prepare reports on
the test results.
" Perform independent review/verification of test documents.
Test Director/IV&V Lead

The Test Director, also the IV&V Lead is a member of the IV&V Staff and reports
to the IV&V Manager. The Test Director is responsible for the overall conduct of assigned test
activities and participates in Project Review Committee (PRC) activities.
The following is a listing of the documents generated as a result of PPS Replacement Project
V&V activities. These documents shall be controlled per PPM 4.0 [Ref 2.4.4]. The specific
documents shall be developed and processed in accordance with the controlling Project
Procedures Manual. These documents shall be generated by the Nuclear IV&V staff, with the
exception of the PTM 1 and will be verified by Nuclear IV&V staff and approved by Nuclear
IV&V Manager.
1) Software Verification and Validation Plan, 993754-1-802.
2) Software Safety Plan, 993754-1-911.
3) Safety Analysis (Criticality/ Hazard/ Risk/ Interface), 993754-1-915.
4) Validation Test Plan, 993754-1-813.
5) Project Traceability Matrix, 993754-1-8041
6) Software Verification Test Plan, 993754-1-868.
7) Validation Test Specification, 993754-1-812.
8) Software Verification Test Specification, 993754-1-869.
9) Software Verification Test Procedure and Test Case, 993754-1n 2 -870-k 3 .
10) Software Verification Test Case Execution and Report, 993754-1n 2-853.
11) Hardware Validation Test Procedure, 993754- In 2-902-0.
12) Factory Acceptance Test Procedure, 993754-1 n2-902-1.
13) Validation Test Report.
a. Hardware Validation Test Report, 993754-1n 2-854-0.
b. Factory Acceptance Test Report, 993754-1n 2-854-1.
14) Project Traceability Matrix 1 , 993754-1-804.
15) V&V Phase Summary Reports, 993754-1-856 to -863.
16) System Time Response Confirmation Report, 993754-1-818.
The PTMs has shared responsibility. The Requirements and Design Phase PTM are prepared by Nuclear Delivery,
where the Implementation and Test Phase PTMs are prepared by Nuclear IV&V.
2 n = 1 through 4 to match the Protection Set. Project Plans are not required to have this additional number because
the plans are at the project level and not specific to a particular Protection Set.
3 k = 1 through i, where i is the number of programs in the V10 Tricon Protection Set application program (PT2
file).
in v'e. n s". inve. ns. s
17) V&V Final Report.
4.2. Project Schedule

The project schedule was developed based on the life cycle defined in the NSIPM [Ref 2.4.2] as
implemented by the PPM. Adhering to the procedures will also assure the required project
deliverables will satisfy PG&E technical and NRC regulatory requirements, and that the
necessary supporting collateral will be generated to support the safety conclusions of both ND
and Nuclear IV&V.
4.3. Software Integrity Level (SIL)

IEEE 10 12-1998, Section 4, provides guidance on selection of criticality levels for software
based on its intended use and application. Criticality levels are established by a subjective
evaluation of attributes. IEEE 1012 uses Integrity Levels to quantify criticality. The assigned
Software Integrity Levels may vary as the software evolves. However, the software and
hardware developed for nuclear safety related portions of this project will be used in a safety-
critical application and shall be classified as Software Integrity Level 4 (Criticality-High).
The project documents listed below identify the types of design outputs at the system level and
will be assigned a Software Integrity Level 4 rating:
1) Project Plans, Software V&V Plan, Software Safety Plan.
2) Project Specifications/Reports
a. Hardware Requirements Specification (HRS)
b. Software Requirements Specification (SRS)
c. Software Design Description (SDD)
d. Validation Test Specification
e. Verification Test Specification
f. V&V Activity Summary Reports
3) System Design Integration Drawings.
4) TriStation Application Project application program.
5) Verification and Validation Test Produces, Test Reports, Final V&V Report.
4.4. Resource Summary

The PPS Replacement Project requires a Nuclear IV&V staff with combined knowledge and
experience with the U.S. NRC regulations and processes, software engineering life cycle
management, and verification and validation of nuclear safety-related hardware and software.
Specific skills and knowledge are required in the following areas:
1) Application of U.S. NRC Regulatory Guides relevant to safety-system software
development.
2) Application of U.S. NRC Regulatory Guides relevant to independent verification and
validation of safety-system software.
i n V'e. n s'.y s- inVye.n s'. s"
Document: 993754-1-802 Title: So Verification And Validation Plan
ware
3) Application of relevant U.S. NRC staff guidance related to design and licensing of
nuclear safety systems, such as DI&C-ISG -06 [Ref 2.2.4].
4) Understanding of staff guidance contained in Chapter 7 of U.S. NRC NUREG-0800,
Standard Review Plan [Ref 2.2.5].
5) Application of Institute of Electrical and Electronics Engineers standards (e.g., those
endorsed by U.S. NRC Regulatory Guides) relevant to independent verification and
validation of software for nuclear safety-related applications.
6) Implementation of the Invensys Operations Management NSIPM and PPM to nuclear
safety-related projects.
7) Knowledgeable in the use of the TS 1131 Developer's Workbench, Invensys Emulator
Test Driver (ETD) and Microsoft Excel.
8) Knowledgeable of Tricon hardware.
9) Knowledgeable of safety and protection systems.
10) Experienced with reading and interpreting P&IDs, instrument diagrams, and function
block diagrams.
4.5. Tools, Techniques, and Methods
4.5.1. Tools
i n v'e. n s. s'
in v e. n s'.> s"
EL
i nv'e.n s'.: s"
in v'e. n s'.> s
w
in v* .n s'.ý s
i~~~~~~~ "e. rn {• - ".:: i V"e n s'.ý:
.. s-

DIocument: 1993754-1-802 I Title: I Software Verification And Validation Plan
5. V&V Process
The following explains the correlation of the Invensys Operations Management NSIPM life
cycle to IEEE 1012-1998 life cycle processes and activities.
Table 1. LifecycleMapping
IEEE 1012 V&V Lifecycle Processes NSIPM V&V Lifecycle Processes
Management Throughout (Primary Planning)
Acquisition Acquisition
Supply Throughout (Planning)
Development Development
" Concept • Planning
" Requirements • Requirements
" Design ° Design
" Implementation ° Implementation
• Test ° Test
Operation Delivery (scope of supply based on contract requirement.)
Maintenance
1) Management
The Management process is applicable to all phases the Project. Invensys Operations
Management shall meet the task performance requirements for management of V&V as
stated in IEEE 1012-1998. All acquisition process tasks shall be performed as
Management process activities. The supply process contract review task shall be
performed as a Management process activity.
2) Acquisition
Prior to accepting a Purchase Order, Nuclear Delivery reviews it to identify any
compliance issues. Until the review is completed, the Purchase Order is placed on.
Nuclear Hold, until the Acceptance Review is completed. A compliance matrix is created
to determine that the PG&E requirement can be satisfied. Nuclear IV&V reviews the
compliance matrix in accordance with IEEE Standard 1012-1998. Any deviations and
exceptions to PG&E requirements will be documented by Invensys Operations
Management and approved by PG&E.
3) Supply
This process is applicable for purposes of contract review, because a purchase order has
been offered and accepted. The supply process is initiated by either a decision to prepare
a proposal to answer an acquirer's request for proposal, or by signing and entering into a
contract with the acquirer to provide the system. This process also verifies that the
request for proposal requirements and contract requirements are consistent.
4) Development
This process is applicable to the Project and incorporates the majority of the project
activities. Invensys Operations Management shall meet the task performance
requirements for Development process activities as outlined below:
i n V e. n s-.i s- in Ve. nl s'. s"
a. Concept V&V - System architecture, allocation of system requirements to

hardware, software, and user interface components, and a specific implementation
are delineated in the system requirements and technical specifications provided to
Invensys Operations Management. Therefore these activities are not applicable.
b. Requirements V&V - Invensys Operations Management shall meet the task
performance requirements for Requirements V&V as stated in IEEE 1012-1998.
c. Design V&V - Invensys shall meet the task performance requirements for Design
V&V as stated in IEEE 1012-1998.
d. Implementation V&V - Invensys Operations Management shall meet the task
performance requirements for Implementation V&V as stated in IEEE 1012-1998.
Regression testing, as recommended by RG 1.168 [Ref 2.2.1 ], is accommodated
in this phase by the identification of required retest in the Anomaly Report.
e. Test V&V - Invensys Operations Management shall meet the task performance
requirements for Test V&V as stated in IEEE 10 12-1998.
f. Installation and Checkout V&V - Invensys shall meet the task performance
requirements for Installation and Checkout V&V as stated in IEEE 1012-1998
with the exception of the Final V&V Report which is produced in the Test phase.
During the development process, the following tasks shall be performed and the V&V
task reports issued if any changes to design inputs occur.
a. Evaluation of New Constraints
b. Proposed Change Assessment
These tasks shall be performed as part of the Baseline Change Assessment task included
in each lifecycle activity.
5) Operation
This phase covers the operation of the software product and operational support to users
after installation normal commissioning. It addresses operational testing, system
operations, and user support with respect to the operating procedures.
This is not applicable to the PPS Replacement Project after delivery to the customer.
Plant operating procedures are not within the Invensys Operations Management scope of
work.
6) Maintenance
This applies to modifications to code and associated documentation caused by a problem
or a need for improvement or adaptation of the product. It addresses modifications,
migration, or retirement of the software during the operational process.
Contract requirements are defined by the Warranty terms. These requirements shall be
maintained, along with processes for bug fixes (hardware and software), repairs, and
available upgrades. However, these processes are controlled at a corporate level, and
outside the scope of the PPS Replacement Project once the system is delivered.
in v" 2. n "s.• s- in ye. n.t', s-
Revision: I Page: 25 of 46 Date: 10/13/2011
5.1. V&V Management - General

Project personnel resources are managed separately between the ND staff and the Nuclear IV&V
staff. The Nuclear IV&V Manager ensures that the V&V process is not compromised due to
schedule conflict causing a change in personnel, which may lead to a less rigorous level of
technical review.
Good communication between the ND staff and the Nuclear IV&V staff is a significant
contributor to a proper V&V process. One of the objectives of the V&V process is to verify the
assumptions incorporated into the design solution. The V&V process must ensure that the basis
for an assumption is correct and that the system requirements are met within the constraints of
the assumptions.
5.2. System Life Cycle Verification

This PPS Replacement Project will deliver a configured system that meets the requirements of
the design defined by the customer. This will include translating the design requirements into the
system, and will rely heavily on engineering documents to facilitate this translation.
Tricon system hardware and software were verified as part of the initial qualification program
for Tricon hardware and software as identified in the Nuclear Qualified Equipment List (NQEL)
[Ref 2.4.5]. The TS 1131 programming tool is included in the set of software approved by the
NRC. In accordance with PPM 7.0, Application Program Development, the TSAP software and
system hardware lifecycle activities or phases applicable to the verification and validation of the
PPS Replacement Project are as follows:
1) Planning
2) Requirements
3) Design
4) Implementation
5) Test
5.2.1. Planning Phase

The planning of V&V is applicable to all software life cycles. Software development is an
iterative process. The V&V effort will usually identify the need to make certain software or
document changes requiring subsequent new tasks to implement these changes. V&V tasks are
re-performed if errors are discovered in the V&V inputs or outputs.
The Project will utilize the design review methodology to perform the design verification
process as defined in PPM 2.0 [Ref 2.4.4].
Should baseline documents require modification, the changes shall be controlled in accordance
with PPM 2.0 and PPM 3.0 as appropriate. The design review will use both an in-process project
peer review and an independent review by an independent review engineer.
in v'e. n s's in V e. n s'.* s

5.2.2. Requirements Phase

The system requirements form the basis for all system design and verification activities, and are
used throughout the rest of the system life cycle. They serve as the basis for the verification of
design specifications, which are the basis of design implementation. The system requirements
are the bases against which all validation activities are performed. The intent of verifying the
system requirements is to ensure that the requirements are complete, correct, consistent, clear,
traceable, and testable.
i n v e. n s. s"
inV'e. n s'.> s"
Document: 993754-1-802 Title: of are Verification And Validation Plan
Revision: 1 Page: 27 of 46 1 Date: 110/13/2011
F-L
in v'e. n s-. s" in Ve.n S
se . s'

5.2.3. Design Phase

The purpose of design verification is to ensure that the design documents are adequately and
accurately translated from the design inputs prior to design implementation. The design
specification documents define and provide the details of the system design structure,
in ve. n s.• s" i nV'e. ns.w s"

Revision: 1 Page: 29 of 46 1 Date: I 10/13/2011
information flow, processing steps, and other aspects required to be implemented in order to
satisfy the system design requirements. The intent of design verification is to ensure that the
design documents are clear and understandable, accurate, correct, consistent, complete,
implementable, testable, and traceable to the design requirements. The V&V tasks are conducted
on an ongoing basis. Test planning and verifying the conformance of the design are major
objectives of these V&V activities.
LiZ
i n V e. n s-
n v* e. n s-.!ý-j s-
5.2.4. Implementation Phase

The purpose of implementation verification is to ensure the implementation documents are clear,
understandable, logically correct, and adequately and correctly translate the design
specifications. The objectives of the implementation documents are to facilitate the effective
production, testing, use, transfer, and conversion to a different environment with consideration of
future modifications and traceability to design specifications. In general, the verification
activities should answer the following questions:
1) Does the implementation satisfy design specifications?
2) Does implementation follow established design standards?
3) Does implementation follow established documentation standards?
4) Does the implementation serve production, test, use, transfer, and other needs of the
customer?
5.2.4.1 Implementation Phase required inputs

in v'e. n s, s i n v'e. ns'.• s'

in ve. n s>. s" i n v e. n s'. s"

I Document: 1993754-1-802 I Title: Software Verification And Validation Plan
EiJ
5.2.5. Test Phase
The above verification process should provide a reasonable degree of assurance that the design
requirements were adequately and accurately translated through the Requirements, Design, and
Implementation Phases.
The system validation process determines whether the system meets its functional requirements
(functional operations, system level performance, external interfaces, internal interfaces,
testability, and other requirements stated during the requirements phase). System validation
evaluates the system performance against simulated inputs at the factory test facility. The
integrated system with the actual V10 Tricon Protection Set hardware and software is required.
w
i n v e. n s'.Y s"
in v2 n s'.ý s"
Operations Management Tr iconex
I Document: 1993754-1-802 1 Title: I S• are Verification And Validation Plan
I Revision: I I I Page: 1 33 of 46 1 Date: I 10/13/2011
EL
in V'e. nVS s2 s".
in v~e. n s.. s.
w
5.3. Post Test/Pre-Ship Checkout
Upon completion of the Test Phase activities, a system integration document package shall be
assembled in accordance with PPM 8.0[Ref 2.4.4]. The package shall include all as-built
drawings, completed test procedures, and customer-specified documents.
LiZ
i nl e. nV s'.l s"
in V'e. n s'.> s"
6. V&V Reporting
V&V reporting shall occur throughout the entire life cycle and include the following reporting
mechanisms.
6.1. V&V Activity Summary Report

Summary reports are required for the following phases:
" Requirements Phase
" Design Phase
" Implementation Phase
" Test Phase
6.2. Test Reports

A V&V Verification Test Report will be developed per PPM 7.01, Software Verification, to
summarize the results of the verification test execution.
A V&V Validation Test Report is required to be developed per PPM 6.0 to summarize the
results of the tests performed. This Test Report may be either included the Test Phase summary
reports or incorporated them as attachments.
6.3. Anomaly Reports

The guidelines for the SIDR and its associated form are defined in PPM 10.0 [Ref 2.4.4],
Nonconformance and Corrective Action. Additional guidelines for SIDR generation can be
found in PPM 6.0 and PPM 7.0.
6.4. V&V Final Report
w
i n ve. n s'.
in v'e. n s.! s" s"

w-
in v'e. n s"..
5" inv'e. ns',• s'

Revision: I Page: 37 of 46 I Date: 1 10/13/2011
7. V&V Administrative Requirements
w]
7.4. Control Procedures

The control procedures and plans applied to the V&V effort are:
1) Project Procedures Manual.
2) Project Management Plan.
3) Software Quality Assurance Plan.
4) Software Configuration Management Plan.
5) Software Verification and Validation Plan.
The above documents describe the quality assurance, configuration management, data
management, security, and protection of V&V results from unauthorized alterations.
7.5. Software Standards, Practices, and Conventions

Replacement of the Diablo Canyon Power Plant Process Protection System requires NRC
approval prior to installation of the V1O Tricon Protection Sets. PG&E intends to submit the
License Amendment Request package in the middle of July 2011. There are a number of
regulatory requirements that must be satisfied, such as 10 CFR 50.55a (h), which incorporates
inV 2.
~~~~i9*Il
n s-.ý n n s'..s"in:e V'e.
2
nl .
s'.-
IEEE Standard 603-1991 by reference. There are also a number of regulatory guidance
documents that will be followed by Invensys Operations Management during the V 10 Tricon
Process Protection System development. The regulatory guidance documents endorse consensus
standards from the Institute of Electronics and Electrical Engineers (IEEE). The standards to
which Invensys Operations Management conforms are also listed below.
The software standards, practices, and conventions that govern the performance of V&V tasks
are defined in the Project Procedures Manual. Verification and validation activities shall be
performed in accordance with Project Procedure Manual PPM 2.0, PPM 6.0, and PPM 7.0.
NRC Staff Review Guidance:

" NUREG-0800, Standard Review Plan, Chapter 7.
* Branch Technical Position 7-14, Guidance on Software Reviews for Digital Computer-
Based Instrumentation and Control Systems.
Regulatory Guides:
0 1.152, Criteria for Use of Computers in Safety Systems of Nuclear Power Plants.
0 1.168, Verification, Validation, Reviews and Audits for Digital Computer Software Used
in Safety Systems of Nuclear Power Plants.
0 1.169, Configuration Management Plans for Digital Computer Software Used in Safety
Systems of Nuclear Power Plants.
0 1.170, Software Test Documentation for Digital Computer Software Used in Safety
Systems of Nuclear Power Plants.
* 1.171, Software Unit Testing for Digital Computer Software Used in Safety Systems of
Nuclear Power Plants.
0 1.172, Software Requirements Specifications for Digital Computer Software Used in
a 1.173, Developing Software Life Cycle Processes for Digital Computer Software Used in
* 1.180, Guidelines for Evaluating Electromagnetic and Radio-Frequency Interference in
Safety-related Instrumentation and Control Systems.
IEEE standards:
0 603, IEEE Standard Criteria for Safety Systems for Nuclear Power Generating Stations.
o 7-4.3.2, IEEE Standard Criteria for Digital Computers in Safety Systems of Nuclear Power
Generating Stations.
0 828, IEEE Standard for Configuration Management Plans.
0 829, IEEE Standard for Software Test Documentation.
* 830, IEEE Recommended Practice for Software Requirements Specifications.
0 1012, IEEE Standard for Software Verification and Validation.
0 1028, IEEE Standard for Software Reviews and Audits.
0 1059, IEEE Guide for Software Verification and Validation Plans.
* 1074, IEEE Standard for Developing Software Life Cycle Processes.
* 1228, IEEE Standard for Software Safety Plans.
in v e n s"
in v'e. n s'.> s"
Document: ] 993754-1-802 ] Title: ] Software Verification And Validation Plan
Revision: I Page: 39 of 46 Date: 10/13/2011
Other standards:
" ANSI/ASME NQA-l -1983, Quality Assurance Program Requirements for Nuclear
Facilities.
• ANSI/ASME NQA-la-1983 (Addenda), Addenda to ANSI/ASME NQA-I-1983, Quality
Assurance Program Requirements for Nuclear Facilities.
" ANSI/ASME NQA-I-1994, the basis for the PPM.
invNe.n s'.o s"
in v'e. n sn.=i s"
Revision: 1 Page: 40 of 46 1 Date: I 10/13/2011
8. Appendices
Appendix A - Typical Verification and Validation Flow Chart
Appendix B - Task Report Log
Appendix C - Task Report Form

in V*e. n s j s- i n V e, n s'.ý s"

Document: 1993754-1-802 I Title: Software Verification And Validation Plan
Appendix A - Typical Verification and Validation Flow Chart
Figure A. Typical V&V Flow Chart

in V'e. nfsl ý s'
in V'e. n s'.ý s"
Appendix B - Task Report Log

in v'e. n s-!ý S"
TM i n V e.n sn"t-#
S
Operations Management
Triconex
Document: 993754-1-855
i e. fl
2 nVs s"
in v'e. n s-. s"
I Document: 1993754-1-802 I Title: I Software Verification And Validation Plan
Revision: 1 Page: 44 of 46 ] Date: 1 10/13/2011
Appendix C - Task Report Form

in v'e. n s'.> sOM in V e ns'.- s"
Operations Management
Triconex
Document: 993754-1-855
in v e. n s'.> s" in v'e.n s'.- s"
wL
Document: 993754-1-855

ML11318A030

Uploaded by

Copyright:

Available Formats

ML11318A030

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ML11318A030

Uploaded by

Copyright:

Available Formats

in v'e. n s'.9 s" i nv e. n s-.

Operations Management Triconex

PACIFIC GAS & ELECTRIC

SOFTWARE VERIFICATION AND VALIDATION

Document No. 993754-1-802 (-NP)

October 13, 2011

Non -Proprietary copy per 1OCFR2.390

Name Signature Title

Operations Management Triconex

Document Change History

Operations Management Triconex

L ist of T ables ............................................................................................................5

L ist of F igures ...........................................................................................................6

1. Introd uction .................................................................................................... 7

3. Definition and Acronym s ............................................................................. 13

4. V & V O verview .............................................................................................. 16

5. V &V P rocess ................................................................................................. 23

Operations Management Triconex

6. V & V Reporting .............................................................................................35

7. V & V A dm inistrative Requirem ents ........................................................... 37

Operations Management Triconex

T able 1. L ifecycle M apping ..................................................................................................... 23

®PWR Protection Concept ] ~~~Rod [•1e

Operations Management Triconex

The goals of this SVVP are to:

1.3. Verification and Validation Program Implementation

Refer to Appendix A of this SVVP for a typical V&V Flow Chart.

Operations Management Triconex

2.1. Industry Documents

2.2. NRC Documents

Operations Management Triconex

2.3. PG&E Documents

2.4. Invensys Triconex Documents

3. Derinition and Acronyms

Operations Management Triconex

MWS Maintenance Workstation

Operations Management Triconex

4.1.1. V&V Organization

Figure 3. PPS Replacement Project Organization Structure

Operations Management Triconex

4.1.2. V&V Responsibilities

" Perform independent review/verification of software design documents.

Test Director/IV&V Lead

17) V&V Final Report.

4.2. Project Schedule

4.3. Software Integrity Level (SIL)

4.4. Resource Summary

4.5. Tools, Techniques, and Methods

Operations Management Triconex

a. Concept V&V - System architecture, allocation of system requirements to

5.1. V&V Management - General

5.2. System Life Cycle Verification

5.2.1. Planning Phase

Operations Management Triconex

5.2.2. Requirements Phase

Operations Management Triconex

5.2.3. Design Phase

Operations Management Triconex

5.2.4. Implementation Phase

5.2.4.1 Implementation Phase required inputs