ML20033E441
| ML20033E441 | |
| Person / Time | |
|---|---|
| Site: | Sequoyah  |
| Issue date: | 09/30/1989 |
| From: | Erin L WESTINGHOUSE ELECTRIC COMPANY, DIV OF CBS CORP. |
| To: | |
| Shared Package | |
| ML19293A205 | List: |
| References | |
| WCAP-12375, NUDOCS 9003120784 | |
| Download: ML20033E441 (89) | |
Text
._
WEST!NOMDU$E CLAS$ 3 l
WCAP-12H5 4
1 l
1 TOPICAL REPORT EA8LE-21 i
i i
NICADPMDCESSOR-SASED l
I PROCES$ PROTECTION SYSTEM i
L. E. ERIN
.I l
l l
f SEPTEMER, 1989 7
Approved:
h1 Lb Approved:
A Manager $
- Mnaghr, I
Instrumentation and Process System Control Systems Licensing Engineering Nuclear and Advanced Process Control Division Technology Division i
l t
l Westinghouse Electric Corporation l
Energy Systems Division i
P. O. Box 355
)
Pittsburgh, Pennsylvania 15230 j
l l
I 5
9003120784 900301 PDR ADOC.K C5000927 PhC p
,___.,____.,._.,.,_._...__,_.,_....___..__._,,,___.._,_..,.....,,,_..-__m_,,__.
i l
ACKNOWLEDGEMENTS k
The author wishes to express his appreciation to Carl A. Vitalbo of the Westinghouse Process Control Division whose help was instrumental in assuring the completeness and accuracy of this topical report.
1 i
i i
t i
I 1
TABLE OF CONTENTS 1
ABSTRACT
1.0 INTRODUCTION
2.0 DESIGN PHILOSOPHY AND FEATURES 2.1 Forn Fit-Function Concept 2.1.1 Typical Analog Process Channel 2.1.2 Typical Eagle-21 Process Channel 2.2 Installation i
2.3 Design Features 2.3.1 Single Failure Criterion 2.3.2 Instrument Power Source 2.3.3 Channel Integrity 2.3.4 Channel Independence 2.3.5 Control and Protection System Interaction 2.3.6 Automatic Surveillance Testing 2.3.7 Self Calibration 2.3.8 Channel Bypass l
2.3.g Access to Setpoint and Tuning Constant Adjustments 2.3.10 Diagnostics 3.0 TECHNICAL DESCRIPTION 3.1 Eagle-21 Architecture 3.1.1 Input / Output (1/0) Subsystem 3.1.2 Loop Processor Subsystem 3.1.3 Tester Subsystem 3.1.3.1 Man-Machine-Interface (let!)
TABLE OF CONTENTS (cont) 3.2 Eagle 21 Hardware Description 3.2.1 Analog Input Module 3.2.2 Contact Input Module j
3.2.3 Analog Output Module 3.2.4 Contact Output Module 3.2.5 Trip Dutput Module 3.2.6 Microprocessor Card Chassis Modules 3.2.6.1 a,c 3.2.6.2 3.2.6.3 3.2.6.4 3.2.6.5 3.2.6.6 3.2.7 Miscellaneous Hardware
[
3.2.7.1 Microprocessor Card Chassis 3.2.7.2 DC Power Supply Chassis 3.2.7.3 Test Panel 3.2.7.4 Termination Frame-3.2.7.5 Cabinet Cooling Assembly 3.3 Software j
3.3.1 Software Development 3.3.2 Software Implementation
TABLE OF CONTENTS (cont) 4.0 EQUIPMENT QUALIFICATION 4.1 Equipment Qualification Background 4.2 Equipment Qualification Program Description 4.2.1 Environmental Testing 4.2.2 Seismic Testing 4.3 Equipment Qualification Documentation 5.0 NOISE, FAULT, SURGE WITHSTAND CAPABILITY, AND RADIO FREQUENCY INTERFERENCE (RFI) TESTS l
5.1 Test Description 5.1.1 Noise Tests 5.1.2 Fault Tests j
5.1.3 Surge Withstand Capability (SWC) Tests 5.1.4 Radio Frequency Interference (RFI) Tests 5.2 Test Documentation 6.0 DESIGN, VERIFICATION AND VALIDATION PLAN
6.1 Background
6.2 Applicable Standards 7.0 COMPLIANCE WITH CRITERIA 7.1 IEEE Std. 279-1971 APPENDIX A
" Eagle 21 Replacement Hardware Design, Verification and Validation Plan"
LIST OF FIGURES Fiaure Title 1-1 Eagle-21 Implementation 21 Eagle-21 Design Philosophy 22 Typical Analog Process Protection Channel 2-3 Eagle 21 Existing Cabinet Installation 31 Eagle-21 Subsystems 32 Eagle-21 Input / output subsystem 3-3 Eagle-21 Loop Processor Subsystem 3-4 Eagle 21 Tester Subsystem 3-5 Eagle-21 Architecture i
3-6 Analog Input functional Configuration j
3-7 Contact input Functional Configuration 38 Analog Output Functional Configuration 3-9 Contact Output Functional Configuration j
1 3-10 Partial Trip Output Functional Configuration 3-11 Eagle-21 Software Development-3-12 Eagle-21 Layered Software Approach j
l I
i i
ARSTRACT l
l Process Instrumentation is comprised of those devices (and their interconnection into systems) which measure and process signals for temperature, pressure, fluid flow, and fluid levels.
Process instrumentation specifically excludes nuclear and radiation measurements.
Process Instrumentation includes equipment which performs functions such as:
process measurement, signal conditioning, dynamic compensation, calculations, i
l setpoint comparison, alarm actuation, indication and recording, which are all necessary for day-to day operation of the Nuclear Steam Supply System as well as for monitoring the plant and providing initiation of protective functions l
upon approach to unsafe plant conditions. The Westinghouse Eagle-21 microprocessor based process protection upgrade system is applicable for those l
instrument systems which are ' safety-related" as defined by IEEE Std. 279-1971,
' Criteria for Protection Systems for Nuclear Power Generating Stations". The Eagle 21 portion of process instrumentation includes all necessary devices with the exception of transmitters, indicators, and recorders.
The Westinghouse Eagle 21 microprocessor-based process protection system is a functional replacement for existing analog process protection equipment used to monitor process parameters at nuclear generating stations and initiate actuation of the reactor trip and engineering safeguards systems.
4 r--.
,, - +
1.0 INTRODUCTION
The majority of nuclear power generation statier.s 9resently employ analog I
process protection equipment. This equipment was designed in the 1960's and early 1970's. As illustra,ted in Figure 1-1, the analog protection system receives inputs from sensors, provides information to the operator, performs calculations on these values, and compares the results to allowable limits.
If the limits are exceeded, a partial reactor trip is generated.
External logic performs a voting algorithm on the partial trips from the four redundant protection sets, and conditionally generates a reactor trip. A similar path exists for the generation of engineered safeguard system actuations. These actuations mitigate the effects of an endesired event. The process protection system also provides isolated signals for use by non safety systems such as the control system, the plant computer, and portions of the control board.
Westinghouse Process Protection Systems include three generations of analog electronics:
Foxboro H Line, Westinghouse 7100 Series, and Westinghouse 7300 Series Equipment.
The first generation of analog process protection equipment was Foxboro H Line l
l which is described in WCAP 7671 " Topical Report Process Instrumentation for Westinghouse Nuclear Steam Supply Systems." This equipment was manufactured i
for use during the 1965 - 1972 time frame. Twenty-five nuclear generating stations utilize this equipment.
The second generation of analog process protection equipment was the Westinghouse 7100 Series, also described in WCAP 7671. This equipment was manufactured for use during the 1970 - 1973 time frame. Thirteen nuclear generating stations utilize this equipment.
The third generation of analog process protection equipment was the Westinghouse 7300 Series, described in WCAP 7913 " Process Instrumentation for Westinghouse Nuclear Steam Supply Systems (4 Loop Plants Using MCID 7300 Series Process Instrumentation). This equipment was manufactured for use during the 1973 - 1983 time frame.
Forty-four nuclear generating stations utilize this equipment.
Page 1
l As a result of tCchnological advances, the earlier analog process protection systems are rapidly approaching the point of obsolescence. Additionally, utility personnel have identified the following difficulties ~with the analog systens:
i A.
Time consuming calibration and surveillance test procedures.
8.
Extensive maintenance time for troubleshooting and repair.
C.
Difficulty in maintaining equipment qualification.
D.
Difficulty in maintaining adequate spare parts inventory.
E.
Lack of expansion space to install hardware for functional upgrades and plant _ improvements.
The Westinghouse Eagle 21 Process Protection System is a modular microprocessor based upgrade system for rep 1. acing the existing analog process protection equipment. Features of the Eagle-21 equipment include the following:
A.
Automatic surveillance testing to significantly reduce the time required to perform surveillance tests.
l B.
Self calibration to eliminate rack drift and time consuming calibration procedures.
C.
Self diagnostics to reduce the time required for troubleshooting.
D.
Significant expansion capability to easily accommodate functional upgrades and plant improvements.
I j
E.
Modular design to allow for a phased installation into existing process racks and use of existing field terminations.
i i
Page 2-
2.0 DESIGN PHILOSOPHY AND FEATURES The Eagle 21 Process Protection System, as shown in Figure 2-1, is a digital form, fit, and functional replacement for the existing analog equipment. All system inputs (from plant, sensors) and system outputs (reactor trip logic, engineered safety features logic, indication and control) are preserved. -Thus, the installation of Eagle-21 process equipment has no affect on the existing external interfaces.
2.1.1 Typical Analog Process Channel A typical analog process protection instrument channel is shown in Figure 2-2.
A field sensor is connected to cabinet mounted terminal blocks. The process electronics power the field sensor and perform signal conditioning, calculation, trip logic, and isolation operations on the input signal.
Each element of the process is an individual electronic module or printed circuit board assembly. Typical functions performed by these modules are as follows:-
loop power supply, summation, lead / lag, multiplication, comparator, square root, amplification, signal conversion, and isolation.
2.1.2 Typical Eagle-21 Process Channel In a typical Eagle-21 Process Protection Instrument Channel, field sensors are connected to cabinet mounted terminal blocks. The process electronics power the sensors and perform signal conditioning, calculation, and isolation operations on the input signals. However, each element of the process is not an individual electronic module or printed circuit board assembly. A multiple channel Analog Input module is used to power the field sensor (s) and perform signal conditioning.
All calculations for the process channel functions are performed by a centralized Loop Calculation Processor (LCP). Typical functions performed by the Loop Calculation Processor are as follows:
summation, lead / lag, multiplication, comparator, averaging, and square root conversion.
Trip logic is provided through multiple channel Partial Trip Output modules.
Multiple channel isolated analog outputs are provided by Analog Output modules.
In addition, all Eagle-21 process protection channels are configured to perform automatic surveillance testing via a centralized Test Sequence Processor (TSP).
Page 3
Typical protection channels which may be processed with the Eagle-21 Process Protection System are as follows:
A.
Average Temperature and Delta Temperature B.
Pressurizer Pressure C.
Pressurizer Water Level 0.
Steam Flow and Feedwater Flow E.
Reactor Coolant Flow F.
Turbine Impulse Chamber Pressure G.
Steam Pressure H.
Containment Pressure 1.
Reactor Coolant Wide Range Temperatures J.
Reactor Coolant Wide Range Pressure K.
Boric Acid Tank Level I
L.
Pressurizer Liquid and Vapor Temperatures M.
Steam Generator Narrow Range and Wide Range Water Level 2.2 INSTALLATION The Eagle-21 Process Protection System is a modular electronics upgrade package for the existing analog plant process protection equipment. The Eagle-21 equipment has been designed to fit into existing process racks and to interface with other plant systems in a manner identical to the existing analog equipment. The design maintains the existing field terminals to avoid new cable pulls or splices within the rack. The components for each rack are built into subassemblies which can be easily installed into the existing racks. All internal rack cabling is pre-fabricated. The subassemblies are tested in a factory mock-up to verify proper fit and operation. Detailed installation procedures and~ drawings are provided with each system.
An example of Eagle-21 hardware being installed into an existing process rack is depicted in Figure 2-3.
)
Page #
u
2.3 System Design Features l
i 2.3.1 Single Failure Criterion
{
4 The Eagle 21 Process Protection System is designed to provide three or four instrumentation channels and outputs to two trip logic trains for each protective function. These redundant channels and trains are electrically isolated and physically separated. Thus, any single failure within a channel or train will not prevent a required protective system action.
2.3.2 Instrument Power Source Electrical power for the Eagle-21 Process Protection System instrumentation is obtained from four separate instrument busses that are equal to each other in reliability and quality of the power available. The arrangement of the four busses with respect to the ultimate power source is covered in detail in the FSAR for each plant. The use and availability of the four busses is important to the plant instrumentation in the following ways:
A.
Each of the four protection sets is assigned to one of the instrument ~
busses and no other.
B.
Instrument channels are arranged so that loss of any one bus will not force a trip of the reactor. However, all reactor trip bistables and most of the safeguards bistables will trip in that protection set.
(e.g. all 2 out of 3 reactor trip logic will revert immediately to a condition of I out of 2 logic.)
C.
Loss of any one bus will not put the plant in an unprotected condition.
D.
Coincident loss of any two busses will trip the reactor insiediately as-a result of the preferred failure mode of the bistables and initiate most safeguards action associated with those protection sets (e.g. two of the logic inputs for each associated 2 out of 3 or 2 out of 4 logic will immediately exist as trip signals).
Page 5 J
l 2.3.3 Channel Integrity The Eagle-21 Process Protection System has been designed to operate and maintain necessary functional capability under extremes of conditions relating to environment, energy supply, malfunctions and accidents. The environmental and energy supply extremes throughout which the system will perform are detailed in Sections 4.0 and 5.0, t.3.4 Channel Independence Within the Eagle-21 Process Protection System, there are four separate and independent rack sets. Channels which provide signals for the same protective functions are each located in different rack sets ensuring that they will be independent and physically separated. Since all equipment within any rack-is associated with a single Protection Channel Set (PCS), there is no requirement for separation of wiring and components within the rack.
2.3.5 Control and Protection System Interaction The Eagle-21 Process Protection System functions completely independent from the control systems.
Its' operation in protecting the plant from unsafe conditions is not affected by any fault or malfunction in the control systems.
i The transmission of signals from the Eagle-21 Process Protection System to the control systems is through isolatinn devices that are classified as part of the protection system. No credible fault at the output of an isolation device can prevent the associated Eagle-21 Protection System channel from meeting the minimum performance requirements specified in the design bases.
Fault testing of the isolation devices is described in more detail in Section 5.0 of this document.
The same type of 41ectrical isolation is also used to separate from the Eagle-21 Protect ton System, those signals (such as RCS average temperature),
which are requi"ed and used to control actual plant variables.
For this use, however, consioeration must be given to possible protection channel failures that can both prevent a particular trip signal from that channel and cause the Page 6
control system to drive the plant toward the unsafe condition ~ for which the particular trip signal is needed.
In each case where this is possible, either four protection channels have been provided and 2 out of 4 logic is used to ensure the plant remains fully protected even when degraded by a second random failure, or a diverse means for providing a reactor trip is available.
2.3.6 Automatic Surveillance Testing The Eagle-21 Process Protection System performs automatic surveillance-testing of the digital process protection racks via a portable Man Machine Interface (MMI) test cart. The MI test cart is connected to the process rack by inserting a connector into the process rack test panel. Using the MMI, the
" Surveillance Test" option is then selected.
Following instructions entered l
through the MMI, the rack test processor automatically performs the following l
operations:
l 1.
Selection of the individual process channel to be tested.
2.
Calibration of the test reference signals and verification of the tester time base.
3.
Placement of the individual channel trip outputs in either " Channel i
Trip" or " Bypass" (password protected) mode.
A.
Bypass Mode -- disables the individual channel. bistable trip circuitry which forces the associated logic input relays to remain in the non-tripped state until the " bypass" is removed.
B.
Channel Trip Mode -- Interrupts the individual channel bistable outputs to the logic circuitry to de-energize the associated logic l
input relay (s).
4.
Activation of the test injection signal, 5.
Performance of Analog to Digital (A/D) converter test, and engineering unit values conversion test.
Page 7
6.
Performance of bistable setpoint tests.
7.
Performance of channel time response test.
8.
Completion of test cycle and automatically remove " Channel Trips".
9.
Verify calibration of the test injection signals.
- 10. Display of test results on the teil screen.
Interruption of the bistable output to the logic circuitry for any reason-(test, maintenance purposes, or removed from service) causes that portion of I
the logic to be actuated and accompanied by a channel trip alarm and channel status light in the control room.
Status lights on the process rack test panel indicate when the associated bistables have tripped.
Each channel is fully testable via the portable MMI test cart.
2.3.7 Calibration i
The Eagle 21 Process Protection System provides for continuous on-line self-calibration of analog input signals. The Digital Filter Processor (DFP) addresses high and low reference signals via a multiplexer circuit on each analog input channel. The Loop Calculation Processor (LCP) then compares the output of the DFP Analog to Digital (A/D) Converters to stored high and low reference values to determine if any errors have been introduced by analog signal processing and A/D conversion.
If necessary, the LCP automatically compensates gain and offset coefficients to eliminate any errors that have been introduced.
2.3.8 Channel Bypass The Eagle-21 Process Protection equipment is designed to permit any one channel to be maintained, and when required, tested during power operation i
Page 8 l
without initiating a protective action at the systems level. During such operation, the process protection system continues to satisfy single failure criterion.
If an Eagle 21 protection channel has been bypassed for any purpose, a signal is provided to allow this condition to be continuously indicated in the control room.
a,(
l The material in this section has been deleted from this nonproprietary document due to its proprietary nature. The material in this section discussed channel bypass capability.
l
~
l
~-
Additionally, it is not possible to disconnect the feil test cart from an l
Eagle 21 protection rack and leave a channel in " bypass" (see Section 3.2.5).
2.3.9 Access to Setpoint Adjustments The Eagle-21 design has provided for administrative controls and multiple levels of security for access to setpoint and tuning constant adjustments.
In order tn adjust a setpoint or tuning constant in the Eagle-21-system, an individual must have access to the following:
a,c Page 9
i a,c i
The material in this section has been deleted from this nonproprietary document due to its proprietary nature. The material in this section=
' discussed access to setpoint adjustments.
t 2.3.10 Diagnostics The Eagle-21 Process Protection equipment provides specific diagnostic infomation to the user via numerous printed circuit card and test panel status LEDs, as well as information available through the portable Man-Machine Interface (Pet!). This design feature allows for easy recognition, location, replacement, and repair or adjustment of malfunctioning components or modules.
Page 10
4 3.0 TECHNICAL DESCRIPTION i
3.1 Eagle-21 Architecture The Eagle 21 Process Protection System replaces existing analog process protection equipment with multiple microprocessor based subsystems. Typically for each Eagle-21 protection system, three subsystems are used:
a Loop Processor Subsystem, a Tester Subsystem, and an Input / Output Subsystem (see Figure 3-1). An_ overall view of the Eagle-21 architecture is shown on Figure 3 5.
3.1.1 Input / Output (1/0) Subsystem The input portion of the I/O subsystem (see Figure 3-2) consists of customized Analog Input and Contact Input signal conditioning modules specially designed-for use in Process Protection Systems of nuclear generating stations. These modules satisfy all of the unique signal conditioning, signal conversion, isolation, buffering, termination and testability requirements.
The signal conditioning modules are configurable to accept various process inputs including:
10-50 mA current loop (active or passive), 4-20 mA current loop (active or passive), 0-10 vde, RTD's and field contacts. Both the Analog Input and Contact Input Modules provide. signals to the Loop Processor Subsystem. These modules also interface with the-Tester Subsystem for test and t
diagnostic purposes.
The output portion of the I/O subsystem consists of Analog Output, Contact Output and Partial Trip Output modules. These modules receive data from the Loop Processor Subsystem and construct analog, contact, and trip logic output signals. Class 1E isolation is provided for all analog and contact output signals.
To minimize the total installation effort for the Eagle-21 equipment, the existing input / output interfaces are fully emulated.
In plants with more advanced control or display equipment, Class 1E isolated data links may be extended directly to those systems, thereby eliminating the analog hardware at both ends.
Page 11
3.1.2 Loop Processor Subsystem The Loop Processor Subsystem is that portion of the Eagle-21 system which A
computes all of the algorithms and comparisons for the protective functions.
Loop Processor Subsystem (see Figure 3-3) consists of a Digital Filter Processor (DFP), Loop calculation Processor (LCP), Communication Controller, Digital 1/0 Module, and a Digital to Analog (D/A) converter.
The Digital Filter Processor receives analog siCnals from Analog Input Modules and performs both Analog to Digital (A/D) conversions and anti-aliasing filtering operations on the input signals. The outputs of the Digital Filter Processor are then passed on the Loop Calculation Processor.
The Loop Calculation Processor performs calculations for protection channel functions, data comparison to setpoint values, and initiation of trip signals based on the data received from the Digital Filter Processor.
The Communication Controller collects information from the Loop Calculation
~
Processor and transmits it to the Tester Subsystem.
The Digital I/O module is utilized to process contact inputs, contact outputs, and trip logic output signals.
The D/A converter module is utilized to convert digital values from the Loop Calculation Processor into analog values which are sent to analog output modules for further processing.
3.1.3 Tester Subsystem The Tester Subsystem is the focal point of human interaction with the protection system. Together with the Man-Machine-Interface (MMI) Test Cart it provides the interface which allows test personnel to adjust setpoints and tuning constants, and to perform surveillance tests on the protection system.
A Tester Subsystem (see Figure 3-4) consists of a Test' Sequence Processor (TSP), Communication Controller, Digital to Analog (D/A) Converter Module, and a Digital I/O Module.
Page 12 I
The Test Sequencer Processor (TSP) reads information from the Communication Controller Digital I/0 Module, and the MI Test Cart. This infomation allows the TSP to monitor the overall status of the Eagle 21 protection rack, perform self diagnostics, and initiate surveillance testing. The TSP provides information to the Communication Controller, Digital I/O Module, D/A Converter, and El Test Cart. This infomation provides for status indication and creation of the Signal. Injection and Response (SIR) bus. This bus is distributed through the signal conditioning modules and allows the Tester Subsystem to control and test each module.
The Connunication Controller receives infomation from the Loop Processor Subsystem Communication Controller. This information is then read by the TSP which allows it to monitor the status of the LCP. The Tester Subsystem Communication Controller also provides a serial. link to the Test Panel, which allows for information display and printing when connected to the MI Test Cart.
l The D/A Converter Module receives digital information from the TSP and converts it into high resolution analog signals that are used for test injection via the Signal Injection and Response (SIR) bus.
The Digital I/O module receives information from the TSP and provides signals j
to a Contact Output Module that provides contacts for field devices.
3.1.3.1 Man Machine-Interface (MI)
A portable test cart is connected to the Eagle-21 rack mounted test panel to provide the Man-Machine-Interface (MI) to the Protection System. The.m!
permits the user to perform the following functions:
[
Ja,c Page 13 s,._.
a,c -
The material in this section has been deleted from this nonproprietary document due to its proprietary nature. The material in this section discussed Man-Machine Interface design.
a 3.2 Eagle-21 Hardware Description The Eagle-21 Process Protection System is comprised of a number of hardware modules and sub-assemblies which are described in this section.
3.2.1 Analog Input Module The analog input module provides the interface between process transmitters, RTD's and the Eagle-21 computer hardware. Each analog input module provides the capability to interface with a maximum of four inputs. Analog. input modules are capable of interfacing with both 4-20 mA and 10-50 mA current loops, o to 10 VDC signals, and four-wire RTD inputs.
j l
l The 4-20 mA and 10-50 mA current loops are arranged as two-wire current loops with the transmitter power supplied from the analog input module. Separate-current loop power supplies and separate signal conditioning circuitry are provided for each tremotter.
The 0-10 vde inputs are arranged as two-wire double-ended input signals.
q Separate signal conditioning circuitry is provided for each input signal.
Page 14
=
L The RTD inputs are arranged to' accept a four-wire input configuration. The RTD excitation current source is supplied from the analog input module.
Separate current sources and separate signal conditioning circuits are provided for each RTD input.
Included on the analog input module are provisions for automatic testing and automatic calibration. The automatic testing is accomplished via the Tester Subsystem. The analog input module communicates serially with the Test Sequence Processor (TSP) over the Signal Injection and Response (SIR) Bus.
Test commands are transmitted to the input module which allows a selected analog input channel to switch from the field sensor to one of the inultiple analog reference signals controlled by the TSP and carried by the SIR Bus.
During surveillance test, the test injection signal is varied with respect to amplitude and frequency to verify proper channel operation.
On-line calibration is controlled continuously by the Digital Filter Processor (DFP) to eliminate potential gain and offset drift in the analog hardware of the input module and the analog-to-digital (A/D) converter located on the DFP.
During a calibration cycle, the DFP sends a command to the analog input module to switch from the field sensor to either the high or low on-board precision reference.
The values that the DFP receives for the calibration references are used by the Loop Calculation Processor (LCP) to calculate a correction' factor that is applied to the input signal.
Referring to Figure 3-6, the analog input module provides, the following features for each input signal:
a,c Page 15
4,c 1
The material in this section has been deleted from this nonproprietary document due to its proprietary nature. The material in this section discussed Analog Input Module design.
s l
l l
3.2.2 Contact Input Module The contact input module provides the interface between field contact devices and the Eagle-21 computer hardware. Each contact input module is capable of processing either four complementary contact pairs, or eight independent contacts. The output signals from the contact input modu's are read directly by the Loop Cal.culation Processor through digital I/O ports.
Referring to Figure 3-7, the contact input module provides the following features for each contact input:
Page 16 4
,-v e -,
,n-,,
,a
~
u s
a,c The material in this section has been deleted from this nonproprietary document due to its proprietary nature. The material in this section discussed Contact Input Module design.
l r
3.2.3 Analog Otput Module The analog output module (Figure 3-8) provides an interface between the Eagle-21 computer hardware and field devices.
Page 17
WESTINGHOUSE CLASS 3 a,C The material in this section has been deleted from this nonproprietary document due to its proprietary nature.
The material in this section discussed Analog Output Module design.
i 3.2.4 Contact Output Module j
I The contact output module (Figure 3 9) provides the interface between field devices operated by contact logic and the Eagle-21 computer hardware.
Each contact output module is capable of providing up to eight complementary contact pairs for output purposes. The Loop Calculation and Test Sequence Processors-l control the relay status / contact logic through Digital I/O cards connected to the IEEE Std. 796 bus.
The contact output module provides the following features for each output:
a,c--
The material in this section has been deleted from this nonproprietary document due to its proprietary nature.
The material in this section i
discussed Contact Output Module design.
m I
Page 18 i
[
ja,c 3.2.5 Partial Trip Output Module
. The partial trip output module (Figure 3-10) provides the interface between the Eagle-21 computer hardware and the trip logic system.
Each partial trip module is capable of providing up to four channels of logic outputs. The trip output module converts a signal from the Loop Processor Subsystem Digital Input / Output module into_ an On/Off voltage used to drive relays in the trip logic system.
Additional features of the partial trip output module are:
4 a,c The material in this section has been deleted from this nonproprietary document due to its proprietary nature.
The material in this section discussed Partial Trip Output Module design.
4 Page 19
a,c 3.2.6.3
[
),c
\\
l a,c 3.2.6.4 [
Ja,c i
a,c
-i Page 21 i
8
f 3.2.6.5
[
3a,c a,C b
(
L
~
3.2.6.6
['
ja.c a,C 3.2.7 Miscellaneous Hardware 3.2.7.1 Microprocessor Card Chassis a,c The material in this section has been deleted from this nonproprietary document due to its proprietary nature. The material in this section discussed the Microprocessor Card Chassis design.
Page 22
3.2.7.2 DC Power Supply Chassis a,c The material in this section has been deleted from this nonproprietary document due to its proprietary nature. The material in this section discussed the DC Power Supply Chassis design,
\\
\\
l 3.2.7.3 Test Panel a,c j
4 7
-The material in this section hks been deleted. from this nonproprietary document due to its proprietary nature. The material in this section i
discussed the Test Panel design.
i Page 23
a,c 3.2.7.4 Termination Frame The Eagle-21 Termination Frames are modular assemblies which accommodate a -
single Input / output printed circuit board. The Termination Frame serves to stiffen the Input / output board against seismic input and provides terminals for power and signal connections. Each Eagle-21 process protection rack will contain sixteen termination frames, installed one above the other in a structure known as the termination framework.
3.2.7.5 Cabinet Cooling Assembly a,c The material in this section has been deleted from this nonproprietary j
document due to its proprietary nature. The material in this section.
l discussed the cabinet cooling assembl9 design.
1 l
1.
l t
Page 24
3.3 Software 3.3.1 Software Development a, c __
The material in this section has been deleted from this nonproprietary document due to its proprietary nature. The material in this section discussed Software Development.
l 4
i 4
il i
Page 25 1
a,c T
D l
3.3.2 Software Implementation a,c.
The material in this section has been deleted from this nonproprietary document due to its proprietary nature. The material in this section discussed Software Implementation.
Page 26
_,.K
. j : y,,(, -J
~
'54{..e.
4--
.i'-t.
1 y
t z
y,g +;,
' V E
h#<,, f
?
Q um
~
s y
. +
, s e
p f ': n*
-A 1,
i y,
.c
~~,
2
,.. -. -a Y'
t
/
3 E ',( a q
^
+
w; 4
j.
9
,+.
i
,,.. :.,,,.s a,,
c'
+,i
{Y 4
{c e-
.:s,.
-1
^
v : n_1u i
!. I. "
-_[-.3.,-
?
vf' g. --
'r..
f t
l
-3 4
l g
'p y'
L
}r
,,,.-_-}5 2F.
.~.y>
j 4
[ -
.q.
g 5--
1
-o' 9
4
?
s f
.-5 u
~ -.
v m.. -
.m av r
E I
4
.'t'.
I V
+
,P'l 4
3 i
j
+
oi,-
m
=,
1
- f_{.
..h,.,.,,-
j
(
- '7,+:
.A
)
L xk' j.-
2
. (
3-
?
ir t. p 3
A t
+
h
,,el' p
'l
['
f t
f I
(
.E 1
Jr i
1-
,k 2mn-1 c
3 i
i
\\
-,- F,7;.
,4M
~
)
E S
4 2
+..
.,.%..,.m
.j-+
x i'
i.-
l 'l c-6 i:
ar..
r---..
=
g y. t
{
ma r
m
,, D:
eJ r
, +
1.,
t A
4%
s.
T 1
T 1
N J.+.~'
['_-
1-;
c.
n,
,_q,
~ <
t
^
+
1 f
e-1, i
-.y
--(--
s,.x,s,.
-5,.1.
a b.~%
q' b
~
+
3,
}
j. '{ *r Yh-
- i$
.w
t, {
t :a
'1 4
l L
b t
_ t-
,-.A.
u c.q..
r a.
J
- 3) :
Pa'ge 27 y
s
~
m
- j. '7 4
1 s,
i t
[ b\\
)
'. ; j :, )
k L
b
}
3 g
-_')'.
y
, g
{
4.0 EQUIPMENT QUALIFICATION 4.1 Equipment Qualification Background in November of 1974, the NRC issued Regulatory Guide 1.89, " Qualification of Class IE Equipment for Nuclear Power Plants' which endorsed IEEE Std. 323-1974,
'IEEE Standard for Qualifying Class IE Equipment for Nuclear Power Generating Stations" and in March of 1976 the NRC issued Regulatory, Guide 1.100, " Seismic Qualification of Electrical Equipment for Nuclear Power Plants" which endorsed 7
IEEE Std. 344-1975, "!EEE Recommended Practices for Seismic Qualification of Class IE Equipment for Nuclear Power Generating Stations."
Westinghouse recognized that NRC approval of testing methodology and parameters prior to performance of the test is desirable to avoid ratesting. Therefcre, the initial strategy with the IEEE Std. 323-1974 Qualification Program was to obtain NRC approval prior to implementation of the Qualification program. To accomplish this, in October 1975, Westinghouse issued WCAP-8587, Revision 0,
' Methodology for Qualifying Westinghouse WRD-Supplied NSSS Safety-Related Electrical Equipment" and in May 1980, Westinghouse issued WCAP-9714,
" Methodology for the Seismic Qualification of Westinghouse WRD Supplied Equipment." Meetings were held with the NRC staff to discuss qualification methods. Based on this interaction and state-of-art methodology, revisions were made to WCAP-8587. As a result, WCAP-8587, Revision 6 and WCAP 9714 were accepted by the NRC staff in a letter from Cecil 0. Thomas, Chief, Standardization and Special Projects Branch, Division of Licensing, to E. P.
Rahe, Jr., Manager, Nuclear Safety Department, Westinghouse Electric Corporation, dated November 10, 1983.
4.2 Equipment Qualification Program Description The Equipment Qualification Program demonstrated that the Eagle-21 Process Protection Equipment is capable of performing its designated safety related functions under all specified environmental and seismic conditions. This was accomplished by testing as follows:
Page 28
4.2.1 Environmental Testing (IEEE Std. 323-1974)
The Eagle-21 equipment was tested under both ' normal' and " abnormal' environmental conditions.
a,c The material in'this section has been deleted from this nonproprietary document due to its proprietary nature. The material in this section I
discussed Environmental Test Parameters.
i j
4.2.2 Seismic Testing (IEEE Std. 344-1975)
The Eagle-21 equipment was subjected to multi-axis, multi-frequency inputs in accordance with Regulatory Guide 1.100. The equipment was-subjected to both Operation Basis Earthquake (OBE) and Safe Shutdow-thquake(SSE) events.
4.3 Equipment Qualification Documentation The overall equipment qualification documentation plan consists of three sets of documents:
1.
WCAP-8587 ' Methodology for Qualifying Westinghouse WRD Supplied NSSS Safety Related Electrical Equipment" which is a Westinghouse Class 3 (Non-Proprietary) report and represents the generic program parent document and describes the basis methodology for the Westinghouse equipment qualification program.
Page 29 i
2.
WCAP-8587, Supplement 1, EQDP-ESE-69A ' Equipment Qualification Data j
Package" is a Westinghouse Class 3 (Non-Proprietary) report which presents a summary of the Eagle-21 test parameters, performance i
specifications, acceptance criteria, and test results.
3.
WCAP-8687, Supplement 2-E69A
- Equipment Qualification Test Report,' is
. i a Westinghouse Class 2 (Proprietary) report and presents a detailed l
description of the Eagle-21 test parameters. -perfomance specifications, acceptance criteria, and test results.
L r
+
[
l l
l l
i.
i.
l t
l l
l 3
Page 30 x
m
_.~,.
.,m,.
..m
-m
5.0 N0!$E, FAULT, SURGE WITH$TAND CAPABILITY, AND RADIO FREQUENCY INTERFERENCE TESTS 5.1 Test Description The Noise, Fault, surge Withstand Capability, and Radio Frequency Interference (RFI) tests demonstrated that the Eagle 21 process protection equipment is capable of performing its designated safety-related functions when subjected to these specified conditions. This testing was accomplished as follows:
5.1.1 Noise Tests The Eagle-21 equipment was subjected to four types of noise testing:
a,c 1
The material in this section has been deleted from this nonproprietary document due to its proprietary nature. The material in this section discussed Noise Test Parameters.
9 l
l Page 31
- n.
a,c _
i I
i l
5.1.2 Fault Tests The Eagle-21 process Equipment was subjected to following fault voltages:
)
i a,c The material in this section has been deleted from this nonproprietary document due to its proprietary nature. The material in this section
]
discussed Fault Test Parameters.
5.1.3 Surge Wit'hstand Capability (SWC) Tests (IEEE Std 472-1974) i The Eagle-21 process equipment was subjected to the following surge signals:
1 a,e _
a The materini in this section has been deleted from this nonproprietary document due to its proprietary nature. The material in this section i
discussed Surge Withstand Capability Test Parameters.
5.1.4 Radio Frequency Interference (RFI) Tests 4
4 i
ja c t
Page 32 t
502 Test Documentation The Eagle 21 Noise, Fault, surge and Radio Frequency Interference (RFI) tests and results are documented in EAP-ll733 (Proprietary) and EAP-11896 (Non-Proprietary).
P i
Page 33 l
6.0 DESIGN, VERIFICATION ANO VALIDATION PLAN
6.1 Background
Westinghouse introduced th'e concept of microprocessor based Protection Systems in the early Ig70's on the Integrated Protection System (IPS) which tras part of the RESAR 414 standard plant design. The software verification program conducted on this prototype is documented in WCAP g153 '414 Integrated Protection System Prototype Verification Program', and WCAP-g73g ' Summary of Westinghouse Integrated Protection System Verification and Validation Program".
Building upon the experience gained in performing software Verification and Validation on the IPS prototype and implementing the " lessons learned" from the Nuclear Regulatory Commission (NRC) audit process, a much improved V1V program was defined for the South Texas Qualified Display ProcessingSystem(QDPS).
In July 1987 the NRC issued a favorable Safety Evaluation Report (NUREG 0781, Supplement No.4) " Safety Evaluation Report related to the operation of South Texas Project Units 1 and 2.
In September of 1986, Tennessee Valley Authority purchased Eagle 21 Protection System Replacement Hardware for Watts Bar Units 1 and 2.
The Eagle-21 V&V process is the same as the one conducted on the South Texas QDPS, modified only to the extent of refining the process based on previous experience and resolution of NRC audit comments.
Page 34
The NRC final audit of the Eagle.21 equipment for Watts Bar cas conducted at the Westinghouse Instrumentation Technology and Training Center in April, 1989. The NRC Safety Evaluation Report on the Eagle 21 systen utilization for Watts Bar was transmitted June 13, 1989 from Suzanne Black, Assistant Director for Projects. TVA Projects Division, Office of Nuclear Reactor Regulation, to Mr. Oliver D. Kingsley, Senior Vice President, Nuclear Power, Tennessee Valley Authority. This report was subattted on Docket Numbers 50-390 and 50-391 for Watts Bar Units 1 and 2 respectively.
The Eagle 21 Design, Verification and Validation Plan is attached as
' Appendix A* to this report.
6.2 Applicable Standards The standards which are applicable to the Eagle-21 Design, Verification and Validation Plan are listed below:
A.
- IEEE STANDARD CRITERIA FOR SAFETY SYSTEMS FOR NUCLEAR POWER GENERATINGSTATl0NS" 8.
REGULATORY GUIDE 1.153, December, 1985
- CRITERIA FOR POWER, INSTRUNENTATION, AND CONTROL PORTIONS OF SAFETY SYSTEMS"
- Regulatory Guide 1.153 endorses the guidance IEEE Std. 603-1980.
Page 35 4
C.
ANSI /IEEE ANS 7-4.3.2 1982 l
i
'APPLICAT!0N CRITERIA FOR PROGRAW M8LE DIGITAL COMPUTER SYSTEMS IN l
i SAFETY SYSTEMS OF NUCLEAR POWER GENERATING STATIONS' I
-ANS!/IEEE-ANS-7-4.3.2 1982 expands and amplifies the requirements IEEE Std. 603 1980.
l l
t l
D.
REGULATORY GUIDE 1.152, November 1985 1
'CRITERI A FOR PROGRAPMABLE DIGITAL COMPUTER SYSTEM SOFTWARE IN j
l SAFETY-RELATED SYSTEMS IN. NUCLEAR. PLANTS
- j
- Regulatory Guide 1.152 endorses the guidance of ANSI /IEEE-ANSI-7-4.3.2 l
l l
l l
Page 36
,_.._,_,,,,,__y.._.__.
7.0 COMPLIANCE WITH CRITERIA 7.1 IEEE Std. 279-1971
' Criteria for Protection Systems for Nuclear Power Generating Stations.
Some of the information in this report demonstrates the means with which the Eagle-21 Process Protection Equipment satisifies the applicable requirements detailed in Section 4 of the above criteria. References are provided as follows:
Ranuirement.4.1 ' General. Functional Requirement" This report in general describes the Eagle 21 process equipment and its performance requirements.
Raouirement 4.2 " Single Failure criterion" See Section 2.3.1 Reauirement 4.4
- Equipment Qualification" See Section 4.0 Reauirement 4.5 ' Channel Integrity' See Sections 2.3.3, 4.2 and 5.0 Reauirement 4.6 ' Channel Independence" See Section 2.3.4 Reauirement 4.7
- Control and Protection System Interaction' See Section 2.3.5 Page 37
- l Renuirement 4.9 ' Capability for Sensor Checks'
)
)
See Section 2.3.6 l
Renuirement 4.10 ' Capability for Test and Calibration *
\\
See Sections 2.3.6 and 2.3.7 Renuirement 4.11 Channel Bypass or Removal from Operation" See Section 2.3.8 1
Raouirement 4.13 ' Indication of Bypasses" See Section 2.3.8 i
Reauirement 4.14 ' Access to Means for Bypasses' i
See Section 2.3.8 Renuirement 4.18 " Access to Set Point Adjustments, Calibration, and Test Points" See Sections 2.3.7, 2.3.8, and 3.2.7.3 Reauirement 4.21
" System Repair" See Section 2.3.10 Page 38
EAGLE-21 w
IMPLEMENTATION
" et**"/
sw
\\e
/
t
\\
/
8"eiL*"' /
\\
t
/
gllll;:nF ag=lrr
/
/
\\
c=a-
\\
/
=,,
N c-a-s -
m,
- 11 11t' '
=/// '/
M* /
/ r#' t ll::;.
f w/
~~.
~
w
=///'t.
/
a
/
.n a
I
.n r=* ^*8 f/(
/
/
W'/
/
8
}
1/
n a
v 2
e,,, f
( :4g7
/ + (
/7-
_f j
~~
r/
t z
t.e r
- _/
/
/
- _/
Typices eac system seock osegram 1970 D20241ANCODf
- - - ~ - - - - - - -
EAGLE-21 Y
DESIGN PHILOSOPHY e Form, fit and function replacement 4 sTermenes Analog System = Digital System Power Supply Aeso Sensors I
Teeeer r PAR 4S leolators
.=
e
=.
Control Sensors Bistable
+
Lead / Leg P
EW E8F 3
r bMw Trip Reactor Trip soro osomes.com FIGURE 2-1 g
e
.m__
lu II h
EAGLE-21 W
Typical Analog Process Protection Channel 118VAC 118VAC 4
I Power Lead Supply Lag
{
118VAC 00 I
OO Te 7 '
3,','
s' Yen 00
=
os
= emi.e= -
00
=
=
son.or 00, 00 118VAC g
I 00 eo
.=
=
Control Systens Cabinet Boundary
\\
{
l-
\\
@ r saastDE #
I j
\\
p Ped 8F M 4
t 7#
i I
1 I
dP 1
e hrness
\\
i
'\\
taisting takinet lasta11ation of Eagle 31 Equipment FIGURE 2-3
EAGLE-21 SUBSYSTEMS Immt/ Output Subsystem S
Analog card cage h
input I
LOOP Modu'a g
processor Subsystem O
Trip To Trip
'l Output j t
Log lC F
Tester Subsystem T
A"
- trol, s
r Ou
"-----]
4
- MCB, c
0 L
Computers, l
etc.
Test
___a Panel SIR To Mon-Machine-Interface Test Cart 1970 paese1.006 FleUpE 3-1
. -. - - -.. -- -ii--.<,-------...-.,........,...
.s...
...............-m
EAGLE-21 INPUT / OUTPUT SUBSYSTEM From Tester NY*
~
Test Signal
,,o,os, M '-
S e>
-.e Anacog oest P
P u euso Moduse l"P Field Sensor
' Auto h
h Y"
From Loop Contact Input Cagbration
=* Mact E
E Processor <
- Omeput Output Subeystem Module
~
O O
From Tester l
Subsystem Tester %
gTest Subsystem $
7 7
PartialTr5 Partial Contact Loop 9
9
+
Output
+ Trip Input Processor 0
0 Moduso Subsystem Module W
T B
B Field U
U Contact
_S
_S From Tester contact See,et-o.t.ut 1970 030241.007 FNIUME 3-2
g METS 8
Y
-8 E
S 55 B
9F US R
OSSEC 1O 2RP ELP GO AO EL
i l
I 2
Nw>to CDD r to 9cc t
mm
-3l-0 (0
<W W >-
4 1
-E h
eO N
m _Z JOO
<E W<
r f
i I
i 1
l i
I ANALOG INPUT FUNCTIONAL CONFIGURATION
..c I
i i
l l
t l
I I
i i
L f
i 1
I i
l 1
I i
i
c 7
N O
ITARU G
IFN OC LA I-S N
M O
O ITCNUF TUPN I
TCATN OC
L i
i i
1 i
i 4
i ANALOG OUTPUT FUNCTIONAL CONFIGURATION i
i t
f i
l
..e i
l f
1 l
I I
t I
l l
t k
1 I
l i
l 1
1
?
M S-S j
l
]
4 i
I
LAN O
M IT M
CN U
I l
)
PARTIAL TRIP OUTPUT FUNCTIONAL w
i l
CONFIGURATION E
soc l
l i
I i
l t
l
'i i
I i
k I
l i
4 k
I t'
i FeeURE S-90 1
i l
}
i l
i 1
~.
. ~.
I I
l l
SOFTWARE DEVELOPMENT l
l 4,C l
~'
l l
i l
\\
a l
I t
?
i I
i l
l i
[
l t
l 4
1 t
4 FIstNE 3-11 i
i t
I I
?
9 1
i
-.- J
m.mi.ii EAGLE 21 LAYERED SOFTWARE APPROACH FIGURE 3-12
APPENDIX A EAGLE !! REPLACEMENT HARDWARE DESIGN, VERIFICATION AND VALIDATION PLAN Page 39
useet.=e 8CIF8 CAT 60N SM8tT sutgTieseMOWBt SL8cTR*C CenPORAtsag.
DESteed9P use eene oneses ensaw a=,, syn P8. Den 36 8teuewgh.8ennsytiene 16330 osaggeie. car o=
. avg ae visip =o e,ve$/12/89
'Y ' kah*vhusy.
enomer Generic anaca ints souwessut; EAGLE 21 Replacement Hardware Design, Verification and Validation Plan saan oneen: 322/393 emeu; Process Protection System Reviewed by:Mj D 8 k 11-/65
~
Ric afety IEV. 1 h, h. f* b 6 /
- e9-P D t
arv. a Abd '/ te e o m.u.,,
REV. 3 D[k f-3/- n C 860N PROPRIETARY O WESTiteGMOUSE PROPRIETARY:
"'8T"@i ald M8,V 'ahp 4ETM, #8V 8
- 8V 8
- 8V 8
- 8V 8 -
a iM:WMeCJM SW
= ;*8' 8t2;WCW*19?M'.C72"MRsw!%
o.P.u.m,W.naat%%s%%
~
=,cisc, i.r.r.arnett //L M Mbt Rye patn E Sn W.C.Gangloff MMMM[/y/
prpg
'y 1
- 27. _ +.
e e
e.ap.
i l
i i
12E CF CDCDUS 1.0 2ntrosactiert j
1 1.1 purpme 1.2 Systen FWct. lams 1.3 system Aredtasture 2.0 hafarun as 3.0 Dmfirdtisms 4.0 systan Development 5.0 System Verificatism 5.1 2ntrosactism 5.2 Verifistian Philonagery 5.3 Verification Tadmispans 5.3.1 Arviews 5.3.1.1 Design Dommentaticri Review 5.3.1.2 Senaron Ctda Review t
5.3.1.3 Furational twt hyview 5.3.2 Softwars 'hsting 5.3.2.1 structumi 'hsting 5.3.2.2 Punctional 'hsting 5.4 Darificatiart Imval 5.4.1 Safety Classificatiert 5.4.2 Eiararddcal Isval of Softwars Camponents 5.4.3 Justificaticri of Umrification Imvel 5.4.3,.1 Safety mainted software (Inval 1) i 5.4.3.2 Mm4afety Related software (Isval 2) 1 MI i
1 i
l 5.4.4 Applicatie of the verificatie 1sval ard critaria Utilised fe Software 'hsting for the Eagle-21 Replacemmt Har$are 3.4.4.1 Applicatie of the varificatie Inval I
5.4.4.2 critaria Utilised for software 'hsting i
4.0 system validaticm 5.1 W11dation philanestry 6.2 hiidatim 'hsting overvint a
s.2.1 annarmi Demariptian 4.2.2
'Ity-Inval Functional maquisssts 6.2.3 Furetimal Requirements ' pasting s.2.4 Abnmenal-Mada 'hsting 4.2.5 syste prudency anviet ' hating 7.0 Duvalegament, varificaticm and Validatica 'Dess organization 7.1 Duvalapsont 'han 7.1.1 miaf Programmar 7.1.2 Pringrammars 7.2 Varificaticm ' ham 7.2.1 mief Verifier 7.2.2 Varifiars 7.2.3 Librarian 7.3 Validaticm 'Desa l
7.3.1 miaf verifier
{
7.3.2 Functional Amp 11rumartts We 1
7.3.3
!and %11dat z
]
7.3.4 Sast Diginmar 7.3.5 Librarian 4
7.3.s
'hst h 1
_____.._....____.._,..._.._.-_._,..,_-,._.-_,,m-_--
1.0
- DfDCODERBI l
1.1 Rttpons The papons of this plan is to pewide a demeigtian of the design, h
verification, and validation perrman ard the general ceganisation of activities that are being used in thman areas cm the 1e-21 1
Procmas Protaction systen suNW haredare. The scritained herein is amialad after th guidanoa prwidad in (a) the 414 Integrated Protection Syste Protctype Verifis tian %.,
Wddh was prenanted to the IGC in 1977 as part of the Westinghouma RESAR 414 systen,- (b) A152/IEZZ-AM5-7a4.3.2-1982 and (c) Regulatory i
rAtlan 1.152, and-(d) the Design, verification, and validation Plan i
laplemented for the south Stocas Qualified MTlay Processing systaa 1
(CBIB).
1.2 System Puncticas the Eagle-21 Proomes Protection System r='W hardware W-the following naje functions:
- 1. Reacte Trip Protaction (Omnnel Trip to Voting Iagic)
- 2. Enginsated Safeguard Ptnatures (EEF) Actuations.
- 3. Zoolated W*= to Crintrol systas, Ctntrol Penals, and Plant-
%*m:s.
- 4. Zaolated cutputs to infernation MTlays for Post Accident 8tmitaring (PNE) indication.
- 5. Autamatic Survmillmca Testing to verify channel performance.
1.3 System Architecture The Begle-21 System Arddtacture is shown in Figure 1.
1he basic subsystems are:
- 1. Ic@ Premmarw subsysten the Zacy Premmence subsystem reonives a subset of the preams I
s14 pals, parfaces ena or acre of the protection algorithms, and craves the wlata charmel t: rip (or partial engineezed safeguards actuatian) signals. It also drives the required lanlated cutputs.
- 2. Testar th2 system the Testar Subsystem servas as the focal point of the human interaction with the channal est. It pzwides a user-friendly interface that pommits test permnnel to configure (adjust estpoints and tuning aanstants), test, and maintain the system.
Pega 4
s
- 3. Irput/ output (IA).
'Jhs micrepamoneser ham"d syste interfaces with the field signals thrmpt various iryut/castput (1/0) modules. '2hese andules hts the plant signals and test irputs frtan the
'hstar Subsystem, tenists perwW11y annitors the integrity of I
the Isop Processor Subsystem.
(
2.0 REFINDIGS l
'Jhe following is a list of relevant frukastrial standards thists were considered in the devolegment of this plant i
l 1.
A15I/IIEE405-7-4.3.2.-1982, "Applicaticri critaria for Programmable
(
Digital camputer Systems in Safety Systans of Nuclear Power l
Generating Stations" i
l 2.
IEEE Std. 279-1971, " criteria for Protecticm Systems for Nuclear power Generating Staticais"
, 3.
IIIZ Std. 603-1980, "Critaria for Safety Systems for Nuclear Power 4
Generating Stations" i
4.
WChP 9153, #414 Integrated Protection System LMype Verification Program," Mastinpacuse Electric Ctep., August 1977.
5.
Wt:hP 9740, "Snamary of the Mastin$acmano I 4.i.ad Protmetion System verification arus validaticm Program," Westinghause Electric carp., September 1984.
6.
Regulatory aside 1.97, Rev. 2, "Instamentation for LiWit-Waterhed Nuclear Power Plants to Ammons Plant and Envirtms omditiers During and Fbliowing an Accident," Daammber 1980 7.
ANSI /ASE MA-1-1983, " Quality Aamurance Program Requirements for Nuclear Power Plants" i
l l
S.
2EEE Rtd 729-1983, " Standard Glommary of Software Engineering
'kmainnlogy" 9.
2EEE Std 730-1981, " Standard for Software Gaality Assurance Plans" l
10.
IIIE Std 828-1983, " Standard for Software Onnfiguration Management j
Plans" 11.
2EEE Std 829-1983, " Standard far Software ' Dest Doomentation" 12.
IEEE Std 830-1984, "Gaide to Software Requirements Specificaticris" 13.
Mui Wai Put11 cation 500-75 (Pubruary 1981), "V111dation, Verification and Testing of Ckaputer Softsare" 1
l 14.
NBS W ai Publication 500-93 (Segf='har 1982), " Software i
validatism, verificaticri, 'hstirg 'Inchnique and 'mol Raference e.
Peps 5 i
- 3. Irput/outpat (7/0)
'the micruprennemer kamed system interfanns with the field signals throuq$1 various input / output (I/0) modules. 'Ihese modules ammoniate the plant signals and test inputs fram the Testar 92 system, tenidh paridi=11y annitars the integrity of the leap Pancammar Subsystan.
I 2.0 3EFDW835
'the following is a list of salsvant indhastrial standards idhidt tore considered in the deve.Wunt of this plan 1.
ANs2/3EI2 MS-7-4.3.2.-19sa, ' Application Critaria for Programable i
Digital W*= Systans in Safety Systmas of Nuclear Power Generating Stations" 2.
2EEE Std. 279-1971, "Critaria for Protection Systems fw Huclear Pewar Generating Stations"
, 3.
3EEE Std. 603-1980, "Critaria for Safety Systems for Raclear Power Generating Stations" 4.
WChP 9153, 8414 Integrated Protecticri Systaa Amype Verification
," meetinocuma nasceric corp., August 1977.
5.
WCAP 9740, saumary of the temstinghouse Integrated Protection System Verification and Validation Program," teastin@cuna Electric Corp., Septanbar 1984.
6.
Regulatory Guide 1.97, Rev. 2, 'Instrumentatiers for Light 48atar-cooled Maclear Stuar Plants to Ammmen Plant and Environs Q:rtditions During and Policwing an Accident," namenbar 1980 7.
ANSI /AENE NQA-1-1983, aQuality Amaurence Program Requirenarits for ga"4 mar Power Plants" 8.
ZEEE Std 729-1983,-" Standard Glenmary of Soft:uare Enginaaring
'D m in018Ef" 9.
IEEE Std 730-1981, " Standard for Software gam 11ty Amaurence Plans" 10.
IEEE Std 828-1983, estandard for Software Configuration Management Plans" 11.
IEEE Std 829-1963, " Standard for Software Test % tion" 12.
2EEE sta 830-1984, udda to software na;pi-.3 Specifications" 13.
MBS Wi=1 Publication 500-75 (Ptubruary 1981), evalidation, Verification and 'Dasting of M_*~ Softmare" 14.
NBS Wa1 Publication 500-93 (Seqt-dhar 1982), "Softuare Validation, verification, 'Dasting 'Da:ttnique and Tool Referunon Gaida" Pega 5 l
w-
15.
805 Pia 1 Publication 500-98 (November 1982), "Plaming for software validatim, verificatian and 'pastisga 14.
2BC sc 45A/WG-A3 (Jarmanry 1984), eDraft: Software for ocuputer in the safety system of macaear Power stations" 17..
e1% anida 1.152, acritaria Scr Av a!= Digital Cteputar system software in safety @ elated systems of maclear Power Plants" 18.
Regulatory cuide 1.153, scriteria far Stamr, Iristzumentation, and centrol Stations of Safety systansa lo.
Design, verificatim and validation Plan for the south 'emmas Prtdast - Oaalified "i?!=y Proconsing system. Design specification Ember 955842, Revisim 3, July 1985.
l 3.0 M:PDt1TB3B
'Zhe definities in this section establimb the meaning of words in the canteet of their uma in this plan.
CDsUIDt scr!WME BNn!1st
'Iha m*me program, <=a*-
data and camputer progrima &nmaritation die ccuprises the cumplete repreaantation of the caputar software system at a rific stage of its develepasnt.
EE523 RIVIDi - A masting e =4=41a* comunication process in die the requirements, design, code, or other pr*+3 of a development prtdect are prenantad to a salauted individual or grogp of paraannel for critigan.
PlatCTICHAL 'IEB1TNG (PT) - Daarcise of the functianal m1.ias of the program to the design requi.
rs.
PWCTIONAL '53T 55VEDt (FIR) - A review eich is perfeemed en tha
&nnersta$ functional tests that were rias by the programmar an his code.
IN5PacrIW - An evaluaticn taenigas in mich software regud.ruments, design, acde, er other pra$ acts are examined by a parean or group other than the designer to detect faults, diffaturicas between development stan$ards, and other pechlans.
INIBEETIM '!IBIB
'Itsts perfesand during the hartheoreoftware integration prmana prior to ai y x systaa validatim to verify
--fih414ty of the acetmare and the miww system hardware.
300@E (M) - Refers to a significant partial functicnal capability of a aut:prognma and consists of are than cme unit. Medalas are usually starealena ps bres er routinam eie may call other louer level uredma or units.
PEER RINIDi - An evaluation tactinigan in 212 software regai.
is, design, code, or other pres are cannined by paraens ecee rank, responsibility, emperience, ard skill are ocaparable to that of the designer.
Page 6
i 1
NCSAM
'Itstality of software in a syste er one trutsperutert part of software of a distrikastad syste implemented by a par +4mh CPU.
soment IEsIW SPEC:IF70GIW (SDB) - A docnament Wnich represents the desipar's definiticm of the way the software is designed ard igleanted to -h the twictional reqpirements, specifying the aupacted performanos. An sDs aan be for a system, mesyste, andule, or unit.
SOF'DeWit IEVEIstgNT 7543301I1,- A taan of indivi&aals or an individual assiped to desip, develap and doelment software.
SCFD50tE 'IENT sPECTFIDETW (525) - A doenment detailing the tests to be portansed, test erwircriment, aammptance critaria and the test asthodology. An Jggroved SDS doctment fcens the basis for the 525.
l 30tmCE GEE ItEVIIN (act) - A reviw Wildt is performed en the source l
aada.
E EPKX3 TAM (sP) - Refers to a anjar functicmal memet of a program and is unde g of one or ante an& ales. A subprogram is typically.,-- 9 by the software esecuted by a single processor.
S!50C3 TRAL 'IENTING (FF) - Camprehensive esercise of the software program l
code and its campcment logic structures, i
l WIT (U)
'Ihe maallest cuspenant in the system software ardhitecture, consisting of a sagaenas of progrunn statmuents that in aggregata perform l
an identifiable service.
l l
VALIDGIN
'Ihe test and evaluation of the int,.M cumsmatar systa to aneurs czepliance with the~ functional, parfanmance and interface requirements i
VHtIFTOETW
'Iha Izomens of determining diether or not the product of each phase of the digital cxuputer system development process fulfills i
l all the requirusents imposed key the previous phase.-
VERIFTEt(S) - An indivh1 cr group of indivi&aals assigned to review l
acurce code, generate test plans, parfasa tests, and docament the test results far a =i-,-- n-system. If the activity is actansive, a chief verifier will be appointed to guide and lead the Verification and Validation parecrmal.
t-VERIFIOCTW 'IIsT IEEFGtr (VIR) - A document containing the test results.
In conjunction with the software ' Dest specificatica it centains enough l
infarnation to anable an independent party to repeat the test and understand it.
4 4.0 SYSIIM IEVEICRIDir
'Ihe devolepsent of the Eagle 21 syste, as shown in Figure 2, involves three stages:
i 889e 7 n e e,-,-,w-m,,.
1.
Definiticri 2.
Design 3.
2aplementatlan ard ' Dust A brief dameriptian of aesta stage is given balcnn
- 1) the definitian stage is cenaracteriand by the statement of the chrjective to be acetieved, the construction of an initial project plan, and a high-Isvol definition of the system. Daring this stage, the cuarell iWetional regairements of the system are identified. Within Mastingrums, theos regairements are becught together in a systen Design Regairements &rummit.
- 2) the design stage is dharacterised by the ------eition of these systae e
Design Reqpirements into Systen Deslgn Specifications and Hardware and.
scetuare Design specifications of sufficient decall to enable the laplementation of the system. Own softvers Design specifimtiems for i
the system are than further a-- ;---9 into subsystem, auxhale are unit v ieications.
3).1he inplementation ard test stage is characterised by the actual constructica of the her&are, ending of the various software entities, and tasting. She aoftware development tasa is responsible for the writing, mamanh14rin, testing, and h= sting the czapucar ende. As the software entit;ms are capleted, haginning at the unit level, they are forna11y turned over to the verifiere for final li4.:
A. review anyar testing as specified in section 5.0.
software damalegnant can he viamed as a sequenos of well-defined staps a h41ae to systes develepaant. The s used to ganarata softamre Design ar= ystem Design specificatice is ifications Wtices in turn are used to develop hips level language programs. Shane progrims are converted by a ocapiler into andly language, than by the ameler into ancitine code, the linhar ambinas groups of madlad code with the library to pre &rm zelocatable cbject exde far iriput to the landar.
ihe leader ganaratas the abenlute cxds ddrh is then burned into read only a - y g ag.
The use of a high level language alicas the designer to express his
$dman in a Seen that is ante natural to him. She 7*=e adjusts to his language and not he to the language of the ocmputar. Software written in a hiWs level larspunge is acre readily reviamed by an ird
.C.;. party the any not be camiliar with the couputer ammanhly-language instruction set. Some features of the high level language aid the C r'M of EmHable software. Ptar sample, bicek str=*=4rsg helps identify and reduma the raaber of.-Ma anoscution Paths.
I As part of testing, the varicus har&are conscmants and software entities are a d iad in a stapwise manner. Additicnal tasting at each stap to ensman that each component perfaces its required function dann integrated with its amarr fated cacycruents.
She final activity maanrinted with the system implementation and tasting stage is the tasting of the systan. A system test plan is derived from saga a 1
)
the syste functiaral requirueerrts and systma design specifications to omfirm that the system aNhibits a 19 Vel of functiarality and perf0Nmme 212 marts or M the stated requirements. Shis final system test -
is referred to as the Factory W_ance 'past.
Several design mammence techniques are utilised throughout all stages of the developeant process to ensure that the haribers and software w ;a mest the reqpired specificatims.
Fturnal design reviews are held within Westin$acuse to ar9sure that the system Design specifications most the system Functiaral Rs;pizusents.
'Ihe design review tasa consists of a group of krculedgeable multidisciplineary engineers to ensure that all arpacts of the design are reviewed.
During the implementation ard test stage, acceptance testing and review are corducted by the designers en the hardware % fa, cizizait boards, and subsystans to ensure they exhibit a level of functionality consistant with the Hartbare Design specifications and Software Design specificaticns.
'2he firal design assurance technique utilized is the acecuticm of the systaa Factory Acceptance 'hst to ensure the system performance meets the' syste functional requirie:arita and syste design specificaticms.
5.0 SYS"5M VDtIFICXrICH 5.1 Irrtroduction With the application of m-.;ble digital ocupatar systans in safety systams of raaclear pcuar generating stations, designere are obligated to conduct ir&An. reviews of the software ~~-Lated with the ccr:putar system to ensure the functionality of software to a level consistant with that denaribed in the system esquirusents.
section 5.2 provides an cuervier of the verifiantico pdloseghy.
section 5.3 describes the verification techniques utilized in parforming the verification prwman. Section 5.4 dmeribes the critaria that the verification ps
..el use far determining the level of verification that should be agplied to one software entity.
5.2 Verification p W %
Figure 2 illustratas the integration of the systaa verification and validation pramma with the systas design process. 'the verificaticn process may be divided into two distinct pases:
verificatism of design &nementation, and verification of software.
As shown en figure 2, independent verification of design hearttatien is performed during the design stage. Ptar example, irgi.p -At plantion will errur to ensure that the translatien fma the P\\inctional Requiriments to the software Design Requirements has been performed preparly and theraughly.
Page e
I Figure 2 Allustrataa Waere an indeparderst zwview ard signoff will be conducted å the design preases. Varifiantion of the design doamentatie will be acepistad prior to the impleantation and test phase.
Daring the implementaticm and test stage, Wann the writing, tasting, assembling, and doommenting associated with each software entity (begiming at the mit level) is acepleted by the design 1
tasst, the software entity is formally turned twer to the verifier.-
At this point,- an independant twiaw an4/cr testing of the software entities is perfemad to that the Amationality of the software entities anst the tamble Software Deste Socifications. After the verifier is entisfied that all requirannts arm met, the software is omfigured for use in the i
final system and subsequent system validaticm pecomes.
the software verification pecomes begins et the unit software level, i.e.,the simplest taailding block in the softwa:e. After all software mita that are utilised in a software module are verified, the verifier proceeds to verify that andule. Not m1y is the software undule verified to most the endule Software Design Specificatism, but the verifier anazres that the w, late units are utilised in generating the software um& ale.
After all software modales neommeary to asocuplish a software.
mahprogram are verified to anst the applicable Software Design,
specificaties, the verifier proceeds to verify that subprugrun.
l As in the emme of the software antale, the verifier not only verifies that the mahprogram ansta the applicable Software Design Specificatims, but also verifies that the w, lata software l
andules were utilised in generating the sabprogram entity. 5his verificaticm philcocphy ensures that the verifier tests and/or l
reviews the interface betuman the software mit, undule and subprogram entities.
Depending p the hartbare implementaticm, the verification proomas any utilise syste hartbare in the verification of the software ac& ales and subsystans.
5.3 Verification Tadinigans MitatiCm M 13ed in softhart M@ fall irito two basic estagorias: swiaw and tasting.
5.3.1 Reviews There are three types of reviam used in the verification of software: Design doctamentation zwiaws, made reviews and functional test toviews.
Page lo l
5.3.1.1 Desip nerumritation Revier this activity irwolves the %--tacn of a design -
Amumarit far a subsystan, neaule, or unit to the design &mmest of the casgonent aheve it to ensure that all of the parternance reqpirements stated in the hi@mr 1sval documarit are ast.
8 5.3.1.2 Sousco Code Review Sauzca coes suview, as cpposed to code tasting, is a verifiestian method in etich the softamre stregran la mmmined vimmily. 1he aparetian of the softamme is dadenti and W with the I
= = =i *===* %.
In effect, the w. dan of tes softamire is simulated aantally to cznfirm that it agrams with the specification.
scurae onde zuviam will be used to verify the transfarnetien scam a Design specification into high level code. Hi@ 1evel code is easy to read and understand, and therefore full ie% at that level is feasible.
5.3.1.3 Punctional test Review A functional test zuview is a review by the verifier of ths &nnmarttation amarm-4ated with the functional tests idhich were perfemmed by the -
designer. this zuview will provide a high degree of aaszemos that the softaere performs the fumations specifiad'in~ the design esquizionants.
5.3.2 Scdb are Testing i
1 softamre tests can be dividad into tan cat, las:
structural and itmetdanal.
5.3.2.1 Statsotarral Testing Structural testing, dtidh attaqpts to ccaprehemsively anarcise (via camputar armiatien) the softamre proprea code and its cagement logic structures, is usually applied at the unit 3mval. She functdanality of the program.is verified along with the internal structure utilizar'l within the program to implanant the -
zisguized function.
Structural tasting esquires that the verifier inspect the code and understand how it functions before selecting the test irputs. the test inputs seculd be chosen to exercise all the pensible camtzol paths within the softaare ocuponent. If this is not possible, the test imputs should be chosen to moorcise every statamnit within the w.. Ptr eenple, if Page 11
4 a trichic function is calculated in severni different ways, esperdiag en the range of the Aryut argeurt, than the test iriputs include tests for the argusert in and of thans ranges, as wall as on the boundaries betmean ranges. In 1~'~, they marcise the gger limit, the limit, are at least one internadiata value within sech range.
5.3.3.3 Punctianal Testing In the functional W. to progre tasting, the internal st:ructure of the progra la ignored during the test data selection. 'Itasts are constructed fraa the functional pWh of the progren thich are specified in the Design-specification. Functionni tasting is-the asthed z
nest frequently used at the arAda er mheystea level. Bemples of functional testing include randas tasting and special cases by functim.
Randan tasting is the nethod'of applying a test iripJt eag-uance chcoan at ran&IB.- '!he authod Can l
be used an the following circumstances: to minulata real time events that are. irdaad randas; to inc:rease the confiderice level in the correctnans of a very cacpleet nredet to test a subsystem ar a systaa there it is not naamanary to test all the passible paths; to get a gaantitative naamrre en the acz:uracy of a numeric calculation; or to get a suasure of the svarage time required by same calculaticn.
&4=' r=as by function can to amauena era the -
Design specifiastion of the mahle and will detaraine acna test emmaa. Ptar exmple, a subreutine for matrix inversian should be tasted i
us minnst eingular and ill-canditioned subroutinas thich accept arguments an frern a specified range should be tastad with these argueants at the extras points of the-range. An arithustic package should be tasted with variables thie have the largest and sen11est aantimma, largest all aeroes, ard all ones an,and smallest exponent, d negative variablas.
S.4 verification Level 1
'Jhe choice of par +4='=* verification tedhniques to be utilized an a system comperient la a function of the following paunsmeters:
A.
'the safety classification of the systes B.
The hierar&ical level of the software w.-d. (unit, ac&le or e4, )
Dage 12 1
1 5.4.1' safety etaamification
'Ihe safety classifiaation of an its is defired ammording
-to 2I22-279-1971 and IZZE std 603-1980. In general, the safety classification of the syste establishes the verification requirtaants far the syste. Nousvar, since all the comprerrts contained in the syste do net neceamarily ps:.faea a; pal safety functions, a higher er lower level of verification any be assigned to specific syste capanents empending en the exnet functions parte msd. If a different level of verification is -
assigned to a onepanent, the interacticma between that w-o. an$ the other eenpanents in the syste must be carefully considered and revissed.
5.4.3 Biararchical Eevel of software etapponents Ptar software that is organized in a hierarchical structure, the intriemefan of the actual cede can nct be easily gras-ped at the upper levels. Ptur e.11 but simple systans it is gru$snt to approach verification in a progressive-sannar, begiming at the unit level. It is at the unit level that the ccde can be most easil 1
wJ-ively testad as rac==aav. y Wd or As the software is built up into higher level cacpansrrts during the integratice stage, it hamma pensible to demonstrata ennpleta processing functions. 'Ihis prwman allcus the validation of functional parfarannme regdrasants. Smas, validation ta2.ing aasman a functional thsee, with the main emphasis cm the interaction between subsystans and their interfaans.
5.4.3 Justification of verification Level censidering the parumstars detailed above, different verification astheds are required far different subsystans and software campanenta.. 'Itible 1 illustretas the levels of verification. Each level of the table specifies the type of tasting er review that will be performed on the software w
- 4. within that einamification. 'Ihm justification of.'
the verification levels fallsam.
S.4.3.1 Safety Related Software (Imvel 1)
The software associated with actuation and/or impleantation of reactor trip, enginasred safety Saaturas, and information MLays for sarnaally-centrolled actions (as defined by IZ2E Std.
3W1971 and ZEIE Std. 603-1980) must receive the highest level (level 1) of verification identiflad. As such, all software mast be Page 13
.= -.-_ -..
l structurally tested to ensure,that all lines indeed meet the intended design specification.
Since the plant' operators rely upon the automatic
)
actuation of the reactor trips and/or engineered safeguards actuations, as well as information displays for manually controlled actions, the highest level of confidence must be afforded.
f
\\:
i 5.4.3.2 Non-Safety Related Software (Level 2)
The following criteria will by applied to all software units.
If all of the following conditions are met, the software is level 2r level l
1 will be used otherwise.
- 1. FUNCTIONS J
Does not generate information used during a.
any' operational mode (eg. normal, testing, 5
maintenance) by level 1 software functions.
b.- Does not perform tests, the results of which are used by level 1 software functions.
- 2. CONNECTIONS a.
There is no direct path to level 1 software functions via a common bus i
structure.
l b.
There is no direct path do hardware I/O used by level 1 software functions..
c.
Data Link-transmission to level 1 software functions is prevented by hardware design.
- 3. ORGANIZATION
- a. 'The software design does not permit l
writing to areas of RAM memory used by level 1 software functions.
j b.
The software design does not permit inhibiting access to memory locations e
utilized by level.1 software functions.
c.
Software is not part of, nor can alter, the execution path for level 1 software functions.
NOTE:
The above criteria will be re-anolied when evaluating the impact of future software modifications.
Page 14 i
.r-
,,.,._,,.,_..,_._.,,___.,,,wc-,--.,,_,,ry,y,-,,
,,,wy.m-_-.e,.<,
5.4.4.
Application of the verification Matrix ard critaria Utiliaad for Softaere Tasting fa the Eagle-21 Replacement Hardware i
5.4.4.1 Application of the verification 1sval the Eagle =21 W:
.i systan aan te divided into tam groups: 1) that eich performs safety Ralated Ametiens, has inpact en safety Ralated functions, ard ele tests safety Anlated functions and 2) that 212 atmitars the systan and provides H2esafety Ralated infatuation to-the user.
She first group censists of the follawing (5taference Figure 1):
i 1.
All of the Zacy Proomance Subsystem
{
i 2.
She partion of the Testar Ribsystaa that runs surve123ance testa and therefore, has an ispect en the I/O acekles 3.
5 hat partien of the 'Destar Subsystaa dich-controls communication to the locp Proommaor a
fe parameter up$ata.
4.
that partion of the NC cart dich allows the cparate to irgut rusw parameters and eich does the limit Mhg cm thces irputs.
5his group, die masts the critaria fe section 5.4.3.1, will be verified at level 1 to give the i
higiast degree of ecnfidence to this code.
the secono group censists of the following (Rafarence Figure 1):
O
- 1. That p: stim of the Testar subsystem' thich -
has re direct lirk to the M Pr - maar other than a reedkaly datalink. - ' mis includes the software thich qpdatas the test penal li@sts and outputs analog trend points.
2.
All of the isc sortaere empt that listad in
- 4) above.
' mis group will ha verified at level 2 since it masts the criteria of emotien 5.4.3.2.
5.4.4.2 critaria tRitimart ser Softamre 'hsting Dds critaria win be applied to level 1 mortuare units. matar to 'mble 1.
namari en gesvious verification etxperience, the following critaria vill be used to identify the tasting reqpirements for igr, ylax p-tmas.
If all of the followirqr canditions are ast, annual structural tast;.rg will be performed; cacputer anulation will be used otherviae.
1.
Prermins uniqpenses - 1he verifier must -
datamine that the partimiar rh is not unisp a in amb a toy that aanguter eradation is nemassary.
2.
Math cparaticris (+,
, e, /) - the rh performs math anly with PEM based variables or data constants.
2.
Engice0 operations (True/ False) - 1he
^
p Ao uses only standard definiticre far True and Fadas; Trus=1, Falsec 4.
Icgical operations (Masking) - the re uses only logical operations thich do not set or clear (sank) status or control bits.
i
- 5. Elitple Paths - The ph has ardy cne direct softamre path.
6.
Prermirre Slas - The sine of the p
^-me is less than to ancrutable lines. Descutable line count dcas not include r-- we
^
declare, A and, and e==rsts.
- 7. Iritemal Prermirres - the r h does not include internal p h (s),
ptge 16
6.o sV3HM VALTDWR34 i
6.1 validation M %
l Itiernas the systaa verification procams verifies the ^
. -ition of the systen requirement doaments in the definition and design stage and also verifies the fimetionality of the software antities I
(urt.t, andale, and s4, u.) beginning frun the ammilest software antity and progneasing to the program level, the system validation pecaans is pseewn=a to demnstrate the system functionality. sy corskasting the systen validation test, the results deanstrate that the syntan design assts the system functional r=r=4%.
Mance,-
any inconsistancias that acamsd the system develapannt, in i
this area, that were not dimoovered the various design verification activities discusand in a* m 5.0, would indeed be reviewed, identiftad, and tracked by the verifiare thruugh resolutica by the design tasm.
Philowing coqpletion of the system validatice test, the usar can iruland have a high degree of confidence that the systes functional requirements are ast.
6.2 Dalidation Testing Overview j
Daring verification, a bottaamap aiw% c approedt is udihm9 i
to tharcughly and indiviAmily review an#ce test each pia:a of i
software within the total system. Bis requires a significant effort and verifies that each software alament cparatas preparly as a stand-alone antity.
validatier..t@lanents the verification greeman and not only.
insures the." *1e final amplananted system antisfies the tcp-level functional auguirements but also that good enginaaring prei~ was utilized maring the design and 49=
rden of the system.
Philawing are the anjar gheses of validatiem:
- StgMlawn functional regai-.- testing Prudency review of the design and its implementation a-3,1c Han4tschina Interface (Dec)~ testing e
the sacroscopic ^@-i functional requirunants phase of validation testing treats the system as a hiack bcoc while the pruanney review sheen requires that the internal structure of the int
.a softwaru@arenze system be analysed in great detail.
nas to this dual approach, validation testing prwides a level of thoroughness and -W accurney mich is at lanse equivalent to that eich coeurs during verification and inmuens detection of any deficiencias that emered during the design perrman but not alarmseed seing verification. validation testing.is parem-e en the verified software residing within the final target harenze.
Page 17
6.2.1 General Descriptian the Validation plan istinas a methodolcgy that amt be followed to portana a series of tapd:wn functional regairement w reviaus an$ tests eich cxmplinant the 6 := 4 appecach *iliam8 during the verifistion tasting gfissa.
Ptaar in$upandant types of reviaus anVar tests are to be acrducted to insaare evimmall system integrity:
- 1. Punstianal Repairements Testing - this insures that the design masts the functicnal regaizumer.ts.
- 2. Abermni ende Testing - this inannas that the design l
cperates prcperly under abnamal-ende conditions.
- 3. System Pru$ency Review / Testing the design andthis ensures that good design praction was utisimed in implementation of critical areas of the system. She itens covered within this section require the internals l
of the system design and la=1% tion to be analysed in i
detail.
- 4. P91c 90nn4tadtine Interface testing - this insnares
.that the operstar interface utilised to miify the systan's data-taae parfarns preparly urder remi code and atsnmal-node data-entry sequamons.' This is a critical arme regairing Wai attention due to the 4=-t en the software of the systamp-level information utdah con be miified via this interface.
She functicmal regpizements an$ atsumi-ecde testing phases of lanlidation utilian a bladt-tasc systems approach while the i
systaa Pru$ancy Review / Testing phase ashasiaes the need to understand the internal aparetiens ans interactions within the systam.
6.2.2 Stp Iavel Punctional Regaisuunnts the functional requizements acrve as the basis for identifying the tests that mast be acrducted during the 1Ralidaticn tasting shoes.
6.2.3 Punctional Regaitements Testing the Validation functional requimmannts tasting shame etemists of the following steps:-
g 1.
Functional requi.taments ?------ Ation the top-level functional requi
- a. must be darrupnand into detailed sub-requirements. Ptzt each sukMtsquirement, a test or a series of tests sust be identified and perfemnd to insure that the specific autMeequirement is satisified.
Page is
Some ad>-rupirements are fairly guneral so it is
%% that the esma irdivMm1 that parterms the
^---v+1 tion also prorides the interpretation as to the type of test tdttices mast be armasted to insure that the sulereqpitement is ast.
- 3. Wildation test w
^me generatien 91cm the ^-- -,,- ition has eermarred, the specifics of the tast(s) mast be defined in test ph form mich that it (they) can be cordacted during validation testing.
3.
Validation test nvmentien (Rafer to Septica 7.3)
'the detaila$ tests per the Validation test r c ^=mes mast be ceniacted by a Validation 'Dast 'De2nician and the results mast be reviewed by the Validation Test Digirimer.
Easts functicmal a@r=5'iM must be unkpaly identified. Die test p -Jae ganareted to test ends sub-res;pizement mast be -Wy identified for ease of crossMreferencing.
i 6.2.4 Abncrmal-Mode 'Desting During this phase of Validation the functional regurunents are reviewed to define a series of abnannal canditiens undssNhich the systaa mast aparate properly without results in e anuairag argr inadvertant or detrimental actions.
Die validatien abncenalenda testing phase cxaisists of the i
sellaving steps:
- 1. Banational requirements ^-- -,---itian The tegelevel functional regairements must be reviewed to identify detailed ahnemmih a:siditicas. 'Ihe i
type of test that mast be cordacted to marcise the system un$se each abrurmale condition saast also be defined.
2.- Validation test p
^me modan I
once the Wition has occurred, the specifics of the test (s) zust to defined in test rh form i
auch that it (they) can be acniacted å validatica t
testing.
Page is
3.
Validation test assaution (Refer to secticm 7.3) the detailed tests per the test proomkres must be I
corukastad by a validatian Stat 'mchnician and the
+
results sust be reviewed by the Validation 'hst l
Engineer.
t l
Each abemoraal-ande conditian mast be miguely identified.
l She test proondian generated to test each sub-requirement naast be entraspondingly identified for esse of i
aross-referencing.
6.2.5 System Pandancy Review / Testing maring this pheme of Validatim, the system design and'-
iglementatian is analysed and reviewed against the "Systm l
Pnadency Checklist". She-systa mast be evalustad erMnst this checklist to insure that good engineering practuam has been followed..
She systen Prudency Checklist addrummes the following critical design areas:.
i Firmare program storage 4
f
- Deta-base informatian storage Witiple-promanese shared assary arthitecture.
I Data-link crianted syste architectures
- Diagr==* 4 =
l
- Systaa time crg.L h=*4m i.
l Must of these items do not relata directly to a functional I
requiresunt er to a merLos of functional requirements but address the imeus of lii6p.M system integrity.
4 j
7.0 IEVEICE9ENT, VERIFIC322CN AND VAI2DR22GI GGANITATICH During the syntam design process, two independent 14anctions will be uti14 =ad: cme for develquant, and me for verification. She software develasmant paremmal receive the system Design specification, generate the software Design Specifications, and them designs, develops, tests,-
i and doctaments the code. She verificatism personnel receive the released
(
ande and its docaanentatism, perfosas the required reviews and tests as -
i dictated by the seetuna verification Isvol within the verification Matrix and pensamos a verification tiest Report (VIR).
l 1his type of ceganization has several advantages. She name of two ir:Sependant entities introduces diversity to the proomms of software 4
generation and reduces the r 1-W4ty of undstacted arvtars. Another I
benefit is that such a schuse fernes the designer to pen &aos sufficient i
and meabiguous doenmentatian before verification aan take plaan.
page 20
_ _, _.. _~
,,,,___,,%..,,.,yy,
,,y
,,y._
.,.,,,..,,,..,%._,_.4,,,,
j Rush independence is emnertial to amisve thane goals. In par +!=i
, the two facticms will have separeta lead ergineers. Nota that the developuert parecimal sutunits the code for verification only l
after the devolegmart tems has omfirmed the code to its entisfactim.
Elrrere discovered (datuging) thring the developmut simme testirg are not required to be donnanented by the verification enginmars.
the use cf the abzwe Ww does not preclude the possibility that the developer of one mo&Lle any be the verifier of a differert andule, as long as that perum did not participate in the design er coding of the suzkle being verified.
7.1-Develegsmart Activity I
l the awtion of the deve1 cement taan is dependent up= the functions that are required to be performed by the team. Typical l
taan functions include the following:
7.1.1 Q11af Programmar 1his is the tema software leader de is responsible for the software icachnical matters. 1he Aties of the Otief Programmer ir.nlude:
- a. software Design F ification i
the chlaf programmar has the responsibility for the developnert of the software Design Spucifications, Wtich are based cm the system Design *-ification.
- b. Architecture Global decisions en the structure of the acetuare, Witian and data base are unde by the chief i
programmer.
- c. coding scum critimi sections of the programs (both in taram of 1.y ^es and complascity) can be ceded by the chiaf programmer.
- d. General the cesiaf programmer agervises the rest of the team in software te e niemi setters.
t 7.1.2 Progruummes It la ar+<-4N that there wi.11 be unto than one programmer, and that at least ans programmer will function as a back-up to the chief programmar. She progrusumers' tasks are to devolep the code far acdules and/or autMuystans as directed by the Software Design * - ifimtions.
Page 21 m.
-_.___--..____.__.,..,...._,,,.,,~.-,-o.,
.,...,,..-,,-w.w..,.,--w,,.m,-,--,,
o.
i 7.2 Verificaticri Activity l
'Jhs functions of the verificatian tasm are as 'follows:
.7.2.1 Galaf Verifier s
Saam
- the is responsible for all todmical astters. 'the skaties of the Chief Verifier include:
- a. msview System Design angairments and M*ih received fra the development engineer for ocupletanens and Wpaity. ('Jhis review any be perfcemed by another agualif;ad lndivihaal Wo is independant of the design area haing zuviewed.)
- b. msview the Software Design Specifications reonived frta the develagmant engineer for ogletanens and unambiguity.
i
- c. Review verifiar's Softwa:e Test Fificatins for l
csupletaneas.
l
- d. Oversee verification of critical secticrs in the software.
I
- e..g rvias and c.r.ait,ith the verifio. tion t a.
l l
- f. Review Test Reports 7.2.2 Verifiars
(
- a. Derform source onde iW% and review Software Design' l
Specifistisms.
f
- b. Writa Software Test Specificaticms.
l
- c. Am tests en subprograms, andales and units.
- d. Write test reports.
7.2.3 Librarian Ptmetism i
'Ihe Likrarian parfatus the Scallowing skatias in the maintenance of the Verifiastion Software Library:
- s. Responsible for the storage ard ocmfiguration contzel of the cxuputer software being verified as follows:
(1) metablishes identification of each software element (i.e. unit, auxhale, shprogtum) within the ocuputer software anseline (58)
I i-i i
l Pega 22 1
3'
.. _,, _. _ _.. ~
4 (2) thforces gymndures for software ard demmnaritation chmges dLrirg reverification
' atfca%
(3)
Benintains etnfiguration control of the carrrent css b.
Centrols the tranmaittal of camputer softamre to authorised paramnal only c.
Ensuses no unautherised dhanges occur to the CBs 7.3 vnHeatica Punctica 1he functions of the validaters are as fo11cus:
7.3.1 Chiaf verifier l
a.
coordinata total validation program b.
Review validation tasting zusalts ard write final repart c.
Supervias and consult with the vnHdators 7.3.2 Punctiemal Requinmaants P (cytianal/ Chief Verifime) a.
Ceardinata validatica of a specific area b.
Review functional e--- ;-+ition for cespletanens ard accuracy (this review may be parf-d b qualities individual e o is ir @.:.;. y another of the design area heing reviewed) 7.3.3 land Validstar (optional / Chief Verifier) a.
Ctzedinata Valdation of a specific area b.
Review functicmal t-- ;---ition for ccupletanens and accuracy (this review may be perfeemnd by another
?=mied individual who is irdspendant of the design area being reviewed) c.
asview and approve tes procedure vs functional regai-.i test W'i% to frusure test
- p. h is adeg ata d.
Along with the Librarian, insure that proper verified code is being validated Fage 23 4
7.3.4 Validation 'hst Enginaar a.-
Writa validatian test r h b.
oversea validation testing and zwim test results c.-
emnarata validation Tatshle Reports l.
7.3.5 LGrarian a.
Oxsdinate with the chimf 1Aurifier/Imad Validator(s) an4/cr Validation test Enginaars to insure that proper verified ends is being validstad.
b.
coordinata diammainatian of validatism tzcuble reports to the w,hte W anginaar.
7.3.6 Validaticri Test 'hchnician a.
Perform Validation tests usSar direction of the Validation Test Enginaar b.
nocmant test results-i
(
I l
l l
l t
L l
s l
t i
0 Y
Page 24 4
6
-.-,-._,,,,m,,-.._m,
,.7,,
,,c.,g..,..,,,
,,..y,..
,,.w..f
-.7 9.my._,
1/0 B
l Sensor @
l.y Analog Card Cace input p
I Loop.
E Module processor R
Subsystem e
To u
Trip
- ~
Trip
~
l Output Logic e' Module '?
R I88I8I To e
Subsystem Analog u
Control.
s a
Output p.
- MCB, e
o Computers, L
Module
,f,_,,,,;,J o
ofc.
I Teat d
Panel To Terminal.}
{ To Printer MAN-MACHINE-INTERFACE CART anaLE - at PROCESS PROTECTION SYSTEM l
ARCHITECTURE FIGURE 1 Page 25
I i
F1GURE 2, DESIGN, VERIFICATION, AND VALIDATIO'N PROCESS IErINIT!W EAR.E II I
.5 TEM IESIM fuautEsEscs ggjg
,. _ _ _4_ _ j
(
ii E,AR.E.21 E.
i.
M!rICAT!W FECIFICA110N b
l I
IK5!>
p I
CAa.C 26 i
SVETO waa' mar e_-___-_-
_J RES!ON SPECtrICATION I
I l
l l
l 0
U l
teMDrAE serTwemg IWIMILE IEMRT I
- ~ " " ~ ~ ~ " " " " ~ ~ '
I EE318N EEllm I
I I
I I
I U
U 1
I l
. M48D'AE SIFTwent teatrICATION l
~
TEST]NS 1337[q MEEZ55 I
i l
I I
I RSTm i
INTE8 RAT 10N I
I I
l p
V pgte EFTWAE i
TEST EDFISAATim i
l larLDENTAT10N l
TEST p
g l
=>
EDrLUE g
I I
l p
U i
VALIDATl >
1 WN MND l
l l
l o
U
~
3 pro $dm mtPtytt VALIDATION i
G oceTts scruest warricATim Evirv Page 26
SOFTWARE VERIFICATION PROCES$
TABLE 1 Verification Level
> FORMAL LIBRARY Level 1 Level 2
- Code Maintenance.
x x-
- Documentation Maintenance x
x l
- Report (TR & CL) Maintenance x
x l
- Verification Results x
x
- PROM Files (Hex & Checksum) x x
--Impact Analysis Results x
x
- V&V Tools Documentation x
x
- V&V Procedures Manual x
x
> VERIFICATION TESTING t
- Documentation Review x
x l
- Source Code Review x
x l
- Unit Testing l
Structural (5.4.4.2 Criteria)
Functional x
+
l
- Trouble Reports x
x
- Clarification Reports x
x l
- Impact Analysis x
x s
x Indicates item will be performed on all software procedures.
- Manual Structural Testing will be performed if all conditions of the 5.4.4.2 Criteria are satisfied; computer osulation will be used otherwise.
+ Review of functional test results performed by designer.
(
Refer to section 5.3.1.3.
9 Bega 27
-