ML20100A957

SPDS Implementation Plan for Ja Fitzpatrick Nuclear Power Plant

ML20100A957
Person / Time
Site:	FitzPatrick
Issue date:	11/30/1984
From:	POWER AUTHORITY OF THE STATE OF NEW YORK (NEW YORK
To:
Shared Package
ML20100A927	List: ML20100A922 ML20100A957
References
RTR-NUREG-0737, RTR-NUREG-737 GL-82-33, PROC-841130, NUDOCS 8412040146
Download: ML20100A957 (33)

Text

. _ . . - . . . . - . - _ _ _ _ _ _.

ATTACHMENT NO. 1 to JPN NEW YORK POWER AUTHORITY SAFETY PARAMETER DISPLAY SYSTEM IMPLEMENTATION PLAN FOR THE JAMES A. FITZPATRICK NUCLEAR POWER PLANT v .

J 4

I l

l November 30, 1984 Docket No. 50-333 i

8412040146 841120 L

PDR ADOCK 050003g i\

l N-

! s

{ ',

. ~ _. _ - .. .- . _ - . . . . - . . - - . .

Table of Contents l.0 Introduction 2.0 SPDS/ EPIC System Integration with Other Emergency Response ,-

Capabilities 2.1 De' tailed Control Room Design Review 2.2 Post-Accident Instrumentation (Regulatory Guide 1.97, Rev.2).

2.3 Emergency Operating Procedures 2.4 Emergency-Response Facilities

.2.4.1 Technical Support Center (TSC) 2.4.2 Operational Support Center-(OSC) 2.4.3 Emergency Operations Facility (EOF) 2.5 Meteorological Data 3.0 SPDS/ EPIC System General Description 3.1 Data Aquisition System (DAS) 3.2 Host and Peripheral System 4.0 Implementation Schedule (s) 4.1 Design and Development 4.2 Installation 4.3 Testing '

4.4 Training 5.0 Independent Verification and Validation (IV&V) Program 5.1 General 5.2 System Requirements Review I 5.2.1 Approach and. Objectives l 5.2.2 Responsibilities 5.2.3 Resolution of Deficiencies 5.2.4 System Requirements Review Documentation 5.3 Design Review Audits 5.3.1 Approach and Objectives 5.3.2 Respor.sibilities 5.3.3 Resolution of Deficiencies 5.3.4 Design Review Documentation l

l 5.4 Validation Tests l

5.4.1 Approach and Objectives ,

5.4. 2- Responsibilities l- 5.4.3 Resolution of Deficiencies i 5.4.4 Validation Test Plans j 5.4.5 Validation Test Reports l

.. . _ _ _ . , , . . _ . . . _ , , , _ , , ,,,_._m . , _ _ _ . _ _ _ , _ . , . _ _ _ _ _ _ , , . , _ _ _ _ , _ , . _ , _ , , , _ _ . _ . _ , , _ . _ _ , . _ _ , . , _ _ _ _ _ , . _ _ _ . , _ , . . . _ . _ _ . _ ,

d 5.5 Validation Team Reports 5.6 IV&V Summary Report 5.6.1 Overview of IVsV Plan, Documentation and Activities 5.6.2 System Requirements Review 5.6.3 Design Review Audits 5.6.4 Validation Tests i 5.6.5 Summary and Conclusion 6.0 Project Organization 7.0 References i

e 4

6

~* '+ > .-.-w--. . , , - - . , _ , _ . , _ _ , _ _ _ _ , _ _ _

- =- -

Lint of Figuron No. Title 3-1 SPDS/ EPIC System Configuration 4-1 SPDS/ EPIC Implementation Schedule 5-1 Independent verification and Validation Plan Elements i 6-1. SPDS/ EPIC Project Organization 4

f f

I l

f l

i i

(

l l

l

, - + ,. ,-,y-- y-ew.....-,,,ee, ,...r. , - - . - . -,,,,,.r,,.,..,w.e-wn,-,--w.-w,wwm--m.,-,w.-e.,- .--,www.y*., r-wm.,,,,,--r-v.*re,e---~

^

. . : ,.---- : ^

.-...... ...L .. .~~ ~ ~~

i l.0 INTRODUCTION i

Supplement No. 1 to NUREG-0737 (Reference 2), issued by the Nuclear Regulatory Commission.(NRC) via Generic Letter No. 82-33 on December 17, 1982, provided additional clarification regarding requirements for emergency response capability.at nuclear power

plants. The requirements for a Safety Parameter Display System (SPDS) were one of the five items addressed. 82-33 In the Power Authority's response to Generic Letter No. (Reference 1), a description of the current status and plans for implementing a SPDS at the James A. FitzPatrick Nuclear Power Plant (JAFNPP) was i provided. Because definitive and realistic schedules and plans for implementing the SPDS could not be furnished at that time, the Power Authority committed to providing a SPDS implementation plan by December 1, 1984. This document is the Power Authority's SPDS Implementation Plan for JAFNPP.

I SPDS provides control room operators with a concise display of critical plant parameters to aid them in rapidly and reliably determining,the safety status of the plant. SPDS improves the control. room as it enhances the operator's ability to comprehend plant conditions and interact in situations that require operator intervention.

For JAFNPP, the Authority has developed an integrated system that combines SPDS functions, plant process computer functions ,

(including NSSS and BOP), and supplementary operator aids, in a single system known collectively as the Emergency and Plant Information Computer (EPIC). By integrating the SPDS and plant 1 process computer, a more useful and efficient system will result.

! E cause the plant process computer is used daily, plant operators and staff will quickly become f amiliar with the SPDS/ EPIC system and its capabilities.

I This Implementation Plan will not discuss those portions of the EPIC System that do not directly relate to its SPDS functions.

4 This Implementation Plan provides: (1) schedules for the SPDS/ EPIC system design and development, testing, operator training, and the expected date when the system will be fully operational, and (2) a i description of the independent verification and salidation (IV&V) plan for the SPDS/ EPIC system. This information is presented in

! Sections 4.0 and 5.0, respectively. Section 2.0 describes how the

SPDS/ EPIC system will be integrated with the other JAFNPP emergency c response capabilities. Section 3.0 presents a general description of the project organizations and how they interrelate. Section 7.0 is a list of references containing SPDS requirements and guidelines.

,1 4

E I

s..r.,_,--- ., g,,,, _.,vmm,-.,--,_,mm,r_,-,w

2.0 SPDS/ EPIC SYSTEM INTEGRATION WITH OTHER EMERGENCY RESPONSE CAPABILITIES l The NRC requirements on emergency response capability provided in Supplement No.-1 to NUREG-0737 encompassed, in addition to SPDS, Detailed Control Room Design Review, Regulatory Guide .

1.97'(Revision 2) - Application to Emergency Response Facilities, Upgrade of Emergency Operating Procedures, Emergency Response Facilities, and Meterological Data. All of these items are closely related. The incorporation of these new requirements into programs established prior to the issuance of Supplement No. 1 must be carefully integrated to maximize their-benefit.- ,

In Supplement No. 1 to NUREG-0737 -

" Implementation and Integration Plan" attached to the Power Authority's April 15, 1983 letter to the NRC (Reference 1), the Authority presented its plan to. integrate the JAFNPP emergency response capability E efforts. The Authority's integrated plan takes advantage of the.significant progress that-has already been made at JAFNPP regarding the upgrade of Emergency Operating Procedures, Control Room Design Review, and Emergency Response Facilities.

Thus, the SPDS effort is proceeding along a path parallel with i the other emergency response capability efforts in lieu of l driving them. The SPDS/ EPIC system will draw together and optimize many of the other requirements.

l The following sections describe how the SPDS system will specifically interface and be integrated uith the Authority's f

- other emergency response capability efforts in response to supplement No. 1 to NUREG-0737. While all interfaces may not be discussed, the essential elements necessary for an effective and integrated program are described.

To assure the on-schedule implementation of the SFDS/ EPIC s y s:t e m , a " design freeze" will be imposed January 15, 1985.

Any changes to the elements listed below that impact SPDS/ EPIC design will not be considered for implementation until after j installation is complete.

2.1 Detailed Control Room Design Review-1 The Authority has formally committed to submit a DCRDR Summary l Report by November ~ 15, 1985 (Reference 9). This date was l- subsequently confirmed by the Commission'c June 12, 1984 order (Reference 14). In accordance with this order, a proposed schedule for implementing the recommendations of the DCRDR Summary Report will be included with the report. As described in Section 4.0 of this plan, we expect to complete the installation of SPDS/ EPIC by early 1987.

1 l

--- ~ ---._- - __-_.,,.___,_._

Considoring the chort interval between the issuanco of the Summary Report and scheduled completion of the SPDS/ EPIC

' system, DCRDR recommendations which1either require, or are best accomodated by changes to the SPDS/ EPIC system, will not be incorporated by early 1987. Rather, these changes will be scheduled as a DCRDR modification.

2.2 Post-Accident Instrumentation (Regulatory Guide 1.97 Rev. 2)

The SPDS effort will be closely coordinated with and supported by the effort to meet the requirements of Regulatory Guide 1.97 (Rev. 2), " Instrumentation for Light-Water-Cooled Nuclear Power Plants to Aseess Plant and Environs Conditions During and-Following an Accident." The Regulatory Guide 1.97 effort provides two important documents that assist the SPDS/ EPIC design work:

1. A list of those Regulatory Guide 1.97 variables to be provided, and

2. A table listing the environmental qualification, seismic qualification, quality. assurance level, redundancy, instrument range, power supply, and display means for each variable.

The SPDS/ EPIC system will include all Regulatory Guide 1.97 variables rbquired at JAFNPP. In some cases, the SPDS/ EPIC system may provide the means of display in the control room to satisfy Regulatory Guide 1.97 requirements.

The SPDS/ EPIC system will also be used as the means of providing:

1. The Type A, B, C, D and E variables that are esser.tial for

! performance of Technical Support Center (TSC) functions in the TSC, and

2. The primary ir.lic a t o r s needed to monitor containment conditions and releases of radioactive material from the plant in the Emergency Operations Facility (EOF).

Meteorological parameters (i.e., wind direction, wind speed',

and estimation of atmospheric stability) for the cite and vicinity will be provided by a separate and distinct computer system; not by the SPDS/ EPIC system (see Section 2.5).

2.3 Emergency Operating Procedures In order not to delay the implementation of the Emergency Operating Procedures (EOPs).EOPs are being completed without considering the availability of the SPDS system. JAFNPP

-e

,9 gG4

\

fp Technical Guidelinao for EOPo and the'EOPS thstoolveD will bo 2-used as one of the bases for the selection of tho GPDS l' . parameters.__ _

The BWPOG's EOP-ori' anted displays will be integrated with other displays to provide the ability to assess plant safety as well as obtain information to,enscute the symptom-based EOPs. When the SPDS is installed and operational, the EOPs may be revised'if necessary and operator training provided to account for the availability of the SPDS system.

As the Authority has,previously stated (Reference 1), the FitzPatrick TSC is currently capable of monitoring some parameters listed in' Table 1 of Regulatory Guide 1.97 (Rev.

2) throu'gh the use of a plant process computer display terminal. Meteorological variables are avalible in the TSC via' digital signal path, analog signal or telephone.

~

TSC personnel can also monitor the National Weather Service.

2.4x Emergency Response Facilities

'/ -

y,

'2.4.1 Techical Support Center (TSC) s / An SPDS display' console will be located in the JAFNPP TSC to 5s provide the parameters and data required for evaluating the s' ' incident sequence, determining mitigating actions, evaluating damages, and determining plant safety status during recovery operations. Meteorological parameters (i.e., wind direction, wind speed, and estimation of atmuspheric stability) for the site vicinity will be provided by a separate and distinct 4

computer system. (see Section 2.5).

With the installation and operation of an SPD3/ EPIC display terminal in the TSC, the TSC will be fully functional.

Section 4.0 of thic plan provides a schedule for the SPDS/ EPIC system. In accordance with that schedule, the TSC will be fully functiotal,sevea months after the end of the 1986 FitzPatrick refueling outage or January 10, 1987, whichever is later.

2.4.2 Operational Support Center (OSC) ,

As the Authority stated in Reference 1, an SPDS display console will not be installed in the OSC since the OSC's primary function is to provide an assembly area for operations support personnel.

2.4.3 Emergency Operations Facility (EOF)

,1 -

A SPDS display consule"will be located in the JAFNPP EOF to provide the essential information on containdent conditions and radiological releases necedsary to support the EOF

__^

functiono. Mateorological paranoters (i.e., wind direction, wind speed, and estimation of atuospheric stability) for the

-site vicinity.will be provided by=a separate and distinct

~

S2 -computer system. -(see Section 2.5).

' In Reference 16, the Authority committed to complete a new

. Emergency Operations Facility (EOF) by June 28, 1985. When -

the Authority made this commitment, it was not our intention to include the installation and operation of an SPDS as the method for providing the required plant parameters in the TSC. When we described our plans to use the SPDS to ,

communicate the plant ~ conditions to the TSC (Reference 1),

firm schedules for the new EOF and SPDS had not been-

, . developed.

This date was subsequently confirmed by the NRC in an order dated June 12, 1984 (Reference 14). This NRC order does not specifically include or exclude the operation of an SPDS in their definition of a fully functional EOF.

If the NRC staff does not agree with the Authority's interpretation (i.e. the June 28, 1985 date for EOF completion excludes' installation and operation of equipment to collect, store, analyze, display and communicate informction on containment conditions, radiological releases and other EOF functions) then, the Authority hereby requests that the NRC amend their order dated June 12, 1984 (Reference

14) to reflect the scheduled completion date for the FitzPatrick EOF. Because the new dose assessment / meteorological computer system is also scheduled for completion June 28, 1985, no change to the June 12, 1984 order is required to accomodate its schedule.

2.5 Meteorological Data A new computer system, distinct and separate from the SPDS/ EPIC system, will be used to' evaluate the magnitude and effects o;f actual or potential radioactive material release from the plant and to determine dose projections. This computer system will provide the required meteorological parameters in the control room, TSC, and EOF.

j This system will consist of a main (host) computer, two data l collection and storage microcomputers and three meteorological towers, Meteorological instruments located on-each tower will be interrogated by remote terminal units, l

also located at each tower.

l 1

One of tho toworn hco boon docignated the main tower and in l lccated at the procont cite of the Niegara Mohawk. Power i

Corporation tower on the Nine Mile Nuclear Power Plant site.

A second, backup tower has been installed on the FitzPatrick site. The third, inland tower is located approximately thirteen miles inland from Lake Ontario at the Oswego County Airport in Fulton, New York.

Only one of the two data collection storage microcomputers'is operational at any one times the other is normally operated i

in a standby mode, and will automatically takeover should the primary unit fail. These data collection computers will compute averages and sample counts for all data on fifteen

- minute intervals, transmitting the formatted results to the host computer. Should the host. computer be unavaliable to receive data from the data collection computer, the data collection computer will store up to seven days of data for later transfer to the host. These data collection microcomputers also monitor incoming data for availability i and valid range.

l The host (main) computer maintains meteorological and source term data bases, in addition to actually performing the dose calculations and relaying the results to display consoles.

i The dose assessment software was designed to meet the I

guidelines of NUREG-0654 for a class A meteorological model and will provide dose estimates at fifteen minute intervals.

A detailed description of the atmospheric transport and diffusion model used in the shared meteorological system was-submitted October 1, 1982 (Reference,15). Software, based on the existing software, is currently under develoinent, and- ,

• will be optimized for execution on the Authority's new system.

These computers and the associated peripherals have been procured. Modifications to install the host computer in the plant are-currently in progress. Based up.in current schedules, we expect the complete system facluding the Class A~model and' automated data acquisition, will be complete and i

operational by June 28, 1985.

i l Display terminals for this radiological dose assessment

! system will be installed in the FitzPatrick control room, EOF L and TSC.

I I

l l

l-I l

l

= - - , - . *v- e- c+~ r ev -- +-n-* .--,en..%.--,,--w.w+wc-v.--,e-%,,,w.- ----,-,-y,,,--,,-,wv-e--+-wm,--,=,-m-,,.v-,..w., ,-e--+--v-wy y,v- --,-,y+-p*--*

• 3.0 SPDS/ EPIC CYSTEM GENERAL DESCRIPTION The SP'3S functions have bean integrated in a larger EPIC system

that also performs the plant process computer functions and other daily operational functions. The SPDS functions of the EPIC system will comply with the requirements in Supplement No.

1 to NUREG-0737. References listed in Section 7.0 will be used as guidance in the development and design of the JAFNPP SPDS.

Other NRC, IEEE, NEMA 1 ANSI, and NFPA requirements and guidelines, will be fellowed relating to QA requirements, seismic and Class lE rsquirements, separation criteria, etc.

Specifically, the SPDS functions of the ZPIC system will meet the following general requirements as outlined in Supplement No. 1 to NUREG-0737 (Reference 2):

l. The SPDS functions of the EPIC system will provide a concise display of critical plant parameter and variables to the control room operators to aid them in rapidly and reliably determining the safety status of the plant. The SPDS/ EPIC system will, as a minimum, provide the plant operators sufficient information on:

o Reactivity o Core Cooling o Heat Removal o RCS Integrity o Primary Containment o Radioactivity Control (Excludes functions of Meteorological Computer)

2. The SPDS system display consoles will be located convenient to the control room operators.

3. The SPDS system will display information from which the plant status can be readily and reliably assessed by control room personnel.

4 The SPDS system will have a high availability.

5. The SPDS system will be suitably isolated from electrical or electronic interference with equipment and sensors that are in use in safety systems.

6. The SPDS displays will be designed to incorporate accepted human factors principles so that the displayed information can be readily perceived and comprehended by SPDS users.

7. The SPDS/ EPIC system will support the JAFNPP Emergency Operating Procedure (EOPs).

Tho JAFNPP SPDS/ EPIC oyotsm will conaiot of two major subsystems (see Figure 3-1). The Data Acquisition System (DAS) is the data gathering equipment and is based upon redundant central processing units (CPUs) tied to sensor input / output equipment. The other subsystem consists of all the user ,

interface and mass-data storage peripherals and is based upon l redundant CPUs, referred to as the host CPUs. Sections 3.1 and 3.2 futher describe these two subsystems.

3.1 DAS System Data enter the SPDS/ EPIC system from plant sensors, transducers, switches etc. in the form of analog or digital signals. The raw data are processed by the data acquisition subsystem then transferred to the host where more sophisticated processing takes place.

Each DAS CPU is equipped with two megabytes of main memory, floating point accelerator, and a 456 megabyte system disk.

Both DAS CPUs interface with the sensor input units and with the host CPUs. At any time, only one of the two DAS CPUs is the master, while the other is in a standby mode. Both DAS CPUs actively gather data and transmit them to a host CPU.

The sensor input / output equipment consists of Remote Multiplexer units (RMUs). The RMUs are configured into two trains: 1E and non-lE RMUs (except for a single non-lE radwaste RMU). Each RMU contains a dual intelligent remote control unit (IRCU) and is configured with en assortment of analog input, status input, pulse input, and sequence of event cards, or relay output cards. RMUs interface with DAS CPUs through optical modems and high speed serial ports.

l l

l JAFNPP FIELD INPUTS

~~~ ~

~

TRAIN A SIGNALS' ~ TRAIN 8 SIGNALS r- m r-- ,

IttItIIIfIIIieiRRt9 eiiIIIIi99IIiiit88i tiiIitIttiIIIIEteBI iaetteItItttttttttt IE QUALIFIED CPI NON QU,ALIFIED CPI NON QUALIFIED CPI 1E QUALIFIED CPI

' DATA ACQUISITION DATA ACQUISITION DATA ACQUISITION DATA ACQUISITION EQUIPTMENT EQUIPMENT 1E EQUIPMENT - EQUIPMENT J

DATA ACQUISITION .3 RA81 DATA ACQUSITION PROCESSOR DUAL PORT PROCESSOR VAX11/785 WITH 456 MS DISKS VAX11/785 WITH

! 2.0 MS MEMORY 2.0 MS MEMORY

! t I L . X SYSTEM' SYSTEM TERMINAL . TERMINAL 3 RA81 DUAL PORT 4S6 MS DISKS Epic HOST EPIC HOST COW UTER 3 RA81 COWUTER

'VAX11/785 WITH DUAL PORT .,VAX11/785 WITH 8.0 M8 MEMORY 8.0 MS MEMORY 4S6 MS DISKS SYSTEM 2 TU78 SYS1EM J.*

". TERMINAL TEMIM 1600/6250 SPI DUAL PORT TAPE EMERGENCY OPERATIONS FACILITY PROGRNR/ ENGINEER

! 1 19" COLOR CRT TERMINAL FAILOVER MONITOR 2 18H PC TERMINALS 1 COLOR COPIER 32 CHANNEL RS-232 SWITCH EMERGENCY RESPONSE CENTER I

MODEMS

) ONI CONTRE ROOM TECmlAL N T CENTER l 319* COLOR CRT TERMINALS -

