ML20198F785

Reg Guide 01.173, Developing Software Life Cycle Processes for Digital Computer Software Used in Safety Sys of Npp

ML20198F785
Person / Time
Issue date:	09/30/1997
From:	NRC OFFICE OF NUCLEAR REGULATORY RESEARCH (RES)
To:
References
TASK-*****, TASK-RE REGGD-01.173, REGGD-1.173, NUDOCS 9801120161
Download: ML20198F785 (7)

Text

i I'

U.S. NUCLEAR REGULATORY COMMISSION September 1997 f r a g ,,

O REGULATORY GUIDE l

), OFFICE OF NUCLEAR REGULATORY RESEARCH l

1 i

REGULATORY GUIDE 1.173 (Draft was DG-1059)

DEVELOPING SOFTWARE LIFE CYCLE PROCESSES FOR DIGITAL COMFUTER SOFTWARE USED IN SAFETY SYSTEMS OF NUCLEAP. POWER PLANTS A. INTRODUCTION ing, installing, testing, operating, maintaining, or mod-ifying. A specific requirement is contained in 10 CFR in 10 CFR Part 50," Domestic Licensing of Pro- 50.55a(h), which requires that scactor protection sys-duction and Utili7ation Facilities," paragraph 55a(u)(1) tems satisfy the criteria of IElill Std 279-1971,"Crite-icquires, in part,I that systems and components be ria for Protection Systems for Nuclear Power Generat-designed, tested, and inspected to quality standards ing Stations."2 Paragraph 4.3 of Il!EE Std 279-19713 commensurate with the safety function to be per* states that quality of components is to be achieved formed. Criterion 1," Quality Standards and Records," through the specification of requirements known to of Appendix A," General Design Criteria for Nuclear promote high quality, such as requirements for design, Power Plants," to 10CFR Part 50 requires,in part.1 that inspection, and testing.

O a quality assurance program be established and imple-l mented in order to provide adequate assurance that sys-In Appendix 11 to 10 CFR Part 50, many of the cri-ten.a contain requirements closely related to software tems and components important to safety will satisfac, torily perform their safety functions. Appendix D, life cycle activities. Criterion I, " Organization," de-scribes the establishment and execution of a quality as-

" Quality Assurance Criteria for Nuclear Power Plants and Fuel Reprocessing Plants," to 10 CIM Part 50 de- surance program. Criterion 11. " Quality Anurance Pro-scribes criteria that a quality assurance program for sys, gram," states, in part, that activities affecting quality must be accomplished under suitably controlled condi-tems and components that prevent or mitigate the con-tions, which include assurance that all prerequisites for sequences of postulated accidents must meet, in a given activity have been satisfied. This criterion also particular, besides the systems and components that directly prevent or mitigate the consequences of postu- ig,,,,,, i og g,g,,,, o,,3, i i33, .c,g,,i, ,,, s.rciy s3 uemse en.

lated necidents, the criteria of Appendix H iilso apply to dorscs liill sid 603-1991,Cnteria for safety s)Mems ror Nuclear Pow-s

""'" anna iaininsr as a rnethod amriaNe io tw N9c uan tor saia-all activities atfecting the safet7 related functions of tying the NRC s regulations u ith respect to the design, rehabihty,quahn-such systems and components as desigmng, purchas. canon, and icMatnhiy of the power. 4nstrumentation, and control porteons of the safety systems of nucleat power plants-H puhahona may k obtained from the 11.11 senke Center 445 11 HI 50 r e f 11 te Hoes Ianc, Pacataw sy. NJ OM54 ns.c ., mumn onni i n. ~ .. .~, i., io.m.

R.g..-,n..~.~-,, -

-.~.-.~m.u..-,.-,~.e- ,%a. . -

• • ".C*t".TJ.=J;'",.';*d.=,

u. T.J' =' "7 i ,"=T.;".'.ac ?.  ; L"*="6

=,'=A":T;m=:="=:'3x..".r."J.*r. . a:  ; 0:=,0;L. ,: r.= ~ - a-yg,y .,.gp. -. . ~ m -

n  % . ,_,. , .. .,~ - c $;;*=:%"Wh"O=/.::fuTd""R.,'*3L p"""* "t?:"?Z"l=*. .'",';;l** C""4"=:m":'.'e'*e* "

