ML18100A315

Rev 1 to Process Computer Maint & Mod Control Program

ML18100A315
Person / Time
Site:	Salem
Issue date:	07/28/1992
From:	Waite C Public Service Enterprise Group
To:
Shared Package
ML18100A314	List: ML18100A313 ML18100A315 ML18100A316 ML18100A317 ML18100A318
References
ND.DE-AP.ZZ-005, ND.DE-AP.ZZ-5, NUDOCS 9304210003
Download: ML18100A315 (85)

Text

Page 1 of 1 PSE&G NUCLEAR DEPARTMENT ND.DE-AP.ZZ-0054(Q) -

REV. 1 PROCESS COMPUTER MAINTENANCE AND MODIFICATION CONTROL PROGRAM SPONSOR ORGANIZATION:

Engineering and Plant Betterment

=====================================================

REVISION

SUMMARY

1.

This is a limited revision to ND.DE-AP.ZZ-0054(Q), Rev. o.

Margin bars have been used to indicate revision 1 changes.

2.

Added a List of Effective Pages.

3.

Added pages 25A, 25B, and 26A.

4.

Added sections 5.8 and 5.9 and renumbered the subsequent section.

5.

Changed requirements for modifications to existing system Requirements Documents.

6.

Added definitions for authorized users list, backup, protected area, and sponsor.

7.

Changed Form ND.DE-AP.ZZ-0054-3 to refer to Form ND.DE-AP.ZZ-0054-6.

8.

Added Form ND.DE-AP.ZZ-0054-7, Revision Summary.

IMPLEMENTATION REQUIREMENTS:

This Limited Revision is effective upon issuance.

-==-~--------===========================================

PREPARER:

7 /2 7/ef z._

Date

~

1992. PS~c!,(_G Co.

ti.:: aif?Fi~.

. ~304210003 930126--~

I PDR ADOCK 05000272 p

PDR 1

PROCESS COMPUTER MAINTENANCE AND MODIFICATION CONTROL PROGRAM LIST OF EFFECTIVE PAGES Page No.

Rev. No.

Page No.

Rev. No..

CP 1

Attach. 1 1

1 1

0 2

0 2

0 3

0 3

0 4

0 4

0 5

1 Form DEAP54-1 0

6 0

Form DEAP54-2 0

7 0

Form DEAP54-3 8

0 1

0 9

0 2

0 10 1

3 1

11 0

4 0

12 0

5 0

13 0

6 0

14 0

7 0

15 0

8 0

16 0

9 0

17 0

10 0

18 0

11 0

19 0

Form DEAP54-4 20 1

1 0

21 0

2 0

22 0

Form DEAP54-5 0

23 0

Form DEAP54-6 24 0

1 0

25 0

2 0

25A 1

Form DEAP54-7 1

25B 1

26 1

26A 1

27 0

28 0

Rev. 1 Page 1 of 1

L Software ID Number:

system Code:

Software source:

(If not PSE&G)

FORM ND.DE-AP.ZZ-0054-2 computer Index Form Description of software Application ' Intended Use:

Date/Time of Development/Revision:

Name of sponsor:

Software user Designated contact:

Hardware system and Operating system/Software on Which Software is Run:

1. Software Users Manual ID/Rev:

2. Operating System ID/Rev:

3. Hardware:

computer Programming Facilities used:

computer Programming Language:

Time of Day Program is Normally Run:

Associated Vendor Manuals:

Other Information:

Page 1 of 1 Rev. o

THIS PAGE IS INTENTIONALLY LEFT BLANK.

Revision:

Date:

FORM ND.DE-AP.ZZ-0054-3 software/Database Maintenance Form Cover Sheet

~~~~~~~~

Page l of 11 Rev. o

THIS PAGE IS INTENTIONALLY LEFT BLANK *.

FORM HD.DE-AP.ZZ-0054-3 Software/Database Maintenance Form

1. SOFTWARE/DATABASE MAINTENANCE CRITERIA (5.2.l}

The proposed software maintenance task will (check applicable i tern} :

correct identified software errors update software or database parameters to reflect physical plant changes update software or database parameters to reflect changes to procedures, set points, et cetera upgrade existing software functions (e.g. improve accessibility for historical data}

create utility programs for diagnostic, maintenance, or periodic functions An equivalent replacement evaluation, per the generic 10CFR50.59 Review (A-O-COM-ESE-0802}, has been completed; this maintenance meets or exceeds the design requirements of the original design specifications.

Assigned Engineer Date

2. WORK DEFINITION (5.2.2)

A. Statement of Work (attach additional sheets if needed):

B. Deslgn Issues (initial the appropriate status):

Analysis of current activity has not revealed any associated design basis deficiencies.

Analysis of current activity has revealed associated design basis deficiencies. (attach description of design basis deficiency or fill out and attach Discrepancy Evaluation Form (DEF} as appropriate}

Page 2 of 11 Rev. o

I -

FORM ND.DE-AP.ZZ-0054-3 Software/Database Maintenance Form

c. Maintenance Justification (state basis for change, or refer to appropriate documentation) :

correct existing deficiency.

Identify by Software Error Notice Report (Form ND.DE-AP.ZZ-0054-6), DEF per DE-AP.ZZ-0018(Q), or DR per NC.NA-AP.ZZ-0020(Q):

Revision to existing algorithm If revision to existing algorithm, identify basis for change (for example, Change Package number or Engineering Evaluation)

Other (explain, attach additional sheets if needed)

D. Plant Procedure Effects List any plant procedures that will require revision:

{Complete Form NC.NA-AP.ZZ-0032-1, New Procedure/Revision Request {NPRR), and send to sponsor)

Paqe 3 of 11 Rev. 1

I -

FORM ND.DE-AP.ZZ-0054-3 Software/Database Maintenance Form E. Major Activities Briefly list anticipated major activities required (for example, procurement, code modification, special test setups, information required from outside sources):

F. Alternative Approaches Briefly discuss alternatives considered (for small changes where alternatives are impractical, mark N/A)

G. User Impact ariefly.describe impact of changes to users (for changes requiring system downtime, describe implementation and contingency plans)

Page 4 of 11 Rev. o

THIS PAGE IS INTENTIONALLY LEFT BLANK.

3. CONCURRENCE (5.2.3)

FORM ND.DE-AP.ZZ-0054-3 software/Database Maintenance Form A. V&V Concurrence The preliminary information has been reviewed for scope, completeness, and clarity.

Any discrepancies identified during the review have been resolved.

B. Supervisor Concurrence Is special concurrence required? (yes or no)

Computer Supervisor/Date~~~~~~~~~~~~~~-/~~~~~

c. Technical/User Concurrence Signature below indicates concurrence with the definition, and scope of the software/database maintenance activity described in sections 1 and 2 of this form.

Required N/A Signature Salem Operations HC Operations Salem Technical HC Technical E&PB Salem I&C E&PB HC I&C E&PB Elec. Eng.

Page 5 of 11 Rev. o

THIS PAGE IS INTENTIONALLY LEFT BLANK.

4. WORK PLAN (5.2.4)

FORM ND.DE-AP.ZZ-0054-3 Software/Database Maintenance Form A. Work Review Based upon review of existing documentation, identify documents that will require modification/creation: (check

."Required" or "N/A" for each document)

Required N/A SRO DDD AT RTM User Manual Department Procedures PSBPs B. Detailed Work Description Check one of the following:

Attached are revised/new (circle one) copies, of the SRO and ODD section(s) to describe specific work to be performed.

Specific work to be performed does not affect SRO or DOD.

Description of specific work is detailed below.

specific work to be performed is as follows {attaching marked up listings is acceptable where war~ is obvious):

Paqe 6 of 11 Rev. o

I THIS PAGE IS INTENTIONALLY LEFT BLANK.

FORM ND.DE-AP.ZZ-0054-3 software/Database Maintenance Form

c.

Detailed Test Instructions Check one of the following:

Attached is revised/new/applicable section(s)

(circle one) of the AT to provide detailed test instructions including any steps required to implement the change (such as compile, catalog, patch).

The AT document does not contain, and would be inappropriate to contain detailed test instructions for this work.

Detailed Testing directions are identified below.

Detailed testing instructions - where the AT is not being used - are as follows (attaching separate sheet(s) is acceptable) :

5. VERIFICATION AND V)d.IDATION DESIGN REVIEW (5.2.5)

The detailed design for this software/database maintenance package has been reviewed, the results of the review documented, and all identified design discrepancies have been resolved.

V&V Reviewer Date Page 7 of 11 Rev. o

THIS PAGE IS INTENTIONALLY LEFT BLANK.

FORM ND.DE-AP.ZZ-0054-3 Software/Database Maintenance Form

6. IMPLEMENTATION (5.2.6)

A. Approval to Install Computer Group Supervisor Date B. Implementation Checklist

7. TESTING (5.2.7)

Work order obtained Affected user groups notified Existing system confirmed to reflect latest baseline Backup exists for system Testing has been satisfactorily performed, and (check one of the following) :

all discrepancies have been resolved all discrepancies within the scope of this maintenance activity have been resolved.

Discrepancies beyond the scope of this modification were observed and have been documented as DEFs for future consideration.

All signed test documents, discrepancy reports, and retest results have been attached to this document.

Assigned Engineer Date V&V Reviewer Date Page B of 11 Rev. o

THIS PAGE IS INTENTIONALLY LEFT BLANK.

8. CLOSEOUT (5.2.8)

FORM ND.DE-AP.ZZ-0054-3 Software/Database Maintenance Form A. User Notification The following groups have been notified of completion of field testing and installation (identify individual):

Notified N/A Individual Salem Operations HC Operations Salem Technical HC Technical Emergency Prepar.~~~~~~~~~~~~

E&PB Salem I&C E&PB HC I&C E&PB Elec. Eng.

Assigned Engineer Date Page 9 of 11 Rev. o

THIS PAGE IS INTENTIONALLY LEFT BLANK.

1-FORM ND. DE-*AP. ZZ-0054-3 Software/Database Maintenance Form B. System Backup Check one of the following:

A complete system backup has been made, and a copy shall be forwarded to CCG per ND.DE-TS.ZZ-5437{Q).

(*) A partial backup has been made that shall be applied after latest baseline is restored if /when required

(*} A backup has not been made due to the minor nature of the work, changes shall be manually re-entered if /when baseline is restored.

(THIS OPTION MAY NOT BE USED WHEN THERE ARE MORE THAN THREE (3)

MINOR CHANGES SINCE LAST BASELINE.}

In cases where either partial backups or no backups are performed at time of original installation, the date on which the next baseline tape is generated shall be documented below with the name and signature of the engineer performing the backup.

The changes performed under this maintenance form have been incorporated in the latest baseline and a copy forwarded to CCG.

Baseline Date Engineer performing backup

c. V&V Closeout Concurrence The fol.lowing items have been adequately addressed:

Initial Date Plant procedures Soft'\\lit*are design Software correction Software design review Off line testing Online testing Client concurrence Page 10 of 11 Rev. o