l 3 25' COLOR CRT MONITORS - - 319' COLOR CRT TERMINALS 2 600 LPM PRINTERS --- 3 COLOR COPIERS 3 COLOR COPIERS - - 1 600 LPH PRINTER 1 STRIP CHART RECORDER PMAX .

l PROCESSOR

~

Figure 3-1 SPDS/ EPIC System Configuration

. -. - .. . - . - _.. -.-- - - - ..~.- _ _ . -... _ _ _. . - - _ .-. _ _ .

~

3.2 Hoct and Poripheral Systom The host CPUs consist of redundant super minicomputers. Each

~"

host CPU contains at least six megabytes of memory, 32 Kbytes of cache memory, and a floating point accelerator.

Additionally, each host CPU will be interfaced to a 456 megabyte disk and two additional disks. The data disks are -

dual ported to each host computer. This provides 456 megabytes of unshared disk memory and 912 megabytes of shared disk memory for each host. The system is also equipped with two 1600/6250 bit / inch dual port magnetic tape units. The two hosts communicate with each other over high-speed serial links, so the slave is constantly updated with system status and data and can take over the master function with a minimum of disruption. A "failover" device monitors both hosts and can force a failover automatically or by manual intervention. The

! input / output to the control room, Technical Support Center (TSC), and Emergency Operations Facility (EOF), is identical on each host. Dual outputs are routed to programmable switches which will connect the various peripherals to the current active master host. This switch arrangement, the dual ported disks, and the cross-connecting links to the DAS CPUs allow either host to be inoperable with no degradation of the SPDS/ EPIC function.

