ML13009A055
| ML13009A055 | |
| Person / Time | |
|---|---|
| Issue date: | 07/19/2013 |
| From: | NRC/RES/DE/RGDB |
| To: | |
| Sturzebecher K | |
| Shared Package | |
| ML13008A338 | List: |
| References | |
| DG-1210 RG 1.173, Rev 1 | |
| Download: ML13009A055 (9) | |
Text
Public Comments and NRC Responses for Draft Regulatory Guide (DG) -1210, Developing Software Life Cycle Processes for Digital Computer Software used in Safety Systems of Nuclear Power Plants DG-1210 is Revision 1 of Regulatory Guide (RG) 1.173 Page 1 A Federal Register Notice was published on August 22, 2012 (77 FR 50724) announcing the availability of Draft Regulatory Guide (DG) -1210, Developing Software Life Cycle Processes for Digital Computer Software used in Safety Systems of Nuclear Power Plants for public comment.
The comment period ended November 29, 2012. DG-1210 is Revision 1 of Regulatory Guide (RG) 1.173 dated September 1997. The following table contains the public comments received and the NRC staff responses.
Comments were received from the following individuals:
Mark Burzynski, New Clear Day, Inc.
2036 Marina Cove Dr.
Hixson, TX 37343 (ADAMS - ML122910789)
(ADAMS - ML122910792)
David Herrell, MPR Associates, Inc.
320 King St., Alexandria, VA 22314 (ADAMS - ML12346A034)
Comments on DG-1210, Developing Software Life Cycle Processes for Digital Computer Software used in Safety Systems of NPPs DG-1210 is Rev. 1 of RG 1.173 Originator Draft Guide Comment NRC Response David Herrell DG-1210 (RG 1.173)
General With the current emphasis on FPGAs, one would have thought that the topic would have at least been mentioned in this draft.
Incorporate sufficient guidance on software lifecycle techniques to support FPGA VHDL code development.
Thank you for your comment. No changes have been made as a result of the comment. The information on software can be applied to the software of field-programmable gate arrays (FPGAs). For more direct information on FPGAs see NUREG/CR-7006, Guidelines for Field-Programmable Gate Arrays in Nuclear Power Plant Safety Systems (ADAMS Accession No. ML100880142)
David Herrell DG-1210 (RG 1.173)
General This regulatory guide clearly defines the roles and responsibilities of licensees, applicants, and NRC staff for software processes. However, this reviewers experience shows that most, if not almost all, safety software is not written by licensees or Thank you for your comment. No changes have been made in response to your comment. The NRC is responsible for regulating commercial nuclear power plants and other uses of nuclear material through its licensing, inspection and enforcement of its
Page 2 Comments on DG-1210, Developing Software Life Cycle Processes for Digital Computer Software used in Safety Systems of NPPs DG-1210 is Rev. 1 of RG 1.173 Originator Draft Guide Comment NRC Response applicants. Rather, safety software and safety systems are designed and developed by various vendors. This regulatory guide does not define how software and system vendors are to apply the regulatory guidance. This regulatory guide does not define which version of the regulatory guide is to be applied by a software vendor, or the requirements for software vendors to maintain their programs current with regulatory guidance, which seems to be the NRC requirement, based on topical report submittals.
Consistently define the application of RGs 1.168 through 1.173 for software and system vendors, throughout all sections of each of the regulatory guides. Define the expectations for use of current regulatory guides, since software and system vendors do not have the capability to commit to a given version of the regulatory guides and industry standards in a license. Define the expectations for use of current or older regulatory guides in topical report submissions, or point to other NRC documents that define these requirements.
regulations and requirements.
The NRC issues regulatory guidance documents, such as regulatory guides, standard review plans, and the NRC's Inspection Manual to aid licensees in meeting the agencys safety requirements.
The NRC has no authority to regulate or direct the activities of software developers or software and system vendors. The NRC promulgates its regulatory guidance documents to the NRCs licensees and applicants and it is the responsibility of the licensee and applicant to define software and software system requirements to their vendors as needed to demonstrate compliance with the NRC regulations.
David Herrell DG-1210 (RG 1.173)
Section A, page 1, last sentence Separating activities from the modifying clause that affect the safety function makes the sentence more difficult to read than is necessary.
Replace all activities, including design, purchasing, installation, testing, operation, maintenance, or modification, that affect the safety-related functions of such systems and components.
With all activities that affect the safety-related functions of such systems and components, including Thank you for your comment. As a result of the comment, the sentence has been revised.
Page 3 Comments on DG-1210, Developing Software Life Cycle Processes for Digital Computer Software used in Safety Systems of NPPs DG-1210 is Rev. 1 of RG 1.173 Originator Draft Guide Comment NRC Response design, purchasing, installation, testing, operation, maintenance, or modification.
David Herrell DG-1210 (RG 1.173)
Section A, page 2, 2nd paragraph Since the release year/version of the IEEE standard is already defined in the line above, it is not necessary to repeat the issue date.
Delete the phrase issued 2006 that precedes Ref.
4 Thank you for your comment. No changes have been made as a result of the comment. The IEEE title may use the year as part of the number for the standard, however that doesnt mean that it is improper to state the year issued as part of the citation.
David Herrell DG-1210 (RG 1.173)
Section A, page 2, third paragraph Please clarify the version of NUREG-0800 used in reviews.
After the phrase The NRC staff uses the add the phrase latest version of to provide guidance to industry.
Thank you for your comment. No changes have been made as a result of the comment. The revision is left open for the latest versions.
David Herrell DG-1210 (RG 1.173)
Section B, page 3, 2nd paragraph, 2nd sentence In the paragraph beginning Several criteria in Appendix B the word Criterions is used. The plural form of criterion is criteria. While criterions shows up in several informal dictionaries, it should not be used in formal writing.
Suggest rephrasing the start of the second sentence to either The listed criteria are only part or Each criterion listed below is only part to use correct grammar.
Thank you for your comment. As a result of the comment, the word has been revised to Criteria.
David Herrell DG-1210 (RG 1.173)
Section B, page 4, 1st paragraph, next to last line Since confirming the security accreditations is not a phrase that seems to fit in either SDOE or RG 5.71, another phase is required.
Please replace confirming the security accreditations with a phrase more in keeping with Thank you for your comment. No changes have been made as a result of the comment. The phrase security accreditation is specific to the NRC Office of Nuclear Security Incident and Response (NSIR) and is known to licensees and applicants.
Page 4 Comments on DG-1210, Developing Software Life Cycle Processes for Digital Computer Software used in Safety Systems of NPPs DG-1210 is Rev. 1 of RG 1.173 Originator Draft Guide Comment NRC Response NRC regulatory practices and guidance.
David Herrell DG-1210 (RG 1.173)
Section B, page 4, 2nd paragraph The word However at the beginning of the sentence is superfluous. The phrase be provided on the second line is superfluous.
Please delete both However, and be provided Thank you for your comment. No changes have been made as a result of the comment. The existing sentence is designed to eliminate the choppy sentence transition issue. See Diana Hackers A Writers Reference, Page 112. The use of ;
however, will be revised.
David Herrell DG-1210 (RG 1.173)
Section B, page 4, 3rd paragraph This paragraph should apply to licensees and software vendors, not just applicants.
Please rephrase the requirements to include licensees and software vendors.
Thank you for your comment. As a result of the comment, the sentence has been revised.
David Herrell DG-1210 (RG 1.173)
Section B, page 4, 5th paragraph The quality management process should also reference RG 1.169, in concert with RG 1.28.
Please add the Software Quality Assurance requirements to the Nuclear Quality Assurance requirements.
Thank you for your comment. No changes have been made as a result of the comment. This paragraph explains what has changed in the IEEE standard. The Regulatory Guide 1.128 refers to NQA-1.
David Herrell DG-1210 (RG 1.173)
Section B, page 4, 5th paragraph Software V&V is not normally considered something that is performed as a software V&V.
Replace performing a software V&V with performing software V&V Thank you for your comment. No changes have been made as a result of the comment. Software V&V is a topic (noun). Ergo, These activities are called
'Software Verification and Validation' (SVV). Each project must define its Software Verification and Validation activities in a Software Verification and Validation Plan (SVVP). Source: European Space Agency (ESA) PSS-05-0 Issue 1 Revision 1 (March 1995)
Page 5 Comments on DG-1210, Developing Software Life Cycle Processes for Digital Computer Software used in Safety Systems of NPPs DG-1210 is Rev. 1 of RG 1.173 Originator Draft Guide Comment NRC Response David Herrell DG-1210 (RG 1.173)
Section B, page 5, 1st paragraph, 2nd sentence The sentence is not clear.
Replace It describes interrelationships among activities by defining the source activities that produce the inputs and the destination activities that receive the outputs. With The IEEE standard describes how activities produce outputs, which are then used as inputs to the next activities in the life cycle.
Thank you for your comment. As a result of the comment, the first three sentences were altered:
In terms of inputs, development, verification or control processes, and outputs, IEEE Std. 1074 2006 describes a set of processes and constituent activities that are commonly accepted as comprising a controlled and well-coordinated software project life cycle process. It promulgates interrelationships among the life cycle activity groups by the entry input and output information, and the source and destination activities. The standard specifies mapping on to an appropriate software project life cycle model.
David Herrell DG-1210 (RG 1.173)
Section B page 5, 3rd paragraph EPRI TR-106439 is also useful for the acceptance of pre-existing software, and has been referenced in other software draft guides.
Augment the end of the sentence by standing that can be found in Regulatory Guide 1.152. Additional detailed information on acceptance processes appear in Electric Power Research Institute (EPRI) Topical Report (TR)-106439, Guideline on Evaluation and Acceptance of Commercial Grade Digital Equipment for Nuclear Safety Applications, issued October 1996 (Ref. xx). EPRI TR 106439 has been endorsed by the NRC through a Safety Evaluation Report, dated 17 July 1997. This will require adding this to the References section, and providing a note that the TR is freely available from www.EPRI.com.
Thank you for your comment. No changes have been made as a result of the comment. The EPRI information can be found in Part C, 1.(c.)
Page 6 Comments on DG-1210, Developing Software Life Cycle Processes for Digital Computer Software used in Safety Systems of NPPs DG-1210 is Rev. 1 of RG 1.173 Originator Draft Guide Comment NRC Response David Herrell DG-1210 (RG 1.173)
Section C, page 6, 1st paragraph The first sentence can be made more readable.
At least, consider placing a comma after safety system software and before with the exceptions to help.
Thank you for your comment. As a result of the comment, a comma has been added after Regulatory Guide 1.152.
David Herrell DG-1210 (RG 1.173)
Section C 1, page 7. Item c, 6th from last line Regulatory Guide 1.152 does endorse IEEE Std. 7 4.3.2. However, RG 1.152 does not provide the information necessary to accept pre-existing software. In addition, IEEE Std. 7 4.3.2-2003 which is endorse does not provide sufficient information to accept pre-existing software.
Reference the as-yet-unendorsed IEEE Std. 7-4.3.2-2010 for a more complete version of the evaluation criteria.
Thank you for your comment. No changes have been made as a result of the comment. The suitability of the pre-existing software must meet the input/output information and source/destination activity requirements addressed in the IEEE Std. 1074 and thus meet the applicable regulatory requirements and design bases for the safety system. This continues with the forward and backward traceability for these activities, which is stated in RG 1.172.
The existing citation to RG 1.152 provides the touch point to IEEE Std. 7-4.3.2.
David Herrell DG-1210 (RG 1.173)
Section C.1, page 7, Item C, last 5 lines While the comment made is correct (EPRI TR-106439 has never been endorsed by a regulatory guide), the technical report has been endorsed through an NRC SER.
Include a statement in the RG text that EPRI TR-106439 has been endorsed by the NRC through a Safety Evaluation Report, dated 17 July 1997.
Thank you for your comment. As a result of the comment, the phrase With the July 17, 1997 NRC endorsement was added.
David Herrell DG-1210 (RG 1.173)
Section C 1, page 7, Item d, 4th line Failing to consider the operational environment while developing the software will result in security holes.
Add a third security objective (ii) secure operational environment, and renumber existing (ii) to (iii).
Thank you for your comment. No changes have been made as a result of the comment. The item (i) refers to the SDOE. Secure software development inherently implies secure development operational environment.
Page 7 Comments on DG-1210, Developing Software Life Cycle Processes for Digital Computer Software used in Safety Systems of NPPs DG-1210 is Rev. 1 of RG 1.173 Originator Draft Guide Comment NRC Response David Herrell DG-1210 (RG 1.173)
Section C 1, page 7, Item d, 5th and 6th lines Augment the discussion with the secure operational environment and simplify the sentence.
Replace Guidance for secure software development is available in Regulatory Guide 1.152, whereas guidance for cyber security With Guidance for a secure software development and operational environment is available in Regulatory Guide 1.152.
Guidance for cyber security Thank you for your comment. No changes have been made as a result of the comment. The point of a compound sentence was to eliminate the repeating of the phrase Guidance for.
David Herrell DG-1210 (RG 1.173)
Section C.2, page 8, next to last line The pronoun it does not provide clear, unambiguous reference.
Replace related properly to one another; it does not provide with related properly to one another. IEEE Std. 1074-2006 does not provide Thank you for your comment. No changes have been made as a result of the comment. The 2nd compound sentence is related and the pronoun is associated with 1074.
David Herrell DG-1210 (RG 1.173)
Section C 4, page 8, Item a, last line The timing required by the phrase prior to implementation is not clear, and can be interpreted in a manner that makes it impossible to write code in the Implementation Phase of the software life cycle, which is different from installation in the plant. It may be necessary to install the software modification in the plant to test the modification adequately. The wording provided in this draft guidance makes that impossible.
Change prior to implementation to prior to being credited with performing one or more safety functions in a plant for more appropriate guidance.
Thank you for your comment. No changes have been made as a result of the comment. That would defeat the purpose of this exception. A temporary work-around is not permitted in any safety system.
David Herrell DG-1210 (RG 1.173)
Section C.4, The guidance provided makes it necessary and required to take interfacing systems out of service and declare all interfacing systems inoperable.
Thank you for your comment. No changes have been made as a result of the comment. The following requirements under C.4.(b) maintains the safety
Page 8 Comments on DG-1210, Developing Software Life Cycle Processes for Digital Computer Software used in Safety Systems of NPPs DG-1210 is Rev. 1 of RG 1.173 Originator Draft Guide Comment NRC Response page 8, Item b, last line Properly designed and tested, this is excessively detailed and likely inappropriate requirements.
Change the sentence to allow properly designed, procedurally controlled, interfacing systems to be set to appropriate conditions, which could extend to placing all interfacing systems off line, or could be just as little as marking the data provided by that portion of the safety system as bad. This may require manual actions, or be included as part of the automatic actions included in the design for the interfacing system or the system being maintained.
systems adherence to the rules in IEEE Std. 603.
Mark Burzynski DG-1210 (RG 1.173)
Position C.4.d Regulatory Position C.4.d in DG-1210 states:
However, all changes to safety systems must be evaluated using the criteria specified in 10 CFR 50.59. If the change is outside the scope of 10 CFR 50.59 then it must be submitted for review as a licensing amendment request.
It would be better to replace the last sentence with:
If the change does not meet the requirements of 10 CFR 50.59(c)(2) then it must be submitted for review as a licensing amendment request.
10 CFR 50.59(a) essentially defines the scope of 50.59 with respect to the Final Safety Analysis Report for the facility. 10 CFR 50.59(c)(2) outlines specific criteria, if exceeded, require prior NRC approval to make the change to the facility. The suggested change eliminates confusion regarding the scope of 50.59 and the threshold criteria triggering the need for prior NRC approval.
Thank you for your comment. No changes have been made as a result of the comment. The comment may be valid but our current statement is not incorrect either. Note it is stated in Part B on page 4, and Part D on page 11. The present comment is also stated in its general form in Part D of the other 5 regulatory guides.
Page 9 Comments on DG-1210, Developing Software Life Cycle Processes for Digital Computer Software used in Safety Systems of NPPs DG-1210 is Rev. 1 of RG 1.173 Originator Draft Guide Comment NRC Response
- 18. David Herrell DG-1210 (RG 1.173)
Section C.6, page 10, 2nd and 3rd lines The last sentence in this paragraph conflicts with the data provided in the list of annexes below this paragraph.
Change the second sentence to read: Annex A is endorsed, as described in Item 1. Annexes B through F are not endorsed, but may provide useful information.
Thank you for your comment. No changes have been made as a result of the comment. The summarization is not necessary as the intent is for reading through each annex.
- 10. Mark Burzynski DG-1210 (RG 1.173)
Section D DG-1210 Section D states:
Licensees may use the information in this regulatory guide for actions which do not require NRC review and approval such as changes to a facility design under 10 CFR 50.59. Licensees may use the information in this regulatory guide or applicable parts to resolve regulatory or inspection issues.
Does the first sentence of imply that this regulatory guide is not for actions which do require NRC review and approval?
Thank you for your comment. In response to the comment the answer to your question is yes. The regulatory guide information can be used for any software installation.