Regulatory Framework for 
Digital Instrumentation and Control Systems 
in Nuclear Power Plants

MIT Workshop on Safety-Critical Software and Safety
February 27, 2001

Matt Chiramal
Office of Nuclear Reactor Regulation, NRC
E‑mail: 

	TOPICS

•	Introduction - NRC and its Mission

•	Nuclear Power Plants and Digital Equipment

•	Regulations, Standards, and Guidance for Digital Systems

•	Requirements, Criteria, and Guidance for Safety-critical Software

•	COTS

•	Ongoing activities at NRC

•	Conclusion 

U.S. Nuclear Regulatory Commission and its Mission

•	NRC is an independent agency established by U.S. Congress under the Energy Reorganization Act of 1974

•	NRC’s Mission - Ensure adequate protection of the public health and safety, the common defense and security, and the environment in the use of nuclear materials in the United States

•	NRC's Scope of Responsibility includes regulation of 
•	commercial nuclear power reactors 
•	non-power research, test, and training reactors 
•	fuel cycle facilities 
•	medical, academic, and industrial uses of nuclear materials 
•	the transport, storage, and disposal of nuclear materials and waste.

•	NRC’s Regulatory Functions 
•	
•		Establish standards and regulations 
•		Issue licenses for nuclear facilities and users of nuclear materials
•		Inspect facilities and users of nuclear materials to ensure compliance with the requirements. 

	Nuclear Power Plant Safety Systems

Nuclear power plants are equipped with four major types of safety systems to prevent accidents and reduce their effects should one occur:

•	A system to quickly shut down the nuclear reactor and stop the fission chain reaction
•	Numerous systems to control reactor parameters and to continue cooling the reactor fuel ‑‑ that is, to carry away the heat that continues to be generated even after the reactor is shut down
•	Electrical, Instrumentation and Control (I&C) systems for safety systems and for monitoring plant conditions
•	System of barriers to contain radioactivity should it escape from the reactor fuel in an accident. 

Digital Instrumentation &Control Systems

I&C systems provide an important role in the safe operation of nuclear power plants.  Operating U.S. nuclear plants were designed and built with analog technology‑based I&C systems that are being replaced with computer‑based components.  New advanced nuclear plants will use digital systems extensively.

Digital I&C systems have the potential for enhanced safety and reliability; plant operability, availability and maintainability

•	Safety (reduce trips due to instrument and operator errors)
•	Stability (no drift)
•	Self diagnostics
•	Fault tolerance/avoidance
•	Low power requirements
•	Higher data handling and storage
Present challenges to the industry and NRC
	g	Rapidly evolving technology; not a mature discipline; obsolescence
•	New/Subtle failure modes
•	Increased complexity
•	Potential for common mode/cause failure due to software errors
•	Difficulties of complete testing
•	Equipment sensitivity to environment ‑ temperature, humidity, EMI/RFI, power quality, surges, grounding, static electricity
Existing Regulatory Framework

•	10 CFR 50.55a(h) incorporates the requirements of IEEE Standard 603 -1991, “IEEE Standard Criteria for Safety Systems for Nuclear Power Generating Stations.”  Establishes minimum functional design criteria for systems required to protect the public health and safety.

•	IEEE Standard 7- 4.3.2 - 1993, “IEEE Standard Criteria for Digital Computers in Safety Systems of Nuclear Power Generating Stations.”  The computer-specific requirements in this standard supplement the criteria and requirements of IEEE Std. 603.  Endorsed by NRC Regulatory Guide 1.152, Rev. 1, January 1996, “Criteria for Digital Computers in Safety Systems of Nuclear Power Plants.”

•	ASME NQA-1-1989 for hardware, and ASME NQA-2a-1990 Part 2.7 for software.

•	SRP Chapter 7, Rev. 4, June 1997, “Instrumentation and Controls.”

IEEE Standard 603

•	Safety System Criteria

•		Single-failure criterion - Systems shall perform all required safety functions in the presence of (1) any single detectable failure, (2) failures caused by the single failure, and (3) all failures and spurious system actuations due to the design basis event.
•		Completion of requisite action - systems, once initiated, shall continue until completion of all actions.
•		Quality - System equipment shall be designed and operated in accordance with a prescribed QA program.
•		Equipment qualification - Equipment shall be qualified (type tests, operating experience, analysis) to substantiate that it will perform per requirements specified in the design basis.
•		System integrity - Systems shall be designed to perform their safety functions under the full design basis range.
•		Independence - Electrical independence and physical separation shall be maintained between redundant portions of safety systems, safety systems and the effects of the design bases event, and safety systems and other systems. (CONTINUED)