The primary input / output device and operator interface is color graphic monitors. They provide 512 x 512 pixel color graphic and alphanumeric displays. Each is equipped with an alphanumeric keyboard, trackball, and a 60-key special function keyboard. Three operator stations will be located in the control room. Three additional monitors will be mounted on the control room panel without keyboards or trackballs. Additional operator stations will be located in the TSC, along with a printer. An operator station will also be located in the EOF.

Operator stations will have printers associated with them to provide hard copy of monitor displays.

i i

l

. . _ _-- , _ . ~ .- _ , . _ __ _.____ ,_. _- . . . . _ _ _ - , _ . . _

4.0 IMPLEMENTATION SCHEDULE (a)

The dates in Figure 4-1 are the planned schedules, but should be used only for information since they are subject to change.

The following sections briefly describe the individual schedules included in Figure 4-1.

4.1 Design and Development In the Authority's April 15, 1983 letter (Reference 1), the' discussion of the status of the SPDS/ EPIC system described the participation of the Authority in the Northeast Utility Consortium's (NEUC) effort to cooperatively specify and purchase an SPDS. In addition to participation in NEUC, the Power Authority also participated in other industry group efforts relating to SPDS design and development. As a result of these efforts, the Power Authority requested bids from prospective vendors for the JAFNPP SPDS/ EPIC system in mid-1983 In April of 1984, the NEUC disbanded and NYPA signed a contract with Energy Incorporated (EI) for an integrated, SPDS/ EPIC system including hardware, software, and associated architect / engineering (A/E) services.