(V) " " ***"""*

m,.n -. m, i. n.n . e iv. % w w.ci e,.m m i.u.a m ~y

. .uv m (

- o ~ ,

t a = e. .-. m.,

T.ce-c. w*= sm. on n.o ev ."w es s.ei ADht U S teutt R. gut.my C.,ms.mn, W *ungu\ OC 20NS 0001 Roy. Rosi Epnngh.N1 VA 22161 9801120161 970960 jfdhld?fI Nf PDR 01,173 R REGOD -

h , ,

• I M in

• ' - i ~I'Tr0y PDR

l cells for taking into account the need for special con- II. DISCUSSION trols and processes to attai 'he required quality. Crite-tion ll!," Design Control," states, in part, that measures The use of industry consenses standards is part of must be established for the identification and control of an overall approach to meeting the requiremerts of design interfaces and for coordination among partici. 10 CFR Part 50 when developing safety systems for pating design organizations. Criterion XV,"Noncon- nuclear power plants. Compliance with standards does forming Materials, Parts, or Components," requires not guarantee that regulatory requirements will be met.

measures to be established to control materials, parts, llowever, compliance does ensure that practices ac-or components that do not conform to requirements in cepted within various technical communities will be in-order to prevent their inadvertent use or installation. corporated into the development and quality assurance l'inally, Criteria VI, " Document Control," and XVil, processes used to design safety systems. These prac.

" Quality Assurance itecords," provide for the control tices are based on past experience and represent indus-of the issuance of documents, including changes there- try consensus on approaches used for developmet t of 10, that prescribe all activities affecting quality and pro- such systems, vide for the maintenance of sulficient records to furnish Software incorporated into instrumentation and evidence of utivities affecting quality.

o overed by Appendix 11will be referred This segulatory guide endorses liiEi! Std to in this regulatory guide as safety system software.

1074-1995,"ll!Eli Standard fot Developing software The development of software for high mtegrity 1.ife Cycle Processes,"3 subject to the exceptions stated applications, such as safety system software, requires in the itegulatory Position. 't!EE Std 1074-1995 de- the use of a carefnlly planned and controlled develop-wribes a method acceptable to the NitC staff for com* ment process that incorporates the best available ap-plying with parts of the NitC's regulations for promot- proaches to the various aspects of software engineer-ing high functional reliability and design quality in ing. There are a number of consensus standards that sof tware used in safety systems.d in particular, the provide guidance on implementing currently accepted method is consistent with the previously cited General approaches *o specific software engineering activities Design Criteria and the criteria for quality assurance such as softwate requirements specification or software programs of Appendix il as they apply to software de- configuration management. A carefully planned and velopment processes. The criteria of Appendices A and controlled soltware development cffort must incorpo-11 apply to systems and related quality assurance rate these specific activities into an orderly process to processes, and if those systems include sof tware, the re- be followed in the software life cycle, including pre-quirements extend to the sof tware elements. software development and post software-development in general, information provided by regulatory processes. This regulatory guide addresses the subject guides is teuccted in the Standard lleview Plan of designing software life cycle processes appropriate (NUltEG-OS00). NitC's Office of Nuclear lleactor for the development of safety system sof tware.

Itegulation uses the Standard iteview Plan to review IEEliStd 1074-1995 describes, in terms ofinputs, applications to construct and operate nuclear power development, verification or control processes, and plants. This regulatory guide will apply to the revised outputs, a set of processes and constituent activities that Chapter 7 of the Standard lleview Plan. are commonly accepted as composing a controlled and The information collections contained in this regu- well coordinated software-davelopment piocess. It de-latory guide are covered by the requirements of 10 CFil scribes inter-relationships among activities by defining Part 50, which were approved by the Office of Manage. the source activities that produce the inputs and the des-ment and lludget, approval number 3150-001).The tination activities that receive the outputs. The standard NitC may not conduct or sponsor, and a person is not specifies activities that must be performed and their required to respond to, a collection of information un- inter relationships; it does not specify complete accep.

less it displays a currently valid OMil control number, tance criteria for determining whether the activities themselves are properly designed. Therefore, the stan-dard should be used in conjunction with guidance from other appropriate regulatory guides, siandards, and software engineering literature. IEEE Std 1074-1995

%cem ren pieme n ynongnoumih .ren.rci.ica piem,. can be used as a basis for developing specific software ne oenei.i twsn onwn. cmer piemuuuctureund component. life cycle processes that are consistent with regulatory requirements, as applied to software, for controlling M E '."Nc N m D' E N .".*u"t O N [!."/i'm N n'.'n e N

.. rem- and coordinating the design of safety system software.

1.173 - 2 l

Software development processes are intimately re- to lEEE Std 1074-1995 are not 2ndorsed by this regula-lated to system development processes, in the system tory guide, design phase, system safety requirements are allocated To meet the requirements of 10 CFR 50.55a(h) and to hardware, software, and human elements. In the sys.

Appendix A to 10 CFR Part 50 as ensured by comply-tem integration and testing phases, these elements are ing with the criteria of Appendix 11 applied to the devel-combined and tested. Consequently, a standard for soft

• opment processes for safety system software, the fol-ware development processes is intimately related to lowing provisions are necessary and will be considered system level standards, such as IEEE Std 7-4.3.2- - by the NRC staff in the review of applicant submittals.

1993," Standard Criteria for Digital Computers in Safe- (in this Regulatory Position, the cited criteria are in Ap-ty Systems of Nuclear Power Generating Stations," pendix B to 10 CFR Part 50 unless otherwise noted.)

which is endorsed by Revision 1 of Regulatory Guide l.152, " Criteria for Digital Computers in Safety Sys- 1 CLARIFICATIONS tems of Nuclear Power Plants." IEEE Std 1074-1995 Because IEEE Std 1074-1995 was not written spe-describes a complete set of software life cycle cifically for nuclear safety, the following clarifications processes; however, its system level view is a generic apply to the standard, view from a software perspective. To employ IEEE Std - 1074-1995 for developing safety system software, the 1,1 Regulatory Requirements identifled system level activities described in IEEE Std Criterion 111 " Design Control," requires measures 1074-1995 must be addressed within the context pro- to ensure the applicable regulatory requirements and

-vided by regulation and by nuclear industry standards. the design tiasis for those structures, systems, and com-Examples of rystem level issues from this context are ponents to which Appendix B applies are correctly the need for software safety analyses as part of system translated into specifications, drawings, procedures, safety evaluation and the need for determining the ac' and instructions. The descriptions of input information, ceptability of pre existing software for use in safety life cycle activity, and output information that are re-systems. Information on software safety activities and quired by IEEE Std 1074-1995 must identify applica-software life cycle activities in general can be found in ble regulatory requirements, design bases, and related Revision 1 of Regulatory Guide 1.152; NUREG/ gu. dance.

CR4101," Software Reliability and Safety in Nuclear Reactor Protection Systems"5 (November 1993); and 1.2 Consistency NUREG/CR4263,"lligh Integrity Software for Nu* Various statements in the standard imply or state clear Power Plants: Candidate Guidelines, Technical that life cycle activities should be consistent with bud-Basis and Research Needs"5 (June 1995). The second get and schedule or that contingency actions may be area, the acceptability of pre existing software, is par- taken to meet schedule or budget (paragraphs 3.2.3 and ticularly important in the nuclear context. Guidance on 3.2.4 of IEEE Std 1074-1995). All such activities and this subject is in Revision 1 of Regulatory Guide 1.152. contingency actions must be consistent with andjustifi.

C. REGUIATORY POSITION able with 10 CFR 50.57(a)(3), which requires that there be reasonable assurance that the activities authorized The requirements contained in IEEE Std by the operating license can be conducted without en-1074-lon5. "lEEE Standard for Developing Software dangering the health and safety of the public.

Life Cycle Processes,"3 provide an approach accept-able to the NRC staff for meeting the requirements of 1.3 Commercial Software 10 CFR Part 50 and the guidance in Revision l of Regu- Criterion 111, " Design Control," states . that latory Guide 1.152," Criteria for Digital Computers in measures are to be established for the selection and re-Safety Systems of Noclear Power Plants," as they apply view for suitability of application of materials, parts, to development processes for safety system software, equipment, and procewes that are essential to the safe-subject to the provisions listed below. The appendices ty related functions of the structures, systems, and components, Criterion Vil," Control of Purchased Ma-terial, Equipment, and Services," states that measures 5copie m evia.ue a conm rues from the u.s. novernmeni runimg am W eWM to ensme mat pmchased matedal, whether purchased directly or through contractors and O ottwc. rn" tu nos2, wohingion oc 204a2-9ns heSiTaSYsD2asY,tN["1n".'dN.ree" evia we for impeenon os corying rot renm the NRC Pubik Docu.

ociephonenI,*liN2$I$.Ne*s),

subcontractors, conforms to the procurement docu-ments. if pre-existing software (i.e., reusable SoflWare r commercial ff the shelf software) is incorporated NN$1N.

po2 p -n n.rpo2p 3mY'*Nih ngN$sI5Yo[$eYp"E*nel into a safety system developed under the method de-1.173 - 3

scribed by this regulatory guide, an acceptance procen 3. sol'!'WAltE sal'ETY ANAIXSES must be included at an appropriate point in the life cycle Criterion 111. " Design Control," requires measures model to establish the suitability of the pre-existin8 to ensure that applicable regulatory requirements and sof tware for its intended use. 'Ihe acceptance process, the design basis are correctly translated into specifica-its inputs, outputs, activities, pre conditions, and post

• tions, drawings, procedures, and instructions. To conditions, inust meet the applicable regulatory re* ensure that safety system sof tware development is con-quirements and design bases for the safety system. Re- s stent with the defined system safety analyses, addi-vision 1 of llegulatory Guide 1.152 provides tional activities beyond those specified in IliliE Std information on the acceptance of pre existing sof tware. 1074-1995 are necessary Planned and documented Additional detailed information on acceptance sof tware safety analysis activities should be c. ;cted processes is available in El'iti Til 106439," Guideline for each phad of the sof tware development life cycle.

on livaluation and Acceptance of Commercial Grade Therefore, these analyses should be identified in the Digital Equipment for Nuclear Safety Applications" applicant's life cycle model, including the following (October 1996)? inpu' 'ctivity description, and outputs.

1.4 Definition $ 3.1 luput Information

'I he following definitions are used in this regulato- . Itegulatory requirements and guidance, ty guide.

• Informaiion reported for the systen safety Accident An unplanned event of series of events that analysis, result in death, injury, illness, environmen- . Information from previous phases for the so'tware tal damage, or damage to or loss of equip- safety analysis, ment or property.

• The design information from previous and curret llaard A condition that is a prerequisite to an system and software phase activities.

accident.

2. COMPEIANCE WITil IEEE Std 1074-1995 L2 Description Criterion 11, " Quality Assurance Program," I EC"""IS'"*"""'*' ""