•	
	Capability for test and calibration of safety systems and equipment during plant operation shall be provided while retaining the capability of the system to perform its safety function.
•		Information displays for safety system manual controls, status indiction, and bypassed or inoperable indiction shall be accurate, complete, and timely.  Design shall minimize the possibility of ambiguous indiction to operator.
•		Control of access
•		Repair
•		Identification
•		Auxiliary features
•		Human factors consideration
•		Reliability 

IEEE Standard 7- 4.3.2
Criteria in this standard, in conjunction with criteria in IEEE Std 603, establish minimum functional and design requirements for computers used in safety systems.

•	Quality
•	
•			Software development - Software shall be developed, modified, or accepted per an approved Software QA Plan consistent with the requirements of ASME NQA-2a-1990 Part 2.7.
•			Qualification of COTS computers
•			Software tools - Identified within the software development process and controlled under configuration management. Software produced by tools is subject to Verification and Validation activities that will detect flaws introduced by the tools.
•			Verification and validation - To provide adequate confidence that all requirements are implemented, and to minimize the potential for deficiencies that may result from computer development process. Performed by competent group(s) independent of the original designers. 
•			Configuration management
•			Independence - In addition to the requirements in IEEE Std 603, independence of data communication and safety and non-safety portions of software and firmware are required.

Standard Review Plan Chapter 7
Instrumentation and Controls
[]
SRP Chapter 7 contains guidance for the NRC staff in conducting the review and evaluation of I&C system designs of nuclear power plants.  The present SRP Chapter 7, Revision 4, June 1997, was revised to address digital system issues, standards and guidance.
!	Revised Section 7.1 on general requirements and guidance 
	N	Add references to new regulatory guides (RGs) and branch technical positions (BTPs) on special digital system issues
	N	Highlight review areas, acceptance criteria, and review process for digital systems based on IEEE Std 7-4.3.2 (RG 1.152)
!	Section 7.0 and Appendix 7.0-A describe the overall review process for digital systems
!	Appendix 7.1-C gives guidance with respect to review according to IEEE Std. 603 (RG 1.153)
!	Appendix 7.1-A addresses rule changes (Part 52 and revisions to Part 50), and new regulatory guides
!	Revised Sections 7.2 through 7.9, which focus on systems, to add reference to digital system guidance in Section 7.1 
!	Revised Appendix 7-A includes new BTPs

A set of software-related regulatory guides are referenced

RG 1.168 Verification, Validation, Reviews & Audits 	(IEEE 1012 & 1028)

RG 1.169  Software Configuration Management 	(IEEE 828 & 1042)

RG 1.170  Software Test Documentation	(IEEE 830)

RG 1.171  Software Unit Testing 	(IEEE 1008)

RG 1.172  Software Requirements Specification 	(IEEE 830)

RG 1.173  Software Life Cycle Processes 	(IEEE 1074)

 BTPs that address digital system issues

Branch technical positions (BTP’s) contain guidelines to address the resolution of technical issues that arise during detailed review of a plant design.  BTP’s supplement acceptance criteria of NRC regulations, and guidelines in regulatory guides and industry standards.

•	Software Reviews - (BTP-14)

•	Defense-in-Depth and Diversity (BTP-19)

•	Real-Time Performance (BTP-21)

•	On-Line and Periodic Testing (BTP-17)

•	Level of Detail for Design Certification applications (BTP-16)

•	Programmable Logic Controllers (BTP-18)

The Review of Digital Systems
follows IEEE Standard 7- 4.3.2

Supplemental Guidance on Digital
Computer-Based Safety Systems
				                                     |

	Quality	Electromagnetic	Equipment	System	Communications	Reliability	Defense	Evolving
	(¶ 5.3)	Compatibility	Qualification	Integrity	Independence	(¶ 5.15)	Against	Technology/
		|	(¶ 5.4)	(¶ 5.5)	(¶ 5.15)	   	Common-Mode	Methods
		EPRI TR 102323	     |		    |		Failures	Obsolescence
	 	RG 1.180	IEEE-323		Annex G		  |
							Defense-in-Depth
                      Software						 and Diversity
                      Development		                                 	                              Design for			 BTP-19
                      (¶ 5.3.1)		        RGs 1.168	                                Integrity
			-1.172	                             (¶ 5.5.1)
				                               |
                       V&V (¶ 5.3.4)		                                                   Software                               |      
			                        Quality               	                           Real-Time
			         BTP-14	                               Performance
				                               BTP-21
                      CM (¶ 5.3.4)       

				                               Design for
                              Software                                                                           Test &
                              Tools			                                 Calibration
                           (¶ 5.3.3)			                              (¶ 5.5.2)
				                                |
                          Qualification		                                	                                On-Line &
                          of Existing                		                                Surveillance
                           Computers         PLC’s                           	                                Testing
                         (¶ 5.3.2)               BTP-18		                                BTP-17
		          	Commercial Grade
			Digital Equipment
			EPRI TR-106439