The project is oresently on schedule with required major activities, and SPDS/ EPIC system design work should be completed by mid-1985 as shown in Figure 4-1. A " design freeze" willibe imposed to assure on-schedule system implementation.

4.2 Installation The SPDS/ EPIC system will be installed following satisfactory completion of the Factcry Acceptance Test (FAT) and shipment to JAFNPP. Prior to this, critical preparation and installation activities will be completed during planned outages or, as possible, during plant operation. Preparation activities include relay room and computer room core drills, DAS termination cabinet installation, cable pulling, relay room modifications (e.g., HVAC, fire protection, architectural), DAS input / output terminations, etc.

l I

4.3 Testing l

The planned validation tests include the Factory Acceptance i Test (FAT), the Site Acceptance Test (SAT), and the 1000-hour Operational Availability Demonstration (OAD). The FAT will be

! performed at the contractor's shop and will assure that system requirements have been met prior to shipment to JAFNPP. The FAT will include analyses, inspection, hardware functions software functions, a system performance test, and a 100-hour system endurance test. A maintainability validation test

4 t

4 b

1981 1984 l 198$ l 1986 l19C7 l 0, A M JJ A5 0N O J F M A M JJ A $ 0 N OJ F 81 A P J J A $ 0 h 0 J F MAM JJA $ 0N OJ F nA M ,

