ML20056H398
| ML20056H398 | |
| Person / Time | |
|---|---|
| Issue date: | 08/17/1993 |
| From: | NRC |
| To: | |
| Shared Package | |
| ML20056H383 | List: |
| References | |
| NUDOCS 9309090257 | |
| Download: ML20056H398 (11) | |
Text
F 0R myn t<=
,1 Nib d 0 BRANCH TECHNICAL POSITION (HICB_1 DIGITAL INSTRUMENTATION AND CONTROL SYSTEMS IN ADVANCED PLANTS The following Branch Technical Position (BTP) has been developed to assist the staff in technical judgements during their review of digital instrumentation and control (I&C) systems in Advanced Light Water Reactors (ALWRs). The BTP is primarily an instruction to staff reviewers that outlines an acceptable approach to the technical issues and ensures their uniform treatment by staff reviewers.
The approach taken in the BTP, like the recommendations of regulatory guides, is not mandatory, but does provide defined, acceptable, and immediate solutions to the technical problems and questions of interpretation that arise in the review process. This BTP would be incorporated into tne SRP in a manner similar to existing BTPs.
DEFENSE AGAINST COMMON MODE FAILURES IN DIGITAL INSTRUMENTATION AND CONTROL SYSTEMS BACKGROUND A digital I&C system has a greater degree of sharing of data transmission, functions, and process equipment compared to previous analog systems.
Although this sharing forms the bases for many of the advantages of the digital system, it also raises a key concern.
The concern is that a design using shared data bases and process equipment has the potential to propagate a common cause or common mode failure via software programming errors that can defeat the redundancy achieved by the hardware architectural structure.
Because of this concern, the staff has placed particular emphasis on defense-in-depth against propagation of common rrode failures within and between functions. The principle of defense-in-depth is to provide several levels or echelons of defense to challenges to plant safety, so that failures in equipment and human errors will not result in an undue threat to public safety. The echelons of defense provided by I&C systems are as follows:
- 1) the control systems that regulate plant process variables within specified normal ranges
- 2) the protection systems that initiate a trip of the reactor and place the plant in a safe condition when specified limits are exceeded 3) the engineered safety features actuation systems that provide initiation of essential functions to either maintain the integrity of barriers to the release of radioactive materials or to mitigate the consequences of failures in these barriers in order to control the release of radioactive materials within acceptable limits 4) the monitoring and diagnostic surveillance systems that provide information to the plant operations personnel regarding the state of plant processes and plant equipment 1
9309090257 930817 M
PDR ORG NREA I
The first integrated digital I&C system design reviewed by the staff specifically to address these echelons and defense-in-depth against potential common mode failures was the Westinghouse RESAR-414 design.
The results of this study were published in NUREG-0493, "A Defense-in-Depth and Diversity Assessment of the RESAR-414 Integrated Protection System" (March, 1979). The NUREG discussed common mode failures and different types of diversity, and presented a method for assessing the defense-in-depth of designs.
More recently, the staff described concerns with common mode failures and other digital system design issues in SECY-91-292, " Digital Computer Systems for Advanced Light Water Reactors." This document described an approach to defend against the propagation of common mode failures within the digital I&C systems in future plant designs based on a defense-in-depth and diversity in system design. Application of this approach is described in the staffs safety evaluation of the General Electric Advanced Boiling Water Reactor (ABWR).
The above documents describe how common mode failures could defeat not only the redundancy achieved by the hardware architectural structure but also could result in the loss of more than one echelon of defense in depth provided by the monitoring, control, reactor protection, and engineered safety functions performed by the digital I&C systems.
The two principle factors for defense against common mode / common cause failures are auality and diversity. Maintaining high quality will increase the reliability of both individual components and complete systems.
Diversity in assigned functions, for both equipment and human activities, and diversity in equipment, hardware and software, can reduce the probability that a common mode failure will propagate. The staff has developed the following position on quality and diversity to address the issue of common mode failures:
A.
SOFTWARE OUALITY VIA DESIGN PROCESS Instrumentation and Control (I&C) systems help to ensure that the plant operates safely and reliably by monitoring, controlling, and protecting critical plant equipment and processes. The digital computer based I&C systems for proposed advanced light water reactors (ALWRs). differ significantly from the analog systems used in current operating nuclear plants.
Because of the greater information content of digital signals compared to analog signals and the increased information processing capability of digital equipment compared to analog equipment, the change to digital computer based I&C systems provides the potential for improvements in the safe and reliable operation of nuclear power plants. This potential is achievable through the implementation of highly reliable digital I&C systems for' all service conditions of operation of the equipment.
However, to achieve reliability, special constraints on the system architectural designs and features are necessary and the application of a high level of discipline to the processes associated with the lifecycle phases of design, manufacture, installation, operation, maintenance, and modification of the I&C system is required. Such requirements, however, must also allow for flexibility in the application of the evolving digital computer technology.
2
i i
Under the one-step licensing process of 10 CFR Part 52 for certification of j
standard designs, the staff will approve a nuclear power plant design including the I&C systems through rule making for a 15-year period. However, because the certification process does not require vendor specific information, and because of the desirability to maintain flexibility in order i
to take advantage of evolving digital technology, the level of detail for the I&C systems, particularly the software design aspects will be at a relatisely high level.
Thus, the staff will not " lock-in" design details which may i
become obsolete during the life of the certification.
Rather, the approach that will be used for design certification under 10 CFR Part 52 is to " lock-in" a quality design process and the specific design acceptance criteria (DAC), constraints, limits and attributes on that process, which if met would result in a design which is acceptable. The concept of DAC would enable the staff to make a final safety determination, subject only to satisfactory a
design implementation and verification by the combined license (COL) applicant who references the certified design through appropriate inspection, tests, i
analyses and acceptance criteria (ITAAC).
1 It is the staff position that the following activities be carried out in an orderly and systematic means through the software development process.
This position for ensuring software quality is addressed in more detail in the ABWR Safety Evaluation Report (SER).
l The ITAAC/DAC for software quality requires the following design stages with appropriate documentation (the software lifecycle) for the development of both safety-related and non-safety-related software.
The timing of the various l
l activities while shown in sequential order may vary and overlap.
However, it is intended that they be fully accomplished in order to produce a high-quality i
software product.
No particular life cycle is endorsed, however, an example of these activities is shown on the attached figure.
The important aspect of i
this position is the activities that must be carried out through the software j
i development process. These activities have been divided into eight stages merely to group related activities; there is no implication that the i
activities in any one stage must be all carried out at the same time, or that activities in "later" stages must follow those of " earlier" stages. The eight stages are as follows:
i 1.
Planning 2.
Requirements l
3.
Design 4.
Implementation 5.
Integration 6.
Validation 7.
Installi. tion i'
8.
Operation and Maintenance i
The ITAAC/DAC will specify criteria (constraints and limits) which describe the method for developing plans and procedures that will guide the design i
process throughout the lifecycle stages. The activities and documentation are listed below:
i 1.
Planning activities result in a number of documents which are used to 3
t
?
a
=
I l
i control the development process.
Six are recommended here:
a Software l
Management Plan, a Software Development Plan, a Software Quality
{
Assurance Plan, a Software Safety Plan, a Software Verification and i
Validation (V&V) Plan, a Software Configuration Management (CM) Plan.
s These plans are discussed in detail in the referenced ANSI /IEEE standards.
2.
Requirements activities for the software system. Six documents are recommended:
the Requirements Specification, the Interface Specifications, a Requirements Safety Analysis, a V&V Requirements l
Analysis Report, a V&V Anomaly Report, and a CM Requirements Report.
These documents will fully capture the requirements of the software project, and relate these requirements to the overall protection system i
functional requirements and protection system safety requirements.
i 3.
Design activities include eight recommended documents. The Unit Test l
Plan, the Hardware & Software Architecture, a Design Specification, a Interface Design Specification, a Design Safety Analysis, a V&V Design Analysis Report, a V&V Anomaly Report, and a CM Design Report.
The l
4 Hardware and Software Architecture will describe the computer system design at a fairly high level, including hardware devices and mapping of software activities to those devices.
I 4.
Implementation activities include writing and analyzing the actual code, 4
using some programming language.
Documents include the actual Code Listings, a Code Safety Analysis, a Integration Plan, a Integration Test d
Plan, a V&V Unit Test Report, a V&V Test Anomaly Report, and a CM Implementation Report.
1 5.
Integration activities are those activities that bring software, hardware and instrumentation together to form a complete computer system. Documents include the System Build Documents, a Validation j
Plan, a Validation Test Plan, an Integration Test Safety Analysis, a V&V t
Integration Test Report, a V&V Test Anomaly Report, and a CM Integration I
Report.
6.
Validation is the process of ensuring that the final complete computer j
system achieves the original goals which were imposed by the protection system design. The final system is matched against the original i
I requirements, and the protection system safety analysis.
Documents 4
include the Installation Plan, a Installation Test Plan, a Training l
Plan, Operations Plan, a Validation Test Safety Analysis, a V&V Test Analysis Report, a V&V Test Anomaly Report, and a CM Validation Report.
7.
Installation is the process of moving the complete computer system from the developer's site to the operational environment within the actual reactor protection system. The completion of installation provides the
]
operator with a documented operational computer system. Nine documents are recommended: the Operations Manuals, the Installation configuration Tables, Training Manuals, Maintenance Manuals, the Maintenance Plan, an i
Installation Safety Analysis, a V&V Installation Test Report, a V&V Anomaly, and a CM Installation Report.
4 a
h
l 8.
Operations and maintenance activities involve the actual use of the computer system in the operating reactor, and making any required changes to it. Changes may be required due to errors in the system j
which were not found during the development process, changes to hardware or requirements for additional functionality.
Safety analyses, V&V l
analyses and CM activities are all recommended as part of the i
maintenance process.
1 Implementation of the software ITAAC will be audited by the NRC to verify conformance with the requirements at several phases during the safety related digital control system desic. process. The documents which demonstrate satisfactory implementatic. of the ITAAC will be available for inspection at the completion of each of the above stages. The audit phases and conformance i
review are shown in the attached figure and correspond to the completion of the various design development stages. The COL applicant / holder will be required to satisfactorily complete each ITAAC phase and may proceed to
{
subsequent stages without approval from the NRC audit. However, should the NRC audit indicate failure to successfully complete a phased ITAAC, the COL l
applicant / holder may be required to repeat an earlier ITAAC and/or change the system design. The NRC staff will conduct a conformance review and issue an inspection report for each phased ITAAC and identify any open issues which require resolution.
Significant open issues which are not resolved could result in the NRC staff concluding that the ITAAC had not been satisfactorily completed. At each phased ITAAC, the design development must be verified to l
be in accordance with the certified design process, and that the detailed 1
design developed (through that stage) meets the certified design. Upon completion of each phased ITAAC the COL holder will certify to the NRC that the stage has been completed and the design and construction completed up f
through that stage is in compliance with the certified design. The COL applicant / holder will also provide a description of the next stage of design development and associated testing, analysis and acceptance criteria in j
sufficient detail that the NRC staff can determine whether or not the proposed 1
design development and testing is consistent with the certified design process and the ITAAC.
This phased process will continue until all ITAAC stages for j
the safety-related software are complete.
In addition to the ITAAC requirements, additional testing of the varies safety
[
systems will be required including the I&C systems as part of the normal pre-operational testing program.
REFERENCES 1.
SECY-92-053, "Use of Design Acceptance Criteria During 10 CFR PART 52 Design Certification Reviews," February 19, 1992 2.
SECY-93-087, " Policy, Technical, and Licensing Issues Pertaining to Evolutionary and Advanced Light-Water Reactor (ALWR) Designs," April 2, i
1993
~
i 3.
SECY-92-349, " Draft Final Safety Evaluation Report on the GE Nuclear j
Energy (GE) Advanced Boiling Water Reactor (ABWR) Standard Safety i
Analysis Report (SSAR) for Design Certification," October 14, 1992.
S 1
J
i 4.
IEEE 828-1983, "IEEE Standard for Software Configuration Management j
Plans".
j 5.
IEEE 829-1983, "IEEE Standard for Software Test Documentation".
}
6.
IEEE 830-1984,_ "IEEE Standard for Software Requirements Specifications".
j l
7.
IEEE 1012-1986, "IEEE Standard for Software Verification and Validation i
Plans".
i 8.
IEEE 1033-1985, "IEEE Recommended Practice of Application of IEEE Standard 828 to Nuclear Power Generation Stations".
l 1
i 9.
IEEE/ANS P-7.4.3.2, " Standard Criteria for Digital Computers in Saftey Systems of Nuclear Power Generating Stations", Draft 8.
l 10.
IEC 880, " Commission Electrotechnique Internationale Norme De La Cei,"
l International Electrotechnical Commission IEC Standard".
j l
l
?
i i
f I
I 2
i t
?
I a
i i
{
=
n 6
F i
1 i
i i
.M 4
i
\\
B.
DIVERSITY IN DESIGN i
4 Provision for diversity in the design of digital I&C systems is necessary l
because even with a hardware / software system developed in accordance with the previously described quality process, it is recognized that the potential for 4
a common mode failure is still sufficiently likely to warrant additional defense-in-depth.
One of the nore effective means of achieving diversity is to provide some form of diversity between preselected sets of functions (functional diversity) to ensu e that common mode failures of equipment do not degrade the performance of more than one set of these functions.
The concept of functional diversity is dis:ussed in NUREG-0493.
In that assessment, the l
preselected sets of functions were control, including general monitoring functions; reactor trip; and eigineered safety features. A block concept was introduced to provide a mechanism for systematically analyzing the effect of l
common mode failures on the de fense-in-depth of the I&C system.
The block i
concept aggregates the equipmeat (components and modules) of the system into a manageably small number of fun 1:tional blocks. The staff chose three such i
blocks: measured variable, derived variable and command blocks. These blocks l
provide the equipment structur4! for the preselected sets of system level i
functions. The resulting block structure is used for the analysis of the j
consequences of postulated common mode failures.
l l
Based on recent assessments of integrity of software applied to various i
safety-critical functions covering a broad range of applications which include j
computer-based medical treatment facilities, computer-based fly-by-wire aircraft control systems, nuclear power plant protection systems, and opinions
{
j among experts the staff has developed the following diversity position:
l 1.
The acolicant shall assess the defense in deoth and diversity of the i
Droposed instrumentation and control system to demonstrate that vulnerabilities to common mode failures have been adeouately addressed.
The staff considers software design errors to be credible common mode l
failures that must be specifically included in the evaluation. An acceptable method of performing analyses is described in NUREG-0493, "A Defense-In-Depth and Diversity Assessment of the RESAR-414 Integrated Protection System," March 1979. Other methods proposed by an applicant will be reviewed individually.
2.
In cerformino the assessment. the vendor or acolicant shall analyze each postulated common mode failure for each event that is evaluated in the accident analysis section of the safety analysis report (SAR) usina best-estimate methods.
The vendor or aDolicant shall demonstrate adeouate diversity within the desian for each of these events.
3.
If a costulated conmon mode failure could disable a safety function.
then a diverse means, with a documented bases that the diverse means is unlikely to be subiect to the same common mode failure. shall be reovired to cerform either the same function or a different function.
The diverse or different function may be performed by a non-safety system if the system is of sufficient ouality to perform the necessary 7
.y function under the associated event conditions.
Diverse digital or non-digital systems are considered to be acceptable means. Manual actions from the control room are acceptable if time and information are available to the operators. The amount and types of diversity may vary among designs and will be evaluated individually.
4.
A set of displays and controls located in the main control room shall be provided for manual system-level actuation of critical safety functions and monitorino of oarameters that support the safety functions.
The displays and controls shall be independent and diverse from the safety computer system identified in items 1 and 3 above.
The specific set of equipment shall be evaluated individually, but shall be sufficient to monitor the plant states and actuate systems required by the control room operators to place the nuclear plant in a hot shutdown condition and intended to control the following critical safety functions: reactivity control, core heat removal, reactor coolant inventory, containment isolation, and containment integrity.
The displays and controls shall be hardwired in the safety computer system architecture to the lowest level practical. To achieve system-level actuation at the lowest level in the safety computer system architecture, the controls may be hardwired either to analog components or to simple, dedicated, and diverse software-based digital equipment that performs the system-level actuation logic.
If nonsafety grade t
controls are used to actuate safety-related equipment, proper isolation between nonsafety and safety related equipment is necessary. The safety i
parameter displays may include digital components exclusively dedicated to displays.
This requirement would provide for an independent and diverse control logic for manual system-level actuation of the safety function that would be connected downstream of the lowest level safety software-based component without affecting the hardware (interconnecting cables and interfaces) between the lowest level electronic cabinets and the plant's electro-mechanical equipment.
Human engineering principles and criteria shall be applied to the selection and design of the particular displays and controls. The design of the displays and controls shall ensure that the human system interface shall be adequate to support the human performance requirements.
The hardwired system-level controls and displays provide the plant operators unambiguous information and control capabilities. These controls and displays are required to be in the main control room to enable the operators to expeditiously mitigate the effects of the postulated software common mode failure of the digital safety I&C system. The control room would be the center of activities to safely cope with the event which could also involve the initiation and implementation of the plant emergency plan.
The design of the plant i
8
)
should not require operators to leave the control room for such an event.
For the longer term recovery operations, credit may b2 taken for actions from outside the main control room, when the emergency response organization is fully briefed and in place to take such actions.
9
y, r
s' j
REFERENCES e
1.
SECY-92-349, " Draft Final Safety Evaluation Report on the GE Nuclear Energy (GE) Advanced Boiling Water Reactor (ABWR) Standard Safety i
Analysis Report (SSAR) for Design Certification," October 14, 1992.
2.
SECY-91-92, " Digital Computer Systems for Advanced Light Water Reactors," September 16, 1991 i
3.
U.S. Nuclear Regulatory Commission, "A Defense-In-Depth and Diversity Assessment of the Resar-414 Integrated Protection System," NUREG 0493 March 1979.
4.
SECY-93-087, dtd 2,1993, " Policy, Technical, and Licensing Issues l
Pertaining to Evolutionary and Advanced Light-Water Reactor (ALWR)
Designs", April 2, 1993 l
l i
i i
i L
e f
i 10 1
I
Fl w cf Dscum:nts thrcugh tho Seitwero Lifo Cycla Softwats Developer Acthrille3 O[
Planning Requiremente Dealgn impaomentation integrauon Validation instapellon g
st.g.
stage stage stag.
Sieg.
si.go s'* o*
si.g.
j g
.A n Softmase Unit Test Plan integrettor Pfen Validation Plan Installation Mehtenance Regresolon Plan Plan TeelPlan Management Pian integention Validetton installation Operations Manuele Software Test Plan Test Plan Teet Plan Development Plan Software O A Requiremente Headware &
Code System Butid Tsetning Plan instaNetion Configusation Plan SpecNicollon Software Uelings Documente Tables Architecture Operellone g
Testning 3
a g
Interface g
SpecNicollon g
Plan g
Manuale s
Design g
g SpecNicatione 5
5 E
E I
5 e
Melntenance e
F F
Deelgo 8
'S E
Manuela E
interface
.e e
n g
l SpecNication g
g g
g Salety Plan
{ Safety Analyste !
Analy ele
~
Code Safety
)
integration
)
Validation
.5 tantallation o
Change B
Design Safety c
Test Safety g Test Sately Salety Software o
Requk emente g
Anatysle Test Safety o
o j
u Analyste 8
Analyels O
Analy ele Analyste Software VAV V&V Requke-V&V Design V&V Unit V1V VAV Test &
V&V V&V Change Plan mente Analyste Analyslo Test bpoet Integrallon Analyste installation Report Report Report Test bport Report Test bport V&V Anomaly V1V Anomaly VAV Test VAV Test V&V Test V&V Test Report Report Anomaly bport Anomaly bport Anomaly Repori Anomaly bpost Sof twase CM CM Requke-CM Dealgn CM koplemen-CM integ'ellon CM Validation CM instalia-CM Change Plan ments bport Repo,t tation Report Report bpost tion fleport Report Rowlelone to Rowlelone to Revisions to hwielone to Rewbloneto Revisions to Rewletone to Earlier Earlier Estiler Eastler Eas sler Earlier Earlier Documente Documento Documente Docuenente Documente Documents Documente h
f h
l c i
D Q
3
=
=
3 9
c a
e I
kE j!
jE t
a-e c-
$5
$w 54 se
% ~a
\\~j)
)
c e
J ad gu E
a4
)
V E" A )
)
s J
~
NRC Software Audit
,