Document: NUREG-0800
Document ID: 4865fc6d-b85f-4173-9bca-162fa9fe67d2
Document Type: srp
Title: Appendix 7-A
Source: NUREG-0800
Source URL: https://www.nrc.gov/docs/ML0525/ML052500555.pdf
Revision Date: 2023-06
Chapter: 7
Section ID: 7
CFR Part: 
CFR Title: 

Content:
ed provided that it can be demonstrated that functions required by the ATWS rule (10 CFR 50.62) are not impaired. 4. No failure of monitoring or display systems should influence the functioning of the reactor trip system or the ESFAS. If plant monitoring system failure induces operators to attempt to operate the plant outside safety limits or in violation of the limiting conditions of operation, the analysis should demonstrate that such operator-induced transients will be compensated by protection system function. The adequacy of the diversity provided with respect to the above criteria must be justified. NUREG/CR- 6303, in Section 3.2, describes six types of diversity and describes how instances of different types of diversity might be combined into an overall case for the sufficiency of the diversity provided. Typically, several types of diversity should exist, some of which should exhibit one or more of the stronger attributes listed in NUREG/CR-6303 for the diversity type. Functional diversity and signal diversity are considered to be particularly effective. The following cautions should be noted where applicable: • The justification for equipment diversity, or for the diversity of related system software such as a real- time operating system, must extend to the equipment’s components to ensure that actual diversity exists. For example, different manufacturers might use the same processor or license the same operating system, thereby incorporating common failure modes. Claims for diversity based just on difference in manufacturer name are insufficient without consideration of the above. • With respect to software diversity, experience indicates that independence of failure modes may not be achieved in cases where multiple versions of software are developed to the same software requirements. Other considerations, such as functional and signal diversity, that lead to different software requirements form a stronger basis for diversity. Rev. 4 — June 1997