, f I I f 1 I I e I I I I I I I I I I I I I I I e I I I e I I I I I I i 1 I I e a I e 1 i i iI I i1 i

J \

Power Authority - (I SPOS/IPIC

$80$/ EPIC '

Funy b rational V

System Contract y

i i l  !

] Design and I ,

Development .......

l t l

. I i i

Installation outa9' Outa9e Out49e l (During Outages) -----:  :- - - - - - --- - H- - - - - ' = -- - - - - - H - - - - - - l l j i l I 9 g 1 I 1 I I l f Testing 1 I

y!l 5"* .  !

' '10005ou-Operettoaal 4.

I I Availabtitty Derenstratica l t

I $PD$/ EPIC 8 i

l functionai I  !

E I Overview l l 1 Training  %  ;  ; ,

l

] Hardware peactor Ooerator and i l 1

, Malatenance Senter peactor Operator.' j

Fundamentals of Progra:alag,

! and $PD$/ EPIC Systee Software ,

, l' i

-l i .

Figure 4-1

SPDS/ EPIC IMPLEMENTATION SCHEDULE I

will also be run prior to the FAT. The SAT will duplicate the FAT under actual plant operating conditionc cnd will vorify correct installation of the equipment. The-1000-hour OAD will be the final SPDS/ EPIC system acceptance test.

In addition to these final validation tests an extensive prevalidation testing program will be conducted. Prevalidation tests will include hardware acceptance tests, software module acceptance tests, and a certified " dry-run" prior to the FAT.

A parallel operations test will also be run at JAFNPP, as a preliminary test of hardware compatibility between the data acquisition system (DAS) and the existing GEPAC plant process computer. Both the new SPDS/ EPIC systems will be operated in parallel for some period even after full operation of the SPDS/ EPIC system as a futher confirmation of satisfactory system operation.

4.4 Training As shown in Figure 4-1, training will cover hardware maintenance, a system overview, fundamentals of programming, system software, and reactor operator and senior reactor operator training. Training will be completed prior to the system becoming fully operational. In addition, during the 1000-hour operational availability demonstration, (which is the final test prior to the SPDS/ EPIC system becoming fully operational), the Power Authority will operate and maintain the SPDS/ EPIC system to provide the operator with additional experience.

5.0 INDEPENDENT VERIFICATION AND VALIDATION PROGRAM 5.1 General To meet the verification and validation requirements of Supplement 1 to NUREG-0737 and to ensure that the JAFNPP SPDS/ EPIC syistem meets all of its functional requirements, an Independent 7erification and Validation (IV&V) program will be conducted. This section describes the requirements and l procedures of the JAFNPP SPDS/ EPIC system IV&V program.

Additional details can be found in Reference 10.

The IV&V program for the JAFNPP SPDS/ EPIC system has been developed using the guidelines of NSAC-39, " Verification and Validation for Safety Parameter Display System" (Reference 11) as a basis for planning a comprehensive program. Both SPDS/ EPIC system software and hardware will be subject to

l. verification and validation.

l Verification is the review of the requirements ~to see that the right problem is being correctly and completely addressed and then the review of the design to see that it meets the l

l l

l 1

1 octablishod roquironento. Validation 10 tho test and ovaluation of the integrated hardwaro and coftware syston to determine compliarce with the functional, perforcance, and interface requirements.

Responsibility for the JAFNPP SPDS/ EPIC IVEV Program has been delegated by the Power Authority to the SPDS/ EPIC system contractor. The IV&V program will be in addition to the normal 1

or in process design review and quality assurance activities performed by the contractor. The IVsv team will consist of a chairman, a hardware representative, and a software representative who are independent of the design and i implementation of the system per Regulatory Guide 1.64 requirements (Reference 12) and who have the qualifications and experience necessary to carry out the IV&V responsibilities.

The Power Authority will maintain close cognizance of the review of the IVEV activities as they progress and are documented.

The major elements of the IV&v program are listed and  !

summarized below.

1 System Requirements Review - The system requirements review is perhaps the most important IVEV element. The SPDS/ EPIC system requirements are the foundation on which the completed system must be designed, built, and accepted. Also, the completed system is validated against the SPDS/ EPIC system requirements. The* principal goal of the system requirements review is to independently determine if the right problem is being solved and that the requirements are correct, complete, consistent, feasible, and testable. The system requiraments review also provides the basis for the system validation tests.

t Design Review - The SPDS/ EPIC system design reviews provide verification that the hardware and software design has properly implemented the system requirements.

I Traceability of the various design features to particular requirements is emphasized, as is the completeness of the

! design with respect to the requirements. The design reviews also examine the design with respect to logical quality, sufficient detail, and testing implications.

4 I Validation Tests,- Two validation tests will be conducted. The first will be conducted as part of the factory acceptanco test (FAT) and is performed to demonstrate and document that the integrated system meets the requirements. The second validation test will be conducted as part of the site acceptance test (SAT) and is performed to demonstrate and document the installed system's compliance with system requirements as validated by the first validation test. The second validation test 4

. . , . . . _ _ .. .. ~ , -- - - . .. - - . - . . - . . _- - _ __ _

.includan what NSAC-39 rofore to CD the field vorification-toot which verifico that the cystos 10 prcporly installed. Test plans and procedures will be prepared prior to validation testing. Test execution-and results analysis complete the testing activity with any identified discrepancies and their resolution documented.

Validation Team Reports - Validation team reports will document each step of the IV&V process. This multi-volume f

report will provide.the necessary traceability of information generated by the IV&V team during the IVEV

' program.

s Summary Report - The IV &V summary report will be prepared

j. by the IV&V team after all IV&V program elements are concluded. The report will summarise both IV&v program activities and other V&V performed as a normal part of the i

software and hardware design team efforts. Traceability

~

of the JAFNPP SPDS/ EPIC system verification and valtdation I activities, identification and resolution of discrepancies, and reference to detailed documentation will be provided.

l Figure 5-1 shows the relationship among the above elements of 1 the Iv&V program. The following sections describe each element in more detail, discussing the approach and objectives, responsibilities,-resolution of deficiencies, and documentation.