THIS PAGE IS INTENTIONALLY LEFT BLANK.

FORM ND.DE-AP.ZZ-0054-3 software/Database Maintenance Form The implementation, testing, turnover of changes, and document updates made for this maintenance activity have been completed.

All discrepancies resulting from this maintenance activity have been dispositioned.

V&V Reviewer Date Assigned Engineer Date D. Documentation Update The Workbook, NC.DE-WB.ZZ-0004(Q), "Engineering Workbook for Document -

Only Change" (CCP), has been completed.

Assigned Engineer Date Page 11 of 11 Rev. o

THIS PAGE IS INTENTIONALLY LEFT BLANK.

FORM ND.DE-AP.ZZ-0054-4 Verification and Validation Checklist System Requirements Document:

Review the System Requirements Document for the following and indicate acceptability by specifying either Yes or No. (If the item does not apply, specify "NA".)

Acceptable Yes/No Complete and correct specification of the performance requirements and operational capabilities and concepts of the system Comp*lete and correct system definition and interfaces with other equipment Unambiguous, correct, and consistent description of the interfaces and performance characteristics of each major function Establishment of reasonable and achievable set of test requirements, which are related to performance goals and also define acceptance criteria

• Definition of physical characteristics, reliability and maintainability objectives, operating environment, transportability constraints, and design and construction standards, including those intended for the software

• Definition of necessa~y logistics, personnel and training requirements and considerations

• Definition of input and output signals, and establishment.and management of the database

• Treatment of the human/machine requirements

• Definition of the subsystems and integration requirements

• Definition of installation, operation, and maintenance requirements Page 1 of 2 Rev. o

Verification and Validation Checklist Detailed Design Document:

Review the Detailed Design Document for the following and indicate acceptability by specifying either Yes or No. (If the item does no apply, specify "NA".)

Acceptable Yes/No

• Architecture for both hardware and software

• Input/output interfaces

• System and executive control

• Operating sequences: initialization, startup, error detection, restart, etc.

• Testability: use of test equipment such as data tapes and simulations

• Timing analysis: sampling rates, response time, etc.

• Availability: analysis and data indications

• Algorithm design and data verification

• Information flow: communication between hardware subsystems, data management, and signal conversion to engineering units

• Human factors engineering Test Validation:

Indicate the acceptability of the following for test validation.

Acceptable Yes/No

• The software adequately and correctly performs* all intended functions.

• The software does not perform any function that either by itself or in combination with other functions can degrade the performance of the entire system.

V&V Reviewer Date Page 2 of 2 Rev. o

• Software/System Name:

Revision:

Type of Review:

COMMENT:

DISPOSITION:

v'v ACCEP'l'AlfCI:

FORM ND.DE-AP.ZZ-0054-5 Verification and Validation comment/Disposition Form Comment No.

V&V Reviewer Sponsor V&V Reviewer Paqe 1 of 1 Date Date Date Rev. o

THIS PAGE IS INTENTIONALLY LEFT BLANK.

Software ID Number:

FORM ND.DE-AP.ZZ-0054-6 Software Error Notice Report Software Error Notice Number:

Software Error Notice Revision:

Software Document Name:

Sponsor Group:

Error Summary: {Use additional pages as necessary.)

Proposed Corrective Action:

Paqe 1 of 2 Rev. o J

FORK ~u.u~-~.~~-00~4-Software Error Notice Report Items Affected by the Error:

Sponsor The error has been corrected by Name*

on Date Page 2 of 2 Date Rev. o

td 1111 IQ CD 0

~

CD <.

REVISION

SUMMARY

PROCESS COMPUTER DATE

• ORIGINATOR PACKAGE REVISION

• = sign and print name Process Computer Packaqe Number

• V&V ENGINEER

• SUPERVISOR REVISION DESCRIPTION Page

THIS PAGE IS INTENTIONALLY LEFT BLANK.

I

~

ND.DE-AP.ZZ-0054(Q)

PROCESS COMPUTER MAINTENANCE AND MODIFICATION CONTROL PROGRAM TABLE OF CONTENTS Section Title 1

• 0 PURPOSE ************* o ******* e ************

• 2 2 ** 0 SCOPE ***.*** a **************************** ;.

• -2 3.0 RESPONSIBILITIES........................... 2 4

• O BACKGROUND o ****************** o ** o *******

• 3 5. 0 PROCEDURE.*...*..*..... o ****************** o 4 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 Evaluation of Existing Software....... 5 Software/Database Maintenance......... 6 Hardware Maintenance Change criteria. 16 Functional Design Changes....... ~.... 18 System Troubleshooting and Emergency Maintenance Instructions **...*.*..... 23 Commercial Software....... * *. *....... 2 5 Error Reporting.***..**....*****.**.. 2 5 Critical Software Electronic Media Backup * * *. * * * * * * * * * * * * * * * * * * * *. * * * *

• 2 5A Software security...*..*....*......* 25A Records *. *. *.... *. * *.. *... * *...... o *

• 2 6 6. 0 DEFINITIONS...............*...... o ** o *

• 2 6 7. O REFERENCES *. * * * * * * * * * * * * * * * * * * * * * * * * * *.. *

• 2 7 ATTACHMENT - Generic 10CFRS0.59 A-O-COM-ESE-0802 FORMS ND.DE-AP.ZZ-0054 Process Computer Package Cover Sheet ND.DE-AP.ZZ-0054 Computer Index Form ND.DE-AP.ZZ-0054 Software/Database Maintenance Form ND.DE-AP.ZZ-0054 Verification and Validation Checklist ND.DE-AP.ZZ-0054 Verification and Validation Comment/Disposition Form ND.DE-AP.ZZ-0054 Software Error Notice Report ND.DE-AP.ZZ-0054 Revision Summary Page l of 28 Rev. 1

ND.DE-AP.ZZ-0054(Q) 1.0 PURPOSE The purpose of this procedure is to document the method by which maintenance and modifications to existing process computer systems and installations of new process computer systems shall be performed.

This procedure describes the methods of test performance, how errors will be documented and corrected, and the degree of subsequent testing.

The completed Form ND.DE-AP. ZZ-0054-3, Software/Database Maintenance Form, Form*

ND.DE-AP.ZZ-0054-4, Verification and Validation Checklist, and Form ND.DE-AP.ZZ-0054-5, Verification and Validation Comment/Disposition Form, report the verification and validation of the maintenance or modification.

2. 0 SCOPE This procedure will apply to the maintenance or modification to any existing Plant Process Computers as defined in VPN-MSP-10, Process Computer systems, or to the installation of any Plant Process Computers performed under the direction of the Engineering and Plant Betterment (E&PB) Nuclear Computer Group (NCG).

This procedure is to be used in place of ND.DE-AP.ZZ-0052(Q),.*

Software Control, for these systems.

This procedure does not address the issues of funding, prioritization, or account authorization.

The assumption is made that all modifications exceeding the prescribed funding limits will have been cleared through the Nuclear Department Resource Allocation Program (NDRAP) process in accordance with NC.NA-AP.ZZ-0065(Z), Nuclear Department Resource Allocation Program.

This procedure shall apply to maintenance or modifications initiated through Work Requests, Work Orders, Engineering Work Requests, and projects authorized through the NDRAP Program.

3.0 RBSPOBSIBILITIIS 3.1 Nuclear Computer Group supervisor is responsible for:

Rav. o Maintaining this procedure Training a-11 group members in the use of this procedure and documentation of this training Resolving concerns over the use of this procedure Page 2 of 28

ND.DE-AP.ZZ-OOS4(Q)

Identifying/evaluating any problems or suggestions to improve this procedure Assigning Verification and Validation (V&V) reviews 3.2 senior Project Engineer is responsible for:

Ensuring this procedure is incorporated into all Project Scope Proposals (PSPs) or other preliminary documentation for projects affecting computer systems Ensuring this procedure is followed for all project implementation Identifying any problems or suggestions to improve this procedure Performing or coordinating V&V review assignments of computer Group Engineers / Analysts 3a3 computer Group Engineers/Analysts are responsible for:

Implementing this procedure for computer maintenance and modifications Identifying any problems or suggestions to improve this procedure Performing V&V review as requested

4.0 BACKGROUND

This procedure defines the details for implementing the

• various requirements of:

NC.NA-AP.ZZ-0064(Q)

NC. NA-AP. ZZ-0009 (.Q)

NC.NA-AP.ZZ-OOOS(Q)

Software Quality Assurance Work Control Process Control of Design and.Configuration Change, Tests and Ext;)eriments computer systems pose unique configuration contr.ol problems, based on the nature of the media being controlled.

CR-92-002 This procedure was created as a result of NQA Action Request M29-91-090-6M.

Paqa 3 of 28 Rev. o

ND.DE-AP.ZZ-0054(Q) 5

• 0 PROCEDURE Rev. o There are four categories of activities:

Software Maintenance - Software activities made to correct deficiencies and to update software to reflect new conditions that do not affect existing functional designs Data Maintenance - Data activities made to correct deficiencies and to update such items as limits, constants, and deadbands to reflect existing plant conditions Hardware Maintenance - Activities made to correct deficiencies or upgrade components that do not affect existing functional desi'gns or the approved design basis as described by the Salem and Hope Creek Updated Final Safety Analysis Reports (UFSARs)

Functional Design Changes - Changes that add, delete, or modify portions of the functional design of a system The following subsections describe the criteria for determining the type of activity, the methods, and the requirements for addressing each change type.

Tasks shall have a responsible engineer and a V&V reviewer assigned by the NCG Supervisor.

Normal Maintenance Activity for hardware (see 5.3.1) does not require a V&V reviewer.

The engineer assigned to each task is resp.onsible for making an initial determination as to which process to follow.

After preliminary scoping has been performed, concurrence with the determination shall be obtained.of the Senior Project Engineer or NCG Supervi~or.

When an activity does not fall clearly within.the bounds of the defined types, the NCG Supervisor shall make the determination as to which process or processes to follow.

When problems do not have known causes, investigation is permissible prior to initiating the formal maintenance or modification process.

Refer to section 5.5 for limitations and considerations to be used during investigation or troubleshooting.

Page 4 of 28

5.1 5.1.1 ND.DE-AP.ZZ-0054(Q)

NOTE Throughout the remainder of this procedure, any reference to a specific document (for example, a System Requirements Document, a Detailed Design Document, or an Acceptance Test) applies either to that document or to its equivalent, as indicated on Form ND.DE-AP.ZZ-0054-1, Process Computer Package cover Sheet.

(See 5.1.5).

Evaluation of Existing Software Existing software shall be evaluated by the sponsor in order to justify continued use.

Evaluation shall ensure adequacy of the software and shall also ensure that all changes are controlled in accordance with this procedure.

Evaluation consists of the manager's documented approval of the software for use.

This approval may be in the form of a letter that is signed by the sponsor's manager.

A copy of each evaluation shall be retained in the sponsor's files.

5.1.2 After completion of the evaluation, an abbreviated software package shall be developed by the responsible NCG Engineer.

The package shall consist of the following completed documents:

5.1. 3 Form ND.DE-AP.ZZ-0054-1 Form ND.DE-AP.ZZ-0054-2, Computer Index Form The initial or revised evaluation of the software, as applicable Form ND.DE-AP.ZZ-0054-7, Revision summary, starting with a revision number of O in the Process Computer Package Revision column The software package identification number shall be obtained.

This number is described in DE-AP.ZZ-0032(Q),

Document Identification, and is obtained per DE-AP.ZZ-0033 (Q), Configuration Control - Engineering Document Control Procedure.

The system code i~ obtained per DE-TS.ZZ-5408(Q), MMIS Input Documents.

Process the completed software package per DE-AP.ZZ-0033(Q).

5.1.4 The sponsor shall make backup copies of the program and data disks or tapes and process them per ND.DE-TS.ZZ-5437{Q),

storage and Retrieval of Electronic Media.

The sponsor shall also supply any additional copies of the disks to the configuration Control Group (CCG) and designate in writing those users who are authorized to have copies.

Paqe 5 of 28 Rev. 1

5.1. 5 Any System Require::tents Document, Detailed Design Document, or Acceptance Test shall be identified on Form ND.DE-AP.ZZ-0054-1.

Equivalent documents, such as manuals supplied by a system vendor, are acceptable.

If equivalent documents are used, they shall be identified as the SRO, the ODD, etc. (Note that a vendor manual may be equivalent to both the SRO and the DOD.)

5.2 Software/Database Maintenance All software and database maintenance shall be tracked using Form ND.DE-AP.ZZ-0054-3. The form shall be filled out as each activity is completed.

The following sections describe the activities that shall be performed for all software and database ma ::.ntenance.

5.2.1 Software/Database Maintenance Cr~~eria Rev. o

a.

The following types of software activities shall be performed using the method described in this procedure:

Activities to correct identified software errors Activities to update software to reflect physical plant changes Activities to update software to reflect changes to procedures, setpoints, etc.

Activities to upgrade existing software functions (for example, improving accessibility for historical data)

Activities to create utility programs for diagnostic, maintenance, or periodic functions

b.

The following types of database activities shall be performed using the method described in this procedure:

Activities to correct identified data errors Activities to update database parameters to reflect physical plant changes Activities to update database parameters to reflect changes to procedures, setpoints, etc.

Page 6 of 28

5.2.2 ND.DE-AP.ZZ-0054(Q)

c.

Upon determining that the task meets the preceding criteria and completing the Cover Sheet and Software/Database Maintenance Criteria, section 1, the assigned engineer shall proceed to Work Definition, section s.2.2.

d.

If the task does not meet the criteria for software and database maintenance, the assigned engineer shall review the Normal Maintenance Activity - Criteria section (5.3.1) and the Functional Design Change Criteria section (5.4.1) to determine if the change belongs in another category.

e. If no clear definition exists, the NCG Supervisor shall determine the process to follow.

f., the generic 10CFR50.59 Review and Safety Evaluation for software and database maintenance (reference number A-O-COM-ESE-0802), from NC.NA-AP.ZZ-0059(Q), shall be reviewed.

Any activity(ies) not covered under this review shall be considered a "functional" change and shall follow requirements of section 5.4 of this procedure.

Each unique use of the A-O-COM-ESE-0802 10CFR50.59 generic evaluation requires completion of an equivalent replacement evaluation to determine whether the new software or data meets or exceeds the design requirements of the original design specifications.

The assigned engineer shall complete Page 1 of Form ND.DE-AP.ZZ-0054-3 and then sign and date Software/Database Maintenance Criteria, section 1, when it is determined that maintenance complies with the generic 10CFR50.59 Review and Safety Evaluation constraints.

Work Definition

a.

Once the determination has been made that a specific reques~ fits the definition of software or database maintenance, the assigned engineer shall complete the Work Definition, section 2A.

Page 7 of 28 Rev. o

ND.DE-AP.ZZ-OOS4(Q)

Rev. o

b.

The assigned engineer shall:

Clearly, concisely, and accurately describe the change(s) being made or the problem(s) to be corrected.

Unless the change to be made is simple and obvious, the description shall be written in functional terms.

For example, use "the comparison between flow and temperature requires an average temperature" instead of "average points T3838, T5673, and T999, create point T8888 to hold the average, and compare T8888 against flow point F2992. 11 Analyze the request to ensure that root causes for problems are being addressed and not simply masked.

While::-*ome activities may be made to address problems in the short term, the assigned engineer is responsible for raising concerns if users are requesting activities to overcome poor design.

A statement shall be included to either confirm that no root design problems exist, or a discussion of any related issues shall be included.

Complete Design Issues, section 2B.

Describe the basis for performing the maintenance under Maintenance Justification, section 2C.

Any documentation used as a basis for the maintenance shall be referenced.

List in Plant Procedure Effects, section 2D, any plant procedures that require revision because of the maintenance and complete Form NC.NA-AP.ZZ-0032-1, New Procedure/Revision Request, for each affected procedure and send it to the sponsor.

Provide a general list of activities that shall be performed in Major Activities, section 2E.

This list shall address such activities as any document revision or creation required (for example, identify the section within the Software Requirements Document (SRO) that will be modified), any procurement, or any test bed environments that shall be developed.

Any special efforts should be clearly defined.

Paqe 8 of 28

5.2.3 ND.DE-AP.ZZ-0054(Q)

c.

The NCG Engineer shall identify alternative approaches that have been explored in Alternative Approaches, section 2F. For minor changes, where activity is limited realistically to a single alternative (for example, changing the alarm limit from 11.GE. 11 to ".GT."), the assigned engineer may mark the Alternative Approaches section "N/A" for Not Applicable.

d.

The assigned engineer shall describe the impact of any changes to users of the system in User Impact, section 2G.

For changes that will require system downtime, the engineer shall describe implementation and contingency plans (for example, "backup system will be used for initial implementation and returned to original configuration if maintenance is found unacceptable").

e.

The V&V reviewer shall review sections 1 and 2 of Form ND.DE-AP.ZZ-0054-3, using Form ND.DE-AP.ZZ-0054-4, as appropriate.

f.

Any discrepancies shall be brought to the assigned engineer for correction or clarification.

g.

The V&V reviewer has the option to track discrepancies on Form ND.DE-AP.ZZ-0054-5.

Concurrence

a.

Once sections 1 and 2 of Form ND.DE-AP.ZZ-0054-3 have been prepared and concurred with by the V&V reviewer in section 3A, the NCG Supervisor shall review sections 1 and 2 for adequacy and to determine if any special concurrence is required in section 3B.

}!Qll The review of sections 1 and 2 shall provide a basis for concurrence that the problem has been correctly identified and that the proposed maintenance makes sense from both a rasourca and anqineerinq

• tandpoint.

b.

As a minimum, concurrence shall be obtained from the initiating department, user groups directly affected (for example, operations and emergency preparedness),

and any group responsible for maintaining configuration of any items to be changed (for example, Instrumentation and Controls (I&C) for setpoint changes) in section 3C.

Page 9 of 28 Rev. o

NOTE Bach siqnatura shall be dated.

siqnatures may be obtained DY FAX; copies of FAX sheets shall be added to the process computer packaqe.

5. 2. 4 Work Plan Rev. 1

a.

When activities are minor or are well understood, preparation of section 4 of Form ND.DE-AP.ZZ-0054-3 may proceed in parallel with v&v reviews and concurrence activities.

For activities requiring.

significant hours, or for activities for which the assigned engineer is not reasonably assured of receiving concurrence, concurrence shall be obtained prior to proceeding.

b.

The following documents shall be reviewed and modified where appropriate during the work plan stage:

system Requirements Document (SRO)

Detailed Design Document (ODD)

Acceptance Test (AT)

Requirements Traceability Matrix (RTM)

User Manuals/Procedures - Computer Group Plant or User Controlled Documents The names and locations of existing documents are listed on Form ND.DE-AP.ZZ-0054-1.

The follow~

sections apply to these documents.

System Requirements Document CSROl If an SRO exists, the assigned engineer shall review the document for any potential impact.

Changes to the SRO shall require that the SRO be revised and approved by the initiating department, user groups directly affected, and any group responsible for maintaining configuration of any items to be changed.

Changes to*system requirements shall be carefully analyzed by the assigned engineer to ensure the original intent is not invalidated.

Page 10 of 28

ND.OE-AP.ZZ-0054(Q)

If no SRO exists, as with some older systems, the assigned engineer shall develop an outline for an SRO and document the portion of the system that is being modified.

The intent is to document the SRD as maintenance is performed.

The SRO outline shall indicate "later" for those sections not being documented.

Approval for the SRO outline shall be obtained from the initiating department, user groups directly affected (for example, operations and emergency preparedness), and any group responsible for maintaining configuration of any items to be changed.

For most maintenance activities, the SRO will not require revision.

Detailed Design Document (DOD)

If a ODD exists, the assigned engineer shall review the document for any impact.

The assigned engineer shall revise or create new sections of the DDD where appropriate.

For example, database activities may not affect the DOD, but any code alteration will usually result in some change or addition.

Changes to the ODD are similar in nature to drawing changes for software.

If no ODD exists, the engineer shall develop an outline and document the portion of the DOD being_

worked.

For new DDDs, the entire ODD shall be included in the detailed design package; this may be primarily an outline.

For existing DDDs, only that portion being' *changed is required for the package; the change will be incorporated into the existing document as part of closeout.

Acceptance Test CAT)

For all major maintenance, there shall be a documented test(s).

The assigned engineer.shall analyze the need for incorporating the test(s) into an AT.

For one-of-a-kind testing that is unlikely to be repeated, revision or creation of an AT may be waived with the concurrence of the V&V reviewer.

Paqe 11 of 28 Rev. o

Rev. o For systems with existing ATs, the assigned engineer shall review the AT for applicable sections.

Where existing tests are no longer applicable, the test shall be revised or deleted.

If no AT exists and the AT has not been waived, the assigned engineer shall develop an outline and develop the applicable section of the AT.

For new ATs, the entire AT shall be included in Form ND.DE-AP.ZZ-0054-3.

For existing ATs, only that portion being changed is required; the change will be incorporated into the existing document as part of closeout.