BTP -14 describes the review of software quality

•	Purpose

	N	Confirm that plans exist that will provide a high-quality software life cycle process 
	N	Confirm that these plans commit to documentation of life cycle activities that permit evaluation of the quality of the design features upon which safety determination is based 
	N	Verify that implementation of the software life cycle process meets the criteria expected for high-quality software 
	N	Assess the adequacy of software life cycle design outputs

Factors considered in BTP-14

•	Personnel quality and experience
•	Use of an established, structured life cycle for product development
•	Use of configuration management
•	Early problem detection and resolution, and continuous process improvement
•	Clear, stable, and validated software requirements
•	Independence of verification and validation, configuration management and quality assurance
•	Traceability from systems requirements and design through software requirements, software design, code, and validation testing
•	Use of hazards/safety analysis and risk analysis to guide software development
•	Clearly defined and stated management policy and  well-managed and complete documentation

Flow of Documents Through the Software Life Cycle
Life
Cycle
Activity
Groups	Planning
Activities	Requirements Activities	Design Activities	Implementation Activities	Integration
Activities	Validation
Activities	Installation Activities	Operations & Maintenance Activities	
	Software
Management Plan	Requirements Specifications	Design Specifications	Code Listings	System Build Documentation		Operations Manuals		
	Software Development Plan		Hardware & Software Architecture				Installation Configuration Tables		
	Software
QA Plan								
	Integration Plan								
	Installation plan								
	Maintenance plan						Maintenance Manuals		
	Training plan						Training Manuals		
	Operations Plan								
	Software
Safety Plan	Requirements Safety Analysis	Design Safety Analysis	Code Safety Analysis	Integration Safety Analysis	Validation Safety Analysis	Installation Safety Analysis	Change Safety Analysis	
	Software V&V Plan	V&V Requirements Analysis Report	V&V Design Analysis Report	V&V Implementation Analysis & Test Report	V&V Integration  Analysis & Test Report	V&V Validation & Test Report	V&V Validation & Test Report	V&V Change Report	
	Software CM Plan	CM Requirements Analysis Report	CM Design Report	CM Implementation Report	CM Integration Report	CM Validation Report	CM Installation Report	CM Change Report	
Note:  A separate document is not required for each topic identified, however, project documentation should encompass all the topics.

 
 	Process
Planning	   	  	Design
Outputs	   	  	Process
Implementation	

System Life Cycle Activities

Eight activity groups: Planning, Requirements, Design, Implementation, Integration, Validation, Installation, and Operations and Maintenance.

Purpose of Documents

•	The goal of safety-critical software-based system is safe software in a safe system
•	Documents are tools used to achieve this goal - not the goal itself
•	
•	Documents contain recorded information about specific life cycle activity and includes:
g   Software life cycle design outputs (e.g., Requirements spec.,code listing, system build documents, operation and maintenance manuals) 
g   Software life cycle process documentation.

Planning

•	Planning software life cycle activities should be in context of overall system planning
•	Planning of safety-critical software should occur within the context of system hazard analysis, system risk analysis, and system design 
•	Characteristics considered for acceptable criteria for safety-critical software process planning are categorized as management, implementation, and resource characteristics.

System Life Cycle Activities (Continued)

Software Life Cycle Process Implementation 
 
Acceptance criterion for implementation activities is that the tasks in the corresponding plans have been successfully carried out for each applicable activity group.
•	Software Safety Analyses - system safety requirements are adequately addressed; no new hazards introduced; software requirements, design elements, and code elements that can affect safety are identified; and all other software requirements, design and code elements will not adversely affect safety.
•	Verification and validation analyses and test reports - design outputs for the applicable activity groups satisfy the required characteristics; problems identified and actions taken tracked and documented; traceability of systems design and requirements, in both directions, through software requirements to installation and operation; and all tests required by V&V plan are successfully completed.
•	Configurations management reports - configuration items identified; baselines established; adequate change process established for changes to baselines; and appropriate audits performed to verify conformance to established configuration management procedures.

	System Life Cycle Activities (Continued)

Software Life Cycle Process Design Outputs

Acceptance criteria for design outputs are that certain characteristics (named Functional and Software Development Process Characteristics) are exhibited by the design outputs.