j- The IVEV progr4m is in addition to, not instead of, the review

' activities normally performed by the software and hsrdware

design teams. These in process activities are governed by internal contractor procedures. Specific in process review

' activities include second level reviews, formal design reviews, documentation, inspection, and testing.

1 In addition, a comprehensive Reliability, Availability, and l

' Maintainability (RAM) program and the QA program address the SPDS/ EPIC system hardware design and installation. As a result of this, several of the IV&V elements described herein j primarily consist of audits and reviews to ensure proper l performance of in process review functions. However, the , ,

ultimate responsibility for verification and validation is with

' the IVsV team.

i f

5.2 System Requirements Review The system requirements review is a key element of the verification and validation program. A clear statement of the l

i requirements is necessary in order to determine whether the i

k

-_.g-_,.,... ..--.,.-,-.m--,m,%-ww, ,.._w.wr,._.%y.%. .-w n,.m.yn.,m..m..,.w,n.w.e,-y -.,.me

correct problon in being colvod and whothar cubcoquent design l

roviowa cro corrcctly addroccing the statcasnt of the problon.

Moreover, it is the system requirements against which validation test results are measured.

5.2.1 Approach and Objectives The system requirements review will be performed to evaluate ,

the requirements with respect to a number of criteria. These criteria incl ude : 1) correctness, 2) completeness, 3) consistency, 4) feasibility, and 5) testability.

I i .

i f

i l

l l

._ . _- - - _ _ . _ - - - _ - - _ - . _ _ - . - . _ _ - . . . - . _ - _ ~ - . . . - .

""j*~~' ='- -9 =' .::l=, =': -'"""

-T;.- r.{," .:=:.

9 "[j,1,%

I, I f t t t t 41 4 t 1 i lI l 'I l a- ---

Y~' . = N.:::Y:,,,,

~~

=N] _N",'- - ';,,y) =N',~,'

n . , , ,

o

.. - . =,- ...

-=\, __

-=- ,

=\-.,

" = [=, .

.=.

Figure 5-1 IV&V Elements i

i r - -

The correctness and-completeness criteria are applied to the

~

-requirements to determine if the correct problem is being solved.- When requirements are being reviewed for correctness, they are to be reviewed with respect to being necessary.as well as sufficient.

A spot-check of requirements for consistency toward applicable standards and regulations will be conducted. The consistency evaluation will also be conducted regarding the <

. other relevant plant-specific requirements.

Requirements will be reviewed for feasibility and testability to determine a reasonable and meaningful set of acceptability test criteria. Emphasis will be placed on review of the stated requirements with respect to how well they lend themselves to testing against measurable test criteria.

Requirements which are not easily. tested against objective 1

criteria or with. repeatable results will be identified.

t specific requirements shall be identified by references to i- the specific sections in the system requirements

, documentation. Traceability of requirements through subsequent documentation and later phases of the IVEV program is initiated in this manner.

[ Along with a thorough examination of the requirements as j stated in the SPDS/ EPIC system specification, the review will-produce an independent, documented definition of the system 8

itself, physical characteristics such as interfaces with other systems or equipment, signal inputs and outputs, etc.

4 In order to facilitate the system requirements review, every

requirements document has three appendices:

I l

(1) Sufficiency Matrix - Maps paragraphs of the system i

specification to the requirements document.

I

' (2) Necessity Matrix - Maps paragraphs of the requirements document back to the system specification.

j- (3) Validation Matrix - Maps paragraphs of the requirements document to the various forms of validations analysis, ,

inspection, functional test, performance test, endurance i test.

5.2.2 Responsibilities i.

l The software and hardware design teams, via their in-process V&V activities, have the responsibility for performing and h

t 4

1

. -. - .- , , - . - . _ . _ , _ . . . . - _ . . _ _ _ ~ . _ _ _ _ _ _ - _ _ . . _ _ _ _

docunanting the oyotos requiromonts reviow and correcting any

'doficioncios idontified by oither tho in prccess V&V activities or the IVEV team.

The IV&V team has the responsibility'to ensure that these reviews-are performed and to perform spot-check reviews of their own.

5.2.3 Resolution of Deficiencies Deficiencies identified during the requirements review will Ebe summarized in the validation team reports. Deficiencies may be resolved by modification.of the system requirements documentation or by providing supplementary documentation addressing the particular requirements issues involved.

5.2.4 System Requirements Review Documentation The results of the system requirements review will be documented by the IVEV team and included in the validation team reports. This document will describe the review approach and verify the. requirements with respect to the criteria of Section 5.1.1. In general, the section of the validation team report containing the system requirements review, will contain the following sections: 1)

Introduction, 2) System Definition, 3) Requirements Summary,

4) Evaluation Summary, and 5) Identification of Deficiencies.

5.3 Design Review Audits Design reviews are performed as a normal part of the contractor effort to verify that the hardware and software designs correctly address the system requirements. The IV&V i team will audit this. design review process. Traceability of l the various design features to particular requirements is

! emphasized, as is the completeness.of the design with respect

! to requirements. The review process also examines the design l with respect to logical quality, sufficient detail, and testing implications.

5.3.1 Approach and Objectives l

A number of documents will be used to perform the design review audits. Included are the SPDS/ EPIC system l specification, the functional requirements document, the l validation ~ team reports, design review reports, l reconciliation reports, general and detailed design documents i

l l

4 L

rolating to hardwaro end oeftwaro, and cny other supplecontal documents which may provide deoign inforcotion. Tracochility of design. features to the various specific requirements recorded in the requirements review report will be provided.

All such requirements will be thus identified in terms of associated design information.

One phase of the review will be to perform independent evaluations of hardware and software design. The hardware design review audit will address the following design features and considerations:

(1) Hardware architecture; (2) Input and output interfaces; (3) Hardware availability and redundancy (4) Equipment locations and environmental requirements; (5) Signal types and rates, testing approacht (6) Hardware integration including communications, subsystem integration, and testing approach; and (7) Human factors considerations.

The software design review audit will address the following design considerations:

(1) Software structure, i.e., distribution of functions into subsystem packages; (2) Data structure definition; (3) Interfaces, including interfaces among subsystems and input / output interfacess (4) System and executive controit (5) Consistency between preliminary or top-level design and detailed design; l

, (6) Performance analysis; f

i (7) Human f actors considerations; and (8) Association of design features to requirements. ,