requires all activities af fecting quality to be accom-

• System safety requirements have been correctly plished under suitably controlled conditions. Section addressed, 1.5.1, " Applicability," of Ilil!E Std 1074-1995 permits

• No mv hard , hve been introduced, elimination of some life cycle activities, although com-pliance with the standard may not then be claimed. . Sof tware elements that can affect safety are According to this regulatory guide, compliance with identified,

- lEEli Std 1074-1995 means that all mandatory activi. . There is evidence that other software elements do ties are performed, that the requirements described as not af feet safety, and

'shall' are met, and that all the inputs, outputs, activi- . .

ties, pre-conditions, and post conditions mentioned by

. Safety problems and resolutions identified in these IEEli Std 1074-1995 are described or accounted for in analyses are documented.

the applicant's life cycle model. IEEE Std 1074-1995 These activities must be conducted according to a is an organizing standard that ensures that activities deemed important to software quality are performed Software Safety Plan addressing the organization to and related properly to each other; it does not provide puform the analyses, the responsibilities of its safety detailed information regarding the implen entation of officer, the management of the software safety activi-ties, and the analyses to be perf ormed for each phase to

' specific life cycle activities.

address hazards and abnormal conditions and ever.:s.

3.3 Output Information information for the current phase activitics is re-ported in the sof tware safety analysis. This information

