Document: NRC Regulatory Guide
Document ID: c7a40fcc-fc9d-4eb2-ad86-f9f5b0f04c82
Document Type: regulatory_guide
Title: Plant-Specific, Risk-Informed Decisionmaking:  Technical Specifications (Rev. 2)
Source: NRC Regulatory Guide Division 1
Source URL: https://www.nrc.gov/docs/ML1920/ML19206A489.pdf
Revision Date: 2023-06
Chapter: 
Section ID: RG-1.177
CFR Part: 
CFR Title: 

Content:
odels are necessary. c. Since PRAs typically model the plant at the individual component level, they may be used directly to analyze both CTs and SFs. d. Component unavailability models should include contributions from random failure, common-cause failure (CCF), test downtime, and maintenance downtime. e. Changes to the component unavailability model for test downtime and maintenance downtime should be based on a realistic estimate of expected surveillance and maintenance practices after DG-1287, Page 13 the TS change is approved and implemented (e.g., how often the CT is expected to be entered for preplanned maintenance or surveillance). f. The component unavailability model for test downtime and maintenance downtime should be based on plant-specific or industrywide operating experience, or both, as appropriate. g. The component unavailability model should have the flexibility to separate the unavailability contribution from test and maintenance downtime. For evaluating a CT, the contribution from maintenance downtime can be equated to zero to delete maintenance activities, if desired. For an SF evaluation, the contribution from test downtime determines a contribution to risk from carrying out the test. h. Additional details in terms of separating the failure rate contributions into cyclic demand-related and standby time-related contributions can be incorporated, if justifiable, for evaluating surveillance requirements. The CCF contributions should be modeled so that they can be modified to reflect the condition in which one or more of the components is unavailable. Note that CCF modeling of components is not only dependent on the number of remaining inservice components, but it is also dependent on the reason the components were removed from service (i.e., whether for preventive or corrective maintenance). For appropriate configuration risk management and control, preventive and corrective maintenance activities need to be considered, and licensees should,