l l

l l

1

.At tho conclusion of thofindopondent herdwaro and coftworo I rovicwa, on intograted rovicw prccoco will onouro thct the i total system design is completely described and adequately referenced to the requirements.

5.3.2 Responsibilities The responsibility of the IVEV team is to ensure that all design reviews are conducted in accordance with established procedures, to ensure that independent design reviews are conducted for both hardware and software, and to verify that the system requirements are indeed being met by the design.

The IVEV team findings will be reported in team reports.

The software and hardware design teams will perform the I

hardware and software reviews in accordance with established procedures and provide the IV&V team with the results of >

these reviews. The hardware and software design teams will i also have the responsibility for documenting the hardware and

. software design reviews and correcting any deficiencies identified in both their design reviews and the IVav reviews.

5.3.3 Resolution of Deficiencies

! Deficiencies identified during both the system design reviews

!- performed by the hardware and software design teams and the i IV&V team review will be identified in the validation team i reports. - They may be resolved by revision of. design

! documentatior., issuance of additional documentation, or ,

written clarification. The resolution of deficiencies will be reported in both the validation team reports and the IV&V i Summary Report.

5.3.4 Design Review Documentation e The hardware and software design review and IV&V team audits will be documented in the validation team reports. The

. following general outline will be included in this section~of l

the report: 1) Introduction, 2) General Design Evaluation, 3)

! Performance Analysis, and 4) Deficiencies.

5.4 Validation Tests The first validation test will bc conducted after the system l hardware and software are fully integrated. Thus, the first validation test will be conducted in conjuction with the a

1

fcctory accoptanco toGt (FAT) and tho accond validation test will b3 conducted in conjuction with the cite ecceptanco toot (SAT). The second validation test satisfies the requirements

~~

~-~of what NSAC-39 (Reference 11) refers to-as the " Field _

Verification Test."

5.4.1 Approach and Objectives e

The objective of the first validation test is to demonstrate and document the compliance of the integrated system to the requirements. The objective of the second validation test is to demonstrate and document the installed system's compliance with system requirements as validated by the first validation-test. The validation test plans will be prepared by the design team and reviewed by the IVSV team. Both test plans will contain test requirements, test philosophy, test environment, test specifications, detailed test descriptions, e test procedures, and test evaluation approach. Both validation test plans will be documented in a validation team report.. A representative of the IV&V team will audit the test activities to ensure that the test execution follows the procedures and that detailed test records are accurately maintained. Documentation will be prepared to ensure traceability back through the requirements documents.

5.4.2 Responsibilities The design team is responsible for preparation of the validation test plans. Validation test plans will identify test requirements, philosophy, environment, specifications, descriptions, procedures, and evaluation approach with the objective of demonstrating that the completed system meets all system requirements. The procedures will be defined functionally in a manner which will allow tracking of test results to system requirements. The design team will be responsible for detailed step-by-step descriptions for performing the tests within the framework of the test plans.

The IVSV team will review the test plans for completeness and include the final test plans in a validation team report.

Note, the validation test plans may be comprised of several separate documents such as: Overall Test Plan, FAT Test Plan, SAT Test Plan, FAT Procedures, and SAT Procedures.

An IV&V representative will audit the test execution and be responsible for ensuring that the tests are conducted in accordance with the test plans. The desige. team will be

rocyonsiblo for porforcing tho actual tecto.- The IVEV toam will review tho validation toot reperto prepared by tho design team and make an evaluation of systom parformanco for each step. The IV&V team will be responsible for verification of acceptable performance in accor3ance with.

< specified acceptance criteria.

Following completion of all validation testing, the IV&V team will prepare a summary of the validation tests, including any deficiencies identified. The summary will be finalized upon resolution of identified deficiencies and required retesting and included in a validation team report.

. 5.4.3 Resolution of Deficiencies The disposition of deficiencies and approach to test case repeats and sign-offs will be defined in the test plans.

Provisions will be made for resolution of minor deficiencies j' during or immediately after the performance of a test case, l

in which case documentation attached to the procedure would i describe the nature of the correction or allowance and contain approval signatures including the IVsv team. If, l

during testing, procedural errors are identified, they would .

he handled in the same manner.

Provisions will be made to retest s ec tio r.J of test cases which fail. These provisions will include criteria to determine when the entire test case must be re-run and when .

1 only selected sections of a test case need repeated. These criteria will be specifically defined in the test specifications portion of the test plans. Provisions will also be included in the test plans to handle major test failures or repeated test failures.

The procedures will contain a final sign-off to be signed by ,

designated responsible parties including the IV&V team after successful completion of all portions of the test and resolution of all discrepancies.

5.4.4 Validation Test Plans

! The validation test plans will include test requirements, test philosophy, test environment, test specifications, 4

detailed test descriptions, test procedures,.and test evaluation approach. The collection of test cases will be selected to provide a fully integrated functional test of the j system. In general, the validation test plans will contain I

4 f

- . -- .- ~ _ . - . . .. ._- .~

the follcwing occtiencs :L ) Introduction, 2) Prorsquisites,

3) Syston Dancription and Toot Roquiromento, 4) Test Environmental Specifications, 5) Test Equipment and Software,

6) General Test Specifications, 7) Individual Test Case Specifications, and 8) Test Procedures.

5.4.5 Validation Test Reports The design team will prepare and compile the major portion of the validation test reports subsequent to completion of the

! ' validation tests. It is anticipated that these reports.will be issued as a portion of a validation team report. These reports will summarize each test and include an attachment

containing all relevant hard copy test results. In general, j this report will contain the following sections

1) introduction, 2) list of reference documents, 3) individual test case analysis, 4) overall summary, including- .

capabilities successfully demonstrated and deficiencies, and

'5) recommendations.

i.

• 5.5 Validation Team Reports The purpose of the validation team reports is to document

each step of the IV&v process. Each successive report will 4

be assigned a sequential volume number. This multi-volume report will provide the necessary traceability'of all information generated by the IVEV team during the IV&V process. It is anticipated that these reports will contain I the reports described in Sections 5.1, 5.2, and 5.3. Thus, the outline of the validation reports will be dictated by the

! previously described outlines for the system requirements i report, design review report, and validation test reports.

5.6 IVGV Summary Report i

The IV&V summary report will be prepared by the IVEV team

! after all other SPDS/ EPIC system IV&V program elements are

