ML13009A055

Public Comments on DG-1210 and NRC Response

ML13009A055
Person / Time
Issue date:	07/19/2013
From:	NRC/RES/DE/RGDB
To:
Sturzebecher K
Shared Package
ML13008A338	List: ML13009A055 Regulatory Guide 1.173
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 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, David Herrell, New Clear Day, Inc. MPR Associates, Inc.

2036 Marina Cove Dr. 320 King St., Alexandria, VA 22314 Hixson, TX 37343 (ADAMS - ML12346A034)

(ADAMS - ML122910789)

(ADAMS - ML122910792)

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 With the current emphasis on FPGAs, one would Thank you for your comment. No changes have been (RG 1.173) have thought that the topic would have at least been made as a result of the comment. The information on General mentioned in this draft. software can be applied to the software of field-programmable gate arrays (FPGAs). For more direct Incorporate sufficient guidance on software lifecycle information on FPGAs see NUREG/CR-7006, techniques to support FPGA VHDL code Guidelines for Field-Programmable Gate Arrays in development.

Nuclear Power Plant Safety Systems (ADAMS Accession No. ML100880142)

David Herrell DG-1210 This regulatory guide clearly defines the roles and Thank you for your comment. No changes have been (RG 1.173) responsibilities of licensees, applicants, and NRC made in response to your comment. The NRC is General staff for software processes. However, this responsible for regulating commercial nuclear power reviewers experience shows that most, if not almost plants and other uses of nuclear material through its all, safety software is not written by licensees or licensing, inspection and enforcement of its Page 1

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 regulations and requirements.

systems are designed and developed by various The NRC issues regulatory guidance documents, vendors. This regulatory guide does not define how such as regulatory guides, standard review plans, and software and system vendors are to apply the the NRC's Inspection Manual to aid licensees in regulatory guidance. This regulatory guide does not meeting the agencys safety requirements.

define which version of the regulatory guide is to be applied by a software vendor, or the requirements for The NRC has no authority to regulate or direct the software vendors to maintain their programs current activities of software developers or software and with regulatory guidance, which seems to be the system vendors. The NRC promulgates its regulatory NRC requirement, based on topical report submittals. guidance documents to the NRCs licensees and applicants and it is the responsibility of the licensee Consistently define the application of RGs 1.168 and applicant to define software and software system through 1.173 for software and system vendors, requirements to their vendors as needed to throughout all sections of each of the regulatory demonstrate compliance with the NRC regulations.

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.

David Herrell DG-1210 Separating activities from the modifying clause Thank you for your comment. As a result of the (RG 1.173) that affect the safety function makes the sentence comment, the sentence has been revised.

Section A, more difficult to read than is necessary.

page 1, Replace all activities, including design, last sentence 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 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 design, purchasing, installation, testing, operation, maintenance, or modification.

David Herrell DG-1210 Since the release year/version of the IEEE standard is Thank you for your comment. No changes have been (RG 1.173) already defined in the line above, it is not necessary made as a result of the comment. The IEEE title may Section A, to repeat the issue date. use the year as part of the number for the standard, page 2, however that doesnt mean that it is improper to state Delete the phrase issued 2006 that precedes Ref.

2nd paragraph the year issued as part of the citation.

4 David Herrell DG-1210 Please clarify the version of NUREG-0800 used in Thank you for your comment. No changes have been (RG 1.173) reviews. made as a result of the comment. The revision is left Section A, open for the latest versions.

After the phrase The NRC staff uses the add the page 2, phrase latest version of to provide guidance to third paragraph industry.

David Herrell DG-1210 In the paragraph beginning Several criteria in Thank you for your comment. As a result of the (RG 1.173) Appendix B the word Criterions is used. The comment, the word has been revised to Criteria.

Section B, plural form of criterion is criteria. While criterions page 3, shows up in several informal dictionaries, it should 2nd paragraph, not be used in formal writing.

2nd sentence 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.

David Herrell DG-1210 Since confirming the security accreditations is not Thank you for your comment. No changes have been (RG 1.173) a phrase that seems to fit in either SDOE or RG 5.71, made as a result of the comment. The phrase Section B, another phase is required. security accreditation is specific to the NRC Office page 4, of Nuclear Security Incident and Response (NSIR)

Please replace confirming the security 1st paragraph, and is known to licensees and applicants.

accreditations with a phrase more in keeping with next to last line 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 NRC regulatory practices and guidance.

David Herrell DG-1210 The word However at the beginning of the sentence Thank you for your comment. No changes have been (RG 1.173) is superfluous. The phrase be provided on the made as a result of the comment. The existing Section B, second line is superfluous. sentence is designed to eliminate the choppy page 4, sentence transition issue. See Diana Hackers A Please delete both However, and be provided 2nd paragraph Writers Reference, Page 112. The use of ;

however, will be revised.

David Herrell DG-1210 This paragraph should apply to licensees and Thank you for your comment. As a result of the (RG 1.173) software vendors, not just applicants. comment, the sentence has been revised.

Section B, Please rephrase the requirements to include licensees page 4, and software vendors.

3rd paragraph David Herrell DG-1210 The quality management process should also Thank you for your comment. No changes have been (RG 1.173) reference RG 1.169, in concert with RG 1.28. made as a result of the comment. This paragraph Section B, explains what has changed in the IEEE standard. The Please add the Software Quality Assurance page 4, Regulatory Guide 1.128 refers to NQA-1.

requirements to the Nuclear Quality Assurance 5th paragraph requirements.

David Herrell DG-1210 Software V&V is not normally considered something Thank you for your comment. No changes have been (RG 1.173) that is performed as a software V&V. made as a result of the comment. Software V&V is a Section B, topic (noun). Ergo, These activities are called Replace performing a software V&V with page 4, 'Software Verification and Validation' (SVV). Each performing software V&V 5th paragraph 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 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 David Herrell DG-1210 The sentence is not clear. Thank you for your comment. As a result of the (RG 1.173) comment, the first three sentences were altered:

Replace It describes interrelationships among Section B, activities by defining the source activities that In terms of inputs, development, verification or page 5, produce the inputs and the destination activities that control processes, and outputs, IEEE Std. 1074 2006 1st paragraph, receive the outputs. With The IEEE standard describes a set of processes and constituent activities 2nd sentence describes how activities produce outputs, which are that are commonly accepted as comprising a then used as inputs to the next activities in the life controlled and well-coordinated software project life cycle. 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 EPRI TR-106439 is also useful for the acceptance of Thank you for your comment. No changes have been (RG 1.173) pre-existing software, and has been referenced in made as a result of the comment. The EPRI Section B other software draft guides. information can be found in Part C, 1.(c.)

page 5, Augment the end of the sentence by standing that 3rd paragraph 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.

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 The first sentence can be made more readable. Thank you for your comment. As a result of the (RG 1.173) comment, a comma has been added after Regulatory At least, consider placing a comma after safety Section C, Guide 1.152.

system software and before with the exceptions to page 6, help.

1st paragraph David Herrell DG-1210 Regulatory Guide 1.152 does endorse IEEE Std. 7 Thank you for your comment. No changes have been (RG 1.173) 4.3.2. However, RG 1.152 does not provide the made as a result of the comment. The suitability of Section C 1, information necessary to accept pre-existing the pre-existing software must meet the input/output page 7. Item c, software. In addition, IEEE Std. 7 4.3.2-2003 which information and source/destination activity 6th from last line is endorse does not provide sufficient information to requirements addressed in the IEEE Std. 1074 and accept pre-existing software. thus meet the applicable regulatory requirements and design bases for the safety system. This continues Reference the as-yet-unendorsed IEEE Std. 7-4.3.2-with the forward and backward traceability for these 2010 for a more complete version of the evaluation activities, which is stated in RG 1.172.

criteria.

The existing citation to RG 1.152 provides the touch point to IEEE Std. 7-4.3.2.

David Herrell DG-1210 While the comment made is correct (EPRI TR- Thank you for your comment. As a result of the (RG 1.173) 106439 has never been endorsed by a regulatory comment, the phrase With the July 17, 1997 NRC Section C.1, guide), the technical report has been endorsed endorsement was added.

page 7, Item C, through an NRC SER.

last 5 lines 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.

David Herrell DG-1210 Failing to consider the operational environment while Thank you for your comment. No changes have been (RG 1.173) developing the software will result in security holes. made as a result of the comment. The item (i) refers Section C 1, to the SDOE. Secure software development Add a third security objective (ii) secure operational page 7, Item d, inherently implies secure development operational environment, and renumber existing (ii) to (iii).

4th line environment.

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 Augment the discussion with the secure operational Thank you for your comment. No changes have been (RG 1.173) environment and simplify the sentence. made as a result of the comment. The point of a Section C 1, compound sentence was to eliminate the repeating of Replace Guidance for secure software development page 7, Item d, the phrase Guidance for.

is available in Regulatory Guide 1.152, whereas 5th and 6th lines 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 David Herrell DG-1210 The pronoun it does not provide clear, Thank you for your comment. No changes have been (RG 1.173) unambiguous reference. made as a result of the comment. The 2nd compound Section C.2, sentence is related and the pronoun is associated with Replace related properly to one another; it does page 8, next to 1074.

not provide with related properly to one last line another. IEEE Std. 1074-2006 does not provide David Herrell DG-1210 The timing required by the phrase prior to Thank you for your comment. No changes have been (RG 1.173) implementation is not clear, and can be interpreted made as a result of the comment. That would defeat Section C 4, in a manner that makes it impossible to write code in the purpose of this exception. A temporary work-page 8, Item a, the Implementation Phase of the software life cycle, around is not permitted in any safety system.

last line 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.

David Herrell DG-1210 The guidance provided makes it necessary and Thank you for your comment. No changes have been (RG 1.173) required to take interfacing systems out of service made as a result of the comment. The following Section C.4, and declare all interfacing systems inoperable. requirements under C.4.(b) maintains the safety 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 page 8, Item b, Properly designed and tested, this is excessively systems adherence to the rules in IEEE Std. 603.

last line 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.

Mark DG-1210 Regulatory Position C.4.d in DG-1210 states: Thank you for your comment. No changes have been Burzynski (RG 1.173) However, all changes to safety systems must be evaluated made as a result of the comment. The comment may Position C.4.d using the criteria specified in 10 CFR 50.59. If the change be valid but our current statement is not incorrect is outside the scope of 10 CFR 50.59 then it must be either. Note it is stated in Part B on page 4, and Part submitted for review as a licensing amendment request. D on page 11. The present comment is also stated in its general form in Part D of the other 5 regulatory It would be better to replace the last sentence with: guides.

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.

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

18. David DG-1210 The last sentence in this paragraph conflicts with the Thank you for your comment. No changes have been Herrell (RG 1.173) data provided in the list of annexes below this made as a result of the comment. The summarization Section C.6, paragraph. is not necessary as the intent is for reading through page 10, 2nd and each annex.

Change the second sentence to read: Annex A is 3rd lines endorsed, as described in Item 1. Annexes B through F are not endorsed, but may provide useful information.

10. Mark DG-1210 DG- 1210 Section D states: Thank you for your comment. In response to the Burzynski (RG 1.173) Licensees may use the information in this regulatory comment the answer to your question is yes. The Section D guide for actions which do not require NRC review and regulatory guide information can be used for any approval such as changes to a facility design under 10 software installation.

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?

Page 9