ML20045D105
| ML20045D105 | |
| Person / Time | |
|---|---|
| Issue date: | 03/11/1993 |
| From: | Lewis H Advisory Committee on Reactor Safeguards |
| To: | Advisory Committee on Reactor Safeguards |
| References | |
| ACRS-2865, NUDOCS 9306250333 | |
| Download: ML20045D105 (12) | |
Text
i
- ~
~
CERTIFIED BY:
9 H. Lewis - 3/11/93 ADVISORY COMMITTEE ON REACTOR SAFEGUARDS COMPUTERS IN NUCLEAR POWER PLANT OPERATIONS SUBCOMMITTEE MEETING MINUTES:
QUANTITATIVE SOFTWARE ASSESSMENT and ANALOG-TO-DIGITAL INDUSTRY EXPERIENCE FEBRUARY 9, 1993 BETHESDA, MARYLAND INTRODUCTION:
The ACRS Subcommittee on Computers in Nuclear Power Plant Operations held a meeting on February 9, 1993, in Room P-110, 7920 i
Norfolk
- Avenue, Bethesda, Maryland to hear from invited representatives of the computer, software development community on the subject of developmental techniques and quantitative risk assessment methods for use with nuclear power plant safety-related sof tware-based instrumentation and controls systems. Additionally, the Subcommittee heard from three utilities on their implementation of digital retro-fits for the replacement of analog instrumentation systems.
The entire meeting was open to public attendance.
Mr. D.
Coe was the cognizant ACRS staff engineer for this meeting.
The presentation schedule for the meeting is attached. The meeting was convened at 8:30 am and adjourned at 4:05 pm.
ATTENDEES:
ACRS H. Lewis, Chairman J.
Carroll, Member I.
Catton, Member T.
Kress, Member P.
Shewmon, Member C. Wylie, Member R.
Kemmerer, Consultant P.
Place, Consultant D.
Coe, ACRS staff PRESENTERS R.
Cobb, Software Engineering Technology, Inc.
T.
Pietrangelo, NUMARC G. vanNooredenn, Northeast Utilities R. Plappert, Southern California Edison R. Gladney, Tennessee Valley Authority gg NRC STAFF DESIGNATED ORIGINAL g
J. Wermiel, NRR/DRCH/HICB
,..,.,g W
J. Mauck, NRR/DRCH/HICB h
Y F. Coffman, RES/DSR/HFB hg A complete attendance list is included in the attachment.
D\\
9306250333 930311
Minutes of ACRS Subcommittee i
on Computers in NPP Operations February 9, 1993 Chairman's Openino Remarks Dr. Lewis, the Subcommittee Chairman, convened the meeting at 8:30 am and stated that the purpose of the meeting was to hear presentations by and hold discussions with representatives of the software development community and the utility industry regarding their experiences and views related to the application of digital technology to the instrumentation, control, and protection systems of nuclear power plants.
There were no written comments or requests for time to make oral statements received from members of--
the public.
DEVELOPMENT AND CERTIFICATION OF CORRECT SOFTWARE FOR SHUTDOWN SYSTEMS IN NUCLEAR POWER PLA.NTS - Mr. Richard H.
Cobb. Software Engineering Technoloov, Inc.
Mr. Cobb presented a paper on the principles of the "Cleanroom" approach to software development as put forth by himself and Dr.
I Harlan Mills of SET, Inc.
The name "Cleanroom" draws an analogy to computer chip manufacturing, in which the chips are created in an ultra-clean room to avoid introducing deficiencies which must be detected after manufacture.
Applying this same principle "Cleanroom" engineering, as developed by Dr.
- Mills, uses a
structured and mathematical approach to software development.
I Mr. Cobb addressed the following questions which he stated were of concern to the ACRS, NRC, and industry.
i Is it feasible to produce correct software?
Mr. Cobb stated that using mathematical based ergineering methods such as "Cleanroom," it is possible to develop a correct program and to prove its correctness.
He postulated that for an " average" reactor protection system channel (one of four identical channels), an estimated 12,000 to 20,000 lines of code would be required.
This is relatively small and therefore amenable to a formal proof of correctness.
He noted most software development. efforts today omit a proof of correctness, but that in a public regulatory environment such as nuclear
- power, recording such a
proof enables all interested parties (including the regulator) to evaluate its adequacy.
Dr. Lewis pointed out that between the extremes of the very simple and the very complex lie the real systems which will have to be evaluated.
Mr. Cobb responded that actual tests of software systems of up to 300,000 lines of code created using these methods have not yet experienced failure, and that the
-2
Minutes of ACRS Subcommittee on Computers in NPP Operations February 9, 1993 proofs required for the more simple nuclear shutdown systems are achievable.
Mr. Cobb agreed with Dr. Lewis that not having yet experienced failure during testing did not constitute a " proof" of correctness.
What engineering practices should be followed to produce failure-free software?
Mr. Cobb stated that much of the software written today is developed using a " craft" approach, which views a piece of software as a linear set of instructions created with a specific structure, but which must be debugged following.
completion.
The debugging process often introduces inadvertent additional-errors which can be harder to detect than the original bug.
Conversely, the "cleanroom" approach views software as a black box function which maps inputs to desired outputs. Once this function is specified, it can then be expanded into code by a series of stepwise refinements, each followed by a verification algorithm or proof.of correctness.
Following completion of the sof tware construction process, the "cleanroom" approach uses a Markov model to define probability density functions of input conditions which then provide the testing regimen.
Rather than using such testing to find-program bugs (as is done in craf t-based sof tware development),
Markov testing is used _ to confirm the already existing hypothesis that the software is correct.
Mr. Cobb added.that the testing regimen should also. include tests of boundary and near-boundary input conditions, as well.as inputs which may cause the most significant failures.
Furthermore, the Markov model accounts for the probability that one input state will
~
transition to one of many others,.as well as the probability
~
i that any given input state exists.
i Dr. Shewmon asked if such testing would account for what f
happens during power supply disruptions.
Mr. Cobb' replied i
that various degrees of power supply disruption could be made part of the input / output
" black box" specifications, or alternatively, beyond a given threshold these disruptions could. simply be recognized by the software as outside the input domain, with a selected response specified for all such inputs.
\\
~
Minutes of ACRS Subcommittee on Computers in NPP Operations February 9, 1993 i
Is it feasible to correctly specify the functions which the i
software is to perform?
Mr.
Cobb discussed the process of specifying the desired behavior of a representative shutdown channel.
This involv~-
dissecting the channel into software " components," each t a
specific
- mission, from which individual componet specifications are developed.
The composite behavior of al.t integrated components within a channel is verified to form to the desired behavior.
Common-mode failure risk due to faulty software logic is minimized by an appropriate selection or integration of various software components.
Mr.
Cobb emphasized that this process would be the same for non-software components.
What engineering practices should be followed to produce i
correctly specified software functions?
Mr. Cobb discussed the concept of viewing sof tware as a " black box" which provides a given response for each unique sequence of stimuli.
The "Cleanroom" specification for the black box consists of six distinct parts:
a mission statement, the stimuli / response options, the function which defines responses versus stimuli histories, a validation of the function, the Markov probability density function for moving from one input state to any other state, and a construction plan for building the system in a series of small increments.
Mr.
Cobb briefly discussed defense against common-mode software logic failure by stating that the NRC defense strategy of quality and diversity could be accommodated by using "Cleanroom" methods to achieve quality and to do so with more than one safety system (for diversity).
He also commented that common-mode failure of hardware or software specifications could be minimized by use of black box functions.
What methods should regulators follow to determine the probability the licensed software is correct and will provide failure-free performance?
Mr. Cobb stated that nuclear safety regulators should require safety-critical sof tware developers to retain the incremental proofs of software correctness, as defined by the "cleanroom" approach, and submit them as evidence of having produced correct software.
In addition, he suggested that the NRC should license the sof tware function separately from licensing the implementation of that function.
-4 t
Minutes of ACRS Subcommittee on Computers in NPP Operations February 9, 1993 Mr.
Cobb_ described a suggested IRC review process for licensing software which included checks at several points in the "Cleanroom" process.
These checks could include a review of specification adequacy, a sampling of the proofs documented for software components, review of the certification history, and evaluation of the rigor of the entire process.
What is the probability that regulators will make a licensing error, such that incorrect software is licensed or correct software is not licensed?
Mr. Cobb admitted that he could not address _the probability that a specification would be incorrect, because that would-depend upon the plant designer's knowledge.
However, he reiterating his belief that once the specification was developed, "Cleanroom" methods would ensure the specification was correctly implemented by the software.
Mr. Cobb concluded with the following points.
He believes the size and complexity of current reactor protection systems is amenable to
" formal methods" which he defined as the mathematical engineering approach such as "Cleanroom," versus the more historical " craft-based" process.
He stated that an effective certification method for assuring highly reliable sof tware - would include documented proofs, peer review of those proofs, and use of statistical testing as an added measure of assurance, which would enable greater ef fort to be applied to the more significant question of the correctness of the specifications being implemented by the software.
He assessed the current industry standards as being a codification of the less rigorous " craft-based" approach to software development and suggested these were not, by themselves, adequate to the task of reactor protection software development.
Finally, -he stated that the approach to managing software risk during its development must include simple data handling techniques, easy to prove l
mathematical rules which describe the functions performed by the sof tware, and careful attention to the specifications from a safety
)
standpoint.
ROUNDTABLE DISCUSSION l
.An open discussion took place among the Committee members, consultants, and NRC staff.
Topics that were touched upon included:
potential for unexpected interactions between software components (i.e. memory o"arlap), the inherent complexity of the communication process between two separate processors, the separation between safety and control systems, construction of Markov probability matrices for moving from one state to any other l
L _.
Minutes of ACRS Subcommittee on Computers in NPP Operations.
February 9, 1993 possible state, the difficulty in accurately defining all possible inputs which must be considered, the lack of a consensus definition of "f ormal methods, " common-mode f ailure mitigation strategies, and suggested NRC actions.
Finally, an NRC contractor from Science Applications International Corporation (SAIC) offered comments on the variable human nature of the "Cleanroom" process, the need for automated computer tools to verify software, the need for testing beyond Markov-based methods, and continuous process improvement techniques.
INDUSTRY EXPERIENCES WITH ANALOG-TO-DIGITAL CONVERSIONS Comments of Mr. Tony Pietrancelo. NUMARC Mr. Pietrangelo, NUMARC,. opened this portion of the meeting by stating that NUMARC's role in the analog-to-digital (A/D) issue is one of supporting the Electric Power Research Institute (EPRI),
which has taken a leadership role within industry to facilitate' the introduction of digital technology into nuclear power plants.
He encouraged the Committee to provide its views on the question of how to deal with common-mode failure potential, as the' answer is essential to the resolution of how an Unreviewed Safety Question is determined, which is essential to - the determination of the conditions under which a licensee can perform an A/D conversion without NRC staff review and approval.
?
Comments of Mr. Jerry vanNooredenn and Mr. Mike Brothers, Northeast Utilities Mr.
vanNooredenn discussed the 1991 upgrade performed on the auxiliary feedwater (AFW) instrumentation and control system at Connecticut Yankee (Haddam Neck) and the proposed upgrade to the main feedwater control (FWC) system and portions of the reactor protection system.
Mr. Brothers discussed the use of the Foxboro Spec 200 micro card in the reactor protection (RPS) and FWC systems.
He stated that each card takes.in 59 analog inputs and produces 13 separate trip signals, making it a relatively simple software design.
He noted that the software was designed and.
implemented by the vendor, with input from CY.
A planned digital.
upgrade to the RPS/FWC is being submitted to the NRC for review, even though it is not considered by the utility to be a USQ.
Previous A/D upgrades to the RPS were accomplished under the 10 CFR 50.59 process, but subsequently were reviewed by the NRC staff and found to be acceptable.
Mr. Brothers emphasized the simpl
'ture of the tasks performed by the micro cards, and stated that concerns over digital system J
=
4 Minutes of ACRS Subcommittee on Computers in NPP Operations February 9, 1993 complexity do not apply to a large clats of A/D upgrades such as those done or planned at CY.
He also expressed concern that the lack of replacement analog equipment was forcing the industry.to move toward digital systems in a regulatory environment which lacks clear guidance on the requirements and standards which must be met.
Mr. Carroll asked what failures have occurred in the micro cards at i
CY since installation.
Mr. Brothers stated that two failures have occurred, both of which were immediately detected via an alarm and each time impacted only one out of four protection system channels.
He added that surveillance intervals are chosen to increase the chance that an un-alarmed card failure will be detected.
In response to Mr. Wylie, he stated that no changes had been deemed necessary for the plant grounding system.
Mr. vanNooredenn closed by stating that the NRC standards appear to be a moving target and that Northeast Utilities encourages continuing the NUMARC/NRC dialogue in this area.
Finally, he emphasized the need to allow licensees to make the USO determination for A/D upgrades.
Comments of Mr. Robert Plapoert, Southern California Edison Mr. Plappert discussed a recent simple A/D upgrade made to the radiation monitoring system. at San Onofre Nuclear Generating Station (SONGS).
He emphasized its simplicity in that the principle task of the digital portion of the circuit was to compute the logarithm of an analog input, taking the place of a zener diode which had been previously used for this purpose.
The upgrade was i
motivated by the difficulty of obtaining precision zener diodes, the desire to improve the efficiency of system testing, and the need to reduce spurious system alarms and actuations.
In response to Mr. Wylie, Mr Plappert stated'that no changes had been made to the plant grounding system specifically for the digital upgrade.
Mr. Plappert explained the SCE process by which the software was written and validated, based on IEFE 830.
He also noted that the Failure Modes and Effects Analysis (FMEA) was performed using IEEE 352 for guidance.
This FMEA was done' manually, using electrical schematics, and determined that failure of any upgraded component will be a safe failure.
He concluded by noting that this upgrade was accomplished under 10 CFR 50.59, was determined by SCE to not be a USQ, and has not yet been reviewed by the NRC staff..
.s Mi,nutes of ACRS Subcommittee on Computers in NPP Operations February 9, 1993 Comments of Mr. Rod Gladney. Tennessee Valley Authority Mr. Gladney discussed the installation of the Westinghouse designed Eagle 21 plant protection and control system at the Sequoyah plant.
The motivation for upgrading to the digital Eagle 21 system included reducing calibration time, improving system drift and
- accuracy, reducing inadvertent reactor trip
- risk, automating surveillance testing, and allowing flexibility in channel bypass capability and transmitter upgredes.
He noted that ' TVA made a determination that, under 10 CFR 50.59, the Eagle 21 upgrade was a USQ, based in part on its originality and the uncertainty over the software standards to be applied.
The entire system was described as having approximately 10,000 lines of source cod 3.
The NRC staff reviewed the Westinghouse Verification and Validation (V&V) process, but did not include a line-by-line review of the source code.
In response to Mr. Wylie, Mr. Gladney stated that no changes were deemed necessary to the instrument ground system for the digital upgrade.
Mr. Gladney explained some of the features that were added.to the Eagle 21 system during its implementation at Sequoyah, including hot leg temperature stratification calculations, and steam generator level instrument adjustment for containment environmental conditions.
He submitted that the V&V process performed by independent groups within Westinghouse, in combination with extensive testing and startup calibration checks, was suf ficient to ensure there were no hidden sof tware defects. Additionally, during testing he maintained that the test equipment could not allow access to the program code.
This portion of the meeting concluded with a general discussion on the on-line test capability of the Eagle-21 system, and the hardware and methods employed to perform such testing.
Snhcommittee Action The Subcommittee determined that a draft letter report would be prepared and made available during the full Committee meeting scheduled for February 11-13, 1993.
Follow-un items There were no follow-up items as a result of this meeting.. -.
4 Minutes of ACRS Subcommittee on Computers in NPP Operations February 9, 1993 BACKGROUND MATERIAL PROV~.DED THE SUBCOMMITTEE FOR THIS MEETING 1.
Memorandum from S.
Long and M.
Stella to H.
Lewis, " SELECTED BACKGROUND MATERIAL FOR SUBCOMMITTEE MEETING ON CRITICAL COMPUTER ISSUES, FEBRUARY 9, 1993" dated January 25, 1993, with enclosures.
- 2. Status of Item A-19: DIGITAL COMPUTER PROTECTION SYSTEM excerpt l
from NUREG 0933, Supplement 13, pg. 2.A.19-1, dated 30 June 1991.
3.
Memorandum frr R.
Pulsifer to J.
Hannon, " MEETING
SUMMARY
NUCLEAR MANAGEMEN1 AND RESOURCES COUNCIL (NUMARC), DISCUSSION ON THE DRAFT NUMARC ' GUIDELINE FOR LICENSING NUCLEAR PLANT DIGITAL I&C UPGRADES,'" dated 7 January 1993.
4.
SOFTWARE QUALITY ASSURANCE STANDARDS USED BY THE NUCLEAR
- INDUSTRY, prepared for the ACRS Computer in Nuclear Plant Operations Subcommittee of the Advisory Committee on Reactor
-l Safeguards, by N. Moreau and M.
Pratl, February 1993.
NOTE:
Additional details of this meeting can be obtained from a transcript of this meeting available in the IRC Public Document Room, 2120 L Street, N.W.,
Washington, D.C.
20006, (202) 634-3274, or can be purchased from Ann Riley and Associates, Ltd.,
1612 K Street, N.W.,
Suite 300, Washington, D.C.
20006, (202) 292-3950.
1
-9
)
i l
-m
.i i
I i
1 e.',
+i
+
+
t-
~ ATTACHMEh"I' e
s e
{
'4 s
9
..g s
h i
4 8
e b
i 1
8
..'{
?
?
2 Y
/',
i P
e _
^I I
h
..1 l
l 1
- 1 i
-.I
- 1 i
l 1
' l
!~
i
. )
-m:.
,,,,r-
-i
. Minutes of.ACRS Subcommittee
.i on Computers in NPP Operations February 9, 1993
)
i LIST OF ATTENDEES HRC M. Chiramal, NRR L. Beltracchi, RES F. Coffman, RES J. Gallagher, NRR J. Stewart, NRR J. Joyce,.NRR D. LaBarge, NRR R. Brill, RES H..Pastis, NRR C. Doutt, NRR M. Waterman, NRR J. Mauck, NRR P. Loeser, NRR B. Pulsifer, NRR U.S.
INDUSTRY /GOVERNNENT R. Mullens, NUSME/OSI R.
Plappert, Southern California Edison l
M. Kirk, NUMARC.
P. Place, Software Engineering Institute E. Dailey,' Software Engineering Institute H
R.
Fink, MPR Associates
-i A. Sterdis, Westinghouse J.
Chenard, Atlantic Research R. Torok, EPRI J. Kenner, Software Engineering Technology, Inc.
R. Cobb, Software-Engineering Technology, 7'.c.
P. Harris, SERCH/Bechtel:
k Wyman, Lawerence-Livermore-National Laboratory.
G. Suski, Lawerence Livermore' National Laboratory i
L. Erin, Westinghouse R. Kemmerer, University of California Santa Barbara
.)
P.
Fulton,.LIS
.j J.:Stevens, SEA, Inc.-
1 S'.'Jilek, U.S.1 Department of Energy W Hudnall,1 Asea Brown Boveri.
)
S. Troisi, Arizona Public Service
- l G. Pitman, NUSCO G.-vanNoordennen, Northeast Utilities T.:Cleary, Northeast Utilities
. ATTACHMENT
- 1 i
l
A i
Minutes of ACRS Subcommittee on. Computers in NPP Operations February 9,_1993 M..Bain, Northeast Utilities M. Snodten,.Conneticut Yankee J. Leger, Conneticut Yankee J. Fouger,.Conneticut. Yankee T. Pietrangelo, NUMARC-
.W.
Reuland, EPRI M. Hellums, Tennessee Valley Authority R. Gladney, Tennessee Valley Authority P.
Place, Software Engineering Institute I
s ATTACHMENT
_ _ _ - _