• lleone Powcr Rescanh Imutute documcnti may be obtuned from the .

I PRI Dntobunon Ocnier. 207 Coggtm Dme, Po Itot 23:05, Plenani should be used for the design activities of the current tidl. CA 943211 PRl l R lus439 ts aho as adaNc rat invection os corp life cycle phase, subsequent software safety analysis .

mg for a fec m he NRC PuNie IMment koom at 21:01. street Nw.

wohmgen. c.ihc ron .mutme naarce Mia smp t.t s.. wnhing. activin.es, the sd> ware configmation management .

ion. Dc :esss-oooinricehone 1:o e4-3:73. r.s I oze4-n41 process, and me verification and validation process. )

1.173 - 4

4. NEW OR MOlHFIED SAFETY SYST131 arounds employed during the installation activities are SOITWARE removed.

Criterion XV," Nonconforming Materials, Parts, or 4.3 Operation Components,',' requires measures to be established to Section 6.23, " Operate the System," of IEEE Std controi matenals, parts.or components that do not con-1074-1995 requires the identification and reporting of form to requirements in order to prevent their inadver-

, anomalies as well as invocation of the verification and tent use or instalianon. ,The foncwing clarifications validatm.n (V&V) process and the sof tware configura-Should be made to IEl!E Std 1074-1995 with respect to

