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 Regu latory Guide (RG) 1.172 Page 1 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 follow ing table contains the public comments received and the NRC staff responses.
Comments were received from the following individuals: Matt Gibson, Duke Energy (Matt.Gibson@Duke-Energy.Com) (ADAMS - ML12321A013) Mark Burzynski, New Clear Day, Inc. 2036 Marina Cove Dr. Hixson, TX 37343 (ADAMS - ML122910794) David Herrell, MPR Associates, Inc. 320 King St., Alexandria, VA 22314 (ADAMS - ML12346A034)
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 (RG 1.172)
General With the current emphasis on FPGAs, one would have thought that the topic would have at least been mentioned in this draft. Incorporate at least some small amount of guidance on applicability of software lifecycles techniques to 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-1209 (RG 1.172)
General This regulatory guide clearly defines the roles and responsibilities of licensees, applicants, and NRC staff for software processes. However, this reviewer's experience shows that most, if not almost all, safety software is not written by licensees or applicants. Rather, safety software and safety Thank you for your comment. No changes have been made as a result of the 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-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 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 agency's 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 NRC's 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-1209 (RG 1.172)
Section A
Page 2, first partial paragraph, line 5 Eliminate the ambiguous reference to "it" for clear, unambiguous requirements. Replace the phrase "-assure a quality product and that it will perform-" with "-assure a quality product that will perform-" (delete "and" and "it") for clarity. Thank you for your comment. As a result of the comment, the sentence has been revised to eliminate the ambiguity. David Herrell DG-1209 (RG 1.172)
Section A In the paragraph starting "The NRC issues regulatory-" simplify the sentence structure. Replace "applicants; however" with "applicants. 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 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 3 rd paragraph 4 th line However," for consistency with other regulatory guides. sentence" transition issue. See Diana Hacker's "A Writer's Reference," Page 112. The use of ";
however, will be revised. David Herrell DG-1209 (RG 1.172)
Section A page 2, third
paragraph, next
to last line 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 NRC staff does not identify specific revisions for some guidance documents. This type of dynamic referencing is done because different licensees and applicants may have 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 (RG 1.172)
Section B First paragraph, first line - Editorial style - For consistency with other standards, add a comma after "such as IEEE standards" to set off the phrase. Thank you for your comment. As a result of the comment, the comma was added. David Herrell DG-1209 (RG 1.172)
Section B Page 3, next to last paragraph, line 3 In the paragraph starting "The original regulatory guide..." the third sentence is ambiguous, the word "venue" is being used incorrectly, and "IEEE 830-1998" is not consistent referencing of the standard (should be "IEEE Std. 830-1998"). Replace the sentence "Within this same venue is a new section to this regulatory guide called
'Unambiguity'." with "This regulatory guide provides a new section, 'Unambiguity' consistent with IEEE Std. 830-1998." If that is the intent of this sentence. Thank you for your comment. As a result of the comment, edits were made and the new sentence reads: "All subjects associated with the development of safety system are applicable for review and not inherently ambiguous. Within this same thought a new section to this regulatory guide called "Unambiguity" has been add."
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 David Herrell DG-1209 (RG 1.172)
Section B
Page 3, first paragraph The last two sentences of the first paragraph are confusing as written. A few examples of the confusing statements include: The word "corrects" is misleading (suggesting something is wrong with IEEE Std. 830) and the word "enhancements" is opinionated. The actions being performed should be stated more precisely. The phrase "other perspectives" is vague - what are the "other" perspectives being referred to and why are the perspectives of the software attribute being changed and not the software attribute itself? "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." Thank you for your comment. No changes have been made as a result of the comment. The original regulatory guide had incorrect information on topics like security and this new revision now corrects this situation. The basic topic of this paragraph in this discussion is centered on the regulatory guide and not the IEEE Std. 830. The term attribute in used to generally describe what the IEEE standard may call characteristic or requirements. There is no reference to software attributes as the read discussion in the IEEE standard
refers to the SRS. David Herrell DG-1209 (RG 1.172)
Section B Page 3, second
paragraph The first two sentences of the second paragraph are confusing as written. A few examples of the confusing statements include:
The phrase "changes in the way software is viewed and documented" is confusing. What does it mean to Thank you for your comment. No changes have been made as a result of the comment. The discussion states the changes from the old regulatory to the new and the reader needs to have an understanding of both standards. The new regulatory guide states that requirements for a SRS need to be unambiguous and 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 say software is being viewed differently and whose viewpoint is being referred to, possibly the NRC staff? How is software being documented differently in a manner that justifies this argument? And does this mean "software development" as opposed to "software"? The second sentence is also confusing and it is unclear what value is being added by the sentence - if 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 staff's 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 staff's 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 this paragraph is reaffirming that the original regulatory guide was updated from the statement of nonapplicability, which was never stated in the IEEE standard. Thus, software development isn't viewed this way nor is it documented in this manner. The correct version provides all aspects or subjects of the software for review and documentation. The reader has to remember this is only a discussion area and not part of the staff regulatory position.
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 software for safety-related systems." David Herrell DG-1209 (RG 1.172)
Section B second paragraph The last sentence of the second paragraph is confusing as written. A few examples of the confusing statements include: The opening statement "This is also the case" is confusing because it is not clear what is also the case. The name "associated features" is never defined either in this RG or in RG 1.170. The use of the name in the third paragraph on Page 5 of DG-1207 implies associated features are safety system features that are exercised during testing but not identified. If this is the meaning, then it is unclear how making a 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. Thank you for your comment. No changes have been made as a result of the comment. The reference is to the previous sentence, as clarity of the SRS is needed for the documentation in RG 1.170. Digital systems have what is globally understood as features based on software. A digital single loop
controller can have a feature of reset inhibit for its latest model and be completely different in details from that of another vendor. Again the term associated features is very familiar for instrumentation and control engineers with the term, and thus a global topic that does not require a definition or citation. David Herrell DG-1209 (RG 1.172)
Section B, In the third sentence, the statement is made that the NRC staff does not endorse Subclause 5.3.6.3 of IEEE Std. 830-1998 due to not "-having sufficient Thank you for your comment. No changes have been made as a result of the comment.
The IEEE standard does point to specific 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 third paragraph and Section C,
Page 8, Sub-section 6b, First Paragraph detail for protecting software." This non-endorsement is re-iterated in Section C.6.b of this RG. Subclause 5.3.6.3 of IEEE Std. 830-1998 states
the following: "[Security Software Attribute] should specify the factors that protect the software from accidental or 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 staff's
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 requirements for cyber security and also mixes security controls into the secure development arena.
The NRC has clarified the proper assessment of cyber security and SDOE guidance. Is it up to the licensee or applicant to define software and software system requirements to their vendors as needed to demonstrate compliance with the NRC regulations.
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 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 (RG 1.172)
Section B,
Page 5, first paragraph The opening sentence is unclear as written and states, "This regulatory guide is based on standards and describes methods acceptable for any safety system and discusses the required SRS activities." 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." Thank you for your comment. No changes have been made as a result of the comment. By not adding international or national the structure leaves the source as an open option. The following sequence of and in the proposed sentence are too close.
David Herrell DG-1209 (RG 1.172)
Section C,
Page 6, Sub-section 2a, The paragraph is titled "Traceability and Accuracy" which is consistent with the previous version of this regulatory guide. However, the word "accuracy" is it pertains to requirements specification is not defined in this regulatory guide nor IEEE Std. 830, so its Thank you for your comment. No changes have been made as a result of the comment. Accuracy is a general term and it refe rs to how accurate the representations of the natu ral language descriptions are developed and traced for configuration 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 First Paragraph meaning is unclear. In addition, the use of the word "traceability" in this section is not consistent with the use of that word in the section titled "Traceability" (the notion of traceability has to do with tracing through stages of software development, which is not the same as ensuring each natural language requirements stays "linked" to the same requirement under the representation tool). Finally, the use of representation or specification tools for requirements is part of the "unambiguous" section of IEEE Std. 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." management. The term traceability is not exclusive in meaning to the software development life cycle as in letter g. of the regulatory guide. It is again a generic term and holds to point out how a subject matter is traceable. The logic that a tool can create one and only one interpretation is questionable and thus the reason for the separate subsection called "Unambiguity" in the regulatory guide. David Herrell DG-1209 (RG 1.172)
Section C,
Page 7, Sub-section 2e, First Paragraph As discussed in this section, IEEE Std. 830-1998 states that unverifiable requirements should be removed or revised. The NRC guidance is that unverifiable requirements should be "modified" or "restated". It is not clear how restating an unverifiable requirement can make it become verifiable (unless it is being modified in the process), and it is not clear why these aren't the same as revising a requirement Recommend NRC staff replace "modified or restated" with "revised" so that the section reads Thank you for your comment. No changes have been made as a result of the comment. The NRC promulgates its regulatory guidance documents to the
NRC's 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. Thus an unverifiable requirement should be "modified" or "restated".
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 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 (RG 1.172)
Section C,
Page 7, Subsection 2.g. 830 does not state that each requirement is traceable to a higher level requirements specification. This would make an infinite backward traceability. It states that origin is clear. Backward traceability refers to previous stages of development NOT higher levels of requirements. The wording here does not capture the intent of 830 which is that if requirement origins are identified in earlier documents, backward traceability to those origins must be maintained. Thank you for your comment. No changes have been made as a result of the comment. The regulatory position describes what is traceable in IEEE Std. 830 and explains that the SRS must be backward traceable to a higher level requirements specification and ultimately to the system licensing (e.g.,
regulatory requirements that it satisfies) and the
design bases (e.g., IEEE 603-1991 Clause 4). Matt Gibson DG-1209 (RG 1.172)
Section C,
Page 7, Subsection 2.g. Not all requirements can be traced to specific licensing or design bases documents. For example, specific self-diagnostic features of which ensure notification of component failures or HMI requirements found in standards such as HFES-100 can't be found in licensing or design bases documents. This is a level of detail not found in these documents but requirements may have their origins in other standards. Clearly the origins must be identified and design bases and regulatory requirements must be included but the requirements won't end up being limited to these origins. An additional example is provided by this regulatory guide below. Thank you for your comment. No changes have been made as a result of the comment. The use of digital systems can add new levels of complexity and value
when added by the applicant or licensee. With this complexity there can be self-diagnostic feature that will still require traceability to a higher level requirement and ultimately the system licensing and design basis. The criteria in GDC 1 in Appendix A to 10 CFR Part 50 has not changed. Is it up to the licensee or applicant to define software and software system requirements to their vendors as needed to demonstrate compliance with the NRC regulations. David Herrell DG-1209 This section is confusing and vague as written Thank you for your comment. As a result of the 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 (RG 1.172)
Section C,
Page 7, Sub-section 2h, First Paragraph because it is not clear what new information is being provided by this section that is not already in IEEE Std. 830-1998. What does it mean to say the "relationship" between software requirements and the products they are used to create should be 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. comment the sentence was changed to: "Software requirements are generally derived from associated software products, such as safety system requirements; the combination of the SRS and such associated documents should be unambiguous." David Herrell DG-1209 (RG 1.172)
Section C, Page 8,
Sub-section 3, First Paragraph The second and third sentences appear to be poor use of the words "should" and "may" in regulatory guidance. By using the word "should," the NRC staff is stating a preferred approach. It would be a better approach to use a format such as "either the licensee or applicant should-or the licensee or applicant should-" so that the NRC is not providing a
preferred approach (without justification) if either approach is acceptable. It is not clear why the NRC staff's preferred approach is that the licensee or applicant should have a separate change control process for the SRS. Why isn't the preferred approach to use a single software change control process that is part of the Configuration Management Program per RG 1.169? Thank you for your comment. No changes have been made as a result of the comment. The word "should" provides the option to the licensee or applicant in
their approach to addressing the topic. In this situation the IEEE standard begins to discuss the aspect of configuration management, which may be good information and relate to the SRS development process or can be addressed in the regulatory guide on configuration management. The option is up to the licensee and applicant.
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 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 (RG 1.172)
Section C, Page 8, Subsection 6.c. [this is] Another example of requirements that do not originate in licensing or design bases. Thank you for your comment. No changes have been made as a result of the comment. Is it up to the licensee or applicant to define software and software system requirements to their vendors as needed to demonstrate compliance with the NRC regulations. David Herrell DG-1209 (RG 1.172) "Annex" Subsection, Header - This section has the same number as the previous section Thank you for your comment. As a result of your comment, the section has been renumbered.
Page 13 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 9 Change this section number to Section 7. David Herrell DG-1209 (RG 1.172)
Section C, Page 9 "Annex" Subsection, First
Bullet The bullet is poorly worded. What does it mean to say licensees may use non-endorsed Annex A "as an example"? What does it mean to say Subclause 5.3.7 "may be taken as advisory only"? Is it okay for licensees and applicants to use Annex A format - if not then why? The wording of this bullet implies that 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 licens ee 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. Thank you for your comment. No changes have been made as a result of the comment. An example serves as a pattern to be imitated. However, it is up to the licensee or applicant to define software and software system requirements to their vendors as needed to demonstrate compliance with the NRC regulations.
Mark Burzynski DG-1209 (RG 1.172)
Section D DG-1209 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. The answer to Question is yes. The regulatory guide information can be used for any software installation.