ML13007A160
| ML13007A160 | |
| Person / Time | |
|---|---|
| Issue date: | 07/19/2013 |
| From: | Michael Orr NRC/RES/DE/RGDB |
| To: | |
| Orr M | |
| Shared Package | |
| ML12354A538 | List: |
| References | |
| DG-1209 RG 1.172, Rev 1 | |
| Download: ML13007A160 (13) | |
Text
Public Comments and NRC Responses for Draft Regulatory Guide (DG) -1209, Software Requirement Specifications for Digital Computer Software used in Safety Systems of Nuclear Power Plants DG-1209 is Revision 1 of Regulatory Guide (RG) 1.172 A Federal Register Notice was published on August 22, 2012 (77 FR 50726) announcing the availability of Draft Regulatory Guide (DG) -1209, Software Requirement Specifications for Digital Computer Software used in Safety Systems of Nuclear Power Plants for public comment. The comment period ended November 29, 2012. DG-1209 is Revision 1 of Regulatory Guide (RG) 1.172 dated September 1997. The following table contains the public comments received and the NRC staff responses.
Comments were received from the following individuals:
Matt Gibson, Mark Burzynski, David Herrell, Duke Energy New Clear Day, Inc. MPR Associates, Inc.
(Matt.Gibson@Duke-Energy.Com) 2036 Marina Cove Dr. 320 King St., Alexandria, VA 22314 (ADAMS - ML12321A013) Hixson, TX 37343 (ADAMS - ML12346A034)
(ADAMS - ML122910794)
Comments on DG-1209, Software Requirements Specifications for Digital Computer Software used in Safety Systems of NPPs DG-1209 is Rev. 1 of RG 1.172 Originator Draft Guide Comment NRC Response David Herrell DG-1209 With the current emphasis on FPGAs, one would Thank you for your comment. No changes have been (RG 1.172) 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 at least some small amount of guidance information on FPGAs see NUREG/CR-7006, on applicability of software lifecycles techniques to Guidelines for Field-Programmable Gate Arrays in FPGA VHDL code development.
Nuclear Power Plant Safety Systems (ADAMS Accession No. ML100880142)
David Herrell DG-1209 This regulatory guide clearly defines the roles and Thank you for your comment. No changes have been (RG 1.172) responsibilities of licensees, applicants, and NRC made as a result of the 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 applicants. Rather, safety software and safety Page 1
Comments on DG-1209, Software Requirements Specifications for Digital Computer Software used in Safety Systems of NPPs DG-1209 is Rev. 1 of RG 1.172 Originator Draft Guide Comment NRC Response systems are designed and developed by various regulations and requirements.
vendors. This regulatory guide does not define how The NRC issues regulatory guidance documents such software and system vendors are to apply the as regulatory guides, standard review plans, and the regulatory guidance. This regulatory guide does not NRC's Inspection Manual to aid licensees in meeting define which version of the regulatory guide is to be the agencys safety requirements.
applied by a software vendor, or the requirements for software vendors to maintain their programs current The NRC has no authority to regulate or direct the with regulatory guidance, which seems to be the activities of software developers or software and NRC requirement, based on topical report submittals. system vendors. The NRC promulgates its regulatory guidance documents to the NRCs licensees and Consistently define the application of RGs 1.168 applicants and it is the responsibility of the licensee through 1.173 for software and system vendors, and applicant to define software and software system throughout all sections of each of the regulatory requirements to their vendors as needed to guides. Define the expectations for use of current demonstrate compliance with the NRC regulations.
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-1209 Eliminate the ambiguous reference to it for clear, Thank you for your comment. As a result of the (RG 1.172) unambiguous requirements. comment, the sentence has been revised to eliminate Section A the ambiguity.
Replace the phrase assure a quality product and Page 2, that it will perform with assure a quality first partial product that will perform (delete and and it) paragraph, line 5 for clarity.
David Herrell DG-1209 In the paragraph starting The NRC issues Thank you for your comment. No changes have been (RG 1.172) regulatory simplify the sentence structure. made as a result of the comment. The existing Section A sentence is designed to eliminate the choppy Replace applicants; however with applicants.
Page 2
Comments on DG-1209, Software Requirements Specifications for Digital Computer Software used in Safety Systems of NPPs DG-1209 is Rev. 1 of RG 1.172 Originator Draft Guide Comment NRC Response rd 3 paragraph However, for consistency with other regulatory sentence transition issue. See Diana Hackers A 4th line guides. Writers Reference, Page 112. The use of ;
however, will be revised.
David Herrell DG-1209 Please clarify the version of NUREG-0800 used in Thank you for your comment. No changes have been (RG 1.172) reviews. made as a result of the comment. The NRC staff Section A does not identify specific revisions for some guidance After the phrase The NRC staff uses the add the page 2, third documents. This type of dynamic referencing is done phrase latest version of to provide guidance to paragraph, next because different licensees and applicants may have industry.
to last line committed to different versions of the guidance documents and it would be inappropriate to always use the latest version of the guidance document for reviews when different applicants and licensees may have committed to alternate versions.
David Herrell DG-1209 First paragraph, first line - Editorial style - For Thank you for your comment. As a result of the (RG 1.172) consistency with other standards, add a comma after comment, the comma was added.
Section B such as IEEE standards to set off the phrase.
David Herrell DG-1209 In the paragraph starting The original regulatory Thank you for your comment. As a result of the (RG 1.172) guide... the third sentence is ambiguous, the word comment, edits were made and the new sentence Section B venue is being used incorrectly, and IEEE 830- reads:
Page 3, next to 1998 is not consistent referencing of the standard All subjects associated with the development of last paragraph, (should be IEEE Std. 830-1998).
safety system are applicable for review and not line 3 Replace the sentence Within this same venue is a inherently ambiguous. Within this same thought a new section to this regulatory guide called new section to this regulatory guide called Unambiguity. with This regulatory guide Unambiguity has been add.
provides a new section, Unambiguity consistent with IEEE Std. 830-1998. If that is the intent of this sentence.
Page 3
Comments on DG-1209, Software Requirements Specifications for Digital Computer Software used in Safety Systems of NPPs DG-1209 is Rev. 1 of RG 1.172 Originator Draft Guide Comment NRC Response David Herrell DG-1209 The last two sentences of the first paragraph are Thank you for your comment. No changes have been (RG 1.172) confusing as written. A few examples of the made as a result of the comment. The original Section B confusing statements include: regulatory guide had incorrect information on topics Page 3, first like security and this new revision now corrects this The word corrects is misleading (suggesting paragraph situation. The basic topic of this paragraph in this something is wrong with IEEE Std. 830) and the discussion is centered on the regulatory guide and not word enhancements is opinionated. The actions the IEEE Std. 830.
being performed should be stated more precisely.
The term attribute in used to generally describe what The phrase other perspectives is vague - what are the IEEE standard may call characteristic or the other perspectives being referred to and why requirements. There is no reference to software are the perspectives of the software attribute being attributes as the read discussion in the IEEE standard changed and not the software attribute itself?
refers to the SRS.
Nonapplicability and Unambiguity are not software attributes, but the wording implies that they are.
The last two sentences of the first paragraph should be clarified. A suggested rewording is:
This version of Regulatory Guide 1.172 endorses IEEE Std. 830-1998, addresses Annex B of IEEE Std. 830-1998, provides guidance on the Unambiguous characteristic of an SRS, provides clarification on the Security attribute of an SRS, and deletes the existing Regulatory Guide 1.172 section titled Nonapplicability.
David Herrell DG-1209 The first two sentences of the second paragraph are Thank you for your comment. No changes have been (RG 1.172) confusing as written. A few examples of the made as a result of the comment. The discussion Section B confusing statements include: states the changes from the old regulatory to the new Page 3, second and the reader needs to have an understanding of both The phrase changes in the way software is viewed paragraph standards. The new regulatory guide states that and documented is confusing. What does it mean to requirements for a SRS need to be unambiguous and Page 4
Comments on DG-1209, Software Requirements Specifications for Digital Computer Software used in Safety Systems of NPPs DG-1209 is Rev. 1 of RG 1.172 Originator Draft Guide Comment NRC Response say software is being viewed differently and whose this paragraph is reaffirming that the original viewpoint is being referred to, possibly the NRC regulatory guide was updated from the statement of staff? How is software being documented differently nonapplicability, which was never stated in the IEEE in a manner that justifies this argument? And does standard. Thus, software development isnt viewed this mean software development as opposed to this way nor is it documented in this manner. The software? correct version provides all aspects or subjects of the software for review and documentation. The reader The second sentence is also confusing and it is has to remember this is only a discussion area and not unclear what value is being added by the sentence - if part of the staff regulatory position.
a subject is associated with the development of a safety system, then it is expected that it would be applicable for review. Is the purpose of the second sentence to mean that all sections in IEEE Std. 830-1998 are applicable to the development of software for safety-related systems?
The first two sentences of the second paragraph should be clarified. A suggested rewording, if it meets the NRC staffs intent, is:
The section titled Nonapplicability in the previous version of this regulatory guide is being deleted because the NRC staff believes all sections of IEEE Std. 830-1998 are applicable to the development of software for safety-related systems.
The first two sentences of the second paragraph should be clarified. A suggested rewording, if it meets the NRC staffs intent, is:
The section titled Nonapplicability in the previous version of this regulatory guide is being deleted because the NRC staff believes all sections of IEEE Std. 830-1998 are applicable to the development of Page 5
Comments on DG-1209, Software Requirements Specifications for Digital Computer Software used in Safety Systems of NPPs DG-1209 is Rev. 1 of RG 1.172 Originator Draft Guide Comment NRC Response software for safety-related systems.
David Herrell DG-1209 The last sentence of the second paragraph is Thank you for your comment. No changes have been (RG 1.172) confusing as written. A few examples of the made as a result of the comment. The reference is to Section B confusing statements include: the previous sentence, as clarity of the SRS is needed second paragraph for the documentation in RG 1.170.
The opening statement This is also the case is confusing because it is not clear what is also the Digital systems have what is globally understood as case. features based on software. A digital single loop controller can have a feature of reset inhibit for its The name associated features is never defined latest model and be completely different in details either in this RG or in RG 1.170. The use of the from that of another vendor. Again the term name in the third paragraph on Page 5 of DG-1207 associated features is very familiar for implies associated features are safety system features instrumentation and control engineers with the term, that are exercised during testing but not identified. If and thus a global topic that does not require a this is the meaning, then it is unclear how making a definition or citation.
requirement unambiguous will allow associated features to be identified. Or is this intended to be tied to the idea of associated circuits in IEEE 383?
The last sentence of the second paragraph should be clarified and the NRC staff should explain more clearly how making requirements unambiguous allows for associated features to be identified.
The term associated features should be defined. In addition, the word associated has very specific meaning when it comes to safety-related systems so the NRC staff should consider if this is the correct use of this word.
David Herrell DG-1209 In the third sentence, the statement is made that the Thank you for your comment. No changes have been (RG 1.172) NRC staff does not endorse Subclause 5.3.6.3 of made as a result of the comment.
Section B, IEEE Std. 830-1998 due to not having sufficient The IEEE standard does point to specific Page 6
Comments on DG-1209, Software Requirements Specifications for Digital Computer Software used in Safety Systems of NPPs DG-1209 is Rev. 1 of RG 1.172 Originator Draft Guide Comment NRC Response third paragraph detail for protecting software. This non- requirements for cyber security and also mixes and endorsement is re-iterated in Section C.6.b of this security controls into the secure development arena.
Section C, RG. Subclause 5.3.6.3 of IEEE Std. 830-1998 states The NRC has clarified the proper assessment of cyber Page 8, the following: security and SDOE guidance. Is it up to the licensee Sub-section 6b, or applicant to define software and software system
[Security Software Attribute] should specify the First Paragraph requirements to their vendors as needed to factors that protect the software from accidental or demonstrate compliance with the NRC regulations.
malicious access, use, modification, destruction, or disclosure. Specific requirements in this area could include the need to IEEE Std. 830-1998 is a standard on how to specify requirements, and it is not the source document for what the requirements must be. The NRC staffs non-endorsement of this section is written as if IEEE Std. 830-1998 is attempting to specify content, when it is only describing attributes. This would be similar to the NRC staff saying they do not endorse the Availability software attribute subclause because requirements for safety-system availability are provided in other documents. Even though the source of security requirements are located in other documents, the ability to specify these requirements for a specific software language and system design can be different with each application so providing software attributes of security requirements adds value. Requirements for software should always include cyber security requirements, which is all this portion of the IEEE standard attempts.
The NRC staff should clarify the guidance provided in Subclause 5.3.6.3 of IEEE Std. 830-1998, not state that they do not endorse the subclause and then point to the source documents for the requirements Page 7
Comments on DG-1209, Software Requirements Specifications for Digital Computer Software used in Safety Systems of NPPs DG-1209 is Rev. 1 of RG 1.172 Originator Draft Guide Comment NRC Response themselves (this standard is not specifying the source of the requirements, only the attributes of the requirements specification). In other words, the NRC staff should clarify their position on Security with regards to Software Requirements Specification, not with regards to the source documents for those requirements.
Licensees and applicants know they are required to comply with RG 1.152 for SDOE and 10 CFR 73.54 for Cyber-Security - having to reiterate this fact in every software RG seems to be an unnecessary, burdensome approach and confuses the fact that, although RG 1.52 and 10 CFR 73.54 are the source of requirements, that does not mean they provide sufficient information on how to write the software specifications for those requirements.
David Herrell DG-1209 The opening sentence is unclear as written and states, Thank you for your comment. No changes have been (RG 1.172) This regulatory guide is based on standards and made as a result of the comment. By not adding Section B, describes methods acceptable for any safety system international or national the structure leaves the Page 5, first and discusses the required SRS activities. source as an open option. The following sequence of paragraph and in the proposed sentence are too close.
Please clarify this sentence, which should likely read, This regulatory guide is based on international consensus standards and describes methods and SRS activities acceptable for any safety system software.
David Herrell DG-1209 The paragraph is titled Traceability and Accuracy Thank you for your comment. No changes have been (RG 1.172) which is consistent with the previous version of this made as a result of the comment. Accuracy is a Section C, regulatory guide. However, the word accuracy is it general term and it refers to how accurate the Page 6, pertains to requirements specification is not defined representations of the natural language descriptions Sub-section 2a, in this regulatory guide nor IEEE Std. 830, so its are developed and traced for configuration Page 8
Comments on DG-1209, Software Requirements Specifications for Digital Computer Software used in Safety Systems of NPPs DG-1209 is Rev. 1 of RG 1.172 Originator Draft Guide Comment NRC Response First Paragraph meaning is unclear. In addition, the use of the word management.
traceability in this section is not consistent with the The term traceability is not exclusive in meaning to use of that word in the section titled Traceability the software development life cycle as in letter g. of (the notion of traceability has to do with tracing the regulatory guide. It is again a generic term and through stages of software development, which is not holds to point out how a subject matter is traceable.
the same as ensuring each natural language requirements stays linked to the same requirement The logic that a tool can create one and only one under the representation tool). Finally, the use of interpretation is questionable and thus the reason for representation or specification tools for requirements the separate subsection called Unambiguity in the is part of the unambiguous section of IEEE Std. regulatory guide.
830-1998, where it correctly belongs, since the use of tools for requirements is about the process of ensuring there is one and only one interpretation.
Recommend changing the title of this section to Unambiguity and combining discussion from Section 2.h in with this section. Also, the use of the word traceability should be replaced with a different word in this section to prevent confusion with the SRS characteristic traceability.
David Herrell DG-1209 As discussed in this section, IEEE Std. 830-1998 Thank you for your comment. No changes have been (RG 1.172) states that unverifiable requirements should be made as a result of the comment. The NRC Section C, removed or revised. The NRC guidance is that promulgates its regulatory guidance documents to the Page 7, unverifiable requirements should be modified or NRCs licensees and applicants and it is the Sub-section 2e, restated. It is not clear how restating an responsibility of the licensee and applicant to define First Paragraph unverifiable requirement can make it become software and software system requirements to their verifiable (unless it is being modified in the process), vendors as needed to demonstrate compliance with and it is not clear why these arent the same as the NRC regulations. Thus an unverifiable revising a requirement requirement should be modified or restated.
Recommend NRC staff replace modified or restated with revised so that the section reads Page 9
Comments on DG-1209, Software Requirements Specifications for Digital Computer Software used in Safety Systems of NPPs DG-1209 is Rev. 1 of RG 1.172 Originator Draft Guide Comment NRC Response more clearly. Specifically, it appears that the RG is saying that the IEEE standard requires unverifiable requirements to be removed or revise to be verifiable, but the NRC staff only endorses the option to revise to be verifiable.
Matt Gibson DG-1209 830 does not state that each requirement is traceable Thank you for your comment. No changes have been (RG 1.172) to a higher level requirements specification. This made as a result of the comment. The regulatory Section C, would make an infinite backward traceability. It position describes what is traceable in IEEE Std. 830 Page 7, states that origin is clear. Backward traceability and explains that the SRS must be backward Subsection 2.g. refers to previous stages of development NOT higher traceable to a higher level requirements specification levels of requirements. The wording here does not and ultimately to the system licensing (e.g.,
capture the intent of 830 which is that if requirement regulatory requirements that it satisfies) and the origins are identified in earlier documents, backward design bases (e.g., IEEE 603-1991 Clause 4).
traceability to those origins must be maintained.
Matt Gibson DG-1209 Not all requirements can be traced to specific Thank you for your comment. No changes have been (RG 1.172) licensing or design bases documents. For example, made as a result of the comment. The use of digital Section C, specific self-diagnostic features of which ensure systems can add new levels of complexity and value Page 7, notification of component failures or HMI when added by the applicant or licensee. With this Subsection 2.g. requirements found in standards such as HFES-100 complexity there can be self-diagnostic feature that can't be found in licensing or design bases will still require traceability to a higher level documents. This is a level of detail not found in requirement and ultimately the system licensing and these documents but requirements may have their design basis. The criteria in GDC 1 in Appendix A to origins in other standards. Clearly the origins must 10 CFR Part 50 has not changed. Is it up to the be identified and design bases and regulatory licensee or applicant to define software and software requirements must be included but the requirements system requirements to their vendors as needed to won't end up being limited to these origins. An demonstrate compliance with the NRC regulations.
additional example is provided by this regulatory guide below.
David Herrell DG-1209 This section is confusing and vague as written Thank you for your comment. As a result of the Page 10
Comments on DG-1209, Software Requirements Specifications for Digital Computer Software used in Safety Systems of NPPs DG-1209 is Rev. 1 of RG 1.172 Originator Draft Guide Comment NRC Response (RG 1.172) because it is not clear what new information is being comment the sentence was changed to:
Section C, provided by this section that is not already in IEEE Software requirements are generally derived from Page 7, Std. 830-1998. What does it mean to say the associated software products, such as safety system Sub-section 2h, relationship between software requirements and the requirements; the combination of the SRS and such First Paragraph products they are used to create should be associated documents should be unambiguous.
unambiguous?
Recommend clarifying the last sentence in Section C.2.h. Specifically, the NRC staff should clarify what is means to say the relationship between a requirement and its end product should be unambiguous. This clarification should be sufficient to allow the applicant or licensee to know what is an acceptable relationship and what is not.
Also, recommend combining this section with Section C.2.a as mentioned in a previous comment.
David Herrell DG-1209 The second and third sentences appear to be poor use Thank you for your comment. No changes have been (RG 1.172) of the words should and may in regulatory made as a result of the comment. The word should Section C, Page guidance. By using the word should, the NRC staff provides the option to the licensee or applicant in 8, is stating a preferred approach. It would be a better their approach to addressing the topic. In this Sub-section 3, approach to use a format such as either the licensee situation the IEEE standard begins to discuss the First Paragraph or applicant shouldor the licensee or applicant aspect of configuration management, which may be should so that the NRC is not providing a good information and relate to the SRS development preferred approach (without justification) if either process or can be addressed in the regulatory guide approach is acceptable. on configuration management. The option is up to the licensee and applicant.
It is not clear why the NRC staffs preferred approach is that the licensee or applicant should have a separate change control process for the SRS. Why isnt the preferred approach to use a single software change control process that is part of the Configuration Management Program per RG 1.169?
Page 11
Comments on DG-1209, Software Requirements Specifications for Digital Computer Software used in Safety Systems of NPPs DG-1209 is Rev. 1 of RG 1.172 Originator Draft Guide Comment NRC Response Incorrect software requirements are known to be a major contributor to the probability of latent errors in software, so it is not clear why the NRC staff does not require the SRS to be a Configuration Item per IEEE Std. 830-1998.
The last sentence of Section C.3 is a standalone statement of fact that does not provide any useful guidance for this section.
Any guidance related to change control and configuration management should be provided in RG 1.169. The guidance in Section C.3 should say that the NRC staff does not endorse Section 4.5 of IEEE Std. 830-1998 because guidance on change control and configuration management is provided in RG 1.169. If the NRC staff believes an exception should be made for the SRS, then this exception should be provided in RG 1.169 and Section 4.5 of IEEE Std. 830-1998 should be referenced there (or the wording from Section 4.5 of IEEE Std. 830-1998 placed directly in to RG 1.169 to prevent having to reference another standard and confuse the issue with IEEE Std. 828-2005).
Matt Gibson DG-1209 [this is] Another example of requirements that do not Thank you for your comment. No changes have been (RG 1.172) originate in licensing or design bases. made as a result of the comment. Is it up to the Section C, licensee or applicant to define software and software Page 8, system requirements to their vendors as needed to Subsection 6.c. demonstrate compliance with the NRC regulations.
David Herrell DG-1209 Annex Subsection, Header - This section has the Thank you for your comment. As a result of your (RG 1.172) same number as the previous section comment, the section has been renumbered.
Page 12
Comments on DG-1209, Software Requirements Specifications for Digital Computer Software used in Safety Systems of NPPs DG-1209 is Rev. 1 of RG 1.172 Originator Draft Guide Comment NRC Response Section C, Page Change this section number to Section 7.
9 David Herrell DG-1209 The bullet is poorly worded. What does it mean to Thank you for your comment. No changes have been (RG 1.172) say licensees may use non-endorsed Annex A as an made as a result of the comment. An example serves Section C, Page example? What does it mean to say Subclause 5.3.7 as a pattern to be imitated. However, it is up to the 9 Annex may be taken as advisory only? Is it okay for licensee or applicant to define software and software Subsection, First licensees and applicants to use Annex A format - if system requirements to their vendors as needed to Bullet not then why? The wording of this bullet implies that demonstrate compliance with the NRC regulations.
the NRC staff has a problem with the format in Annex A, as opposed to the NRC staff not endorsing Annex A because it is informative only.
The NRC staff should clarify their position on Annex A, because it is not clear what the NRC staff is saying they would do if the licensee or applicant provides an SRS in a format from Annex A. If it is okay for a licensee or applicant to provide an SRS in the format of Annex A, the NRC staff should say this.
Mark DG-1209 DG-1209 Section D states: Licensees may use the Thank you for your comment. The answer to Burzynski (RG 1.172) information in this regulatory guide for actions which do Question is yes. The regulatory guide information Section D not require NRC review and approval such as changes to a can be used for any software installation.
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?
Page 13