! concluded. This report will be based on the documentation from both the norwal or in-process VGV activities and the IVsV program. For the in-process VGV activities the report will contain information on: 1) objectives, 2) summary of j activities, 3) results summary, 4) deficiencies and resolutions, and 5) references.- The report will summarize the contents of all the IV&V validation team reports.

i The contents of the IVGV Summary Report will contain the l following information:

l (1) Overview of IVEV Plan, documentation, and activitiest l

i

(- ,

(2) Systen_roquiroconto roviews (3)- Design review audits; (4) Validation tests; and (5) Summary and conclusions.

5.6.1 overview of IVEV Plan, Documentation, and Activities The in process VEV activities and IVEV program will be ~

summarized in the-overview section. The overview will also

! listethe VEV documentation used to implement the IVEV plan'or generated as a result of the IV&V activities.

5.6.2 System Requirements Review This section will summarize the objectives, activities, and results of the system requirements review. It will summarize the deficiencies identified and the manner in which they were resolved and list the reference material germane to the requirements review.

5.6.3 Design Review Audits 1

.This section will contain the same type of information as the previous section. Both the hardware and software design review audits will be included in the discussion. Reference material relevant to the design review phase will be listed.

5.6.4 Validation Tests t The validation test plans will be summarized,'along with the test execution itself and the test reports. Any deficiencies identified during the tests will be discussed, including the manner in which they were resolved. References relative to the validation tests will be itemized.

5.6.5 Summary and conclusions This section will present an overall summary of the SPDS/ EPIC system IVEV program. The conclusions will address the quality of the system, the system's traceability, and the system's auditability. A traceability matrix will be included to serve as a " road map" to the traceability of the various requirements issues. The system auditability discussion will address the role of the various document references listed in the overview section and thus serve as a starting point for any future study of the plant emergency response capability documentation trail.

. . - ~, _ .

6.0 PROJECT ORGANIZATION A Project Organization has been established to ensure the timely operation of the SPDS/ EPIC system at JAFNPP in  !

conformance with system requirements and guidelines. The Power Authority's organization is headed by a full-time Project Manager who is supported by designated individuals responsible for technical areas including licensing; training; Quality Assurance (QA); Reliability, Availability and Maintainability (RAM); softwares displays / consoles and control room design (human factors); hardwares installations and testing. Two Power Authority persons are assigned to each technical area, one at headquarters office and one at the JAFNPP site. Onsite JAFNPP support will ensure that the SPDS/ EPIC design, installation, training, and operation will be efficiently integrated with plant operations and will meet the operational' requirements of the plant. A designated site coordinator coordinates site activities to support the Project Manager.

The Authority's contractor also has a dedicated FAoject Manager who heads a team of qualified professionals responsible for the design, fabrication, delivery, installation, and final demonstration of the SPDS/ EPIC. The project organization is shown in Figure 6-1.

Each responsible individual within the two organizations has direct access to the corresponding personnel within each technical area. This allows direct communications between technical individuals in addition to formal project management communications. A contractor representative has been assigned to the JAFNPP site to enhance technical site contact.

Monthly project meetings are held between the Authority and the primary contractor to assure the progreas of the project.

1

Figure 6-1

. E NYPA RTZPERICK EPIC _

PROJECT ORGANIZATION e

MMMACT esasemesR comaeuunaa .

CONTROL teAsemagt l

PaamCf Asse1msff a C00AgnemOR i

j geef41mfif 0#4fTt RNJ TRasMuse f

i

~

-l g

i &

MM MMM Ml8EA88 mm runsames l

ShC10ftS 4

i M PIBONCf EMessen 4

884 goggeMR WegumR WetNEWR poengunfug N l A4OWMCES SOFT 1uhAE esm art Luse f

PU18Cf108tAL i

N 80808e88R800 l

1

__ 1

7.0 REFERENCES

1. NYPA letter, J.P. Bayne to D.B. Vassallo, dated April 15, 1983 (JPN-83-33). ,

2. NUREG-0737, Supplement 1, " Requirements for Emergency Response capability (Generic Letter No. 82-33, dated December 17, 1982).

3. NUREG-0696, " Functional criteria for Emergency Response Facilities."

4. NUREG-0700, " Guidelines for Control Room Design Review."

5. NUREG-0835, " Human Factors Acceptance Criteria for SPDS."

6. NUREG-0814, " Methodology for Evaluation of Emergency Response Facilities."

7. Regulatory Guide 1.97, " Instrumentation for Light-Water-Cooled Nuclear Power Plants to Assess Plant and Environs Conditions During and Following an Accident," Revision 2.

8. NSAC/21, " Fundamental Safety Parameter Set for Boiling Water Reactors," December 1980.

9. NYPA letter, J.P. Bayne to D.B. Vassallo, dated October 24, 1983 (JPN-83-90), regarding DCRDR Program Plan.

10. " Independent Verification and Validation Plan for New York Power Authority James A. FitzPatrick Nuclear Power Plant Emergency and Plant Information Computer System," NYPA-602, Revision 2, October 1984.

11. " Verification and validation for Safety Parameter Display Systems," Nuclear Safety Analysis Center, NSAC-39, December 1983.

12. " Quality Assurance Requirements f o t' the Design of Nuclear Power Plants," NRC Regulatory Guide 1.64, June 1976 (ANSI N45-20ll, 1979).

13. NYPA letter, J.P. Bayne to D.B. Vassallo, dated August 31, 1984 (JPN-84-57) regarding Supplement to Detailed Control Room l Design Review Program Plan.

14. NRC confirmatory order regarding Commitments on Emergency Response Capability; attachment to NRC letter, D.B. Vassallo to J.P. Bayne, dated June 19, 1984

15. PASNY letter, J. P. Bayne to D. B. Vassallo, dated October 1, 1982 (JPN-82-75B) regarding description of atmospheric transport and diffusion model for dose assessment system.

16. NYPA letter, J.P. Bayne to D.B. Vassallo, dated August 24, 1983 (JPN-83-77) regarding Supplement No. 1 to NUREG-0737 requirements for Emergency Response Capability.

17. NYPA Letter, J.P. Bayne to D.B. Vassallo, dated June 30, 1983 (JPN-83-60) regarding Supplement No. 1 to NUREG-0737 transmits Writers Guide, Verification Program, Validation Program, Technical Guidelines and Training Program Description for Emergency Operating Procedures (EOPs).

1