'*" **"agement pnwess. Sectmn U, Maintmanw the installation and operation of new or modified safety Process, requires the software life cycle to be re-system sof tware.

mapped and executed, thereby treating the Mainte-nance Process as .ierations of development." This 4.1 Temporary " Work Around" process will produce revisions to software executables in its overview discussion of the " Installation and configurations that may then be installed according Process" section 6.1.1 of ll!!!!! Std 1074-1995 states: to the installation process. Maintenance activities must "If a problem arises, it must be identified and reported; conform to the configuration control and V&V proce-if necessary and pmible, a temporary ' work around' dures agreed to under the licensing basis, may be applied." Por the purposes of this regulatory 5, TAILORING SOITWARE guide, the term work around is defined as follows.

Criterion V," Instructions, Procedures, and Draw.

ings," requkes that a6%es aUcedng quaWy be pre-A temporary change, to either the software or its ,

scribed by, and accomplished in accordance with, doc-configuration, that is made for the purpose of mented instructions, procedures, or drawings.

allowing the continuation of installation activi- ", don 615.2 of thEE Std 1074-1995 permits cus-ties and testing of parts of the software that are tomer taHor,ng in the ' Install Software' activity. Any unaf fected by the temporary change, tailoring of packaged sof tware or data m the data base at

" """ "" *"" # #"" " " ' * # I #

4'2 Installation installation planned information of IEEE Std U

Installation of new or modified safety system soft- 1074-1995. Criterion 111. " Design Control," requires ware may only be performed when all functions design changes to be subject to design control measures af fected by the software have been declared inoperable commensurate with those am lied to the original de-according to the plant technical specifications. When sign. T.iiloring that constitutes design changes, includ.

sof tware is involved, particularly for distributed soft. ing configurations not part of the original system de-ware architectures, the determin: tion of affected fune- sign, is not permitted unless such tailoring is subject to tions can depend on extremely subtle considerations, the full range of design and quality assurance measures An example would be two programs related to each oth. applicable to the development of safety system er only through use of a single data item, w hich might software.

not be evident from the examination of architecture dia-grams. As i Hnimum, ell functions performed, in part, 6. OTilER CODES AND STANDARDS by a gisen sof tware executable should be declared in. Various sections of IEEE Std 1074-1995 reference operable if the software executable, its configuration, industry codes and standards. These referenced stan-or its operating platform is to be altered; interconnee- dards should be treated individually, if n referenced tions of all types with other software, hardware, or hu- standard has been incorporated separately into the man elements should also be examined. Any work- NRC's regubtions, licensees and applicants must com-arounds employed during installation must be ply with that standard as set forth in the segulation, if accompanied by a disposition plan, rework procedures the referenced standard has been endorsed in a that conform to configuration control, verification and regulatory guide, the standard constitutes a method ac-validation pmcedures agiecd to under the licensing ba- ceptable to the NRC staff of meetmg a regulatory re-sis, and a resolution schedule. liefore affected func- quirement as described in the regulatory guide. If a ref-tions may be declared operable, the currently approved erenced standard has been neither incorporated into the (m) jv software, under the control of configuration manage.

ment, must be installed according to the procedures NRC's regulations nor endorsed in a regulatory guide, licensees and applicants may consider and use the in-specified in the installation process. This ensures that formation in the referenced standard, if appropriately the intended software is installed and that any work- justified, consistent with current regulatory practice.

1.173 - 5