Requirements Traceability Matrix (RTMl For maintenance which changes the system requirements, there shall be a review of the Requirements Traceability Matrix (RTM).

Maintenance may cause the addition of new requirements, the deletion of requirements, or changes to existing requirements.

For systems with existing RTMs, the assigned engineer shall review the RTM.

Where existing R'l'M entries are no longer applicable, the RTM shall be revised.

If no RTM exists, the assigned engineer shall develop an outline and develop the applicable entries for the RTM.

For new RTMs, the entire RTM shall: be included in Form ND.DE-AP.ZZ-0054-3.

For existing RTMs, only that portion being changed is required; the change will be incorporated into the existing document as part of cios~out.

User Manuals /Procedures - Computer* *Group The assigned engineer shall review-existing manuals and procedures, referred to in the.

following as "documentation."

For existing documents, the assigned engineer shall revise the documentation where applicable.

Page 12 of 28

ND.DE-AP.ZZ-OOS4(Q)

If no documentation exists, the assigned engineer shall determine if documentation is required as a part of the maintenance.

If the assigned engineer determines that documentation is required, the assigned engineer shall identify those documents in the package.

The assigned engineer shall determine whether to include the new documentation in the package or to provide the documentation during the closeout phase.

Plant or User Controlled Documents The assigned engineer shall ensure that impact to plant or user-controlled documentation is identified to the responsible party(ies).

- 5.2o5 Verification and Validation Design Review

a.

Upon completion of Form ND.DE-AP.ZZ-0054-3, the assigned engineer shall forward it to the V&V reviewer.

b.

The V&V reviewer shall review the form to ensure it includes the following:

Detailed work description Detailed testing instructions Identification of documentation changes These requirements shall be met by revision or use of existing design documents (SRO, ODD, and AT).

c.

The V&V reviewer shall review the following System Design Documents for impact:

System Requirements Document (SRO)

Detailed Design Document (ODD)

Acceptance Test (AT)

Requirements Traceability Matrix (RTM)

User Manuals/Procedures The V&V reviewer shall review the form to determine if changes to the system Design Documents have been completely and accurately defined.

d.

Any discrepancies shall be brought to the assigned engineer for correction or clarification.

While not required for maintenance modifications, the V&V reviewer has the option of tracking discrepancies on Form ND.DE-AP.ZZ-0054-5.

Page 13 of 28 Rev. o

e.

The assigned engineer shall correct or clarify any discrepancies found during the V&V design review. If agreement between the assigned engineer and V&V reviewer cannot be made, the-problem will be brought to the NCG supervisor for resolution.

f.

The V&V reviewer shall sign and date in Verification and Validation Design Review, section 5, when the design has been properly defined.

5.2.6 Implementation

a.

The assigned engineer shall present the completed package to the NCG Supervisor for approval to implement.

The NCG Supervisor shall sign and date the implementation approval line in Implementation, section 6.

b.

The assigned engineer shall schedule a time for implementing the change.

The engineer shall ensure that all potentially affected user groups are notified prior to the change.

c.

Work orders will be generated prior to actual installation work.

d.

Implementation Checklist, section GB, shall be completed by the NCG Supervisor.

e. The assigned engineer shall implement the change using written procedures where applicable.

5.2.7 Testing Rev. o

a.

The assigned engineer shall test all maintenance activities performed in this section according to the detailed test developed in the work plan.

All testing shall be witnessed by the V&V reviewer or a mutually agreed upon independent third party.

b. All test steps shall be initialed by both the assigned engineer and the test witness in Testing, section 7.

Page 14 of 28

5.2.S

~---~--~---

ND.DE-AP.ZZ-0054(Q)

c.

Any discrepancies identified. during testing shall be documented using Form ND.DE-AP.ZZ-0054-6, Software Error Notice Report, using a Discrepancy Evaluation Form (DEF) per DE-AP.ZZ-OOlS(Q), Engineering Discrepancy Control, or using a Discrepancy Report (DR) per NC.NA-AP.ZZ-0020(Q), Nonconformance Program.

Where a discrepancy involves a simple procedure problem, for example, steps reversed, the procedure may be redlined to show correction. Corrections shall be concurred and initialed by both the assigned engineer and the test witness.

d.

e.

Testing, section 7, shall be signed and dated by the assigned engineer and the V&V reviewer.

All other problems shall be corrected, documented, and retested.

Requirements for any retesting shall be concurred with by the V&V reviewer.

All retesting shall be witnessed, initialed, and incorporated into the final test documentation.

All signed test documents, discrepancy reports, and retest results shall be attached to Form ND.DE-AP.ZZ-0054-3.

NOTE Software/database changes shall not be used for on-line systems until testing is satisfactorily complete.

An exception can be made if users are specifically informed of any ramifications of using the modified system; this shall be avoided wherever possi))le.

Closeout

a.

The assigned engineer shall notify all affected groups when testing and installation are field complete.

User Notification, section SA, shall be completed by specifying individuals in the affected groups which have been notified of field test completion and installation.

b.

The assigned engineer shall ensure that backup tapes and disks are created.

system Backup, section SB, shall be completed.

This requirement may be waived for minor changes if there are fewer than three minor changes outstanding since the last backup.

c.

The appropriate work order(s) shall be completed and the Senior Nuclear Shift Supervisor/Nuclear Shift Supervisor (SNSS/NSS) signature, if applicable, shall be obtained.

The work order(s) shall be returned to station planning.

Page 15 of 28 Rev. o

d.

The V&V reviewer shall complete the V&V Closeout Concurrence, section BC.

Any discrepancies shall be brought to the assigned engineer for correction or clarification.

While not required for maintenance activities, the V&V reviewer has the option of tracking discrepancies on Form ND.DE-AP.ZZ-0054-5.

e.

The assigned engineer, after V&V signoff, shall sign and date V&V Closeout Concurrence, section BC.

f.

The assigned engineer shall update the process computer package by adding Form ND.DE-AP.ZZ-0054-3 and any applicable V&V comment forms.

These forms and any other NCG control documentation affected by the maintenance shall be updated via NC.DE-WB.ZZ-0004(Q), Engineering Workbook for Document Only Change.

The assigned engineer shall sign and date Documentation Update, section BO, and file Form ND.DE-AP.ZZ-0054-3 in the NCG files.

5.3 Hardware Maintenance Change Criteria Rev. o This section applies to hardware maintenance where existing equipment or components are being removed and replaced.

The purpose of this section is to provide requirements and criteria to distinguish normal maintenance activity from hardware maintenance change activity where equipment is not replaced using identical replacement parts.

For the former, a work order is sufficient to perform the work activity; in the latter case, a design or configuration change is being made and will require development of a workbook per NC.NA-AP.ZZ-OOOS(Q).

The following sections define the criteria for each approach.

Page 16 of 28

ND.DE-AP.ZZ-0054(Q) 5.3.l Normal Maintenance Activity

a. Criteria Standard computer equipment maintenance supplied by the manufacturer typically includes revisions to various boards as potential problems are found and corrected.

This type of maintenance activity shall not be considered a design change under the following conditions:

The part number of the board remains the same Revision has been published by the manufacturer No changes are required for operating systems, application codes, or interfacing equipment (other than dip switch settings or addressing setups)

b. Configuration Requirements The assigned engineer shall ensure a parts list is maintained to reflect the current configuration of boards, including board revision level where applicable.

5.3.2 Hardware Change Maintenance Criteria Replacement of computer equipment with alternate equipment not covered under section 5.3.1 above shall be performed under the processes of NC.NA-AP.ZZ-OOOS(Q).

Under NC.NA-AP.ZZ-OOOS(Q), the replacement of most components within the computer system proper (for example, disk drives, printers, tape driv~s, and controllers) will fit the established criteria for "Equivalent Replacement", as defined in NC.DE-WB.ZZ-OOOJ(Q), Engineering Workbook for Specific Equivalent Replacement.

Replacement of actual computers may also be permissible.

under the "Equivalent Replacement" criteria.

For the purposes of computer replacement, the following criteria shall be met in addition to the criteria found* in NC.NA-AP. ZZ-0008 (Q):

The new computer is manufactured by the same company as the original company, or by a company making compatible systems.

For example, a MicroVax II could be replaced with a Vax 4000, or an IBM PC using a 386SX processor could be replaced with a computer manufactured by DELL using a 486DX processor.

Paqe 17 of 28 Rev. o

ND.DE-AP.ZZ-0054(Q)

Existing software code shall be compatible with the new computer.

Recompilation, new system generation files, and reassignment of devices (such as disk drives} within the existing code is permissible.

The new computer shall use the same or l.ess power than the system being replaced.

The new system shall create the same or less heat load than the system being replaced.

Any computer replacement requires a test of the software residing on the system to ensure all functions are operating accurately.

5.4 FUnctional Design Chan~~s 5.4.1 Functional Design Change criteria

a.

Upon determining that the task meets the criteria of a functional design change, the assigned engineer shall proceed to Work Definition in section 5.4.2.

b. If the task does not clearly meet the criteria for a Software/Database Maintenance Criteria (5.2.1), a Normal Maintenance Activity (5;3.1), or Functional Design Change Criteria (5.4.1), the NCG Supervisor shall determine the process to follow.

5.4.2 Work Definition

a.

Once the determination has been made that a specific request fits the definition of a Functional Design Change criteria, the assigned engineer shall prepare Form NC.NA-AP.ZZ-0008-1, Nuclear Department Change Request (CR).

b.

The process described in ND.OA-PJ.ZZ-0016(Z), E&PB Integrated Project Management Process, shall be followed for Capital or Operation and Maintenance (O&M) projects requiring more than $50,000 or 1000 man-hours to complete.

5. 4. 3 Design

a. If a PSP has been written per OA-PJ.ZZ-OOOJ(Q),

Project Scope Proposals, the assigned V&V reviewer shall review the PSP.

This review will provide a basis for concurrence that the problem has been correctly identified and that the modification makes sense from both a cost and an engineering standpoint.

Rav. o Paga 18 of 28

ND.DE-AP.ZZ-0054(Q)

Rev. 1

a. If using Workbook 1, the assigned engineer shall document the modification and testing instructions necessary for implementation and testing of the design in Workbook 1.

a. This may be as simple as directing the implementer to perform the AT.

b.. Changes should not be used for on-line systems until testing is satisfactorily completed.

Testing may be performed on on-line systems if users are specifically informed of any ramifications of using the modified system.

9.

For Workbook 1, the assigned engineer shall document changes to affected documents on Modification Documents (MDs) or Change Documents (CDs), as applicable.

See NC.NA-AP.ZZ-OOOS(Q) for definitions of MD and CD.

For Workbook 5, documents changed shall be summarized on the Workbook 5 cover sheet.

Applicable documents include:

SRO If an SRO exists, the assigned engineer shal~

review the document for any potential impact.

Changes to the SRO shall require that -the SRO be revised and approved by the initiating department, user groups directly afjected, and any group responsible for maintaining configuration of any items to be changed.

If no SRO exists, the assigned*engineer shall develop an outline for an SRO and document the portion of the system that is being modified.

Approval for the SRO outline follows the same routing as the preliminary documentation.

ODD The assigned engineer shall update the DOD as part of the design analyses.

Changes to the DOD are similar in nature to drawing ch~nges.

Changes to the ODD shall be clearly defined or marked clearly in the altered text or diagrams. Changes to the ODD are approved in the Change Package (CP) approval process.

If no ODD exists, the engineer shall develop an outline and document the portion of the ODD being worked.

Page 20 of 28

ND.DE-AP.ZZ-OOS4(Q)

b.

The assigned engineer shall document, obtain approval for, and implement the design of system modifications with NC.NA-AP-ZZ-0008(Q) using NC.DE-WB.ZZ-OOOl(Q),

