ML17348A469
| ML17348A469 | |
| Person / Time | |
|---|---|
| Site: | Turkey Point  |
| Issue date: | 07/23/1990 |
| From: | Harris K FLORIDA POWER & LIGHT CO. |
| To: | NRC OFFICE OF INFORMATION RESOURCES MANAGEMENT (IRM) |
| References | |
| L-90-277, TAC-69023, TAC-69024, NUDOCS 9008010160 | |
| Download: ML17348A469 (23) | |
Text
ACCELERATED DISTRIBUTION DEMONSTPWTION SYSTEM
~ ~
y REGULATORY INFORMATION DISTRIBUTION SYSTEM (RIDS)
ACCESSION NBR:-9008010160 DOC.DATE: 90/07/23 NOTARIZED: NO DOCKET' FACIL:50-250 Turkey Point Plant, Unit 3, Florida Power and Light C 05000250 50-251 Turkey Point Plant, Unit 4, Florida Power and Light C 05000251 AUTH. NAME AUTHOR AFFILIATION HARRIS,K.N. Florida Power & Light Co.
RECIP.NAME RECIPIENT AFFILIATION Document Control Branch (Document Control Desk)
SUBJECT:
Submits addi info on emergency power sys enhancement project. D DISTRIBUTION CODE: A001D COPIES RECEIVED:LTR ENCL SIZE:
TITLE: OR Submittal: General Distribution S NOTES:
RECIPIENT COPIES RECIPIENT COPIES ID CODE/NAME LTTR ENCL ID CODE/NAME LTTR ENCL PD2-2 LA 1 1 PD2-2 PD 1 1 D EDISON,G 5 5 1 D
INTERNAL: NRR/DET/ECMB 9H 1 1 NRR/DOEA/OTSB1 1 1 - 1 NRR/DST 8E2 1 1 NRR/DST/SELB 8D 1 1 i S NRR/DST/SICB 7E 1 1 NRR/DST/SRXB 8E 1 1 NUDOCS-ABSTRACT 1 1 1 0 OGC/HDS2 1 0 REG FILE 01 1 1 RES/DSIR/EIB 1 1 EXTERNAL: LPDR 1 1 NRC PDR 1 1 NSIC 1 1 I
D D
D NOTE TO ALL "RIDS" RECIPIENTS:
PLEASE HELP US TO REDUCE WASTE! CONTACT THE DOCUMENT CONTROL DESK, ROOM Pl-37 (EXT. 20079) TO ELIMINATEYOUR NAME FROM DISTRIBUTION LIKES FOR DOCUMENTS YOU DON'T NEED!
TOTAL NUMBER OF COPIES REQUIRED: LTTR 21 ENCL 19
1 P I t 0
I l
u
P.O. Box 029100, Miami, FL, 33102-9100 JUL 23 SSO L-90-277 U.S. Nuclear Regulatory Commission Attn: Document Control Desk Washington,,D. C. 20555 Gentlemen:
Re: Turkey Point Units 3 and 4 Docket Nos. 5-250 and 5-251 Request for Additional Information on Emergency Power System Enhancement Project Tac Nos 69023 and 69024 By letter L-88-269, dated June 23, 1988 as supplemented by letter L 89 124r dated April 3r 1989r and letter L-90-196 dated June 4, 1990, FPL provided the Emergency Power Systems (EPS) Enhancement Report to the NRC staff. NRC Letter dated July 5, 1990, requested additional information regarding the Load Sequencer (LS), the Programmable Logic Controllers that comprise the LS, and implementation of this system in the Turkey Point Plant. Enclosed please find the additional information as requested.
Should there be any questions, please contact us.
Very truly yours,
//Y- ~q/
Vice President Turkey Point Plant Nuclear KNH/OIII/oih cc: Stewart D. Ebneter, Regional Administrator, Region II, USNRC Senior Resident Inspector, USNRC, Turkey Point Plant Enc1osure 90080iOi60 900723 PDR ADOCK 05000250 P PDC an FPL Group company
r.
~ >r I
.go~>"'~ "s ~
ENCLOSURE
References:
- 1. "Turkey Point Emergency Power System Enhancement Report (EPSER), Supplement No. 1 - Testing", Florida Power & Light Company Letters L-89-124 (Rev 0) dated April 3, 1989 and L-90-196 (Rev 1) dated June 4, 1990.
- 2. ANSI/IEEE-ANS-704.3.2-1982, "American National Standard, Application Criteria for Programmable Digital Computer System in Safety Systems of Nuclear Generating Stations.
- 3. US NRC Regulatory Guide 1.152, "Criteria for Programmable Digital Computer System Software in Safety-Related System of Nuclear Power Plants,"
November, 1983.
Attachment:
Verification and Validation Plan for the Emergency Diesel Generator Load Sequencer for Florida Power and Light Turkey Point Units 3 and 4.
RAI 1 Describe your plans for performing or reviewing the Verification and Validation (V&V) of the Allen-Bradley PLCs. If the V&V has been performed, provide the documentation of the V&V results. If there is no V&V, how will FPL assure the adequacy of the A-B.PLCs for lE applications?
Res onse to RAI 1 The plan for United Controls Inc's (UCI's) (of Stone Mountain, GA) verifications of the Allen-Bradley Programmable Logic Controllers (PLCs) is described in the attached Verification and Validation Plan (Section 4.3). UCI shall also validate the Allen-Bradley PLCs in accordance with the V&V plan (Sections 5.0 & 6.0) during the operational (functional) testing, when the entire system will be tested prior to shipment, FPL will review the UCI generated procedures and reports, and will witness testing performed by UCI, V&V documentation will be available after shipment of the Load Sequencers from UCI (estimated November 1990).
RAI 2
Describe your plans for performing or reviewing the V&V of the United Controls Inc. LS. If the V&V has been performed, provide the documentation of the V&V results. If there is no V&V, how will FPL assure the adequacy of the LS for lE applications7 Res onse to I 2 UCI will perform the V&V of the Load Sequencers according to the attached V&V Plan. FPL will review the UCI generated procedures and reports, and will witness testing performed by UCI. V&V documentation will be available after shipment of the Load Sequencers from UCI (estimated November 1990).
Page 1 of 7
RAI 3
Reference 1 implies the existence of a procedure for checking control cabinet instruments and logic. Provide a discussion of the acceptance criteria addressed in this procedure.
es onse to RAI 3 The control cabinet instruments and all logic functions will be initially tested under the guidelines of UCI's V8V program. The following LOOP, LOOP/LOCA scenarios will be tested during this V8V program:
- 1. LOOP
- 6. LOCA same train
- 7. LOCA other unit
- 8. HI-HI containment pressure concurrent or less than 13 seconds after a LOCA or LOOP/LOCA
- 9. HI-HI containment pressure later than 13 seconds after a LOCA or LOOP/LOCA The Reference 1 acceptance test will demonstrate that the onsite electrical distribution system adequately supports the necessary systems during a simulated emergency condition. The PLC logic will be tested during the Integrated Preoperational Test. The PLC will be verified for bus stripping and clearing, EDG start, EDG breaker closure and sequencer timing intervals with load starting as required for the following plant conditions:
LOOP LOOP with LOCA LOCA with EDG Loaded to Offsite Power LOCA LOCA with LOOP Unit LOOP, LOCA and HI-HI Containment Pressure (HHCP)
LOOP plus Other Unit LOCA Refer ence 1 states the LS function will be tested "continuously". Provide the frequency of this testing algorithm, and discuss coordination of testing with normal LS operations.
Res onse to RAI 4 An automatic self-test mode will provide continous surveillance of sequencer operation, from its logic input signals through the logic and counter states, relay drivers and continuity through the relay coils.
Page 2 of 7
The time to complete the automatic test for all scenarios is 179 seconds, with one (1) second between one test and the next test. Each scenario (LOOP, LOOP/LOCA, LOCA, etc.) is tested in succession. When each automatic test has been completed, the process is repeated.
The time to reset from a test and respond to a valid input is based on positive monitoring of blocking relays being off (no blocking relays energized), and all timers reset. The maximum time for this function is expected to be less than or equal to 0.3 seconds. Actual time will be determined and verified during initial testing under the guidelines of UCI's V&V program.
RAI S Describe the methods by which a loss of LS function is detected and mitigated, to include the steps required to recover LS function. For example, are watchdog timers included in the LS design.
es o se to I 5 A watchdog timer function is built into the processor which is an annunciated failure. All other failures are per UCI Logic Diagrams (PLC input and output failures, Strip and Sequence Relay Failure, processor malfunction, power failure, and EDG breaker failure to close). The watchdog timer monitors events which occur periodically as a measure of proper function. FPL op rating procedures are being revised to incorporate manual action, bypass the PLC, to strip the buses, start the EDG and load the equipment necessary for safe shutdown onto the EDG should an LS fail to operate.
RAI 6
Provide the PLC Surge Withstand Capability (SWC) specification, and justify the margin between the SWC and expected surges. Describe the PLC power sources.
Res onse to RAI 6 The following information provided by Allen-Bradley reflects the PLC equipment's response to SWC.
A NEN Noise Susceptibility test is performed by Allen-Bradley in accordance with NET ICS 2, Part 2-230 8 NEN ICS 3, Part 3-304.42. The test subjects the equipment to electrical noise which is commonly produced by electrical contacts interrupting inductive loads.
A Surge Transient Susceptibility (SWC) test is performed by Allen-Bradley in accordance with IEEE-472-1974 and ANSI C37.90a-1974. The test subjects the equipment to the type of electrical spikes that are generated by switching relays.
Page 3 of 7
Class 1E power will be provided with regulated 120VAC supply from the station inverter instrumentation supplies. A 125VDC supply from the station DC system will be provided for the PLC annunciator. Solidstate Controls Inc., the manufacturers of the battery chargers and inverters expects maximum surges of 20% above normal. These surges may be caused by input voltage transients and/or load increases or decreases. The above information substantiates sufficient margin between SWC and expected surges.
RAI 7
Provide the PLC Electromagnetic Interference (EHI) specifications, and justify the margin between the EHI specification and expected EMI.
Res onse to RAI 7 The following information provided by Allen-Bradley reflects the PLC equipment's response to EHI.
Two EMI tests are performed. A Radiated Electromagnetic Susceptibility test is performed by Allen-Bradley in accordance with SAMA Standard PMC 33. 1-1978 & IEC Standard 801-3, Edition 1, 1984. This test subjects the equipment to electromagnetic fields simulating those generated from portable radio transceivers or similar devices. Additionally, a Conducted Electromagnetic Susceptibility test is performed by Allen-Bradley for AC line-connected equipment. This test performed in accordance with HIL-STD-461/462 tests CS01, CS02 & CS06 for Class A3 equipment.
QQ 8 NRC RG 1.152, which endorses Reference 2, is not included in Section 8.0 of Reference 1. Provide documentation of the acceptance criteria for the LS system, and justify differences between the FPL acceptance criteria and the Reference 2 criteria.
Res onse to RAI 8 The computer system validation will be performed per FPL'S V&V Plan. Also see the responses to RAIs 1 and 2. These tests, satisfying the requirements imposed by Reference 2 (as endor sed by RG 1.152), will consist of verifying that the static and dynamic system requirements are acceptable and satisfactorily meets a DBE for FPL Turkey Point Plant - Units 3 & 4.
Page 4 of 7
RAI lE certification of the 9'lass PLCs was not discussed in the FPL submittal.
Provide this certification.
Res onse to RAI 9 The PLCs will be Class 1E through Commercial Grade Dedication and testing by UCI.
Commercial Grade Item Dedication Procedure No. CID-001 will be used to qualify the PLCs and related equipment. Test Procedure No. WT-1262 will be used for Wyle test of the PLC.
RAI 10
Describe FPL's configuration control after LS installation.
Res onse to RAI -10 The software program (Ladder Logic-Drawings) will be controlled using the existing FPL gA program. Subsequent revisions will be made via FPL's plant change process. Any technical change requires an Engineering Evaluation and Attendant 10CFR50.59 Evaluation.
RAI 11
Describe site acceptance/preoperational testing: specifically address loss and restoration of power to the PLCs during standby or operation. Describe memory-retention capability.
Res onse to RAI ll-Refer to response RAI 3 for site acceptance/preoperational testing for the PLC.
During preoperational testing power will be removed from the PLC and all programmable functions will be verified to function per design upon restoration of power to the PLC. The memory contains on-board battery back-up capable of retaining all stored program data through a continuous power outage for 12 months. The expected life of this battery is approximately 3 years. The battery will be replaced each refueling outage. Low battery voltage is detected by the processor and annunciated as a Sequencer Trouble alarm in the Control Room.
RAI 12
Are there any methods installed to manually bypass the PLC and load the EDGs?
Res onse to RAI 12 To manually bypass the PLC and load the EDG(s) the operator can remove power from the PLC through a key-lock switch located at the PLC. Then required equipment can be manually loaded.
Page 5 of 7
/~1~3 Provide MTTF and MTTR documentation for the PLCs.
Res onse to I 13 The following HTBF data is calculated from results of Allen-Bradley field history. (HTBF MTTF + HTTR)
E UIPHE T M BF HTTR
- 1772-LXP (processor) 172,030 hrs 15 min 1771-IAD (I/O Module) 2,114,194 hrs 15 min 1771-OW (I/O Module) 1,077,596 hrs 15 min 1771-OAD (I/O Module) 584,132 hrs 15 min 1771-OZL (I/O Module) 1,025,539 hrs 15 min 1771-P4 (power supply) 873,334 hrs 15 min
- Time does not include programming, testing and declaring operational.
R~I~I Describe interfaces with non-1E systems (e.g., annunciators). Discuss methods of isolating 1E systems from non-1E systems.
es onse to I 14 The only non-lE system the PLC interfaces with is the plant annunciator system.
The PLC is optically isolated from the plant annunciator system up to surges of 1500V. See the response to RAI 6.
Qg 15 Provide a description of the devices used in the LS (e.g., programming language, compiler, microprocessors, etc.).
Res onse to 15 Software used is as follows:
A. PLC Program Development 5. Documentation Software CAT. No. 6203-PLC2 Part No. 99874202 Release No. ¹2. 1 This program is used as a "tool" to program the processor to perform the developed system logic.
Page 6 of 7
B. PLC-2 Utilities Software CAT. No. 6203-PL'C2 Part No. 99884202 Release No. 2.1 This program is used as a "tool" to configure the peripheral hardware connected to the processor.
Programming is done in ladder logic format in accordance with Allen-Bradley user manual publication 6200-6.5.9. No compiler is necessary, the programming is done directly with the microprocessor . The format used is communicated using the OP codes and then this information is "interpreted" by the processor into the proper commands.
The following two microprocessors are utilized for the Allen-Bradley PLC-2/16:
- 1) Intel 80C188
- 2) Intel 80C51 Page 7 of 7
ATTACHMENT fPL Response to NRC RAI, dated July 05, 1990 VERIFICATIONAND VALIDATIONPLAN FOR THE EMERGENCY DIESEL GENERATOR LOAD SEQUENCER FOR FLORIDA POWER AND LIGHT TURKEY POINT UNITS 3 AND 4 REVISION 0 PAGE 1 OF 11
ATTACHMENT FPL Response to NRC RAI, dated July 05, 1990 TABLE OF CONTENTS PAGE NUMBERS
- 1. SCOPE
- 2. DEFINITIONS
- 3. VERIFICATION OF HARDWARE RE UIREMENTS
- 4. VERIFICATION OF SOFTWARE 4.1. VERIFICATION OF SOFTWARE REQUIREMENTS 4.2 VERIFICATION OF NEW SOFTWARE DESIGN 4.3 VERIFICATION OF PREVIOUSLY DEVELOPED SOFTWARE 4.4 VERIFICATION OF SOFTWARE IMPLEMENTATION 4.5 VERIFICATION OF HARDWARE/SOFTWARE INTEGRATION
- 5. SYSTEM VALIDATION 5.1 SYSTEM TEST PROCEDURE 5.2 SYSTEM TEST REPORT SPECIAL HARDWARE VALIDATION
- 7. REVIEW AND AUDIT PROCEDURES
- 8. VERIFICATION AND VALIDATION REPORT 10 REVISION 0 PAGE 2 of ll
ATTACHMENT FPL Response to NRC RAI, dated July 05, 1990
- 1. SCOPE l
This document defines the progr am used to verify and validate the software design and implementation of the programmable logic controller (PLC) employed in the Emergency Diesel Generator Load Sequencers (hereinafter referred to as the Sequencers) for Turkey Point Units 3 and 4. The Sequencers are required to perform the function of emergency bus load shedding and on-site emergency diesel generator loading when there is an accident and/or undervoltage trip of the emergency bus. The Sequencers are considered Seismic Category I, Nuclear Safety Related.
The Sequencers are designed, implemented, and tested by United Controls, Inc.,
using requirements provided by Florida Power and Light and Ebasco. Project responsibilities for each phase of this V 8 V program are defined in each applicable section.
Verification and Validation (V8V) is the method to systematically assure that the computer system meets the functional requirements; and that the system is implemented such that there is a predictable response to every stimulus and that response is not contrary to the purpose of the system.
The primary emphasis of this plan will be to establish the following principles which have been proven to be very effective in software development programs:
- l. Well defined system requirements
- 2. A comprehensive software development methodology
- 3. Comprehensive testing procedures 4, Independence of the V8V reviewer from the development organization
- 2. DEFINITIONS a lications software - Software developed to perform a specific function baseline - Software which has been formally reviewed and can only be changed using formal change control procedures.
chan e control rocedures - Procedures, formally approved and maintained by the software development organization, used to control changes to software.
com uter ro ra - A sequence of instructions expressed in a form suitable for execution by a programmable digital computer.
confi uration ite - A configuration of hardware or software elements treated as a unit for the purpose of configuration control.
REVISION 0 PAGE 3 of ll
ATTACHMENT FPL Response to NRC RAI, dated July 05, 1990
- 2. Definitions (continued)
I confi uration control - The process of identifying and defining the configuration items in a system, and controlling the release and change of these items.
error - a discrepancy between the observed or measured value or condition and the true, specified, or theoretically correct value or condition.
~interru t - The capability to respond to external or internal events which change the normal program flow.
software - Computer programs and data software ualit assurance lan - A plan for the development, implementation, and maintenance of software products necessary to provide adequate confidence that the software conforms to established requirements.
s stems software - Software designed for a specific computer device to facilitate the development, operation, and maintenance of applications software.
~testin - The process of exercising or evaluating a system or system component by manual or automated means, to verify that it satisfies specified requirements.
test case - A specified set of data and associated procedures developed for a particular objective, such as to exercise a particular program path or to verify compliance with a particular requirement.
validation - The test and evaluation of the integrated computer system to ensure compliance with the functional, performance, and integration requirements.
verification - The process of determining whether or not the product of each phase of the development process fulfills all the requirements imposed by the previous phase.
- 3. VERIFICATION OF HARDWARE RE UIREHENTS The hardware documentation requirements necessary to meet IEEE603-1980 for the Sequencer shall be supplemented with documentation of hardware requirements which impact software. The hardware specifications shall include (as required):
- 1. All input/output and requirements, including range, accuracies and data rates.
REVISION 0 PAGE 4 of ll
ATTACHMENT FPL Response to NRC RAI, dated July 05, 1990
- 3. Verification of Hardware Requirements (continued)
- 2. Design features (e.g., keylocks) which provide administrative control of all devices capable of changing the content of the stored programs or data.
- 3. Initialization requirements, such as power-up and power-down.
- 4. Design features for the detection of system failures (e.g., on-line self tests).
- 5. Manually initiated in-service test or diagnostic capabilities.
- 6. Human factors engineering design features which ease the interaction with the Sequencer for operation, maintenance, and testing.
- 7. Hargins for timing, memory/buffer size, etc., including minimum margins for design.
- 8. Interrupt features.
The documentation shall be prepared by UCI for the Sequencer project. This documentation shall then be reviewed by UCI individuals independent of the development organization with skills similar to those individuals performing the development. All observations and conclusions resulting from the verification review shall be transmitted to the design organization in written format, and saved for inclusion in the final V&V Audit Report. Problems shall be immediately resolved, obtaining FPL or Ebasco concurrence when required.
- 4. VERIFICATION OF SOFTWARE The Sequencer software must be prepared and documented using written UCI software quality assurance procedures. This procedure shall include the following areas:
- l. Hanagement organization, tasks, and responsibilities
- 2. Documentation requirements
- 3. Standards, practices, and conventions used in software development Review and audit procedure
- 5. Software configuration management and control
- 6. Problem reporting and corrective action.
- 7. Software verification and validation The plan shall define what software products it applies to or state that it applies generically to all software products produced.
Software verification activities shall be performed by individuals independent of the development organization with skills similar to those performing the development. All observations and conclusions resulting from the verification review shall be transmitted to the design organization in written format, and saved for inclusion in the final V&V audit report. Problems shall be immediately resolved, obtaining FPL or Ebasco concurrence when required. Verification activities shall be auditable, with all review comments resolved and documented to the reviewer's satisfaction.
REVISION 0 PAGE 5 of ll
ATTACHMENT FPL Response to NRC RAI, dated July 05, 1990 4.1 VERIFICATION OF SOFTWARE REQUIREMENTS UCI shall perform a verification of software requirements for the Sequencer to ensure that requirements used in the design process are adequately documented and can be validated by test or analysis. All requirements transmitted to UCI by FPL or Ebasco shall be independently verified by the organization providing the design input to ensure that all Turkey Point plant safety related design issues are realized in the design of the Sequencer.
The software requirements to be documented and verified shall include:
- 1. Process inputs including voltage and sampling frequency.
- 2. System software, utility routines and other auxiliary programs required for operation of the Sequencer.
- 3. Algorithms to be programmed with consideration to handling of abnormal events.
- 4. Data files and data required for the algorithms, including symbolic names an requirements for flexibility.
- 5. Process outputs, including ranges, accuracies, update interval, and human factors considerations of the operator interface.
- 6. Initialization requirements, such as initial values and start-up sequence.
- 7. Program logic for response to detected failures.
- 8. Operator interface requirements (switches, readouts).
- 9. In-service test or diagnostic capabilities.
- 10. Timing requirements for all time dependent events, including overall system requirements.
- 11. Limitations on processor time and memory capabilities.
- 12. Security requirements (e.g., passwords).
4.2 VERIFICATION OF NEW SOFTWARE DESIGN UCI shall perform a verification of the Sequencer software design to ensure that the design requirements (verified as described in Section 4. 1) are adequately translated into Programmable Logic Controller (PLC) logic blocks and data structures. The design documentation shall address all software requirements and provide a correlation of the design elements with the software requirements. In addition, the verification shall answer the following questions:
- 1. Is the design correct and complete?
- 2. Is the design internally consistent?
- 3. Is the design feasible?
- 4. Is the design clear and unambiguous?
- 5. Is the design testable?
4.3 VERIFICATION OF PREVIOUSLY DEVELOPED SOFTWAR Software procured by UCI shall not be utilized until it has been placed under configuration control and procedure established to validate its use in the REVISION 0 PAGE 6 of ll
ATTACHMENT FPL Response to NRC RAI, dated July 05, 1990 4.3 Verification of Previously Developed Software (continued)
Sequencer development. This Software Control Procedure shall be developed and independently verified by UCI. The Software Control Procedure (SCP) shall address the following:
The software used and its documentation shall be maintained and controlled during development, implementation, and testing.
Procedures shall state how verification of the configuration is to be accomplished, to assure that the software for testing is the same as that used for the final system.
- 2. The software and its use shall be described in sufficient detail for an independent verification to determine the impact of using this software for the Sequencer. This description would include the following:
- a. Adequacy of the documentation (complete, unambiguous, and consistent with the software).
User interface with the software.
Use of the software in development of the ladder logic.
What control the software has over the final output; e.g., is the software primarily used as a documentation tool or does it influence the exact software running in the PLC.
- e. A description of how the software will be used to make changes to the sequencer after installation.
- 3. A method of notifying FPL if errors are discovered in use of this program after installation which may affect Sequencer operation.
4, A determination of what, if any, additional documentation, testing, or reviews are required to validate the use of this software in the Sequencer development.
UCI gA shall audit the development, implementation, and testing of the Sequencer to document compliance with the SCP. Audit results shall be submitted to FPL for review as part of the Verification and Validation report, with certification that the procured software (Name, manufacturer, part/model number, revision) is acceptable for use in the Sequencer development.
- 4. 4 VERIFICATION OF SOFTWARE IMPLEMENTATION UCI shall perform a verification of the software implementation for the Sequencer to ensure the design has been translated correctly into PLC logic. Procedures to specify the PLC programming techniques, documentation standards, coding conventions, and test requirements shall be developed and independently verified to assure complete and accurate implementation. Verification activities shall address the following:
REVISION 0 PAGE 7 of ll
ATTACHMENT FPL Response to NRC RAI, dated July 05, 1990 4.4 Verification of Software Implementation (continued)
Are the comments provided sufficient to provide an adequate description of the logic?
- 2. Is the logic consistent with the design?
- 3. Is there satisfactory error checking?
Is the logic clear and understandable?
- 5. Is the source media (tape, disk, etc.) under configuration control?
4.5 VERIFICATION OF HARDWARE SOFTWARE INTEGRATION UCI shall perform a verification of the hardware/software integration of the sequencer to assure the adequacy of the interfaces between the hardware and the software. The hardware/software integration plan may be part of the final system validation test procedure and shall include:
A plan for integrating the hardware and software, including loading the software and checks to assure the software is properly loaded.
- 2. Test procedures and associated acceptance criteria to demonstrate the adequacy of the hardware/software interfaces. Examples would be correct response to operator keyboard/switch/pushbutton input; and correct output to CRT displays, lights, LED's etc.
- 3. The test configuration for the computer system.
The quality assurance activities involved in the hardware/software integration and for controlling subsequent changes.
The hardware/software integration plan shall be independently verified by UCI.
- 5. 0 SYSTEM VALIDATION The software validation consists of preparation and independent verification of a test procedure; execution of the tests; and documentation with independent verification of the test results.
The system validation test-plan shall be developed, the tests executed, and the test results evaluated by individuals who did not participate in the software design or implementation.
5.1 SYSTEM TEST PROCEDURE System validation test procedures shall be prepared by UCI based upon the requirements of the design, and shall include test cases encompassing the range of usage intended for the Sequencer. Test procedure(s) shall specify the following:
REVISION 0 PAGE 8 of 11
ATTACHMENT FPL Response to NRC RAI, dated July 05, 1990
- 5. 1 System Test Procedure (continued)
- l. Identification of the test cases.
- 2. Description of the test cases.
- 3. Relationship of the test cases with the requirements and testing of all logic branches.
Expected results of the test cases with acceptance criteria.
- 5. Special requirements or conditions for the test, such as hardware configuration, monitoring hardware or software, sequencing of tests, etc.
- 6. The simulation of the plant and plant systems shall be documented, including any special hardware or software required for these simulations.
- 7. An indication of how to evaluate the test results to determine technical adequacy. For example, results may be compared with results obtained from alternate methods such as: Analysis without computer assistance; experiments and tests; standard problem of known solutions; or confirmed published data.
- 8. Procedures to report errors found during testing, and acceptable means of retesting these errors after error correction has been performed. These procedures and error correction shall be independently verified in accordance with this V8V plan.
The system validation test procedure(s) shall be independently verified by UCI to ensure they address the following:
A. Is the test procedure description complete?
B. Are the test problem definitions adequate and complete?
C. Is each testable requirement adequately covered?
D. Is the plan for evaluating and reporting test results adequate?
5.2 SYSTEM TEST REPORT The software validation test(s) shall be documented in a report. The report can consist of a completed copy of the test procedure with all blank information completed, such as:
- l. Computer software tested.
- 2. Hardware used (model number/serial number).
3.
4, Test equipment used and calibration data, Date of test and personnel performing the test.
if applicable.
- 5. Test problems.
- 6. Results and acceptability.
- 7. Action taken in connection with any deviations noted. Errors and their correction shall be documented and independently verified in accordance with this procedure.
REVISION 0 PAGE 9 of 11
ATTACHMENT FPL Response to NRC RAI, dated July 05, 1990 5.2 System Test Report (continued)
The software validation test report(s) shall be independently verified by UCI to ensure they address the following:
A. Do the test results comply with the format specified in the test procedure?
B. Do the test results provide an accurate statement of the testing performed're C. the test results acceptable and auditable by persons not involved with the test?
6.0 SPECIAL HARDWARE VALIDATION Validation testing of special hardware requirements, such as seismic and environmental requirements, will require the Sequencer to be running software exercising the system hardware to ensure full system functionality is demonstrated before, during, and after the one-time tests. This software must sufficiently exercise system hardware and software functions to assure the seismic and environmental testing is applicable to the final system configuration. The methodology to be employed by UCI for verification and validation is identical to that described in sections 3, 4, and 5 of this specification.
7.0 REVIEW AND AUDIT PROCEDURES All technical reviews of design documentation, specifications, and test procedures shall be conducted using the following format:
Objective implemented of the review (e.g., Review to determine software meet the design stated in the software if the requirements documentation).
- 2. Criteria to meet the objectives of the review (e.g., to answer the questions in section 4.2 of this plan).
- 3. gualification of -the personnel conducting the reviews (e.g.,
resumes).
State any activities which must be performed prior to the review (e.g., required reading of reference material).
- 5. Agenda and schedule for the review, with a list of all data and documentation required for the review.
- 6. The decisions or activities which may be affected by this audit (e.g., testing may not proceed without an approved and verified test procedure).
All significant observations and conclusions shall be documented in the verification and validation report.
REVISION 0 PAGE 10 of 11
ATTACHMENT FPL Response to NRC RAI, dated July 05, 1990 8.0 VERIFICATION AND VALIDATION REPORT UCI shall prepare a V&V report which provides:
A listing of all V8V documentation produced. This documentation shall include records of the following reviews as a minimum:
Hardware design requirements review; Software design requirements review; Audit results of previously developed software; Software implementation review; Hardware/software integration review (if separate from validation testing); and test procedure/test report review. All reviews shall be conducted in a similar manner and have the following format (as a minimum):
- a. Review summary
- b. Recommendations (including any requirements for further reviews).
- c. Detailed review comments and resultant actions.
- 2. A Requirements Traceability Hatrix which provides a listing of where each system function is defined, documented, implemented, and tested. A possible format is:
Requirements Design Test S stem Function Doc. Reference Doc. References Procedure Reference
- 3. A listing of deficiencies detected with corrective action taken.
An evaluation of the Sequencer based upon the V8V.
- 5. Comments and recommendations to aid in future system upgrades and development.
- 6. A Software Code Certificate for each separately identifiable software item which states that the code is approved for its intended application and lists:
- a. Name
- b. Code/Model/Part Number
- c. Revision/Version Number
- d. Applicable computer system
- e. Signature and date for the authorized UCI Engineering person(s).
- f. Signature and date of the person independently verifying the V8V report.
The V&V. report shall be formally submitted to FPL for review.
REVISION 0 PAGE 11 of ll
tE 4