D. IMPLEMENTATION with the specified portions of the TPAC's regulations, the methods described in this guide will be used in the The purpose of this section is to provide informa- evaluation of submittals in connection with applica-tion to applicants and licensees regarding the NRC tions for construction permits and operating licenses, staff'a plans for using this regulatory guide. No backfit- Dir guide will also be used to evaluate submittals from ting is intended or approved in connection with the operating reactor licensees that propose system modifi-issuance of thi. proposed guide. cations that are voluntarily initiated by the licensee if lixcept in those cases in which an applicant pro- there is a clear nexus between the proposed modifica-poses an acceptable alternative method for compl,.ing tions and this guidance.

O O

1.173 - 6

i HillLIOGRAPIIY liecht,11., A.T. Tal,- K.S. Tso, " Class IE Digital Sys- Lawrence, J.D., and G.G. Preckshot, " Design Factors v' tems Studies," NUREG/CR-6113, USNRC, October for Safety Critical Software," NUREG/CR-6294, 1993.1 USNRC, December 1994.1 Institute of Electrical and Electronics Engineers,"Stan- Seth, S., et al., "lligh Integrity Software for Nuclear dard Criteria for Digital Computers in Safety Systems Power Plants: Candidate Guidelines, Technical Basis of Nuclear Power Generating Stations," IEEE Std 3nd Research Needs," NUREG/CR4263, USNRC, 7-4.3.2,1993. June 1995.3 Lawrence, J.D., " Software Reliability and Safety in USNRC, " Criteria for Digital Computers in Safety Nuclear Reactor Protection Systems," NUREG/ Systems of Nuclear Power Plants," Regulatory Guide CR4101 (UCRL-ID-117524, Lawrence Livermore 1.152, Revision 1, January 1996.2 National Laboratory), USNRC, November 1993.1 USNRC, " Standard Review Plan," NUREG-0800, February 1934.

IC opies may be porchased at current rates from the U.s. Government Pnn. 2 single copics of regulatory guides may be obtained free of charge by writ-tirig Office. P.O. Ilon 37082. Washington, DC 20402-9328 (telephone ing the Pnntmg, Graphics and Distribution Branch. Office of Administra-(202)$12-2249); or f rom the National Technical Informatton service by tion, U.s. Nuclear Regulatory Commission. Washington. DC w titing NTis at 5285 Port Roy al Road, Sprmgricid, VA 22161. Copies are 20555-0001, or by tax at (301)415-5272. Copies are available for in-available for inspection or copying for a fee from the NRC Public Docu- spection of copying for a fee from the NRC Public Document Room at ment Room at 2120 L street NW., Washington. DC; the PDR's maihng ad- 2120 L street NW, Washington. DC: the PDR's mailing address is M*'l dress is Mail stop 11-6, Washington, DC 20$55-0001; telephone stop lL-6. Washington. DC 20555-0001; telephone (202)634-3273; rax

' (202)634-3273; fau (202)634-3343. (202)634-3343.

REGULATORY ANALYSIS h A separate replatory analysis was not prepared for this regulatory guide. The regulatory analysis prepared for Draft Regulatory Guide DG-1059," Developing Software Life Cycle Processes for Digital Computer Softwafe Used in Safety Sys-tems of Nuclear Power Plants," provides the regulatory basis for this guide. A copy of the regulatory analysis is available for inspection and copying for a fee at the NRC Public Document Room,2120 L Street NW., Washington, DC; the PDR's mailing address is Mail Stop LL-4, Washington, DC 20555-0001; phone (202)634-3273; fax (202)634-3343.

Pririted '

on recycled paper

,a

( )

Federal Recycling Program 1.173 - 7 i 1

!l1? l l '

N U

C P

WL E E

M L

T Y O FF F

AA S

H R N R U I

G E T GIN OC OUT

,NLE R A PL AD RB D T S NU AS C OT T

EN I

RA E >' Y T US nC E S S

,E %O S 3

5M 0

0 6MS 1

I S

I O

N P

O S .

P TIF .

E AR .

R GS M U ET TS AC I

NR N DNL O. CFS G

47 E

EM SA A

S I

P L A

I D

• 3a8W&E E Eb - ~lEm 48O i ,lllIiI1:liii I ll1 iill1lllI41ll 1 ) l