Engineering Workbook for Standard Change Package (Workbook 1), or NC.DE-WB.ZZ-0005(Q), Engineering Workbook for As-Built Document (Workbook 5), as determined by NC.NA-AP.ZZ-0008{Q), as follows:

1.

The Interface Record, Form NC.DE-WB.zz-0001-2 from Workbook 1 or Form NC.DE-WB.ZZ-0005-2 from Workbook 5, shall document, as a minimum, concurrence from the initiating department, user groups directly affected, the assigned V&V reviewer, and any group responsible for maintaining configuration of any items to be changed.

2. If using Workbook 1, the Change Package Executive summary shall be completed witq information agreed upon in the.PSP or other preliminary documentation.

3.

The associated SRO and DOD should be listed in the Design Input Record section of the applicable workbook as references for establishing the design criteria and inputs.

4.

The specialty reviews section of the applicable workbook shall be completed by the necessary disciplines when affected by the mod if icat.ion.

5.

The Design Analyses section of the applicable workbook shall be completed to summarize any methodologies used in the design.

a.

The ODD shall be cited if all or part of the design analyses information is contain'ed in the ODD.

b. If the SRO has to be modified due* to design evolution or circumstances, the.assigned engineer shall obtain concurrence for the revised SRO from the groups initially approving this document.

6.

The 10CFRS0.59 Review and Safety Evaluation*

section shall be completed to document the safety implications of the change.

7. If using Workbook 1, the assigned engineer shall complete the Modification Summary.

This information should supplement information on the executive summary.

Page 19 of 28 Rev. o

ND.DE-AP.ZZ-0054(Q)

AT RTM User Manuals NCG / Station Procedures system Drawings Other System Affected Drawings/Manuals/Programs Vendor Manuals/Drawings 5.4.4 Verification and Validation Design Reviews

a.

The assigned V&V reviewer shall review the CP against the following system design documents to ensure that changes to design documents have been accurately defined and that the CP correctly reflects the design documents:

System Requirement Document (SRD)

Detailed Design Document (DOD)

Acceptance Test (AT)

Requirements Traceability Matrix (RTM)

User Manuals/Procedures

b.

The V&V reviewer should use Form ND.DE-AP.ZZ-0054-4 as a guideline to review the design.

c.

The assigned engineer shall resolve discrepancies identified by the V&V reviewer.

Form ND.DE-AP.ZZ-0054-5 shall be used to document the V&V reviewer's comments and the assigned engineer's resolutions.

d.

The NCG Supervisor shall resolve discrepancies that cannot be resolved between the assigned engineer and the V&V reviewer.

e. The V&V reviewer shall complete the Design Verification section of the applicable workbook to document approval of the design, testing instructions, and update documentation changes.

Page 21 of 28 Rev. o

ND.DE-AP.ZZ-0054(Q) 5.4.5 Implementation After the CP has been approved by the NCG Supervisor and the Station Operation Review Committee (SORC), as applicable, the assigned engineer shall:

Coordinate a time for implementation of Workbook 1 CPs with the affected station Planning Department

• Ensure that all necessary work activities have been generated for implementation Prior to implementation, ensure that all potentially affected groups are notified of the implementation schedule Implement the change using approved procedures, as applicable 5. 4. 6 Testing

a.

The assigned engineer shall test all modifications according to the detailed test developed in the design stage and documented in the CP.

All testing shall be witnessed by the V&V reviewer or a third party assigned by the NCG Supervisor.

b. All test steps shall be initialed by both the assigned engineer and the test witness on the CP.

c.

Any discrepancies during t9sting shall be documented.

Discrepancies shall be doc~mented with a Modification Concerns and Resolutions** (MCR) form in accordance with**DE-AP. ZZ-0017 (Q), Modification Concerns and Resolutions;.

d.

MCRs correcting discrepancies shall be reviewed and approved by the V&V reviewer.

e.

Problems shall be corrected and retested, as applicable to the MCR.

All retesting shall be witnessed, initialed, and incorporated into the final test document and CP.

5. 4. 7 Closeout Rev. o

a.

The assigned engineer shall:

Notify all affected groups when testing and installation are field complete and shall close any associated work activities.

Page 22 of 28

ND.DE-AP.ZZ-0054(Q)

Ensure that necessary backup tapes and disks are created.

(These activities may be a part of the CP modification instructipns.)

Update the applicable process computer package by adding the Executive summary (for Workbook 1) or a written description of the change, the reason for the change, and a list of documents affected (for Workbook 5).

Close the CP in accordance with NC.NA-AP.ZZ-0008 (Q).

b.

The V&V reviewer shall initial and date the "System Engineer or Project Manager" line on the Closeout Checklist (part B for Workbook 1) along with the system engineer's or project manager's signature.

NOTE The v'v reviewer's initials document that all discrepancies resultinq from this modification have been dispositioned and that the implementation, testinq, turnover of chanqes, and document update performed for this activity have been completed.

s.s system Troubleshooting and Emergency Maintenance Instructions The following administrative instructions shall be used when troubleshooting system problems.

If practical, troubleshooting should be performed on off-line systems, so that plant monitoring is not affected.

Troubleshooting shall be considered to be off-line only when it is performed under conditions where the equipment is isolated to the point where its active functions are inhibited from affecting plant equipment, operations, or monitoring.

5.5.1 A work order for the troubleshooting work shall be initiated and obtained from the station Planning Department in accordance with NC.NA-AP.ZZ-0009(Q) when troubleshooting using an on-line system.

A work order for an off-line system is optional.

Page 23 of 28 Rev. o

5.5.2 If an on-line system is to be affected, ensure that an acceptable time and date are coordinated with the SNSS/NSS and the Planning/Scheduling Department.

All user groups shall be contacted to ensure there are no activities planned for which the computer was to be used (for example, flux mapping requires the P250; operations may not be cognizant of flux mapping schedule).

5.5.3 If the backup system is to be used for troubleshooting, ensure that the SNSS/NSS has granted permission before securing the backup.

5.5.4 If the applicable system can be taken off-line for troubleshooting, ensure that the SNSS/NSS has granted permission before disabling the system.

5.5.5 Notify the Nuclear Control Operator (NCO) that the troubleshooting activity is starting and inform the NCO as to which specific alarms and indications will be affected.

5.5.6 Troubleshoot under the following precepts to identify the cause of the problem or malfunction.

a.

Employ sound, logical troubleshooting techniques, using approved procedures and methods as applicable..

b. Notify the NCO of any changing conditions or indications which may affect the NCO.

c.

Independent verification shall be required for each lifted lead or jumper disconnected while troubleshooting.

The verification shall be documented on an Independent Verification Record, Maintenance Troubleshooting, in accordance with HC.IC-GP.ZZ-OOOS(Q) for Hope Creek or SC.IC-GP.ZZ-0006(Q) for Salem.

d. Lifted leads, repositioned jumpers, or other alterations to designed equipment remaining after troubleshooting {or after more than two shifts of no work) shall be controlled in accordance with NC.NA-AP. ZZ-0013 (Q), Control of Temporary Modifications.

5.5.7 At the completion of troubleshooting, perform any necessary retest activities to verify proper system operation.

5.5.8 Make system software backups to maintain configuration control, as applicable.

Rev. o Page 24 of 28

ND.DE-AP.ZZ-0054(Q) 5.5.9 Restore the affected systems to.normal (for example, bringing up backups).

5.5.10 Notify the NCO that troubleshooting is completed and inform the NCO as to the system's status (that is, operable or inoperable).

5.5.11 Document discrepancies on Form ND.DE-AP.ZZ-0054-6 with a DEF in accordance with DE-AP.ZZ-OOlS(Q), Eng.irieering Discrepancy Control, or with a DR in accordance with NC.NA-AP.ZZ-0020(Q), as appropriate.

5.5.12 Complete the appropriate work order(s) and* obtain the SNSS/NSS signature, if applicable.

Return the work order(s) to station planning.

5.5.13 Where modifications are made for emergency situations, the NCG Supervisor shall be informed within three working days.

The engineer performing the change shall leave a clear indication upon the system console of any work that may affect system operation.

The modification shall be reviewed on the next normal work day, and plans for removal or incorporation into the system through normal procedures will be planned.

5.6 commercial Software When commercial software is obtained, the vendor-supplied documentation may be evaluated and used in place of an SRD, ODD, and RTM.

5.7 Error Reporting 5.7.1 All ident~fied computer software errors shall be reviewed by the responsible engineer.

5.7.2 Form ND.DE-AP.ZZ-0054-6 shall be completed by the sponsor.

The software error notice number is the software ID number plus a unique consecutive identifier tracked by the sponsor.

5.7.3 The errors shall be evaluated for substantial safety hazard in* accordance with 10CFR21.

5.7.4 For errors affecting user operation, Form ND.DE-AP.ZZ-0054-6 shall be distributed to all affected parties by the sponsor.

5.7.5 If a design deficiency is discovered, the Discrepancy Evaluation Form (DEF) per DE.AP.ZZ-OOlS(Q) shall be completed and a copy attached to Form ND.DE-AP.ZZ-0054-6.

Paqe 25 of 28 Rev. o

HD.DE-AP.ZZ-0054(Q) 5.8 critical Software Electronic Media Backup 5.8.1 Electronic media backups shall be created and maintained by the sponsor for each Process computer system.

The backup shall be created or updated under the following conditions:

• Three minor modifications or one major modification has been made since the last system bac~up~

One year has elapsed since the last backup.

A system backup does not currently exist.

More frequent backups may be performed if considered necessary by the sponsor.

5.8.2 The sponsor shall create two copies of software and database files, a master system backup and a duplicate.

The master shall be stored in the Engineering Document Control Center (EDCC) per ND.DE-TS.ZZ-5437 (Q)

• Electronic media that are stored in the EDCC shall be accessed by only authorized personnel, as specified on the Authorized Users list provided with the backup.

The Authorized Users list is originally produced by the sponsor.

This list may be modified at the time of a backup update.

The duplicate shall be stored in a location separated from the EDCC.

This location shall provide access control, easy retrieval, and protection from damage and erasure of programs and data.

The electronic media should be maintained under the conditions recommended by the media manufacturers.

s.'

sottware~:*aecurity* -

• 5.9.1 Sponsors of critical software shall ensure that passwords are changed with the following frequency:

Rev. 1 Computer systems limited to protected-area access require password changes for all users every six months.

Computer systems with modem access require one of the following:

Captive accounts - every six months Non-captive accounts - every two months Paqe 25A of 28

5.9.2 5.9.3 ND.DE-AP.zz-oos4(Q)

Passwords shall be de-activated within ten working days for those individuals who terminate their employment or whose assignments no longer require computer access.

Levels of control shall be established by the sponsor to limit access to critical software and database files.

Typical levels of control include Read, Write, and Delete permissions.

(Go to Page 26)

Paga 25B of 28 Rev. 1

ND.DE-AP.ZZ-OOS4(Q) s.10 Records Records associated with the Process Computer Maintenance and Modification Control Program shall be retained in accordance with NC.NA-AP.ZZ-OOll(Q), Records Management Program.