Functional characteristics relate directly to the actions required of the safety-critical software:
Accuracy, Functionality, Reliability, Robustness, Safety, Security, Timing.

Process characteristics contribute to the assurance that the software will perform the required actions:
Completeness, Consistency, Correctness, Style, Traceability, Unambiguity, Verifiability

The challenge of software quality

Recognizes that in spite of all the life cycle activities associated with a well-structured software development process, software cannot be proven to be absolutely error-free.  In nuclear power plant safety I&C systems, redundancy (basically hardware) is provided in the design to meet the requirements of single failure tolerance and testability. However, for software-based systems, the redundancy achieved by hardware is defeated in the event of a software failure in identical software residing in the redundant hardware. 

The NRC’s position is that software-based safety systems are considered to be susceptible to common-cause failure, and requires that the licensee/applicant  demonstrate that vulnerabilities due to such common-cause failures have been adequately addressed in the plant design.  

Principles for managing software common-cause failures

•	Defense-in-depth
•	Diversity

Both are system solutions, not software solutions.

BTP-19, “Guidance for Evaluation of Defense-in-Depth and Diversity in Digtal Computer-Based Instrumentation and Control Systems,” provides the details of an acceptable process.

	Dedication of Commercial-Grade Digital Equipment

Two methods for qualifying digital equipment for use in nuclear safety systems ‑ 10 CFR 50 Appendix B and/or 10 CFR Part 21

!	10 CFR Part 21, "Reporting of Defects and Noncompliance" requires, in part, that the dedicated commercial equipment be deemed equivalent to equipment produced under a 10 CFR Part 50 Appendix B, "Quality Assurance Criteria for Nuclear Power Plants and Fuel Reprocessing Plants" program.
!	It is allowed to have an Appendix B application installed upon a commercially dedicated platform. The dedication process itself must be performed under an Appendix B program.

Dedication of Commercial-Grade Digital Equipment (contd)

EPRI Topical Report, TR‑106439, "Guideline on Evaluation and Acceptance of Commercial Grade Digital Equipment for Nuclear Safety Applications"   October, 1996
"The efforts performed by the utility or dedicator do not add product quality; they seek to help confirm that the commercial product already has adequate quality.  If a product has a critical shortcoming, dedicating it may not be possible at any cost."
! Equivalent assurance (Figure 3‑2)
! A "graded" level of effort depending upon importance to safety and complexity
! NP‑5652, (June 1988), "Guidelines for the Utilization of Commercial Grade Items in Nuclear Safety Applications" describes four methods for acceptance
1) Special Tests and Inspections
2) Commercial Grade Survey of Supplier
3) Source Verification
4) Acceptable Supplier/Item Performance Record
! For most digital devices a combination of methods 1,2 and 4 will be needed

Dedication of Commercial-Grade Digital Equipment (contd)

4) Evaluation and Acceptance

! Define and Verify the Critical Characteristics
! Includes hardware, software, HMI, quality and reliability
! Three main categories (Table 4‑1)
1) Physical Characteristics
2) Performance Characteristics
3) Dependability Characteristics
! For each Characteristic
1) Description of the Characteristic
2) Acceptance Criteria
3) Methods of Verification
4) Application of Methods
! Guidance is provided for the dedication team 

5) Maintenance of a Commercial Dedication

	! Evaluation of Product Changes
! 10 CFR Part 21 reporting
! Third party dedication organizations

	Status of Digital System Reviews

DIGITAL PLATFORMS FOR SAFETY SYSTEM APPLICATIONS:

•			Siemens Teleperm XS
•	
•			Westinghouse/CE Common Q
•	
•			Triconex PLC

	       C        	                     Westinghouse ASICs

	C	COTS

   	NRC Digital I&C Research Initiatives

Office of Research activities to support NRR review of digital I&C:
•	Improve efficiency of the review process
•	Address reliability and risk considerations
•	Reflecting evolving technology aspects
•	Keep current with industry standards and practices

Tasks grouped into three areas:

Systems aspects

g  EMI/RFI qualification
g  Environmental qualification
g  Lightning protection guidelines
g  Requirements assessment
g  Diagnostics and fault tolerance
g  Operating systems
Software QA
g  Software engineering
g  Software testing
Risk Assessment
g  Data analysis
g  Digital system failure assessment
g  Risk importance
g  Digital system reliability assessment

	Conclusions

•	Regulatory framework in place to provide high confidence in safety

•	NRC staff activities taking place to remain current with evolving technology and update regulatory framework

•	Meeting challenge of industry as nuclear power plants convert I&C systems from analog to digital equipment