ML17243A428

From kanterella
Jump to navigation Jump to search
ISG-6 R1 D9 and D10 Edits (Clean 20170712)
ML17243A428
Person / Time
Issue date: 10/02/2017
From: Lynnea Wilkins
NRC/NRR/DLP/PLPB
To:
Wilkins L
Shared Package
ML17243A426 List:
References
Download: ML17243A428 (3)


Text

D.9 Compliance with IEEE Std 603 Design Basis IEEE Std 603-1991 requires, in part, that a specific design basis be established for the design of each safety system. If this is an upgrade to a digital system from an existing system, the design basis for the new digital system may be the same as the existing system. In this case, a simple description of the design basis should be provided. If the design basis has not changed, this should be identified clearly in the information provided. If the design basis is changed, the changes shall be identified clearly with a rationale provided for each change.

The new digital system may, however, have a different design basis. For example, the new digital systems may need a diverse actuation system, which would become part of the system design basis. The design basis for the old system and a comparison to the design basis for the new system should be specifically addressed in the information provided.

Equipment Qualification Typically an environmental equipment qualification test specimen is not in the identical configuration as a plant specific application; therefore, equipment qualification is generally addressed in three parts:

(1) Qualifying the equipment to specified environmental conditions. See Section D.5, Environmental Equipment Qualifications, for detailed guidance on environmental equipment qualifications.

(2) Ensuring that the environmental equipment qualification bounds the plant where the equipment will be installed.

(3) Ensuring that the application specific functional and performance criteria are achieved by the specific equipment and configuration proposed.

The licensees submittal should provide sufficient documentation to support the assertion that a proposed digital I&C system is qualified to perform its safety function within its design-basis normal and adverse environments (e.g., as required to be documented by IEEE Std 603 Clause 4.7). The results of the qualification testing should be documented in a summary report.

The NRC staff should review the information provided to conclude that the plant specific application has been demonstrated to be able to meet functional and performance criteria within the expected environment. This includes both the normal operating conditions and the worst conditions expected during abnormal and accident conditions where the equipment is expected to perform its safety function. The system is tested with respect to a wide range of parameters, such as temperature, humidity, seismic, and electromagnetic, based on the environment in which the equipment is located.

Auxiliary Features The auxiliary supporting features need to be designed to the same high quality standards as the rest of the safety-related system, and the same demonstration that all requirements are being met is required. In order to comply with this staff position, the licensee or vendor should demonstrate that any auxiliary supporting features are necessary to perform the safety function.

Enclosure F: Page 1 of 15 ENCLOSURE F, Glossary

If the licensee or vendor cannot show that the supporting feature is needed, a detailed description of the feature, how it is designed and how it functions should be needed for the NRC staff to conclude that having this feature should not compromise the safety or functionality of the system. This detailed description may necessitate the NRC staff to review actual schematics or software code to reach its conclusion.

D.10 Conformance with IEEE Std 7-4.3.2 Software Quality Clause 5.3 states that hardware quality is addressed by IEEE Std 603-1991. This clause also describes a typical application software development life cycle. The licensee should describe the application software development life cycle and evaluate the life cycle in accordance with RG 1.173.

The application software should not be evaluated outside of the plant and platform contexts.

Developing the digital modification should include the use of the platforms digital hardware and software and the development of the application software. The development process must include the integration of the digital hardware, software, and human-system interfaces.

The licensee process must address and document the following activities:

Creating the conceptual design of the system, translation of the concepts into specific system criteria Using the criteria to develop a detailed system design Implementing the design into hardware and software Analyzing, Reviewing, and Testing to assure the criteria have been correctly implemented SRP BTP 7-14 describes the characteristics of a planned and controlled software development process that the NRC staff should use when assessing the quality criteria of this clause. The content of the plans listed in SRP BTP 7-14 should exist, although there is no requirement for each of the plans to exist as a separate entity. The contents and processes defined in the plans described in SRP BTP 7-14 should be reviewed.

All software development life cycles share certain characteristics. The activities that will be performed can be grouped into a number of categories (termed activity groups here); the activity groups are common to all life cycles. Life cycle activities produce process documents and design outputs that can be inspected. The types of documents produced for each life cycle activity group are described in BTP 7-14. It is acceptable to combine documents differently than described in BTP 7-14. Information which is assumed to be provided in two or more documents could be combined into a single document, and information which is assumed to be provided in a single document could be provided in two or more documents. For example, the software safety plan may be included in a general project safety plan.

The approved Topical Report has evaluated and accepted the vendors nuclear quality assurance program, platform software, and software tools, so no further evaluation of those Enclosure F: Page 2 of 15 ENCLOSURE F, Glossary

aspects is required. The LAR provides a high level summary and evaluation of the vendors nuclear quality assurance program. The licensee then determines if a separate project-specific software quality assurance plan is required, beyond the vendors program. The reviewer will evaluate the licensees documented acceptance of that plan in the LAR, using the criteria of SRP BTP 7-14. The vendor plans are available for audit.

Enclosure F: Page 3 of 15 ENCLOSURE F, Glossary