6.0 DEFINITIONS 6.1 Authorized Users List - A list of personnel who are allowed access to electronic media.

This list is created by the sponsor and resides in the EDCC.

6.2 Backup - As defined in ND.DE-AP.ZZ-0052(Q).

6.3 Punctional Design - A functional design describes the basic elements of a system required to meet functional requirements.

The functional design should focus on necessary generic components independent of specific vendor hardware (for example, "display terminal" as opposed to "25 inch IDT model 3500," or "data transfer capability" as opposed to "ethernet link").

6.4 Functional Design Change - Any change which adds, deletes, or alters basic functional requirements or any software and database activity(ies) not covered under.

6.5 Punctional Requirement - A functional requirement describes a need or a problem to be solved. Requirements shall be stated in simple, unambiguous language.

Requirements should be observable or testable. A functional requirement does not describe the solution (for example, "met data is required every.JO s~conds" not "Safety Parameter Display System (SPDS) shall transmit met data over an ethernet cable to the VAX cQmputer").

6.6 Oriqipator - Person or process (for example,. NDRAP) that initiates a request for change or maintenance.

6. 7 Prot1ct14 AZ'** - The area physically located within the security boundaries of the plant site.

6.8 Sponsor - An individual within the group who contr~ls and monitors information for a Process Computer system.

6.9 Rev. 1 system - A self-contained set of computer hardware, software, and.documentation.

Single computer complexes may contain multiple "software" systems that utilize common sets of hardware and operating systems but function independently of other software modules.

Page 26 of 28

6.10 6.11 6.12 ND.DE-AP.ZZ-OOS4(Q)

Validation - As defined in NC.NA-AP.ZZ-0064(Q), Software Quality Assurance.

verification - As defined in NC.NA-AP.ZZ-0064(Q),

Software Quality Assurance.

verification and Validation (V&V> Reviewer -

An individual meeting the criteria for Peer Reviewer, who should also remain independent of the design process.

(Go to Page 27)

Page 26A of 28 Rev. 1

HD.DE-AP.ZZ-0054(Q)

7.0 REFERENCES

7.1 VPN-MSP-10, Process Computer systems 7.2 NC.NA-AP.ZZ-0064(Q), Software Quality Assurance 7.3 ND.DE-AP.ZZ-0052(Q), Software Control 7.4 NC.DE-AP.ZZ-0032(Q), Document Identification 7.5 NC.DE-AP.ZZ-0033(Q), Configuration Control - Engineering Document Control Procedure 7.6 Cross-References 7.6.1 Salem Generating Station Updated Final Safety Analysis Report 7.6.2 Hope Creek Generating Station Updated Final Safety Analysis Report 7.6.3 NC.NA-AP.ZZ-OOOS(Q), Control of Design and Configuration Change, Tests and Experiments 7.6.4 NC.NA-AP.ZZ-0009(Q), Work Control Process 7.6.5 NC.NA-AP.ZZ-OOll(Q), Records Management Program 7.6.6 NC.NA-AP.ZZ-0013(Q), Control of Temporary Modifications 7.6.7 NC.NA-AP.ZZ-0020(Q), Nonconformance Program 7.6.8 NC.NA-AP.ZZ-0032(Q), Preparation, Review, and Approval of Procedures 7.6.9 NC.NA-AP.ZZ-0065(Z), Nuclear Department Resource Allocation Program 7.6.10 NC.DE-WB.ZZ-OOOl(Q), Engineering Workbook for Standard Chanqe Package 7.6.11 NC.DE-WB.ZZ-OOOJ(Q), Engineering Workbook for Specific Equivalent Replacement 7.6.12 NC.DE-WB.ZZ-0004(Q), Engineering Workbook for Document Only Change 7.6.13 NC.DE-WB.ZZ-0005(Q), Engineering Workbook for As-Built Document 7.6.14 DE-AP.ZZ-0017(Q), Modification Concerns and Resolutions Rev. o Page 27 of 28

ND.DE-AP.ZZ-0054(Q) 7.6.15 DE-AP.ZZ-0018(Q), Engineering Discrepancy Control 7.6.16 DE-TS.ZZ-5408(Q), MMIS Input Documents 7.6.17 OA-PJ.ZZ-0003(Q), Project Scope Proposals 7.6.18 ND.OA-PJ.ZZ-0016(Z), E&PB Integrated Project Management Process 7.6.19 ND.DE-TS.ZZ-5437(Q), Storage and Retrieval of Electronic Media 7.6.20 HC.IC-GP.ZZ-OOOS(Q), Maintenance Troubleshooting 7.6.21 SC.IC-GP.ZZ-0006(Q), Maintenance Troubleshooting 7.7 commitment Reference 7.7.1 CR-92-002 (NQA AR M29-91-090-6M, Task 1)

Page 28 of 28 Rev. o

THIS PAGE IS INTENTIONALLY LEFT BLANK.

ND.DE-AP.ZZ-OOS4(Q)

ATTACHMENT 1 GENERIC 10CFRS0.59 REVIEW AND SAFETY EVALUATION 5~:..:;:~ '

~ ~:~cN :~ 5A.C..::.~ L ' 2 5A:..:::X 2 SA:..:::..'1 J : :AS 7".:~SI~E)

!-!Cr't :~!K

-!C?:: C~!X.\\NC SAU.'i c:MMON I

I -

P1mL%C *1.wncs 1uc::uc.um cu.a ocxnsr wc::.D&C~

1cc::n.so.s1 unn UD urnT Jr'ft1..ana*

ccva~

?aq*

Na.

I ~ 3 -..,

~ev.

Na.

O 0 0

0 11'4-"~;,.

~IA~/~

c;...- 'tr-11/lf Oriqinal /.

,,,...,. v,.,,/.. /"f 0

tsa\\18

'~"'

Pear M~.

1saac laYiw Rav. Rwiaian Pnparar/ Raviev Approval/

• Suaary Dau

/OU.a Ol&ta Ktlr* 110.

Pac;e. ot.L J1C *.a-a..2s-0011cQ1

.... 0 A~taabaea* 2 1'/lf Sta~.'\\.an Q.K./

Da~a

,... 1 ot 1 I

I I

Paqe l of 4 Rev. o

\\

I

ATTACHMENT 1 GENERIC 10CFRS0.59 REVIEW AND SAFETY EVALUATION r.o. so. ~--~-;~~------------~

?.!!. so.

Jt*D*COM*fSc*~Bc~

4om!q.s1 gnu yp *um m.i.tm:xc1

~.J

~r;;

;M -

ascri=* the Prcpcsad racility/Prccadura c~anqa Qr ?as~ Qr txpari

an~ (use ccn~inua~icn snaac it

~equirad) (It ie invclvas & cnanqa to tna Fir* Prc~*c:~icn

?roqram er Radicac~iv* ~&*~* Traa~an~ syscama, ensure ~~a~

sec~icns l.2 Qr l.J Qt Exnillie l, a* applicable, are

~eVlaWad]:

Sea continuation sheet.

2.0 tocra=o.!9 s::y::pr - ocas lOCnt!O.st apply to th* proposal?

a.

l:I.

co~* th* proposal cnanqa th* tacility ** daacri~ed 1n Cha SAR?

x

'i!:S _

NO Cc** th* prcpoaal chanqa pracaclursa aa daacribad in Cha SAJl 1 YES --

NO X

c.

cc.. th* propoaal involve a t.. c or experimanc noc daac:r~ecl in the SAJl?

YES NO X:

Cisc:uaa tile tta*u tor th* de~ciona &&Ml identity th* p~t SU **=iona tAat van nvi.,. co uJce th* cletaniaacian* (ua* c:ancimlaciaa 8bHU if nquincl).

S** c:ancinuatian anaat.

It ALL annen in S*c:ticn 2.0 x., *m*, 10CJ'llla.s1 clou NOT apply, ancl c:caplation of.Sc ::.!aa J of t!lia form 1*

NOT r~

(S*=io:t 4 ancl 5 :..-..... ~ **ill b* ~l.*CM).

• a.... *a.ell*Olll(QJ Pac;a l af L Rav. 2_

~. "

>.ttaaneas z tqe !

o~ 1 I

• 1 I

I I

I I

Page 2 of 4 Rev. o

• ND.DE-AP.ZZ-0054(Q)

ATTACHMENT 1 GENERIC 10CFRS0.59 REVIEW AND SAFETY EVALUATION

!.~. SO. ----N**-'~~~~--~~-

RE!". so.

A*O*CC1~ -='5.~*~sc; l 0 cn30. 5' unn I.ID ~

ft"ll.aTIO*

C:~I*'a,"hT;gH SJITTl'

~.J iar~ous plant ~rocess co:putar (as a*tined in 'IPN-~SP lO, "Plant ?rocass c:~putars*) soft~are and/or data :ust

=* ~=ditiad or raplacad du* to-obsQlaacanca, unreliability, upgrades, ar plant ccmpcnant replacem*nt.

This is a qenaric evaluation af th*** chanq** ~bare t.~*

design requira~ents of ~~* :Cldi!iad, upgraded, or replaced SQft~are are ~Qt changed.

The format Qr coding

~ay change, ho~ever.

~acn unique use Qf the l0Cnt~O.S9 evaluation requires cc:pletian of an equivalent replacement evaluat~cn ta dater.!lin* wnath*~ th* nav so!t~are or data ~**ts or exceed* th* d**ic;n requirements Qf th* original design spacitications.

2. 0 (a)

Th* plant process computer d**i;n intent is not chanqad with th* tquivalant Raplacaman~ proc****

Th* tunctional d*s~iption at the SAA ia not changed.

This chanqe dae* not altar th* d**iqn,

!unction, or ~ethod of partorwin9 th* tunction at a struc~ur*, system, or calll'Onent aa da*cribed in th*

SAlt.

Plant proc*** =01111Nt*r sottvara or d&~ i*

upqradad such that it 11189ta or axcaecla tll* oriqinal specification* Qr sy*taa d**i;n raq\\liraaanta.

Th*

proc*** parameters that ara controllacl or monitored by th* sottvara ar* net cnanqed trca t.h* da*i;n requiramant*.

A* a nnlt, there ia no cnanq* to tl1* tacil.ity a* d*s=i.a 1n th* su.

(b)

Ce)

Thar* 1* no chanq* to th* procedUr** ** cl**crUed in the SAR, since th* cnanqe doea not alter procaclural *t*P*.. daac:ribecl in ~* SAA. er chanq*

a~iviti** er conuol* over fun=iou, plant conti;uration, tasJc*, raviava, teata, or **faty*

rav~w ***tinq* that are duc:r~ecl 1n the SAA.

ft* ~dinq of ta* 119~ soiware -or daU cloea not conat1tute a tHt or *Xlteria*nt not cleacrUad*

in tile SAil, since th* new aottvare or data i*

• ~ad to m**t or excaacl th* tunctional.

r9C1'1uuent* ot th* Qdqin&l *oftvare or data.

Kcpa eraelc and Salem UFSAR sactionm 7.S, 1.1, and 1.1.

ware ravievad t~ ~ak* ~iis detarllin&tion.

Paq* _i_ of.::L Rev. _a_

I I

SC.lEIL-~.IS*OlllCQJ

..... 0 uuatmeac a

• acr* 1 ot 7.

1 Paga 3 of 4 Rev. o

ND.DE-AP.ZZ-OOS4(Q)

ATTACHMENT 1 GENERIC 10CFRS0.59 REVIEW AND SAFETY EVALUATION I.C. NO.

~--~~-/~4:.-..----------

REl". NO.

A C:?"". :se*-;)8e~.

iocn!o.u yyxn MP SAZJTT mIArto* (c;ccxag1p>

~. J

~~!

ot sr~c

;:coI::tt ~tYISIOH ;t;;B-~I~hT!ON -Co**

.~e ;;:iro;icsal lnvolv* a Tec:Mica.1. Spaci!icael.cn cnanqe?

5.0

'iE:S _

NO

!danei!y tn* par:inene Tectinical Speci!ication sections tnae **r* reviawed to =*k* th* daearmination:

Becausa th* upqradad softvar* or data ia raquirad to maat or excaad th* oriqinal so!tvara or data functional spaci!ications, no Tacnnica.1. Spac:itication Raviaion would be requir*d du* to th* cnanqinq of tha *oftvara or da~.

~g:1s:~1*g1 YU KO Cea* 10CJ'U0.5t apply? (Seccion 2) 0

~

ts a t1SQ involvacl? (Section l) 0 CJ (Check 11/A 1.C lOCl'R!0.59 dou nae apply).

Ia a Tealmic:al Specification c;il*'.

dlaD98 ~?

(Section 4) tt a OIQ 1a involved and/or a Tac:bnic:al Speai.Cic:ation chanq* 1a ntl'lirad, ectai.n ***1*~* fraa Lic:anaint for additional prcc***int.

t.CJl Mwlbar:..... __.11/.,..d.*----------------

K/A

~

~-.**of 1.

Paqe 4 of 4 Rev. o

FORK ND.DE-AP.ZZ-0054-1 Process computer Packaqa cover Sheet Software ID Number:

System Name:

Sponsor Group:

Completed documents for this package:

Document Name:

Rev. or Date Sponsor Date V&V Reviewer Date Supervisor Date Page 1 of 1 Rev. o

THIS PAGE IS INTENTIONALLY LEFT BLANK.

NC.NA-AP.ZZ-0064(Q)

Revision o PUBLIC SERVICE ELECTRIC AND GAS COMPANY NUCLEAR ADMINISTRATIVE PROCEDURES TITLE: SOFTWARE QUALITY ASSURANCE SPONSOR:

QUALITY ASSURANCE PROGRAMS & AUDITS SPONSOR:

• I°"'..,.,..

--8r;~f~

Date APPROVE:

General APPROVE:

./General Manager - Salem Operations REVISION

SUMMARY

1.

Issued for Implementation.

This procedure becomes effective November 1, 1991.90-291.JF

~ ---~

(

9ao4210005 9 03500AB~;2

~DR ADOCK PDR

NC.NA-AP.ZZ-0064(Q)

Revision o PUBLIC SERVICE ELECTRIC AND GAS COMPANY NUCLEAR ADMINISTRATIVE PROCEDURES TITLE: SOFTWARE QUALITY ASSURANCE TABLE OF CONTENTS SECTION SUBJECT 1.0 PURPOSE...........*..........**.*..*........... 1 2

• 0 SCOPE * **..*............*.*..*.***..**.**.*.*.** 1 3. 0 RES PONS I BI LI TIES.............*.....*........... 1 4. 0 BACKGROUND * *...*.**.......**.*...*..*.***.*.... 2 5. 0 PROCEDURE. *.*..*....***.*..*******.***.*.*.**** 2 5.1 Computer Software Development........... 2 5.2 Verification and Validation..*.*.**..*.. 3

5. 3 System Testing.*.*....*.*....*.****..*** 3

5. 4 Error Reporting *.*...**..**.....**.*.*.. 5 5.5 System Turnover *.*..**...*..*.......*... 5

5. 6 Access Control ****..****...**.****..**** 6 5.7 Computer Software Control ********.***.** 6 5.8 5.9 5.10 5.11 Computer Software Procurement ********.** ?

10CFR 50.59 Applicability Review *....*.* 9 Pre-existing Computer Software.*****.**.* 9 Records *...........*.....*.............. 9

6. 0 DEFINITIONS................................... 10 7. 0 REFERENCES. *****..*******.**********..*.....** 12

NC.NA-AP.ZZ-0064(Q)

Revision o PUBLIC SERVICE ELECTRIC AND GAS COMPANY NUCLEAR ADMINISTRATIVE PROCEDURES TITLE: SOFTWARE QUALITY ASSURANCE 1.0 PURPOSE The purpose of this document is to establish responsibilities and programmatic requirements associated with the design, development, procurement, configuration control, use, validation and verification of computer software.

2.0 SCOPE This procedure applies to critical software used for important to safety design, design analysis, process control and data base management.

3.0 RESPONSIBILITIES 3.1 General Manager - OA/NSR shall be responsible for periodically auditing implementation of the Nuclear Department Software Quality Assurance Program, and providing necessary support in the areas of software procurement and software QA program modifications.

3.2 Department ManagerCsl whose organization develops or has previously developed, procures, or maintains computer software within the scope of this procedure shall:

3.2.1 Identify computer software that is within the scope of this procedure and is used in their department.

3.2.2 Approve the use of computer software and related.

documentation which have been developed within their department.

3.2.3 Ensure that sufficient design and approval interface controls exist during development or maintenance of computer software.

Where computer software is utilized by multiple groups, singular ownership shall be established.

3.2.4 Ensure that procedures to develop, control, revise, and approve, as appropriate, all required computer software and associated documentation are developed, approved and issued.

Page 1 of 13

NC.NA-AP.ZZ-0064(Q)

Revision o PUBLIC SERVICE ELECTRIC AND GAS COMPANY NUCLEAR ADMINISTRATIVE PROCEDURES TITLE: SOFTWARE QUALITY ASSURANCE 3.2.5 Ensure the security, integrity and maintenance of developed computer software.

3.2.6 Maintain the departmental Computer Software Index, which identifies software utilized within that specific department level.

This index should be included in a department level controlled procedure.

4.0 BACKGROUND

Computer software has become an increasingly important part of the design and operation of systems that perform complex and critical functions within the Nuclear power industry.

Computer software is also relied upon to provide essential information which may be utilized during a decision making process involving the safety of station personnel and the general public.

In recognizing the importance of computer software within the Nuclear Department, it has been determined that a consistent, formalized approach associated with the design, development, procurement and utilization of critical software will be adopted and implemented in accordance with requirements identified in this procedure.

5.0 PROCEDURE This section specifies requirements to be implemented during the development, testing and procurement of critical software.

5.1 Computer Software Development The following activities shall be completed during the development of critical software:

5.1.1 A Software Requirements Specification (SRS) *or equivalent shall be prepared.

The SRS shall define the functional requirements for the proposed system..

5.1.2 The SRS shall be reviewed by all affected organizations, comments resolved, and approval documented on the SRS cover page.

5.1.3 A software design description or equivalent shall be prepared describing the major components of the software design and how the requirements of the SRS will be implemented.

Page 2 of 13

NC.NA-AP.ZZ-0064(Q)

Revision o PUBLIC SERVICE ELECTRIC AND GAS COMPANY NUCLEAR ADMINISTRATIVE PROCEDURES TITLE: SOFTWARE QUALITY ASSURANCE 5.1.4 Preliminary design reviews and critical design reviews shall be performed as determined necessary.

5.1.5 Programmer/user manuals shall be developed as applicable.

These manual(s) shall be written and approved in accordance with the developing departments implementing procedures and NC.NA-AP.ZZ-0032(Q); and shall be controlled in accordance with NC.NA-AP.ZZ-0003(Q).

5.1.6 All source code, command files, compilers, etc., required to build the system shall be documented, and controlled.

5.2 Verification and Validation CV&V) 5.2.1 The specified computer software requirements shall be reviewed and approved prior to performing software V&V.

This review shall include a determination of testability of software requirements identified in the SRS.

5.2.2 V&V shall ensure that all computer software requirements have been satisfied.

Where computer software is developed in discrete phases, verification shall be performed between each phase to assure that requirements are correctly translated, in accordance with a procedure or plan.

5. 2. 3 Independent V&V should be accomplished by an indiv.idual or individuals other than those who developed the comput_er software.

5.2.4 The V&V plan or procedure shall describe the methods of test performance, how errors will be documented *and corrected, and the degree of subsequent testing. '

5.3 System Testing Upon completion of development, testing shall be perf~rmed to validate the resulting integrated system.

5.3.1 Testing shall be performed in accordance with a documented and approved test procedure or plan which may be part of the verification and validation plan or procedure.

Page 3 of 13

NC.NA-AP.ZZ-0064(Q)

Revision o PUBLIC SERVICE ELECTRIC AND GAS COMPANY NUCLEAR ADMINISTRATIVE PROCEDURES TITLE: SOFTWARE QUALITY ASSURANCE 5.3.2 The test procedure or plan shall be prepared and approved in accordance with NC.NA-AP.ZZ-0032(Q) and shall 'include the following as applicable:

o A description of the purpose and scope of each level of testing to be conducted, o

Verification that the computer software, operating system and hardware as a whole are working correctly, o

Identification and description of the pre-and post-

_ test documentation to be generated for testing, including test specification, procedures, and logs, o

Test methods to be used to establish compliance, o

Range of input parameters and their expected output, branches, sub-routines, or options tables (etc.) to be verified.during testing, o

Identification and use of the support computer software and computer hardware to be used in testing, and o

Test standards and criteria for acceptance to be employed.

5.3.3 Testing shall be done under a "Test Environment" where there is no risk to damaging existing production file integrity. If this is not possible all precautions shall be taken to ensure a backup of any code that could potentially be damaged during testing is obtained, or is available.

5.3.4 Review and approval of completed test report(s) shall be documented.

Page 4 of 13

NC.NA-AP.ZZ-0064(Q)

Revision o PUBLIC SERVICE ELECTRIC AND GAS COMPANY NUCLEAR ADMINISTRATIVE PROCEDURES TITLE: SOFTWARE QUALITY ASSURANCE 5.4 Error Reporting 5.4.1 Department instructions shall specify methods used for error reporting and corrective actions.

Computer software errors shall be evaluated for substantial safety hazard in accordance with 10CFR21.

5.4.2 The documentation should provide for the following as a minimum:

o Name of computer software and version level.

o A description of the problem and proposed corrective action.

o A list of all items which may be affected by the error.

o Identification of the personnel involved in the origination and disposition of the problem report, and in the resolution of the problem.

o An identification number and date.

o Adequate review and evaluation of the error by affected departments.

5.5 System Turnover 5.5.1 5.5.2 Use of a system will be authorized by the primary user only after completion of testing and resolution of any discrepancies, unless noted discrepancies resulting from final V&V reports are reviewed to ensure that there will be no adverse effects resulting from use of the system.

This review shall be documented to justify system utilization.

system turnover shall include all documentation identified in section "RECORDS"

• Page 5 of 13

L NC.NA-AP.ZZ-0064(Q)

Revision O PUBLIC SERVICE ELECTRIC AND GAS COMPANY NUCLEAR ADMINISTRATIVE PROCEDURES TITLE: SOFI'WARE QUALITY ASSURANCE 5.6 Access Control computer software access shall include, as appropriate:

5.6.1 Adequate protection from unauthorized access to computer software.

5.6.2 Assurance that only the approved versions of computer software are distributed, and that changes are authorized in accordance with established procedures.

5.6.3 Verification that computer software was accurately transmitted from the test environment to the production environment.

5.6.4 Assurance that archived electronic media are maintained in a designated storage facility established to store copies of software and that the media are protected against inadvertent damage.

5.6.5 Measures that ensure backup copies of all software (or data) exist and are physically separated from user (production) software.

5.6.6 Controls which will ensure the input of data is accurate, and does not deviate from approved design documents.

5.7 Computer Software Control 5.7.1 Computer software revisions shall be controlled in accordance with a control system which includes:

o Accurate and unique identification of all versions of a computer software, and dates of production.status.

o Controls to record the changing of computer software and related documentation.

o Identification numbers of computer programs and documentation.

5.7.2 The software documentation package shall provide documented evidence of release authorization

• 5.7.3 Changes to any computer software which will affect multiple user departments shall have the approval of appropriate user departments prior to releasing it into production.

Page 6 of 13

NC.NA-AP.ZZ-0064(Q)

Revision o PUBLIC SERVICE ELECTRIC AND GAS COMPANY NUCLEAR ADMINISTRATIVE PROCEDURES TITLE: SOFTWARE QUALITY ASSURANCE 5.7.4 Measures shall be established to ensure that superseded or invalidated computer software is not available for production usage.

5.7.5 A Computer Software Index maintained by the responsible department shall contain, as a _minimum, the following information:

o Unique computer software identifier (name and version level, etc.),

o Hardware system(s) on which the computer software is run.

o Computer Programming language and facilities used.

o The time of day program is normally run, if applicable.

o User department/designated contact, o

Brief description of the software application and its

use, o

current revision level and date of user manual and programmer manual, o

Vendor/source (if not PSE&G developed).

5.8 Computer Software Procurement 5.8.1 The responsible department shall assure that computer software for important to safety applications, obtained from vendors, service bureaus, or other outside*

organizations are requisitioned and controlled* ih accordance with the requirements of this procedure, and Nuclear Department Procurement Procedures.

Computer software for important* to safet,y application$ shall be subject to 10CFR Part 21.

5.8.2 Software procurement documents shall clearly state the specific requirements that the computer software shall satisfy.

Page 7 of 13

NC.NA-AP.ZZ-0064(Q)

Revision o PUBLIC SERVICE ELECTRIC AND GAS COMPANY NUCLEAR ADMINISTRATIVE PROCEDURES TITLE: SOFTWARE QUALITY ASSURANCE 5.8.3 For computer software to be developed and delivered, the extent of PSE&G review and approvals of development documents and witnessing of testing shall be determined and specified in the procurement documents.

5.8.4 Validation of computer software operability on the intended*computer system shall be addressed in the procurement documents.

5.8.5 Required certifications shall be specified in the procurement documents.

5.8.6 A documentation package containing the following shall be required by the procurement documents as applicable:

0 The Software Requirements Specification (SRS),

0 The Software Design Description (SDD) I 0

The Software Validation and Verification Plan (SVVP) I and o

The Software Validation and Verification Report (SVVR) summarizing the completed SVVP.

The SVVR shall include a description of the actual performance of the software relative to the specified requirements.

Based on vendor license agreements, code application, historical use of the code in industry, these requirements may be omitted.

Alternative methods may be established and approved by management to accept computer software.

Page 8 of 13

NC.NA-AP.ZZ-0064(Q)

Revision o PUBLIC SERVICE ELECTRIC AND GAS COMPANY NUCLEAR ADMINISTRATIVE PROCEDURES TITLE: SOFTWARE QUALITY ASSURANCE 5.8.7 Where it is necessary to use non-critical software in "Important to Safety Applications" the responsible department manager shall ensure that adequate software verification, specific to the end application is performed.

This shall include the performance of sufficient testing and documentation of test results to assure that the software is producing valid results.

Independent review of test results shall also be performed and documented.

5.9 10CFR50.59 Applicability Review 5.10 5.11 The Department Manager shall assure that all new critical software or changes to existing software are reviewed for 10CFRS0.59 applicability in accordance with the requirements of NC.NA-AP.ZZ-0059(Q).

Pre-existing Cbmputer Software Each department shall evaluate computer software programs that are presently in use to justify continued use.

The results of the evaluation shall ensure adequacy of applicable computer software, and ensure that control of changes to applicable computer software are in accordance with this procedure.

Records Records associated with the Software QA Program will consist of the following, and shall be retained in accordance with NC.NA-AP.ZZ-OOll(Q):

s.11.1 Software Requirements Specification (SRS) or equivalent.

5.11.2 Software Design Description, Preliminary Design Review, and Critical Design Review (CDR) where applicable

• Page 9 of 13

NC.NA-AP.ZZ-0064(Q)

Revision O PUBLIC SERVICE ELECTRIC AND GAS COMPANY NUCLEAR ADMINISTRATIVE PROCEDURES TITLE: SOFTWARE QUALITY ASSURANCE 5.11. 3 Software Validation and Verification Plan (SVVP} or equivalent.

5.11. 4 Software Validation and Verification Report (-SVVR} or equivalent.

5.11.5 Source Code Listing for each version of the computer software used in production (where possible).

5.11.6 Problem/discrepancy reports, change requests, evaluations, test validations, and disposition documentation.

5.11.7 Final review and approval documents (Production Status Authorization).

5.11.8 10CFR50.59 Review and Safety Evaluation 5.11.9 Computer Software Index 5.11.10 Departmental Procedures 5.11.11 Software Program User Manuals 5.11.12 Completed Test Documentation.

6.0 DEFINITIONS 6.1 Computer Program - A sequence of instructions suitable 6.2 for processing by a computer.

Processing may include the.

use of an assembler, a compiler, an interpreter, or a translator to prepare the program for execution as well as to execute it.

Computer Software - Computer programs, procedures, rules, and associated documentation and data pertaining to the operation of computer system. When used in this document, computer software may extend to any hardware components where those components (e.g., PROM, EPROM) can in anyway alter the accuracy or reliability of data output, or affect in any significant way the desired result of the computer system or programs run on the computer system.

Page 10 of 13

NC.NA-AP.ZZ-0064(Q)

Revision O PUBLIC SERVICE ELECTRIC AND GAS COMPANY NUCLEAR ADMINISTRATIVE PROCEDURES TITLE: SOFTWARE QUALITY ASSURANCE 6.4 Critical Design Review CCDRl - A review conducted for the purpose of determining the acceptability of the detailed software design to ensure that the requirements of the Software Requirement Specification have been satisfied.

6.5 Critical Software - Software supporting or performing Safety Related, or Important To Safety functions, or providing data upon which decisions can be solely made regarding plant operation, design, or emergency response.

Typical examples of critical software would include:

MIDAS, TRIS, portions of MMIS, etc.

6.6 Developer - An individual, or organization, whose responsibility is to perform any or all of the following:

plan, design, change, test, or produce computer software in accordance with user requirements.

6.7

6. a*

6.9 6.10 6.11 6.12 6.13 Electronic Media - Any media capable of being directly accessed for storage and retrieved, or images by a computer system, such as magnetic tape, magnetic disks, or optical discs.

Hardware - Physical equipment used in data processing and acquisition.

Important To Safety - As defined in NC.NA-AP.ZZ-0059 (Q).

Preliminary Design Review - The process of analyzing design alternatives and defining the software architecture.

Software Design Description CSDDl - A description of the major components of the software design including data bases and internal interfaces.

An expansion of,this description shall be included to describe each sub-component of the major components.

Software Reauirement Specification CSRSl -

A* clear and precise description of each of the essential requirements of the software and external interfaces, including functions, performances, design constraints and attributes.

Each requirement shall be defined such that its achievement is capable of being objectively verified and validated by.a prescribed method, (e.g., inspection, analysis, demonstration, or test).

Software Validation -

The test and evaluation of the completed software to ensure compliance with software requirements.

Page 11 of 13

HC.HA-AP.ZZ-0064(Q)

Revision o PUBLIC SERVICE ELECTRIC AND GAS COMPANY NUCLEAR ADMINISTRATIVE.PROCEDURES TITLE: SOFI'WARE QUALITY ASSURANCE 6.14 Software Verification - The process of determining whether or not the product of a given phase of the software development cycle fulfills the requirements imposed by the previous phase.

6.15 Software Verification and Validation Plan CSVVPl - A plan that describes the methods to be utilized to perform the following:

6.15.1 To verify that:

a.

The requirements of the SRS are implemented in accordance with the SDD.

b.

The design expressed in the SOD is implemented in the code.

6.15.2 To validate that the code, when executed, complies with requirements identified in the SRS.

6.16 Systems Software - Software designed for a specific computer system or family of computer systems to facilitate the operation and maintenance of the computer system and associated programs, (i.e., operating systems, compilers, utilities).

6.17 Testing - The process of exercising or evaluating a system or system component by manual or automated means, to verify that it satisfies specified requirements or to identify differences between expected and actual results.

6.18 User - An individual, or organization, who accesses computer software for the primary purpose of inputting, compiling or correlating data. Activities performed by a user should not result in alteration of computer software.

7.0 REFERElfCES 7.1 ANSI - IEEE 730-1984, "Software Quality Assurance Plans".

7.2 ASME NQA-2a-1989, Part 2.7, "Quality Assurance Requirements of Computer Software for Nuclear Facility Applications".

Page 12 of 13

NC.NA-AP.ZZ-0064(Q)

Revision o PUBLIC SERVICE ELECTRIC AND GAS COMPANY NUCLEAR ADMINISTRATIVE PROCEDURES TITLE: SOFI'WARE QUALITY ASSURANCE 7.3 NUREG/CR-4640, "Handbook of Software Quality Assurance Techniques applicable to the Nuclear Industry".

7.4 ANSI -

IEEE 729-1983, "IEEE Standard Glossary of Software Terminology".

7.5 NC.NA-AP.ZZ-0059(Q) -

10CFR50.59 "Reviews and Safety Evaluations".

7.6 NC.NA-AP.ZZ-0032(Q) - "Preparation, Review and Approval of Procedures".

7.7 NC.NA-AP.ZZ-OOll(Q) -

"Records Management Program".

7.8 NC.NA-AP.ZZ-0003(Q) -

"Document Control".

7.9 Updated Final Safety Analysis Reports, Chapter-17 Page 13 of 13