Get PDF

!"#$%
#$& Society
70
6SRQVRUHGE\WKH
1XFOHDU3RZHU(QJLQHHULQJ&RPPLWWHH

,(((
3DUN$YHQXH
1HZ<RUN1<86$

5HYLVLRQRI
$XJXVW ,(((6WG
Authorized licensed use limited to: College of Engineering - Trivandrum. Downloaded on August 12,2010 at 06:00:49 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 7-4.3.2™-2010
(Revision of
IEEE Std 7-4.3.2-2003)
IEEE Standard Criteria for Digital

Computers in Safety Systems of
Nuclear Power Generating Stations
Sponsor
Nuclear Power Engineering Committee

of the
IEEE Power & Energy Society
Approved 17 June 2010

IEEE-SA Standards Board
Abstract: Additional computer specific requirements to supplement the criteria and requirements
of IEEE Std 603™-2009 are specified. Within the context of this standard, the term computer is a
system that includes computer hardware, software, firmware, and interfaces. The criteria
contained herein, in conjunction with criteria in IEEE Std 603-2009, establish minimum functional
and design requirements for computers used as components of a safety system.
Keywords: commercial grade item, diversity, safety systems, software, software tools, software
verification and validation
The Institute of Electrical and Electronics Engineers, Inc.

3 Park Avenue, New York, NY 10016-5997, USA
Copyright © 2010 by the Institute of Electrical and Electronics Engineers, Inc.

All rights reserved. Published 2 August 2010. Printed in the United States of America.
IEEE is a registered trademark in the U.S. Patent & Trademark Office, owned by the Institute of Electrical and Electronics
Engineers, Incorporated.
PDF: ISBN 978-0-7381-6316-1 STD96076

Print: ISBN 978-0-7381-6317-8 STDPD96076
IEEE prohibits discrimination, harassment and bullying. For more information, visit http://www.ieee.org/web/aboutus/whatis/policies/p9-26.html.
No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior written permission
of the publisher.
IEEE Standards documents are developed within the IEEE Societies and the Standards Coordinating Committees of
the IEEE Standards Association (IEEE-SA) Standards Board. The IEEE develops its standards through a consensus
development process, approved by the American National Standards Institute, which brings together volunteers
representing varied viewpoints and interests to achieve the final product. Volunteers are not necessarily members of the
Institute and serve without compensation. While the IEEE administers the process and establishes rules to promote
fairness in the consensus development process, the IEEE does not independently evaluate, test, or verify the accuracy
of any of the information or the soundness of any judgments contained in its standards.
Use of an IEEE Standard is wholly voluntary. The IEEE disclaims liability for any personal injury, property or other
damage, of any nature whatsoever, whether special, indirect, consequential, or compensatory, directly or indirectly
resulting from the publication, use of, or reliance upon this, or any other IEEE Standard document.
The IEEE does not warrant or represent the accuracy or content of the material contained herein, and expressly
disclaims any express or implied warranty, including any implied warranty of merchantability or fitness for a specific
purpose, or that the use of the material contained herein is free from patent infringement. IEEE Standards documents
are supplied “AS IS.”
The existence of an IEEE Standard does not imply that there are no other ways to produce, test, measure, purchase,
market, or provide other goods and services related to the scope of the IEEE Standard. Furthermore, the viewpoint
expressed at the time a standard is approved and issued is subject to change brought about through developments in the
state of the art and comments received from users of the standard. Every IEEE Standard is subjected to review at least
every five years for revision or reaffirmation, or every ten years for stabilization. When a document is more than five
years old and has not been reaffirmed, or more than ten years old and has not been stabilized, it is reasonable to
conclude that its contents, although still of some value, do not wholly reflect the present state of the art. Users are
cautioned to check to determine that they have the latest edition of any IEEE Standard.
In publishing and making this document available, the IEEE is not suggesting or rendering professional or other
services for, or on behalf of, any person or entity. Nor is the IEEE undertaking to perform any duty owed by any other
person or entity to another. Any person utilizing this, and any other IEEE Standards document, should rely upon his or
her independent judgment in the exercise of reasonable care in any given circumstances or, as appropriate, seek the
advice of a competent professional in determining the appropriateness of a given IEEE standard.
Interpretations: Occasionally questions may arise regarding the meaning of portions of standards as they relate to
specific applications. When the need for interpretations is brought to the attention of IEEE, the Institute will initiate
action to prepare appropriate responses. Since IEEE Standards represent a consensus of concerned interests, it is
important to ensure that any interpretation has also received the concurrence of a balance of interests. For this reason,
IEEE and the members of its societies and Standards Coordinating Committees are not able to provide an instant
response to interpretation requests except in those cases where the matter has previously received formal consideration.
A statement, written or oral, that is not processed in accordance with the IEEE-SA Standards Board Operations Manual
shall not be considered the official position of IEEE or any of its committees and shall not be considered to be, nor be
relied upon as, a formal interpretation of the IEEE. At lectures, symposia, seminars, or educational courses, an
individual presenting information on IEEE standards shall make it clear that his or her views should be considered the
personal views of that individual rather than the formal position, explanation, or interpretation of the IEEE.
Comments for revision of IEEE Standards are welcome from any interested party, regardless of membership affiliation
with IEEE. Suggestions for changes in documents should be in the form of a proposed change of text, together with
appropriate supporting comments. Recommendations to change the status of a stabilized standard should include a
rationale as to why a revision or withdrawal is required. Comments and recommendations on standards, and requests
for interpretations should be addressed to:
Secretary, IEEE-SA Standards Board

445 Hoes Lane
Piscataway, NJ 08854
USA
Authorization to photocopy portions of any individual standard for internal or personal use is granted by The Institute
of Electrical and Electronics Engineers, Inc., provided that the appropriate fee is paid to Copyright Clearance Center.
To arrange for payment of licensing fee, please contact Copyright Clearance Center, Customer Service, 222 Rosewood
Drive, Danvers, MA 01923 USA; +1 978 750 8400. Permission to photocopy portions of any individual standard for
educational classroom use can also be obtained through the Copyright Clearance Center.
Introduction
This introduction is not part of IEEE Std 7-4.3.2-2010, IEEE Standard Criteria for Digital Computers in Safety Systems
of Nuclear Power Generating Stations.
This standard evolved from IEEE Std 7-4.3.2-2003. It represents a continued effort by an IEEE working
group to support the specification, design, and implementation of computers in safety systems of nuclear
power generating stations.
This standard specifies additional computer-specific requirements (incorporating hardware, software, firm-
ware, and interfaces) to supplement the criteria and requirements of IEEE Std 603-2009. This standard
should be used in conjunction with IEEE Std 603-2009 for completeness of the safety system design when
a computer is to be used as a component of a safety system.
This standard recognizes that development processes for computer systems continue to evolve. As such, the
information presented should not be viewed as the only possible solution. This is in keeping with the desire
to use advances in digital technology, provided the criteria and requirements of IEEE Std 603-2009 and this
standard are met. For example, while this standard does not address specifically artificial intelligence sys-
tems or fourth generation languages, their use is not precluded.
This standard does not provide requirements associated with the operation and maintenance of the
computer following installation (i.e., surveillance testing frequency). Any problems identified should be
addressed through applicable standards that specifically address these requirements.
Subclause 5.1 in IEEE Std 603-2009 defines the single-failure criterion. Guidance for the application of this
criterion is provided in IEEE Std 379™-2000 [B16]. The approach stated in Subclause 5.5 of IEEE Std
379-2000 is also appropriate for potential common-cause failures associated with computer hardware and
software that have been developed under the requirements of IEEE Std 603-2009 and this standard.
Additional guidance for determining the need for design diversity in safety-related computer systems is
provided in 5.16 of this standard.
This standard does not address justification for the selection of software tools and acceptance criteria for
compilers, operating systems, and libraries. The working group felt this subject was outside of the scope of
this revision.
In summary, the following major changes were implemented in this version of IEEE Std 7-4.3.2:
⎯ The references were updated to include current IEEE standards.

⎯ Subclause 5.6 is significantly enhanced to specify acceptable communication independence
between safety divisions and between safety and non-safety systems. This also involved revising
Annex E to be more specific on acceptable communication methods.
⎯ The Nuclear Regulatory Commission (NRC) established seven task working groups (TWGs) to
address seven specific areas of digital I&C where the industry requested more specific regulatory
guidance. Utilities, Nuclear Steam Supply System (NSSS) vendors, Electric Power Research
Institute (EPRI), Nuclear Energy Institute (NEI) and other industry representatives interfaced
directly with the NRC in discussing six out of the seven specific areas. The NRC subsequently
issued interim staff guidance (ISG) in these seven specific areas. Three of these impact this
standard in four different areas of the standard:
⎯ Address the issue of computer security (see NRC Interim Staff Guidance DI&C-ISG-01 [B28]
for more information regarding computer security for safety systems). Subclause 5.9 provides
the requirements for computer security for safety systems.
iv
Copyright © 2010 IEEE. All rights reserved.
⎯ Define the requirements for common cause failure as it relates to computer in safety systems
(see NRC Interim Staff Guidance DI&C-ISG-02 [B29] for more information). Added 5.16
Common Cause Failure criteria that augments IEEE Std 603-2009, 5.16. The contents of
Annex B are removed because the information is now normative in 5.16.
⎯ Address the issue of multidivisional control and display stations (see NRC Interim Staff
Guidance DI&C-ISG-04 [B30] for more information. Expanded 5.8 Information Displays, to
define these requirements.
⎯ Address the issue of function prioritization (see NRC Interim Staff Guidance DI&C-ISG-04
[B30] for more information). A new subclause, 5.5.4 Prioritization of functions, was added to
define these requirements.
⎯ A new subclause, 5.17 Use of commercial digital equipment, was added to the standard to provide
clarity on the unique requirements for commercial grade dedication of computer equipment and
software. This subclause was reviewed for consistency with industry guidance. Annex C was
revised to provide specific information for commercial dedication of computer systems in the
United States.
⎯ Removed Annex F because various NRC and industry efforts are underway to determine the
methodologies for establishing computer reliability. The material in this annex therefore may
become obsolete in its current form. This annex will be revised in a future edition of this standard.
⎯ Implemented editorial and clarification changes throughout the standard.
Notice to users
Laws and regulations

Users of these documents should consult all applicable laws and regulations. Compliance with the
provisions of this standard does not imply compliance to any applicable regulatory requirements.
Implementers of the standard are responsible for observing or referring to the applicable regulatory
requirements. IEEE does not, by the publication of its standards, intend to urge action that is not in
compliance with applicable laws, and these documents may not be construed as doing so.
Copyrights
This document is copyrighted by the IEEE. It is made available for a wide variety of both public and
private uses. These include both use, by reference, in laws and regulations, and use in private self-
regulation, standardization, and the promotion of engineering practices and methods. By making this
document available for use and adoption by public authorities and private users, the IEEE does not waive
any rights in copyright to this document.
Updating of IEEE documents

Users of IEEE standards should be aware that these documents may be superseded at any time by the
issuance of new editions or may be amended from time to time through the issuance of amendments,
corrigenda, or errata. An official IEEE document at any point in time consists of the current edition of the
v
document together with any amendments, corrigenda, or errata then in effect. In order to determine whether
a given document is the current edition and whether it has been amended through the issuance of
amendments, corrigenda, or errata, visit the IEEE Standards Association web site at
http://ieeexplore.ieee.org/xpl/standards.jsp, or contact the IEEE at the address listed previously.
For more information about the IEEE Standards Association or the IEEE standards development process,
visit the IEEE-SA web site at http://standards.ieee.org.
Errata
Errata, if any, for this and all other standards can be accessed at the following URL:
http://standards.ieee.org/reading/ieee/updates/errata/index.html. Users are encouraged to check this URL
for errata periodically.
Interpretations
Current interpretations can be accessed at the following URL: http://standards.ieee.org/reading/ieee/interp/
index.html.
Patents
Attention is called to the possibility that implementation of this standard may require use of subject matter
covered by patent rights. By publication of this standard, no position is taken with respect to the existence
or validity of any patent rights in connection therewith. The IEEE is not responsible for identifying
Essential Patent Claims for which a license may be required, for conducting inquiries into the legal validity
or scope of Patents Claims or determining whether any licensing terms or conditions provided in
connection with submission of a Letter of Assurance, if any, or in any licensing agreements are reasonable
or non-discriminatory. Users of this standard are expressly advised that determination of the validity of any
patent rights, and the risk of infringement of such rights, is entirely their own responsibility. Further
information may be obtained from the IEEE Standards Association.
vi
Participants
This document was prepared by the Application of Programmable Digital Computers to Safety Systems
Subcommittee Working Group 6.4 of the IEEE Nuclear Power Engineering Committee. At the time this
standard was submitted to the IEEE-SA Standards Board for approval, the Subcommittee Working Group
6.4 had the following membership:
Warren Odess-Gillett, Chair, Secretary
David Curbo David Herrell Mark Santschi

Ronald Greenthaler Ronald Jarrett Mark Stofko
Paul Loeser
At the time this standard was completed, Subcommittee 6 under the Nuclear Power Engineering Committee
had the following membership:
David J. Zaprazny, Chair

Mark Santschi, Secretary
Ijaz Ahmad David Herrell Ifti Rana

David Curbo Greg Hostetter Mark Stofko
Patrick Gove Ronald Jarrett David Theriault
Ronald Greenthaler Paul Loeser Michael Waterman
Daryl Harmon Barry Marcus Paul Yanosy
Warren Odess-Gillett
The Nuclear Power Engineering Committee (NPEC) that recommended approval of this standard had the
following membership:
John D. MacDonald, Chair

Satish Aggarwal, Vice Chair
George Ballassi, Secretary
Ijaz Ahmad Robert J. Fletcher Alexander Marion

George Attarian Robert B. Fuld Michael H. Miller
Farouk D. Baxter James F. Gleason James Parello
Mark D. Bowman Dale T. Goodney Mansoor H. Sanwarwalla
Daniel F. Brosnan Daryl Harmon Glen E. Schinzel
Nissen M. Burstein Dirk C. Hopp James E. Stoner, Jr.
Robert C. Carruth David A. Horvath Marek Tengler
John P. Carter Paul R. Johnson James E. Thomas
Dennis Dellinger Thomas Koshy Paul Yanosy
John Disosway Harvey C. Leake David J. Zaprazny
Stephen Fleger J. Scott Malcolm
vii
The following members of the individual balloting committee voted on this standard. Balloters may have
voted for approval, disapproval, or abstention.
William J. Ackerman Gary Engmann G. Lang

Satish K. Aggarwal Stephen Fleger Jang-Soo Lee
Stan Arnot James Gleason William Lumpkins
George Ballassi Ron Greenthaler G. Luri
Royce Beacom Randall Groves Faramarz Maghsoodlou
Robert Beavers Daryl Harmon Michael S. Newman
William Bloethe Hamidreza Heidarisafa Warren Odess-Gillett
Wesley Bowers David Herrell James Parello
Thomas Brewington Werner Hoelzl Ted Riccio
Daniel F. Brosnan David Horvath Bartien Sayogo
Nissen M. Burstein Greg Hostetter Glen Schinzel
Robert C. Carruth Peter Hung Gil Shultz
Suresh Channarasappa Ronald Jarrett James Smith
Tom Crawford Paul Johnson Gary Stoedter
Paul Croll James Jones S. Thamilarasan
David Curbo Tanuj Khandelwal James Thompson
Alireza Daneshpooy Chad Kiger John Vergis
Dennis Dellinger Joseph L. Koepfinger David J. Zaprazny
When the IEEE-SA Standards Board approved this standard on 17 June 2010, it had the following
membership:
Robert M. Grow, Chair

Richard H. Hulett, Vice Chair
Steve M. Mills, Past Chair
Judith Gorman, Secretary
Karen Bartleson Young Kyun Kim Ronald C. Petersen

Victor Berman Joseph L. Koepfinger* Thomas Prevost
Ted Burse John Kulick Jon Walter Rosdahl
Clint Chaplin David J. Law Sam Sciacca
Andy Drozd Hung Ling Mike Seavey
Alexander Gelman Oleg Logvinov Curtis Siller
Jim Hughes Ted Olsen Don Wright
*Member Emeritus
Also included are the following nonvoting IEEE-SA Standards Board liaisons:
Satish Aggarwal, NRC Representative

Richard DeBlasio, DOE Representative
Michael Janezic, NIST Representative
Catherine Berger
IEEE Standards Project Editor
Matthew J. Ceglia
IEEE Standards Program Manager, Technical Program Development
viii
Contents
1. Scope .......................................................................................................................................................... 1
2. Normative references.................................................................................................................................. 1
3. Definitions and abbreviations..................................................................................................................... 2

3.1 Definitions ........................................................................................................................................... 2
3.2 Abbreviations and acronyms ............................................................................................................... 5
4. Safety system design basis ......................................................................................................................... 5
5. Safety system criteria ................................................................................................................................. 5

5.1 Single-failure criterion......................................................................................................................... 6
5.2 Completion of protective action .......................................................................................................... 6
5.3 Quality ................................................................................................................................................. 6
5.4 Equipment qualification..................................................................................................................... 10
5.5 System integrity................................................................................................................................. 10
5.6 Independence ..................................................................................................................................... 13
5.7 Capability for test and calibration...................................................................................................... 18
5.8 Information displays .......................................................................................................................... 18
5.9 Control of access ............................................................................................................................... 21
5.10 Repair .............................................................................................................................................. 25
5.11 Identification.................................................................................................................................... 25
5.12 Auxiliary features ............................................................................................................................ 25
5.13 Multi-unit stations............................................................................................................................ 25
5.14 Human factors considerations.......................................................................................................... 25
5.15 Reliability ........................................................................................................................................ 26
5.16 Common Cause Failure criteria ....................................................................................................... 26
5.17 Use of commercial digital equipment .............................................................................................. 29
6. Sense and command features—functional and design requirements........................................................ 36
7. Execute features—functional and design requirements............................................................................ 36
8. Power source requirements....................................................................................................................... 36
Annex A (informative) Mapping of IEEE Std 603-2009 to IEEE Std 7-4.3.2 ............................................. 37
Annex B (informative) Diversity requirements determination ..................................................................... 38
Annex C (informative) Dedication of existing commercial computers ........................................................ 39

C.1 Background ....................................................................................................................................... 39
C.2 Discussion......................................................................................................................................... 40
Annex D (informative) Identification and resolution of hazards .................................................................. 44

D.1 Background....................................................................................................................................... 44
D.2 Discussion......................................................................................................................................... 44
D.3 Purpose of hazard analysis................................................................................................................ 44
D.4 Hazard analysis implementation guidelines...................................................................................... 45
ix
Annex E (informative) Communication independence ................................................................................ 57
E.1 Background ....................................................................................................................................... 57
E.2 Discussion ......................................................................................................................................... 57
Annex F (informative) Computer reliability................................................................................................. 64
Annex G (informative) Glossary .................................................................................................................. 65
Annex H (informative) Bibliography ........................................................................................................... 69
x
IEEE Standard Criteria for Digital
Computers in Safety Systems of
Nuclear Power Generating Stations
IMPORTANT NOTICE: This standard is not intended to ensure safety, security, health, or
environmental protection. Implementers of the standard are responsible for determining appropriate
safety, security, environmental, and health practices or regulatory requirements.
This IEEE document is made available for use subject to important notices and legal disclaimers.
These notices and disclaimers appear in all publications containing this document and may
be found under the heading “Important Notice” or “Important Notices and Disclaimers
Concerning IEEE Documents.” They can also be obtained on request from IEEE or viewed at
http://standards.ieee.org/IPR/disclaimers.html.
1. Scope
This standard serves to amplify criteria in IEEE Std 603™-2009, IEEE Standard Criteria for Safety Systems
for Nuclear Power Generating Stations, to address the use of computers as part of safety systems in nuclear
power generating stations. The criteria contained herein, in conjunction with criteria in IEEE Std 603-2009,
establish minimum functional and design requirements for computers used as components of a safety
system.
2. Normative references
The following referenced documents are indispensable for the application of this document (i.e., they must
be understood and used, so each referenced document is cited in text and its relationship to this document is
explained). For dated references, only the edition cited applies. For undated references, the latest edition of
the referenced document (including any amendments or corrigenda) applies.
IEEE Std 323™-2003 (Reaff 2008), IEEE Standard for Qualifying Class 1E Equipment for Nuclear Power
Generating Stations. 1, 2
1
IEEE publications are available from the Institute of Electrical and Electronics Engineers, 445 Hoes Lane, Piscataway, NJ 08854,
USA (http://standards.ieee.org/).
2
The IEEE standards or products referred to in this clause are trademarks of the Institute of Electrical and Electronics Engineers, Inc.
1
IEEE Std 7-4.3.2-2010
IEEE Standard Criteria for Digital Computers in Safety Systems of Nuclear Power Generating Stations
IEEE Std 344™-2004, IEEE Recommended Practice for Seismic Qualification of Class 1E Equipment for
Nuclear Power Generating Stations.
IEEE Std 603™-2009, IEEE Standard Criteria for Safety Systems for Nuclear Power Generating Stations.
IEEE Std 1012™-2004, IEEE Standard for Software Verification and Validation.
IEEE Std 1042™-1987 (Reaff 1993) (withdrawn), IEEE Guide to Software Configuration Management.
ISO/IEC 12207:2008 (IEEE Std 12207-2008), Second Edition, 2008-02-01, Systems and Software
Engineering—Software life cycle processes.
3. Definitions, acronyms and abbreviations
3.1 Definitions
For the purposes of this document, the following terms and definitions apply. The IEEE Standards
Dictionary: Glossary of Terms & Definitions should be referenced for terms not defined in this clause. 3
3.1.1 acceptance testing: (A) Formal testing conducted to determine whether a system satisfies its
acceptance criteria and requirements; and to enable the customer to determine whether to accept the
system. See also: equipment qualification testing, system testing. (B) Formal testing conducted to enable
a user, customer, or other authorized entity to determine whether to accept a system or component.
3.1.2 basic component: For operating facilities, a structure, system, component (SSC), or part thereof that
affects its safety function and is necessary to assure one or more of the conditions provided below is met.
For new plant designs, a basic component is the design or procurement information approved or to be
approved within the scope of the design certification or approval for a SSC or part thereof that affects its
safety function and is necessary to meet one or more of the following conditions:
⎯ The integrity of the reactor coolant pressure boundary;

⎯ The capability to shut down the reactor and maintain it in a safe shutdown condition; or
⎯ The capability to prevent or mitigate the consequences of accidents with significant potential for
offsite exposures.
Basic components are items designed and manufactured under a nuclear quality assurance program, or
commercial grade items that have successfully completed the commercial grade dedication process. A basic
component includes the safety-related design, analysis, inspection, testing, fabrication, replacement of
parts, or consulting services that are associated with the component hardware, software, design
certification, or design approval, whether these services are performed by the component supplier or others.
3
The IEEE Standards Dictionary: Glossary of Terms & Definitions is available at http://shop.ieee.org/.
2
IEEE Std 7-4.3.2-2010
3.1.3 commercial grade dedication: An acceptance process undertaken to provide reasonable assurance
that a commercial grade item to be used as a basic component will perform its intended safety function and,
in this respect, is deemed equivalent to an item designed and manufactured under a nuclear quality
assurance program. This assurance is achieved by identifying the critical characteristics of the item and by
verifying their acceptability by inspections, tests, or analyses performed by the purchaser or third party
dedicating entity after delivery or through commercial grade surveys; product inspections or witness at hold
points at the supplier’s facility, and analysis of historical records for acceptable performance. In all cases,
the dedication process must be conducted under a nuclear quality assurance program. The process is
considered complete when the dedication activities are complete and the item is designated for use as a
basic component.
3.1.4 commercial grade item: A structure, system, component, or part thereof that affects its safety
function that was not designed and manufactured as a basic component. These do not include items where
the design and manufacturing process require in-process inspections and verifications so that defects or
failures to comply are identified and corrected where one or more of the item’s critical characteristics
cannot be verified. For digital items, the vendor’s software life cycle processes can be included as critical
characteristics.
3.1.5 commercial grade service: A service or activity that affects the safety function of a basic
component, performed by a commercial vendor not operating under a nuclear quality assurance program.
3.1.6 computer security: Protection of digital computer-based systems throughout the development
lifecycle of the system to prevent unauthorized, unintended, and unsafe modifications to the system; this
includes protection of the safety system during operation and maintenance from inadvertent actions that
result in unintended consequences.
3.1.7 configuration: (A) The arrangement of a computer system or component as defined by the number,
nature, and interconnections of its constituent parts. (B) In configuration management, the functional and
physical characteristics of hardware or software as set forth in technical documentation or achieved in a
product.
3.1.8 configuration control: An element of configuration management, consisting of the evaluation, coor-
dination, approval or disapproval, and implementation of changes to configuration items after formal
establishment of their configuration identification.
3.1.9 configuration item: An aggregation of hardware, software, or both, that is designated for configura-
tion management and treated as a single entity in the configuration management process.
3.1.10 configuration management: A discipline applying technical and administrative direction and sur-
veillance to identify and document the functional and physical characteristics of a configuration item,
control changes to those characteristics, record and report change processing and implementation status,
and verify compliance with specified requirements.
3.1.11 critical characteristics: Important design, material, and performance (including design process)
attributes of a commercial grade item that, once verified, will provide reasonable assurance that the item
will perform its intended safety function. Used for the dedication of commercial grade services to confirm
equivalent results are produced to those that would have been produced had the vendor been operating
under a nuclear quality assurance program.
3.1.12 critical characteristics for acceptance: Those selected, identifiable, and measurable attributes and
variables of a commercial grade item or service, when verified, provide reasonable assurance that the item
received is the item specified.
NOTE—Adapted from EPRI NP-5652 [B3]. 4
4
The numbers in brackets correspond to those of the bibliography in Annex H.
3
IEEE Std 7-4.3.2-2010
3.1.13 critical characteristics for design: Those selected properties or attributes which are essential for
the item’s form, fit, and functional performance. For design they are the identifiable and measurable
attributes of a commercial grade item that provide reasonable assurance that the item will perform its
design function. An example for design shall be design methods used to implement the various life cycle
phases.
NOTE—Adapted from EPRI NP-5652 [B3].
3.1.14 dedicating entity: For operating facilities, the organization that performs the dedication process
under a nuclear quality assurance program. Dedication may be performed by the manufacturer of the item,
a third-party, or the utility itself. This organization is responsible for identifying and evaluating deviations,
reporting defects and failures to comply for the dedicated item, and maintaining auditable records of the
dedication process.
3.1.15 engineering workstation: A computer-based tool that performs engineering and maintenance
functions, including creating new control functions, adding various input and output points, modifying
sequential and continuous control logic, simulating the logic offline, supporting database engineering, and
preparing such engineering documentation as input/output (I/O) lists and device summaries. It provides a
means to monitor and troubleshoot various aspects of system operation including diagnostics, install and
update program elements, recover from failures, and perform miscellaneous tasks associated with system
administration.
NOTE—Adapted from the Instrument Engineer’s Handbook, Fourth Edition, ed. by Béla Lipták, and from U.S. CERT
online document, Control Systems Security Program (CSS), Overview of Cyber Vulnerabilities.
3.1.16 equipment qualification: The demonstration and documentation of the ability of the equipment,
consisting of the integrated hardware and software, to perform its safety function or functions under
applicable service conditions, including design basis events. Equipment Qualification is defined in IEEE
Std 323-2003.
3.1.17 firmware: The combination of a hardware device, software and data that are incorporated into the
hardware device. For compliance with this standard, firmware shall be treated as software in a
programmable device.
NOTE—Adapted from IEEE Std 610.12™-1990 [B19].
3.1.18 hazard: A condition that is a prerequisite to an accident. Hazards include external events as well as
conditions internal to computer hardware or software.
3.1.19 hazard analysis: A process that explores and identifies conditions that are not identified by the nor-
mal design review and testing process. The scope of hazard analysis extends beyond plant design basis
events by including abnormal events and plant operations with degraded equipment and plant systems.
Hazard analysis focuses on system failure mechanisms rather than verifying correct system operation.
3.1.20 protected area: An area encompassed by physical barriers and to which access is controlled.
3.1.21 safe shutdown condition: Bringing the plant to those shutdown conditions specified in plant
technical specifications as Hot Standby or Hot Shutdown, as appropriate.
3.1.22 safe state: A state in which potential hazards and operational risks are minimized.
NOTE—Determining the safe state(s) of a device is a plant systems issue, which is outside the scope of this standard
(i.e., not solely related to digital design).
4
IEEE Std 7-4.3.2-2010
3.1.23 software tools: A computer program used in the design, development, testing, review, analysis, or
maintenance of a program or its documentation. Examples include compilers, assemblers, linkers,
comparators, cross-reference generators, decompilers, editors, flow charters, monitors, test case generators,
integrated development environments, and timing analyzers.
NOTE—Adapted from IEEE Std 610.12-1990 [B19].

3.1.24 vital area: Any area that contains any equipment, system, device, or material, the failure,
destruction, or release of which could endanger the public health and safety, directly or indirectly, by
exposure to radiation (referred to as vital equipment), or equipment or systems that are required to function
to protect public health and safety following such failure, destruction, or release.
3.2 Acronyms and abbreviations
The following abbreviations and acronyms appear in this standard:
ATWS anticipated transient without scram

CCF Common Cause Failure
CDR critical digital review
COTS commercial off-the-shelf
D3 defense in depth and diversity
DPRAM dual-ported random access memory
EIA Electronic Industries Alliance
EPRI Electric Power Research Institute
EQ equipment qualification
FMEA failure modes and effects analysis
FTA fault tree analysis
IEC International Electrotechnical Commission
M&TE measurement and test equipment
NEI Nuclear Energy Institute
PLC Programmable Logic Controller
QA quality assurance
QFR reinforced functional qualification (translated from the French)
RAM random access memory
SAR Safety Analysis Report
SER Safety Evaluation Report
SSC structure, system, component
V&V verification and validation
4. Safety system design basis

NOTE—See Annex A for more information about the relationship of this standard to IEEE Std 603-2009.
No requirements beyond IEEE Std 603-2009 are necessary.
5. Safety system criteria

The following subclauses list the safety system criteria in the order they are listed in IEEE Std 603-2009.
For some criteria, there are no additional requirements beyond what is stated in IEEE Std 603-2009. For
other criteria, additional requirements are described in 5.1 through 5.17.
5
IEEE Std 7-4.3.2-2010
5.1 Single-failure criterion
In addition to the requirements in IEEE Std 603-2009, the following criteria apply for digital computers in
safety systems (see also 5.16):
a) Functions that are assumed to malfunction independently in the safety analysis shall not be affected
by failure of a single control processor.
b) Functions shall be configured (e.g., functionally distributed) such that a single processor
malfunction or software error shall not result in spurious actuations that are not enveloped in the
plant design bases, accident analyses, anticipated transient without scram (ATWS) provisions, or
other provisions for abnormal conditions. This includes spurious actuation of more than one plant
device or system as a result of processor malfunction or software error. The possibility and
consequences of malfunction of multiple processors as a result of common software error shall be
addressed (see 5.16).
5.2 Completion of protective action
5.3 Quality
Hardware quality is addressed in IEEE Std 603-2009. Software quality is addressed in ISO/IEC
12207:2008 (IEEE Std 12207-2008) and supporting standards. Computer development activities shall
include the development of computer hardware and software. The integration of the computer hardware and
software and the integration of the computer with the safety system shall be addressed in the development
process.
A typical computer system development process consists of the following life cycle processes:
⎯ Creating the conceptual design of the system, translation of the concepts into specific system
requirements
⎯ Using the requirements to develop a detailed system design
⎯ Implementing the design into hardware and software functions
⎯ Testing the functions to confirm that the requirements have been correctly implemented
⎯ Installing the system and performing site acceptance testing
⎯ Operating and maintaining the system
⎯ Retiring the system
In addition to the requirements of IEEE Std 603-2009, the following activities necessitate additional
requirements that are necessary to meet the quality criterion:
⎯ Software development
⎯ Qualification of existing commercial computers (see 5.17)
⎯ Use of software tools
⎯ Verification and validation
6
IEEE Std 7-4.3.2-2010
⎯ Configuration management
⎯ Risk Management
5.3.1 Software development
Computer software shall be developed, modified, or accepted in accordance with a software quality
assurance (QA) plan consistent with the requirements of ISO/IEC 12207:2008 (IEEE Std 12207-2008). The
software QA plan shall address all software that is resident on the computer at run time (i.e., application
software, network software, interfaces, operating systems, and diagnostics). Guidance for developing
software QA plans can be found in IEC 60880 Ed. 2, (2006-05) [B13] and IEEE Std 730™-2002 [B20].
The software QA plan shall also address the software tools for system development and maintenance as
described in 5.3.2.
5.3.1.1 Software quality metrics
The use of software quality metrics shall be considered throughout the software life cycle to assess whether
software quality requirements are being met. When software quality metrics are used, the following life
cycle phase characteristics should be considered:
⎯ Correctness/Completeness (Requirements phase)

⎯ Compliance with requirements (Design phase)
⎯ Compliance with design (Implementation phase)
⎯ Functional compliance with requirements (Test and Integration phase)
⎯ On-site functional compliance with requirements (Installation and Checkout phase)
⎯ Performance history (Operation and Maintenance phase)
The basis for the metrics selected to evaluate software quality characteristics should be included in the soft-
ware development documentation. IEEE Std 1061™-1998 [B23] provides a methodology for the application
of software quality metrics.
5.3.2 Software tools
If software tools are used during the life cycle process of safety-related software, one or both of the
following methods shall be used to confirm outputs of that software tool are suitable for use in safety-
related systems:
a) The output of the software tool shall be subject to the same level of verification and validation
(V&V) as the safety-related software, to determine that the output of that tool meets the
requirements established during the previous lifecycle phase.
b) The tool shall be developed using the same or an equivalent high quality lifecycle process as
required for the software upon which the tool is being used as described in this subclause (5.3) or
commercially dedicated as in 5.17, to provide confidence that the necessary features of the software
tool function as required.
Software tools used to support the software life cycle process of safety-related software shall be controlled
under configuration management.
7
IEEE Std 7-4.3.2-2010
5.3.3 Verification and validation
NOTE—See IEEE Std 1012-2004 for more information about software V&V.
V&V is an extension of the program management and systems engineering team activities. V&V is used to
identify objective data and conclusions (i.e., proactive feedback) about digital system quality, performance,
and development process compliance throughout the system life cycle. Feedback consists of anomaly
reports, performance improvements, and quality improvements regarding the expected operating conditions
across the full spectrum of the system and its interfaces.
V&V processes are used to confirm that the development products of an activity conform to the
requirements of that activity, and that the system performs according to its intended use and user needs.
This determination of suitability includes assessment, analysis, evaluation, review, inspection, and testing
of products and processes.
This standard adopts the IEEE Std 1012-2004 terminology of process, activity and task, in which software
V&V processes are subdivided into activities, which are further subdivided into tasks. The term V&V
effort is used to reference this framework of V&V processes, activities, and tasks.
V&V processes shall address the computer hardware as it affects software, computer software, integration
of the digital system components, and the interaction of the resulting computer system with the nuclear
power plant.
The V&V activities and tasks shall include system testing of the final integrated hardware, software, firm-
ware, and interfaces.
The software V&V effort shall be performed in accordance with IEEE Std 1012-2004. The IEEE Std 1012-
2004 V&V requirements for the highest integrity level (software integrity level 4) apply to systems
developed using this standard (i.e., IEEE Std 7-4.3.2). See IEEE Std 1012-2004 Annex B for a definition of
integrity level 4.
5.3.4 V&V independence requirements
Independent verification and validation is required for safety-related software. In order to have independent
verification and validation, three different types of independence are required as follows:
1) The verification and validation staff shall report to a separate organization with sufficient authority
and organizational freedom, including sufficient independence from cost and schedule limitations, as
defined in Annex C of IEEE Std 1012-2004.
2) The development activities and tests shall be verified and validated by individuals or groups with
appropriate technical competence, other than those who developed the original design.
3) The original designers, people who contributed to the design, design and development project
management, and staff supervising the original designers shall not perform or oversee independent
verification and validation on safety-related software.
Testing throughout the life cycle process may be conducted by the V&V organization or the design
organization or both. Regardless of who actually writes the procedures and/or conducts the tests, the test
procedures and reports shall be independently verified by the alternate organization.
Annex C of IEEE Std 1012-2004 provides additional guidance.
8
IEEE Std 7-4.3.2-2010
5.3.5 Software configuration management
Software configuration management shall be performed in accordance with IEEE Std 1042-1987. IEEE Std
828™-2005 [B21] provides guidance for the development of software configuration management plans.
The minimum set of activities shall address the following:
a) Identification and control of all software designs and code

b) Identification and control of all software design functional data (e.g., data templates and data bases)
c) Identification and control of all software design interfaces
d) Control of all software design changes
e) Control of software documentation (user, operating, and maintenance documentation)
f) Control of software vendor development activities for the supplied safety system software
g) Control and retrieval of qualification information associated with software designs and code
h) Software configuration audits
i) Status accounting
Some of these functions or documents may be performed or controlled by other QA activities. In this case,
the software configuration management plan shall describe the division of responsibility.
A software baseline shall be established at appropriate points in the software life cycle process to synchro-
nize engineering and documentation activities. Approved changes that are created subsequent to a baseline
shall be added to the baseline.
The labeling of the software for configuration control shall include unique identification of each configura-
tion item, and revision and/or date time stamps for each configuration item.
Changes to the software shall be formally documented and approved consistent with the software
configuration management plan. The documentation shall include the reason for the change, identification
of the affected software, and the impact of the change on the system including the hazards and risks
analysis. Additionally, the documentation should include the plan for implementing the change in the
system (e.g., immediately implementing the change, or scheduling the change for a future version) along
with updating documentation including the hazards and risk analyses and additional software life cycle
activities such as V&V.
5.3.6 Software project risk management
Software project risk management is a tool for problem prevention: identifying potential problems,
assessing their impact, and determining which potential problems shall be addressed to assure that software
quality goals are achieved. Risk management shall be performed at all levels of the digital system project to
provide adequate coverage for each potential problem area. Software project risks shall include technical,
schedule, cost and resource-related risks that could compromise software quality goals, and thereby affect
the ability of the digital system or component to perform its safety-related functions. Software project risk
management differs from hazard analysis (see Annex D) in that hazard analysis is focused solely on the
technical aspects of system failure mechanisms and their effect on plant safety, rather than risks to project
execution. Overlap between the project risks and hazard analyses are possible when elements are common
to both. Such overlaps shall be evaluated as software project risks as well as through the hazards analysis
process.
Risk management shall include the following steps:
9
IEEE Std 7-4.3.2-2010
a) Determine the scope of risk management to be performed for the digital system.
b) Define and implement appropriate risk management strategies.
c) Identify risks to the software project in the project risk management strategy and as they develop
during the conduct of the project.
d) Analyze risks to determine the priority for their mitigation.
e) Develop risk mitigation plans for risks that have the potential to significantly impact software
quality goals, with appropriate metrics for tracking resolution progress. (These risks may include
technical, schedule, or resource-related project risks that could compromise the ability of the safety
computer system to perform safety-related functions.)
f) Take corrective actions when expected quality is not achieved.
g) Establish a project environment that supports effective communications between individuals and
groups for the resolution of software project risks.
Additional guidance on the topic of risk management is provided in ISO/IEC 12207:2008 (IEEE Std
12207-2008).
5.4 Equipment qualification
The requirements in this subclause shall be applied in addition to the equipment qualification criteria
provided by IEEE Std 603-2009, based on IEEE Std 323-2003.
Equipment qualification testing shall be performed with the system functioning with software and
diagnostics representative of those intended to be used in actual operation. All portions of the computer
necessary to accomplish safety functions and those portions whose operation or failure could impair safety
functions shall be exercised during testing. This includes, as appropriate and practicable, exercising and
monitoring the memory, the CPU, inputs and outputs, display functions, diagnostics, associated
components, communication paths, and interfaces. Testing shall demonstrate that the performance
requirements related to safety functions have been met in the presence of all defined environmental and
plant input and output stressors. Equipment qualification is required for commercial grade items as well as
equipment produced under a nuclear quality assurance program.
5.5 System integrity
In addition to the system integrity criteria provided by IEEE Std 603-2009, the following shall be
considered to achieve system integrity in digital equipment for use in safety systems:
⎯ Design for computer integrity

⎯ Design for test and calibration
⎯ Fault detection and self-diagnostics
⎯ Prioritization of functions
5.5.1 Design for computer integrity
The computer shall be designed to perform its safety function when subjected to conditions, external or
internal, that have significant potential for defeating the safety function. Such conditions include input and
output processing failures; precision or roundoff problems; improper recovery actions; electrical supply,
10
IEEE Std 7-4.3.2-2010
input voltage and frequency fluctuations; maximum credible number of coincident signal changes; and
environmental stressors.
If the system requirements identify a safety system preferred failure mode, failures of the computer shall
not preclude the safety system from being placed in that mode. Performance of computer system restart
operations shall not result in the safety system being inhibited from performing its function including
causing a spurious safety system actuation.
5.5.2 Design for test and calibration
Test and calibration functions shall not adversely affect the ability of the system to perform its safety func-
tion. Appropriate bypass of one redundant channel is not considered an adverse effect in this context. The
test and calibration functions shall not affect system functions that are not included in a calibration change
(e.g., setpoint change).
V&V, configuration management, and QA shall be required for test and calibration functions on separate
computers (e.g., test and calibration computer) when the test and calibration functions provide the sole
verification of test and calibration data. V&V, configuration management, and QA shall be required when
the test and calibration function is inherent to the computer that is part of the safety system.
V&V, configuration management, and QA are not required when the test and calibration function is
resident on a separate computer and does not provide the sole verification of test and calibration data for
the computer that is part of the safety system.
5.5.3 Fault detection and self-diagnostics
Computer systems can experience partial failures that can degrade the capabilities of the computer system,
but may not be immediately detectable by the system. Self-diagnostics are one means that can be used to
assist in detecting these failures. Fault detection and self-diagnostics requirements are addressed in this
subclause.
The reliability requirements of the safety system shall be used to establish the need for self-diagnostics and
the frequency of periodic manual testing. Self diagnostics are not required for systems in which failures can
be detected by alternate means in a timely manner. If self-diagnostics are incorporated into the system
requirements, these functions shall be subject to the same V&V processes as the safety system functions.
If reliability requirements warrant self-diagnostics, then computer programs shall incorporate functions to
detect and report computer system faults and failures in a timely manner. Self-diagnostic functions shall not
adversely affect the ability of the computer system to perform its safety function, or cause spurious
actuations of the safety function. A typical set of self-diagnostic functions includes the following:
⎯ Memory functionality and integrity tests (e.g., programmable read only memory checksum and
random access memory tests)
⎯ Computer system instruction set tests (e.g., calculation tests)
⎯ Computer peripheral hardware tests (e.g., watchdog timers and keyboards)
⎯ Computer architecture support hardware tests (e.g., address lines and shared memory interfaces)
⎯ Communication link diagnostics (e.g., cyclic redundancy checks)
Infrequent communication link failures that do not result in a system failure or a lack of system
functionality shall be identified for utility or vendor resolution, and should be evaluated to the extent
practical.
11
IEEE Std 7-4.3.2-2010
When self-diagnostics are applied, the following self-diagnostic features shall be incorporated into the sys-
tem design:
a) Self-diagnostics during computer system startup

b) Periodic self-diagnostics while the computer system is operating
c) Self-diagnostic test failure reporting
5.5.4 Prioritization of functions
This subclause presents criteria applicable to prioritization of functions. A priority function receives device
actuation commands from safety and non-safety sources, and sends the command having highest priority to
one or more safety-related actuated devices. An actuated device is a safety-related component such as a
motor actuated valve, a pump motor, a solenoid operated valve, etc. A non-safety source may be any non-
safety component including operator or maintenance video display units, computerized procedure systems,
control systems, diverse actuation systems, etc.
a) A priority function shall be a safety-related function.

b) The priority function used for a diverse actuation signal shall be independent of the postulated CCF
of the remainder of the digital system, and shall function properly regardless of the state or
condition of the digital system.
c) Commands that originate in the safety system shall have priority over commands that originate in
non-safety systems, with the exception of non-safety diverse actuation signals. When signals that
originate from the safety system are combined with diverse actuation signals, priority shall be given
to the signal that corresponds with the predetermined safe state of the controlled device(s) such that
that the safe state will be achieved even in the presence of a CCF in the safety system that
erroneously demands a non-safe state. For devices with more than one safe state (e.g., auxiliary
feedwater isolation valves), this requires selection of the preferred safe state. Determining the safe
state or the preferred safe state of a device is a plant systems issue, which is outside the scope of
this standard (i.e., not a safety computer system design issue).
d) A priority function may control one or more components. If a priority function controls more than
one component, then all of these provisions contained in this section shall apply to each of the
actuated components.
e) Communication isolation for each priority function should be as described in 5.6.4 of this standard.
f) Software tools used in the design, testing, maintenance, etc. of a priority function are subject to the
requirements in 5.3.2, Software Tools. This includes software tools applicable to any
programmable device used in support of the safety function of a prioritization function, such as
programmable logic devices (PLDs), programmable gate arrays, or other such devices. Validation
of design tools used for programming a priority function or a component of a priority function is
not necessary if the device directly affected by those tools is 100% tested before being released for
service. See item g) below for requirements for 100% testing. The testing should not involve the
use of the design tool itself.
g) If the priority function is to be 100% tested, testing shall include the application of every possible
combination of inputs and the evaluation of all of the outputs that result from each combination of
inputs. If a priority function includes state-based logic (that is, if the response to a particular set of
inputs depends upon past conditions), then all possible sequences of input sets shall be tested. If
testing of all possible sequences of input sets is not considered practical, then the testing that is
excluded shall be identified and the exclusion shall be justified. The testing planned or performed
shall be shown to provide adequate assurance of proper operation under all conditions and
sequences of conditions. It is possible that logic devices within the priority function include unused
12
IEEE Std 7-4.3.2-2010
inputs. If those inputs are forced by the module circuitry to a particular known state, those inputs
can be excluded from the “all possible combinations” criterion.
h) Nonvolatile memory (such as burned-in or reprogrammable gate arrays or random-access memory)
shall not be changeable while in service, either by design provisions requiring removal and
replacement of the memory device, or through the use of physical restrictions such as those in
5.6.4.2 of this standard, i.e., physical cable disconnect, or keylock switch that either physically
opens the data transmission circuit or interrupts the connection by means of hardwired logic. The
contents and configuration of field programmable memory shall be considered to be software, and
shall be developed, maintained, and controlled accordingly.
i) The priority function shall be tested through manual periodic tests and/or through automatic self-
diagnostics. Automatic testing within a priority module, whether initiated from within the module
or triggered from outside and including failure of automatic testing features, shall not inhibit the
safety function.
j) Software-based prioritization shall meet all requirements (quality requirements, V&V,

documentation, etc.) applicable to safety-related software.
The priority function shall be implemented such that the completion of a protective action as required by
IEEE Std 603-2009 is not interrupted by commands, conditions, or failures outside the function’s own
safety division.
5.6 Independence
In addition to the requirements of IEEE Std 603-2009, data communication between safety divisions or
between safety and non-safety systems shall not inhibit the performance of the safety function.
IEEE Std 603-2009 requires that safety functions be separated from non-safety functions such that the non-
safety functions cannot prevent the safety system from performing its intended functions. In digital
systems, software performing safety functions and software performing non-safety functions may reside on
the same computer and use the same computer resources. The non-safety software functions shall be
developed in accordance with the safety-related requirements of this standard.
Safety systems should be as simple as possible; therefore, functions that are not necessary for safety, even
if they enhance reliability, should be executed outside the safety system. A safety system designed to
perform functions not directly related to the safety function would be more complex than a system that
performs the same safety function, but is not designed to perform other functions. The more complex
system would increase the likelihood of failures and software errors. Such a complex design, therefore,
should be avoided within the safety system. For example, comparison of readings from sensors in different
divisions may provide useful information concerning the behavior of the sensors (for example, online
monitoring). Such a function executed within a safety system, however, could also result in unacceptable
influence of one division over another, or could involve functions not directly related to the safety
functions, and should not be executed within the safety system. Receipt of information from outside the
division, and the performance of functions not directly related to the safety function, if used, shall be
justified. The added system/software complexity associated with the performance of functions not directly
related to the safety function and with the receipt of information in support of those functions shall not
significantly increase the likelihood of software specification or coding errors, including errors that would
affect more than one division.
The safety function of each safety channel shall be protected from adverse influence from outside the
division of which that channel is a member. Information and signals originating outside the division shall
not be able to inhibit or delay the safety function of that division. This protection shall be implemented
within the affected division (rather than in the sources outside the division), and shall not itself be affected
by any condition or information from outside the affected division. This protection shall be sustained
13
IEEE Std 7-4.3.2-2010
despite any operation, malfunction, design error, communication error, or software error or corruption
existing or originating outside the division.
For legacy safety systems with only two divisions, each division consisting of redundant channels, each of
those channels is required to be capable of generating a single protective action signal regardless of the
determination reached by other channels. Communications between those redundant channels shall be
restricted in the same manner as described for inter-divisional communication in this standard.
Safety systems shall be designed such that no input from non-safety systems is required for the system to
perform its safety functions. Data input (e.g., setpoints and scaling) from a non-safety system that receives
verification equivalent to the quality of the safety system such as independent reviews and configuration
controls is acceptable for use in a safety system (see 5.6.4.3 for detail criteria).
5.6.1 Between redundant portions of a safety system
See 5.6.4 for additional detailed criteria.
5.6.2 Between safety systems and effects of design basis event
5.6.3 Between safety systems and other systems
5.6.3.1 Interconnected equipment
5.6.3.2 Equipment in proximity
5.6.3.3 Effects of a single random failure
5.6.4 Detailed criteria
5.6.4.1 Buffering function/circuit
A buffering function provides an interface between the communications link and the safety function. The
primary function of the buffering function is to ensure that faults and failures on the communication
originating outside the safety division do not propagate to the safety function within the division,
maintaining the integrity of the safety function. The following criteria shall be applied to the buffering
function:
14
IEEE Std 7-4.3.2-2010
a) The buffering function shall consist of two different circuits, one performing the safety function
and one performing the data communication function. The buffering circuit shall be accessible from
the processor performing the safety function. The buffering function can be provided by, for
example, a communications processor or other processing technology such as simple discrete logic,
logic within an Field Programmable Gate Array, an Application-Specific Integrated Circuit, etc.,
either on the same printed circuit board or on a separate printed circuit board.
b) The safety function processor shall operate asynchronously from the communication processor and
with no dependence on the interface with the communication processor. The safety function
requirements shall be clearly defined for the case where the data expected from the communication
processor is faulted (e.g., increased data rate to the buffer, data is not available or is old, corrupt
data).
c) Communications between function and communication processors shall use a shared memory
resource that is dedicated exclusively to this exchange of information (e.g., dual-ported memory).
The function processor, the communications processor, and the shared memory, along with all
supporting circuits and software, are all considered to be safety-related, and shall be designed,
qualified, fabricated, etc. accordingly. Access to the shared memory shall be controlled in such a
manner that the function processor has priority access to the shared memory to complete the safety
function in a deterministic manner. The safety function circuits and program logic shall be
implemented such that the safety function will be performed within the established timeframe and
without the data from the shared memory in the event that the function processor is unable to gain
access to the shared memory.
d) The cycle time for the safety function processor shall be determined in consideration of the longest
possible completion time for each access to the shared memory. This longest-possible completion
time shall include the time of the memory itself and of the circuits associated with it, and shall also
include the longest possible delay in access to the memory by the function processor, assuming
worst-case conditions for the transfer of access from the communications processor to the function
processor. Failure of the system to meet the limiting cycle time shall be detected and alarmed.
e) If the buffering function provides data used in safety function, the buffering function shall be built
to the same V&V used for the safety functions. Otherwise, a graded V&V approach as defined in
IEEE Std 1012-2004 may be used based upon required integrity level.
f) The electrical isolation, separation and single failure requirements of IEEE Std 603-2009 apply to
the communication links between safety and non-safety systems, and between divisions in a safety
system.
5.6.4.2 Communications independence
A safety channel shall not receive any communication from outside its own safety division unless that
communication supports or enhances the performance of the safety function. Receipt of information that
does not support or enhance the safety function would involve the performance of functions that are not
directly related to the safety function.
The following criteria apply to digital communications between redundant safety divisions and between
safety and non-safety systems:
a) The device (e.g., processor) performing the safety function shall perform no communication
handshaking or interrupts that could disrupt safety function processing.
b) Only predefined data sets shall be processed by the receiving safety system (i.e., the message
format and protocol is pre-determined, that is, the same information is found in each section of
every message). Unrecognized data shall be identified and processed by the receiving system in
accordance with the defined design requirements.
15
IEEE Std 7-4.3.2-2010
c) Within the computer performing the safety function, the data received and data transmitted is stored
in separate, pre-determined locations. The pre-determined memory locations are used only for data
receipt or transmission.
d) Only data sets, not commands that could affect the operation of the safety processor, may be
transmitted or processed. All external signals shall be treated as data to be processed in accordance
with the operational safety logic in the normal sequencing of that logic. Commands that could alter
the safety logic or logic sequencing area are not allowed.
e) The progress of a safety function processor through its instruction sequence should not be adversely
affected by any message from outside its division.
f) The safety system software configuration shall not change while the safety system’s division is
performing its safety function. Changes shall be processed using the same rigorous process as the
original software. This does not preclude automated changes in setpoint values or logic based on
plant conditions, such as changes in reactor mode. Terminals used to make safety system software
configuration changes shall have access (e.g., keylock) and password security.
g) Safety division software shall be protected from alteration while the safety division is in operation.
Hardwired interlocks or physical disconnection of incoming data transmission from the
maintenance/monitoring equipment is a preferred method for changes to safety system software to
control these changes. Provisions for interdivisional communication shall explicitly preclude the
ability to send software executable code to a safety function processor unless all safety functions
associated with that processor are either bypassed or otherwise not in service. A workstation (e.g.,
engineer/programmer station) may alter addressable constants, setpoints, parameters, and other
settings associated with a safety function only by way of the communication requirements
described in 5.6.4.1 of this standard, or when the associated channel is inoperable. Such a
workstation shall be physically restricted from making changes in more than one division at a time.
The restriction should be by means of physical cable disconnect, or by means of keylock switch
that physically opens the data transmission circuit to the safety system. Provisions that rely on
software to effect the disconnection are not acceptable. Software may be used in the safety system
and/or in the workstation to accommodate the effects of the open circuit or for status logging or
other purposes.
h) The safety system software configuration shall be confirmed through periodic automated or manual
surveillance.
i) The safety system software configuration shall not require change or modification to support
periodic automated or manual surveillance testing.
j) Credible communication faults shall not prevent performance of required safety functions. It shall
be assumed that non-safety systems will have multiple and continual failures. The minimum list of
credible faults that shall be considered include the following: 5
⎯ Messages may be corrupted due to errors in communications processors, errors introduced in
buffer interfaces, introduced in the transmission media, or from interference.
⎯ Messages may be repeated at an incorrect point in time.
⎯ Messages may be sent in the incorrect sequence.
⎯ Messages may be lost, which includes both failures to receive an uncorrupted message or to
acknowledge receipt of a message.
⎯ Messages may be delayed beyond their permitted arrival time window, including errors in the
transmission medium, congested transmission lines, interference, or by delay in sending
buffered messages.
5
Most of the listed credible faults originate from IEC 61784-3 [B14].
16
IEEE Std 7-4.3.2-2010
⎯ Messages may be inserted into the communication medium, from unexpected or unknown
sources.
⎯ Messages may masquerade as valid messages from an expected source, which includes
intentional events (see 5.9 for protection from this condition).
⎯ Messages may be sent to the wrong destination, which could treat the message as a valid
message.
⎯ Messages may be longer than the receiving buffer, resulting in buffer overflow and memory
corruption.
⎯ Messages may contain data that is outside the expected range.
⎯ Messages may appear valid, but data may be placed in incorrect locations within the message.
⎯ Messages may occur at a high rate that degrades or causes the system to fail (i.e., broadcast
storm).
⎯ Message headers or addresses may be corrupted.
Annex E provides a set of deterministic remedial measures for these communication faults.
k) Communications that are needed to support a safety function, such as the sharing of channel trip
decisions for the purpose of voting, shall include provisions for ensuring that received messages are
correct and are correctly understood. Such communications should employ error-detecting or
error-correcting coding along with means for dealing with corrupt, invalid, untimely or otherwise
questionable data. The effectiveness of error detection/correction should be demonstrated in the
design and proof testing of the associated codes, but once demonstrated is not subject to periodic
testing. Error-correcting methods, if used, shall be shown to always reconstruct the original
message exactly or to designate the message as unrecoverable.
l) Communications that are needed to support a safety function shall be point-to-point by means of a
dedicated medium. Alternatively, other communication strategies may be used if they provide the
same reliability with documented justification.
m) Communication for safety functions shall communicate a fixed set of data at regular intervals,
whether data in the set has changed or not.
n) The Communication protocol shall be designed such that the validity and timeliness of message
data is included by the protocol, and checked and appropriately processed by the receiver (for more
information, see NUREG/CR-6082, 3.4.3 [B33]).
o) Provisions for communications should be analyzed for hazards and performance deficits posed by
unneeded functionality and complication.
p) The safety function shall not be adversely affected by communication overload and failure.
q) When determining response time, data error rates shall be considered.
5.6.4.3 Data independence
Data exchanged between redundant safety divisions or from a non-safety-related system to a safety-related
division shall be processed in a manner that ensures divisional independence in that it does not adversely
affect the safety function of other divisions. Faults and failures of data shall be identified and the system
design shall include appropriate logic to handle credible data faults and failures such as valid formatted
data that is incorrect due to a degrading input source.
The following criterion applies to data exchange between non-safety and safety systems:
17
IEEE Std 7-4.3.2-2010
a) The safety system shall not be dependent on the non-safety-related communication link or the data
from the non-safety-related system to perform its safety-related function. The non-safety data shall
be assumed to fail concurrent with a single failure in the safety system without preventing the
safety system from performing its intended functions.
b) If a safety division uses data from a redundant division or from a non-safety system (e.g., to adjust
setpoints or calibration data), that data shall be enabled (verified prior to use) either by manual
action within the safety division or by automatic action taken by safety logic within the safety
division.
c) Data used by multiple safety divisions shall be considered a common source of failure that may
adversely affect those multiple divisions.
Guidance for establishing communication independence is provided in Annex E.
5.7 Capability for test and calibration
Any media (disk, compact disk, tape, flash drive, etc.) attached to the measurement and test equipment
(M&TE) for data storage or transfer shall be scanned for viruses and other malicious code prior to use or
shall be controlled and stored in a physically protected area to prevent virus intrusion onto the media.
Any computer temporarily connected to the safety system network for maintenance or test purposes shall
be scanned for viruses and other malicious code prior to connection or shall be controlled and stored in a
physically protected area to prevent virus introduction into the safety system.
Wireless receivers/transmitters on temporarily-connected computers shall be disabled prior to connecting to

safety-related equipment.
5.8 Information displays
Safety-related controls and displays may be provided via safety-related operator workstations, or they may
be provided via hardwired devices such as switches, relays, indicators, and analog signal processing
circuits. In either case, the safety-related controls and indications shall be dedicated to specific safety
divisions. No requirements beyond IEEE Std 603-2009 are necessary for these safety-related controls and
indications in this case.
Alternatively, the remainder of this section provides additional guidance for operator workstations used for
the control of plant equipment in more than one safety division and for display of information from sources
in more than one safety division. This guidance also applies to workstations that are used to program,
modify, monitor, or maintain safety systems that are not in the same safety division as the workstation.
Multidivisional control and display stations addressed in this standard may themselves be safety-related or
not safety-related, and they may include controls and displays for equipment in multiple safety divisions
and for equipment that is not safety-related, provided they meet the conditions identified herein.
5.8.1 Independence and isolation requirements for multidivisional control and display
stations
a) Non-safety stations controlling the operation of safety-related equipment, shall have the following
restrictions:
18
IEEE Std 7-4.3.2-2010
1) The non-safety station shall access safety-related plant equipment only by way of a priority
function associated with that equipment, or via relay based actuation logic. Priority functions
should be designed and applied as described in the guidance in 5.5.4.
2) A non-safety station shall not affect the operation of safety-related equipment when the
safety-related equipment is performing its safety function. This provision shall be
implemented within the safety-related system, and shall not be affected by any operation,
malfunction, design error, software error, or communication error in the non-safety
equipment.
3) The non-safety station shall be able to bypass a safety function only when the affected safety
division has itself determined that such action would be acceptable.
4) The non-safety station shall not be able to suppress any safety function unless the safety
system itself determines that termination of a safety command is warranted as a result of the
safety function having been achieved. It shall be demonstrated that the safety system has all
information and logic needed to make such a determination. If these conditions are met then
the safety command may be reset from a source outside the safety division. If operator
judgment is needed to establish the acceptability of resetting the safety command, then reset
from outside the safety division is not acceptable because there would be no protection from
inappropriate or accidental reset.
5) The non-safety station shall not be able to bring a safety function out of bypass condition
unless the affected safety division has itself determined that such action would be acceptable.
b) Safety-related stations controlling the operation of equipment in other safety-related divisions shall
be subject to constraints similar to those described above for non-safety stations that control the
operation of safety-related equipment.
1) A control station shall access safety-related plant equipment outside its own division only by
way of a priority module associated with that equipment, or via relay based actuation logic.
Priority modules shall be designed and applied as described in the guidance on priority
modules.
2) A station shall not be capable of influencing the operation of safety-related equipment outside
its own division when that equipment is performing its safety function. This provision shall be
implemented within the affected (target) safety-related system, and shall not be affected by
any operation, malfunction, design error, software error, or communication error outside the
division of which those controls are a member.
i) The extra-divisional (that is, “outside the division”) control station shall be able to
bypass a safety function only when the affected division itself determined that such
action would be acceptable.
ii) The extra-divisional station shall not be able to suppress any safety function unless the
safety system itself determines that termination of a safety command is warranted as a
result of the safety function having been achieved. It shall be demonstrated that the
safety system has all information and logic needed to make such a determination. If
these conditions are met then the safety command may be reset from a source outside
the safety division. If operator judgment is needed to establish the acceptability of
resetting the safety command, then reset from outside the safety division is not
acceptable because there would be no protection from inappropriate or accidental reset.
iii) The extra-divisional station shall not be able to bring a safety function out of bypass
condition unless the affected division has itself determined that such action would be
acceptable.
5.8.2 Malfunctions and spurious actuations
Information displays interfacing to safety systems shall comply with the following criteria:
19
IEEE Std 7-4.3.2-2010
a) The result of malfunctions shall be consistent with the assumptions made in the safety analysis of
the plant design and review criteria.
b) Functions that are assumed to malfunction independently in the safety analysis shall not be affected
by failure of a multidivisional control and display station.
c) No single control action (for example, mouse click or screen touch) shall generate commands to
plant equipment. A minimum of two positive operator actions should be required to generate a
command.
d) Safety-related control and display stations shall be qualified as required by IEEE Std 603-2009
5.4. 6 Non-safety control and display stations capable of controlling safety equipment shall be
qualified such that when adverse environments such as seismic conditions, EMI/RFI, power surges,
and all other design basis conditions applicable to safety-related equipment at the same plant
location occur, the non-safety control and display stations shall not produce spurious actuations and
shall not have adverse effects upon any safety-related equipment or device as a result of a design
basis condition, both during the condition and afterwards. This qualification need not demonstrate
that the non-safety multidivisional control and display stations maintain complete functionality
during or after the application of the design basis condition. If this requirement can not be met, then
the plant safety analyses shall envelope the conditions that may result. Qualification should be
supported by testing rather than by analysis alone. Defense in depth and diversity (D3)
considerations may warrant the inclusion of additional qualification criteria or measures in addition
to those described herein.
e) Loss of power, power surges, power interruption, and any other credible event to any operator
workstation or controller shall not result in spurious actuation or stoppage of any plant device or
system unless that spurious actuation or stoppage is enveloped in the plant safety analyses.
f) The design shall have the provision to physically disable the control and display stations upon
abandonment of the main control room, to preclude spurious actuation of safety equipment that
might otherwise occur as a result of the condition causing the abandonment (such as control room
fire or flooding). The means of disabling control room control and display stations should be
immune to short-circuits, environmental conditions in the control room, etc. that might restore
functionality to the control room operator stations and result in spurious actuations of safety
equipment.
g) Failure or malfunction of any operator workstation shall not result in a plant condition (including
simultaneous conditions) that is not enveloped in the plant design bases, accident analyses, and
ATWS provisions, or in other unanticipated abnormal plant conditions.
5.8.3 Additional considerations for multidivisional control and display stations
a) Safety-related plant equipment shall have safety-related controls and displays as required by IEEE
Std 603-2009. This does not preclude additional non-safety controls and displays for the same
safety-related equipment.
b) Equipment that is not classified as part of a safety system shall not be credited in any design basis
analysis in support of safety functions. There shall be sufficient safety-related controls and displays
such that all safety functions, including manual actuation of the safety functions, can be
accomplished using only those safety-related controls and displays.
6
For additional information on safety-related qualification, refer to 10 CFR 50, Appendix A, General Design Criterion 4 [B36].
20
IEEE Std 7-4.3.2-2010
5.9 Control of access
The following requirements combined with those in 5.6 provide sufficient assurance and protection for the
safety system from malicious, threats from outside the vital area.
5.9.1 Physical security
All safety-related digital components and network cabling shall be installed in a plant location that
physically secures the equipment.
Locating the components in the vital area of a nuclear plant provides sufficient physical security to meet
this requirement. For more information regarding the definition of vital area see 10 CFR 73 [B38].
Computer equipment intended to interface with the safety-related equipment that is not permanently
installed shall be kept in a plant area and stored in a manner that limits access to that equipment only to a
defined set of authorized employees whose job requires access to this equipment. Portable computer
equipment intended to interface with the safety-related equipment shall not be used for other purposes, and
shall not be taken out of and returned to the protected area without appropriate controls and safeguards.
Permanently connected engineering workstations and connections for M&TE shall be installed in a plant
area that physically secures the equipment and has access limited to only a defined set of authorized
employees whose job requires access to this equipment.
5.9.2 Access controls
Access to safety-related systems shall be limited to a defined set of personnel who have been specifically
authorized to perform the required actions. This physical and logical access control should be based on the
results of computer security qualitative risk analyses. A computer security risk is the combination of the
consequence to the nuclear power plant and the susceptibility of a digital system to threats both within and
outside of the vital area. The results of the analyses may require combinations of more complex access
controls, such as a combination of knowledge (e.g., password), property (e.g., key, smart-card) and
personal features (e.g., fingerprints), rather than just a password.
Changes to configuration parameters [e.g., setpoints, logic block configuration, and ladder logic) and
software shall comply with the requirements of 5.6.4.2 item g)]. Sufficient access controls shall exist to
prevent inappropriate access.
Vendor default passwords shall be changed before the system is credited with performing its safety
function.
All remote access shall be prohibited. Remote access is defined by the safety system’s computer security
assessment.
Wireless connectivity shall not be implemented. All wireless capabilities shall be disabled on workstations.
All wireless capabilities on M&TE equipment shall be disabled prior to connecting to safety-related
equipment.
5.9.3 Virus protection and security patches
Safety systems should be designed such that virus protection software is not required. Virus protection
software is not required for safety-related systems if there is no communications path into the safety-related
system, or if that communications path is limited to communications from the safety-related system to the
non-safety system, with no response or acknowledgment required. If two-way communication does exist
21
IEEE Std 7-4.3.2-2010
between safety and non-safety systems then an evaluation of the need for virus protection software on the
safety system shall be performed.
Engineering workstations shall have timely, periodically updated virus protection software run and security
patches installed prior to their connection to safety systems if any of the following conditions are met:
1) The workstation has capabilities for removable external storage media.
2) The workstation can be attached to a network other than safety systems.
3) The workstation is not permanently mounted in a vital area.
The safety system shall not contain any removable media devices unless there are barriers to ensure that the
device is not connected during online operation or the design prohibits data being written from the media to
the safety system. Any media (disk, tape, flash drive, etc.) used for data storage or transfer shall be scanned
for viruses prior to use or shall be controlled and stored in a physically protected area to prevent virus
intrusion onto the media.
5.9.4 Life cycle approach
The digital safety systems/equipment development process shall address potential security vulnerabilities in
each phase of the digital safety system lifecycle described in 5.3. The specific security requirements shall
be commensurate with the risk and magnitude of the harm resulting from unauthorized and inappropriate
access, use, disclosure, disruption, or destruction of the digital safety system. The following subclauses
(5.9.4.1 through 5.9.4.8) are appropriate for a waterfall lifecycle. These tasks and requirements may be
modified to accommodate other lifecycle models; however, an equivalent level of protection against
security vulnerabilities and computer protection shall be provided.
5.9.4.1 Concept phase
In the concept phase, the utility and developer shall identify safety system security capabilities that will be
implemented. The utility and developer shall perform a security assessment to identify potential security
vulnerabilities in the relevant phases of the system life cycle. This Phase shall address all aspects of the
security, both physical and logical, for designers, users, and maintainers of the system. The results of the
analysis shall be used to establish security requirements for the system (hardware and software).
5.9.4.2 Requirements phase
The utilities and developers shall define the security functional performance requirements for the complete
system life cycle during the requirements phase. This shall include the following:
⎯ System configuration
⎯ Interfaces external to the system
⎯ Equipment qualification
⎯ Human factors
⎯ Data definitions
⎯ Documentation for the software and hardware
⎯ Installation and acceptance
22
IEEE Std 7-4.3.2-2010
⎯ Operation and execution

⎯ Maintenance
These security requirements shall be part of the overall system requirements. Requirements specifying the
use of pre-developed software and systems [e.g., reuse software and commercial off-the-shelf (COTS)
systems] shall address the vulnerability of the safety system (e.g., by using pre-developed software
functions that have been tested and are supported by operating experience).
5.9.4.3 Design phase
The safety system security requirements identified in the system requirements specification shall be
translated into specific design configuration items in the system design description. The safety system
security design configuration items shall address control over (1) physical and logical access to the system
functions, (2) use of safety system services, and (3) data communication with other systems. Design
configuration items incorporating pre-developed software into the safety system shall address security
vulnerabilities of the safety system. Physical and logical access control shall be based on the results of
computer security qualitative risk analyses. The results of the analyses may require more complex access
control, such as a combination of knowledge (e.g., password), property (e.g., key, smart-card) or personal
features (e.g., fingerprints), rather than just a password.
The developer shall delineate the standards and procedures that will conform with the applicable security
policies to ensure the system design products (hardware and software) do not contain undocumented code
(e.g., back door coding), malicious code (e.g., intrusions, viruses, worms, Trojan horses, or bomb codes),
and other unwanted or undocumented functions or applications. The development process shall ensure the
system does not contain these items.
5.9.4.4 Implementation phase
The implementation activity addresses hardware configuration and setup; software coding and testing; and
communication configuration and set-up, including the incorporation of reused software and COTS
products. The security design configuration item transformations from the system design specification are
verified and validated to be correct, accurate, and complete. The developer shall implement security
procedures and standards to minimize and mitigate tampering with the developed system. The developer’s
standards and procedures shall include testing, and scanning as appropriate, to address undocumented codes
or malicious functions that might (1) allow unauthorized access or use of the system or (2) cause systems to
behave beyond the system requirements. The developer shall remove all hidden functions and vulnerable
features embedded in the code, and the final code shall not contain any features, functions or code not
required to perform the functions designated in the system requirements.
5.9.4.5 Test phase
The objective of testing security functions is to ensure that the system security requirements are validated
by execution of integration, system, and acceptance tests. Testing includes system hardware configuration
(including all external connectivity), software integration testing, system integration testing, system
equipment qualification testing, and system factory acceptance testing. The security requirements and
configuration items are part of validation of the overall system requirements and design configuration
items. Therefore, security design configuration items are just one element of the overall system validation.
Each system security feature shall be validated to confirm that the implemented system does not increase
the risk of security vulnerabilities and does not reduce the reliability of safety functions.
23
IEEE Std 7-4.3.2-2010
5.9.4.6 Installation and checkout phase
In installation and checkout, the safety system is installed and tested in the target environment. The utility
shall perform an acceptance review and test the safety system security features. The testing is to verify and
validate the correctness of the safety physical and logical system security features in the target
environment. The utility shall ensure that the system features enable the utility to perform post-installation
testing of the system to verify and validate that the security requirements have been incorporated into the
system appropriately.
A utility shall have a program that addresses the digital safety system security. The security policies,
standards, and procedures shall require that installation of the digital system not compromise its security,
security of other systems, or the security of the plant. This may require the utility to perform a security
assessment, which includes a risk assessment, to identify the potential security vulnerabilities caused by
installation of the digital system. The risk assessment shall include an evaluation of new security
constraints in the system; an assessment of the proposed system changes and their impact on system
security; and an evaluation of operating procedures for correctness and usability. The results of this
assessment shall provide a technical basis for establishing certain security levels for the systems and the
plant.
5.9.4.7 Operation and maintenance phase
During the operations phase, the utility shall check that the system security is intact by techniques such as
periodic testing and monitoring, review of system logs, and real-time monitoring where possible. The
utility shall evaluate the impact of safety system changes in the operating environment on safety system
security; assess the effect on safety system security of any proposed changes; evaluate operating procedures
for compliance with the intended use; and analyze security risks affecting the utility and the system.
The maintenance phase is activated when the utility changes the system or associated documentation. These
changes may be categorized as follows:
⎯ Modifications (e.g., corrective, adaptive, or perfective changes)

⎯ Migration (e.g., the movement of system to a new operational environment)
⎯ Replacement (e.g., the withdrawal of active support by the operation and maintenance organization,
partial or total replacement by a new system, or installation of an upgraded system)
Software modifications of the safety system shall be treated as development processes and shall be fully
verified and validated. Security functions shall be assessed as described above, and shall be revised (as
appropriate) to reflect requirements derived from the maintenance process.
When migrating systems, the utility shall verify that the migrated systems meet the safety system security
requirements. The maintenance process shall continue to conform to existing safety system security
requirements unless those requirements are to be changed as part of the maintenance activity.
The utility shall specifically address security during the operation and maintenance phase. The security
features shall be maintained under a configuration management program.
The utility shall develop an incident response and recovery plan for responding to digital system security
incidents (e.g., intrusions, viruses, worms, Trojan horses, or bomb codes). The plan shall be developed to
address various loss scenarios and undesirable operations of plant digital systems, including possible
interruptions in service due to the loss of system resources, data, facility, staff, and/or infrastructure. The
plan shall define contingencies for ensuring minimal disruption to critical services in these instances.
24
IEEE Std 7-4.3.2-2010
5.9.4.8 Retirement phase
In the retirement life cycle phase, the utility shall assess the effect of replacing or removing the existing
safety system security functions from the operating environment. The utility shall include in the scope of
this assessment the effect on safety and non-safety system interfaces of removing the system security
functions. The utility shall document the methods by which a change in the safety system security functions
will be mitigated (e.g., replacement of the security functions, isolation from other safety systems and utility
interactions, or retirement of the safety system interfacing functions). The security procedures shall include
cleansing the hardware and data. Upon removal from service, the utility shall consider data cleansing, disk
destruction, or complete overwrite.
5.9.5 Maintenance
For system life cycle, software life cycle, and verification and validation refer to ISO/IEC 15288:2008,
ISO/IEC 12207:2008 (IEEE Std 12207-2008), and IEEE Std 1012-2004, respectively.
5.10 Repair
5.11 Identification
In addition to the requirements in 5.11 in IEEE Std 603-2009, the following identification requirements
specific to computer systems shall be met:
a) Software and hardware identification, including version control, shall be provided and used to
verify that the correct software is installed in the correct hardware component.
b) Means shall be included in the software such that the identification may be retrieved from the
software using software maintenance tools.
5.12 Auxiliary features
5.13 Multi-unit stations
5.14 Human factors considerations
25
IEEE Std 7-4.3.2-2010
5.15 Reliability
In addition to the requirements of IEEE Std 603-2009, when reliability goals are identified, the proof of
meeting the goals shall include the software. The method for determining reliability may include
combinations of analysis, field experience, or testing. Software error recording and trending may be used in
combination with analysis, field experience, or testing.
5.16 Common Cause Failure criteria
The use of digital computers in safety systems, has led to concerns that software design errors could lead to
Common Cause Failures (CCFs), which might in turn disable one or more safety functions in redundant
divisions of a safety system. Safety-related instrumentation and control systems shall have adequate
defense in depth and diversity (D3) to compensate for credible CCF.
Software errors can be introduced into a system at any stage of the life cycle, including specification,
implementation, maintenance or modification.
Latent software faults are design errors that may remain undetected until challenged by a triggering
mechanism. A latent fault is not harmful in and of itself, but requires a triggering event (i.e., a specific
event or operating condition) to become a failure. A latent fault is systematic (i.e., existing in multiple
divisions) if it exists in multiple components in the integrated instrumentation system. A systematic fault
becomes a CCF if a triggering event occurs to challenge the fault, causing simultaneous failure in multiple
divisions of the safety system, defeating one or more safety functions. The failures are considered
simultaneous (and therefore CCF) when the time interval between the failures is too short for repair or
recovery measures to be taken. Software CCF is not subject to the single failure criteria of IEEE Std 379-
2000 [B16]; however, software CCF shall be considered in the D3 analysis described in this subclause.
5.16.1 Diversity and defense-in-depth analysis
A D3 analysis shall be prepared for the plant’s instrumentation and control systems, encompassing the
reactor trip functions, the ESF actuation functions, the plant controls, and the main control room indications
and manual controls. The D3 analysis shall demonstrate that vulnerabilities to digital safety system
software CCF have been adequately addressed. The scope of software CCF to be considered in the D3
analysis includes those that could impair an automatic safety actuation, or could impact the main control
room instrumentation required to support safety-related operator manual actions.
For a methodology example for developing a D3 analysis refer to NUREG/CR-6303 [B34].
The D3 analysis shall assess each postulated software CCF for all events (anticipated operational
occurrences and postulated accidents) analyzed in the plant safety analysis [for example in the U.S., they
are identified in the plant’s Safety Analysis Report (SAR)] using best-estimate methods using realistic
assumptions. The D3 analysis shall demonstrate adequate diversity within the design for each of these
events.
5.16.2 Credible CCF
If digital components have sufficient diversity, then CCF can be categorized as not credible between these
components. Methods and guidelines for determining diversity between digital components can be found in
NUREG/CR-6303. The following cautions regarding diversity are particularly noteworthy:
26
IEEE Std 7-4.3.2-2010
⎯ The justification for the level of diversity of equipment, or of related system software such as a
real-time operating system, shall extend to the equipment’s components to ensure that actual
diversity exists. For example, different manufacturers might use the same processor or license the
same operating system, thereby potentially incorporating common failure modes.
⎯ With respect to software diversity, experience indicates that independence of failure modes may not
be achieved in cases where multiple versions of software are developed to the same software
requirements.
If digital components can be shown to be sufficiently simple and deterministic in performance, measures
such as online error checking and exhaustive testing can be used to demonstrate that the component is not a
significant source of software CCF, and CCF of such components need not be considered in the D3
analysis. An example of exhaustive testing is that every possible combination of inputs, internal and
external initial states, and every signal path can be tested; that is, the system is fully tested (this refers to
proof-of-design testing, not to individual testing of each module and not to surveillance testing) and found
to produce only correct responses.
Defensive design measures can also be employed to eliminate postulated software CCF from further
consideration in the D3 analysis (e.g., by eliminating the possibility of a triggering mechanism causing a
postulated software fault to propagate to a software failure).
The likelihood of a software CCF is reduced by following the development life cycle of a digital system
that conforms with the requirements of this standard.
Software CCF is treated as a beyond design basis event with respect to a plant’s safety analysis.
5.16.3 Adding diversity to address CCF vulnerabilities
If the D3 analysis identifies any safety functions in the safety system that are vulnerable to CCF (i.e., can
be disabled by CCF), then back-up systems or actions shall be identified or added as necessary to provide
diverse means of accomplishing the safety functions.
These diverse means
⎯ Shall not be subject to the same CCF vulnerability

⎯ Shall perform either the same function or a different function that mitigates the particular event
⎯ May be implemented in non-safety-related equipment, with sufficient quality (see 5.16.3.2)
⎯ May be automatic or manual, or a combination thereof
⎯ Shall be powered from sources that will be available during the postulated events for which the
equipment is credited to respond (e.g., during and following a loss of offsite power, as applicable)
⎯ Shall be suitable to operate in the environment that will be present during the postulated events for
which the equipment is credited to respond
If any identified vulnerabilities are not addressed by design modification, refined analysis, or provision of
alternate trip, initiation, or mitigation capability, justification should be provided.
5.16.3.1 Diverse manual controls and displays
Manual operator action may be credited as backup to safety functions disabled by postulated CCF, if the
manual action can be performed reliably in a period such that the plant response remains bounded by the
27
IEEE Std 7-4.3.2-2010
acceptance criteria for radiation release. 7 The operator shall have sufficient information display and
controls (safety or non-safety) in the main control room for the required response, and these displays and
controls shall be diverse from the safety system disabled by the postulated CCF. Suitable human factors
engineering analysis shall be performed to assure that these manual operator actions can be performed.
In addition to the above, a set of displays and controls (safety or non-safety) shall be provided in the main
control room for manual actuation and control of safety equipment to manage plant critical safety
functions, including reactivity control, reactor core cooling and heat removal from the primary system,
reactor coolant system integrity, and containment isolation and integrity. The displays and controls shall be
diverse from the safety system, unaffected by the various postulated software CCFs. If these displays and
controls are credited as backup to safety functions disabled by postulated software CCF, they should
interface to the component actuation circuitry downstream of the lowest-level software-based components
subject to the postulated software CCF (one example would be the use of hard-wired connections). The
interface can occur at either the system or component level.
5.16.3.2 Diverse automatic controls
Diverse automation may be credited as back-up to safety functions disabled by a postulated CCF. The
automation shall be provided by equipment that is not affected by the same postulated safety system CCF.
This equipment may be digital or non-digital.
Status information shall be available in the main control room to indicate the operation of the diverse
automation equipment.
The diverse automation equipment shall be designed to limit the potential for inadvertent actuation and
challenges to safety systems. Diverse automation equipment should be designed to initiate after the safety
system actuation conditions are exceeded.
The automation shall be sufficient to maintain plant conditions within the limits recommended by the
regulator’s recommended acceptance criteria for radiation release.7
Diverse automation equipment designed to compensate for safety system CCF vulnerability shall be of
sufficient quality to perform the necessary functions under the associated event conditions. 8
The diverse I&C system should be designed for the environment that could exist during the events for
which the equipment is assumed to respond.
Other non-safety automated systems that are in continuous use, that are credited in the D3 analysis to
compensate for CCF vulnerability, do not require the augmented quality discussed above.
7
For example, the United States regulatory requirements include five requirements. One of them states that no more than 10% of the
10 CFR 100 [B39] accident radiation release maximum or violation of the primary coolant boundary can occur when these diverse
controls are required when an anticipated operational occurrence happens concurrent with a common cause failure. These criteria are
applied for failures of equipment common to the reactor trip system or of the engineered safety features and its actuation system.
Another states that no more than the 10 CFR 100 [B39] accident radiation release maximum, violation of the primary coolant pressure
boundary, or violation of containment integrity are allowed in any postulated accident. Another criteria requires that failures in the
monitoring or display systems that could influence the reactor trip or engineered safety features could mislead the operator, that the
protection system functions would compensate for any operator-induced transients. [NUREG-0800, Branch Technical Position (BTP)
7-19, Revision 5 [B32]]
8
For example, the United States regulatory requirements for an existing diverse system are provided in 10 CFR 50.62 [B35], and in
U.S. NRC Generic Letter 85-06 [B31].
28
IEEE Std 7-4.3.2-2010
5.17 Use of commercial digital equipment
NOTE—See Annex C for more information about commercial grade item acceptance and dedication.
Commercial-off-the-shelf (COTS) digital equipment was not developed under a nuclear quality assurance
program. For many reasons, nuclear facilities need to have access to these COTS items as basic
components. Since the COTS items were not designed and manufactured under a nuclear quality assurance
program, an alternative approach shall be used to verify a component is acceptable for use in a safety-
related application. The objective of this alternative approach, using the process of commercial grade
dedication, is to verify that the item dedicated is equivalent to basic components developed under an
acceptable nuclear quality assurance program and can thus provide a reasonable assurance that the
commercial grade items will perform the intended safety function or functions.
Dedication is a process used to provide reasonable assurance that a commercial grade item to be used as a
basic component will perform its intended safety function, and , in this respect, will be deemed equivalent
to an item designed and manufactured under a nuclear quality assurance program.
Dedication is defined as the process by which the dedicating entity, operating under a nuclear quality
assurance program, to confirm that a commercial grade item or service meets the design requirements,
expressed as critical characteristics defined by the dedicating entity. Evaluation is required because the
commercial equipment vendor did not perform design, development, maintenance, and manufacturing
under a nuclear quality assurance program, as the commercial item or service was not originally intended
for use in nuclear power plant safety-related applications. The dedicating entity shall perform evaluations
and tests to confirm that the item meets the design requirements and performs its intended safety function,
including behavior in the presence of environmental and application stressors.
The dedicating entity can also make use of commercial services, by determining whether the work product
to be produced by the commercial vendor will meet the design requirements established by the dedicating
entity, including the commercial vendor’s quality processes.
Confirmation is achieved by identifying the critical characteristics of the item or service and verifying their
acceptability by one or more of the methods defined in this section, and providing any required
compensatory actions.
Acceptance of a commercial grade item for use as a basic component depends on whether the item meets
the requirements specified in this standard (including the item’s life cycle processes, under which the
commercial vendor designed, developed, reviewed, tested and maintained the item), or on appropriate
compensatory actions taken under a nuclear quality assurance program by the dedicating entity.
The dedication processes for COTS items shall apply the criteria defined in this standard.
The dedication processes shall evaluate the hardware design, software design, system development life
cycle processes, and documentation for the COTS item and the vendor life cycle processes applied by the
vendor in the design, development, and maintenance of the COTS item, using the criteria of this standard.
Dedication shall be based upon evidence that the COTS item can perform its required safety function,
including hardware, software, human-system interfaces, and interfaces to other equipment. The acceptance
and its basis shall be documented and maintained with the dedication documentation. Appropriate
measures, such as those in EPRI TR-106439 [B9], shall be defined and implemented to compensate for
weaknesses in the vendor design, development, and maintenance of the COTS item.
Commercial equipment is not considered dedicated until the dedication process completes successfully.
29
IEEE Std 7-4.3.2-2010
Not every piece of commercial equipment is manufactured with the quality and design integrity 9 necessary
to be dedicated. A preliminary determination of the likelihood of success should be performed to determine
whether pursuit of commercial grade acceptance and dedication is likely to succeed. This shall include an
evaluation of how cooperative the equipment vendor will be to detailed design analysis of its equipment, as
well as the degree to which compensatory actions are required and possible, and how sufficient these
compensatory measures can be for missing design, review, testing, and other essential documentation.
The dedication process for COTS items shall require a technical evaluation that identifies the physical,
performance, documentation, and development process requirements necessary to provide adequate
confidence that the proposed digital system or component can safely and reliably perform the intended
safety function. The dedication processes shall apply to the hardware, software, human-system interfaces,
interfaces to other equipment, and life cycle documentation for the COTS item that are required to
accomplish the safety function or functions, or whose faults or failures could prevent or impede the
performance of the safety function or functions. The dedication process for software shall include an
evaluation of the system and life cycle processes, whenever possible. If the system and life cycle processes
are not evaluated, then additional compensatory measures are required, or dedication may not be possible.
Some life cycle process phases and associated documentation may not be accessible for evaluation. For
example, the organization performing the evaluation may not have access to the life cycle process
information and documentation for an integrated circuit to be used in the safety system. In this case, it
would not be possible to perform an evaluation of the processes used by the component designer to support
the acceptance process. For this case, other compensatory methods have to be used to dedicate the
integrated circuit.
The commercial grade dedication process shall include performance of equipment qualification, typically
performed as type testing, in accordance with 5.4 of this standard. Records of the equipment qualification
shall be retained as part of the acceptance and dedication records.
For convenience in discussion, the commercial grade item dedication is provided in the phased activities
described below.
5.17.1 Preparation for commercial grade dedication
The utility and/or the dedicating entity need certain information to define the plant systems and
environment in which the COTS item will be installed. These requirements are addressed in 5.17.1.1
through 5.17.1.6.
5.17.1.1 Document the system safety function risks and hazards
An analysis shall be performed to identify the functional and performance requirements of the plant safety
system, as it will be configured after the new equipment is installed. This analysis shall identify the risks
and hazards that could interfere with the COTS item accomplishing its safety function. These risks and
hazards are based on faults and failures possible from mistakes of omission or commission by the operators
or maintainers, as well as the effects on the COTS equipment from faults and failures in the existing plant
systems, instrumentation, actuated devices, and interfaces to other plant systems.
Failure analyses shall identify potential hazards within the COTS item or in interfaces to other plant
systems, operators, or maintainers that could interfere with the safety functions. Acceptable failure analysis
methods include combinations of the standard techniques of failure modes and effects analysis (FMEA)
9
System or Design Integrity is normally associated with the qualitative evaluation of the safety, reliability, availability,
maintainability, and testability of the operation of the COTS equipment (from EPRI TR-1011710 [B7]).
30
IEEE Std 7-4.3.2-2010
and fault tree analysis (FTA), as discussed in Annex D of this standard. The results from failure analyses
may define additional or refine existing critical characteristics.
5.17.1.2 Dedication for a specific use or for generic uses
Commercial grade dedication can be performed either for a specific safety system application or for generic
uses. Use of a commercially dedicated item in safety system applications that is not bounded by the
baseline dedication shall require additional technical evaluation for the new application. Generic dedication
uses a set of generalized requirements that bound a set of safety functions, and not a set of system-specific
requirements. Generic qualification requires creation of a set of bounding requirements for the dedication,
which provide a set of assumptions about the requirements of the systems to which the dedicated
equipment would be applied. These boundaries include performance requirements, accuracies, time
response, system integrity, and configurability or programmability of the COTS item. 10
Use of a generic dedication requires a technical evaluation of the proposed application against the
requirements used in the generic dedication to ensure that the proposed use falls within the boundaries of
the acceptance and dedication, with any required extensions to the acceptance, including the equipment
qualification, incorporated appropriately. Additional requirements provided by a regulatory agency’s
approval shall be included in the evaluation whenever pre-approved equipment is used. 11
5.17.1.3 Identify the safety function(s) the COTS item shall perform
Once the system-level functions have been identified and the risks and hazards have been evaluated, the
utility and/or dedicating entity shall identify the safety functions to be performed by the COTS item. This
process is part of the technical evaluation. This process shall address all safety functions to be performed
by the COTS item, and the potential affect of the COTS item’s functions as well as the identified COTS
item’s faults and failures, on other safety-related functions in plant systems or interfaces to other plant
systems.
5.17.1.4 Establish configuration management controls
COTS items to be used in safety systems shall be controlled in a configuration management process that
provides traceability of the COTS item development life cycle processes, by the vendor and by the
dedicating entity. The COTS vendor’s configuration management and change control processes should
support configuration management and change control by the dedicating entity. The dedicating entity shall
have a configuration management and change control process that compensates for any weaknesses in the
vendor’s processes. Data and error reporting associated with the COTS item shall be provided to the
dedicating entity’s configuration control and change management processes. The dedicating entity shall
define and document the minimum acceptable configuration management controls to be employed by both
the vendor and the dedicating entity. This evaluation shall be retained as part of the dedication
documentation.
5.17.1.5 Plan for error reporting
During the initial evaluation of the COTS vendor, the dedicating entity shall determine the methods,
processes, and contractual arrangements to be used for interfacing with the COTS vendor for prompt,
10
One approach for generic (i.e., not targeted to a specific application) acceptance is documented in EPRI TR-107330 [B10]. This
document provides guidance dedication of COTS items, when updated with current equipment qualification guidance. While initially
written for programmable logic controllers, the approach has been used for and is equally applicable to other COTS items with digital
content
11
EPRI TR-1001045 [B5] has further information on application of generic dedicated equipment.
31
IEEE Std 7-4.3.2-2010
appropriate evaluation of errors detected by the vendor and other non-nuclear customers, as well as changes
to the equipment resulting from obsolescence, enhancement, revision, and modernization. This data shall be
used by the dedicating entity to establish the appropriate error reporting structure for the COTS item. This
data shall also be used to define the methods required to replace failed equipment, including assessment of
the equipment qualification. The plan and evaluation shall be retained as part of the dedication
documentation.
5.17.1.6 Evaluate computer security
COTS items to be used in safety systems shall provide computer security features as required by 5.9 of this
standard. The dedicating entity shall perform an evaluation of the computer security risks and hazards
associated with this system, including impacts on hardware, software, interfaces to other systems, and life
cycle documentation, as well as plant procedures for the COTS items and the interfacing systems. The
dedicating entity shall retain this evaluation as part of the acceptance and dedication documentation.
5.17.2 Performing commercial grade dedication of digital items
After completion of the technical evaluation, including the CDR and identification of critical
characteristics, the COTS item shall be evaluated for acceptability using detailed criteria and one or more
of the acceptance methods.
5.17.2.1 Developing detailed acceptance criteria
The critical characteristics by which a COTS item will be evaluated for use in a safety system shall be
identified by a technical evaluation. Each critical characteristic shall be verified by a combination of
inspection, analysis, or testing. 12 This standard identifies three distinct types of commercial grade item
critical characteristics. Critical characteristics selected for acceptance from the physical and performance
characteristics listed below shall be identifiable and measurable attributes based on the complexity,
application, function, and performance of the item or service for its intended safety function. Critical
characteristics selected for acceptance from the development process characteristics listed below shall be
identifiable and shall be based on objective evidence, selected to demonstrate that the software is
appropriate for its intended safety function. The dedicating entity shall recognize that not all measurable
attributes are critical characteristics. The categories are provided for guidance. Each category provides
broad classes of attributes to evaluate during the dedication. None of the categories provided have any
formal significance. All identified critical characteristics shall be verified.
⎯ Physical characteristics include attributes such as physical dimensions, power requirements, part
numbers, hardware and software model and version numbers, and data communication physical
requirements.
⎯ Performance characteristics include attributes such as response time, human-machine interface
functional requirements, memory allocation, performance during abnormal conditions, reliability,
error handling, required embedded functions, and environmental qualification requirements (e.g.,
seismic, temperature, humidity, radiation, and electromagnetic compatibility based on IEEE Std
323-2003 and IEEE Std 344-2004).
⎯ Development process characteristics include attributes such as supporting life cycle processes at the
vendor (e.g., verification and validation activities, configuration management processes, software
quality assurance, and hazard analyses), traceability, and maintainability.
12
Further explanation on the selection of critical characteristics for digital equipment is available from other sources, including EPRI
TR-106439 [B9] referenced in Annex C.
32
IEEE Std 7-4.3.2-2010
The third bullet above, development process characteristics extends the normal evaluation and acceptance
criteria to include digital aspects. 13 Dependability shall include safety, reliability, availability,
maintainability, built-in quality, detection and annunciation of faults and failures, and other characteristics.
This standard further includes survivability as a dependability attribute. For software-based systems, the
current state-of-the art does not support any single accepted means or process for measurement of these
characteristics. Part of the design analysis as defined in 5.17.4 of this standard assesses the vendor
processes used to develop the system, which provides a method to assess whether the system exhibits
adequate quality for the system to provide the required dependability. The design analysis review also aids
in establishing critical characteristics, which shall be verified by the dedicating entity.
5.17.2.2 Retaining documented assessments
Sufficient data shall be gathered and retained as objective evidence that the quality of the commercial items
are sufficient to accept, environmentally qualify, and dedicate the COTS item for use as a basic component.
5.17.3 Methods for evaluating commercial equipment
Four acceptance methods are useful in evaluating traditional COTS equipment. EPRI NP-5652 [B3] (see
Annex C) documented these methods for traditional commercial grade dedication of physical hardware.
The four methods are defined as follows:
⎯ Method 1 is defined as the use of special tests, inspections, or some combination of tests and
inspections, after receipt of the commercial items. These tests or inspections shall be performed
under a nuclear quality assurance program. Test and inspection results shall be maintained as
quality records within a nuclear quality assurance program. These tests and inspections shall be
prepared and performed to confirm that the commercial items satisfy the selected critical
characteristics.
⎯ Method 2 is defined as the use of a commercial grade survey to take credit for the commercial
controls the supplier exercises. These controls may be based on quality programs, procedures, and
practices. A survey plan shall be prepared to confirm that the supplier maintains control of each
selected critical characteristic. The survey report shall document the methods used by the vendor,
the objective evidence used to evaluate the methods and confirm the methods are used, and the
conclusions of the survey staff. The survey shall reflect the specific scope of the COTS item or
service being procured, and shall be specific to the critical characteristics needed.
⎯ Method 3 is defined as source verification, in which the acceptance and dedication is based on
direct verification of critical characteristics and their control by the vendor. Source verification
shall be performed if the vendor does not document control methods in a quality program, using
vendor practices.
⎯ Method 4 is defined as evaluation of commercial equipment based on the confidence achieved
through proven performance of that item in equivalent service and configuration. Since even small
changes in configuration or environmental stressors can change the behavior of digital systems,
Method 4 shall not be used as the sole means of assessing digital system quality. Method 4 may be
used to support the conclusions reached by application of one or more of Methods 1, 2, and 3.
Method 2 shall not be employed as the basis for accepting items from suppliers with undocumented
commercial quality control programs or with programs that do not effectively implement their own
necessary controls. Method 2 should not be employed as the basis for accepting items from distributors
unless the survey includes the part manufacturer(s) and the survey confirms adequate controls by both the
distributor and the part manufacturer(s).
13
Derived from the EPRI TR-106439 [B9] dependability characteristics.
33
IEEE Std 7-4.3.2-2010
5.17.4 Performing design analysis
In order to document the technical evaluation adequately, certain data needs to be gathered concerning the
COTS items and the processes under which the vendor designed, developed, reviewed, tested, assured
quality, and performed maintenance on the system, hardware, and software. The technical evaluation of the
design analysis shall provide a documented evaluation of the COTS items’ design for the system, the
hardware, and the software:
⎯ An evaluation of the life cycle processes used for the life of the COTS item, including design,
development, quality assurance, review, test, configuration management, and change control.
⎯ An evaluation of the architecture.
⎯ An evaluation of the vendor’s or dedicating entity’s failure modes and effects analysis, as the
COTS items faults and failures would affect plant safety.
⎯ An evaluation of the operating history of the COTS item, in applications of similar safety
criticality.
⎯ A summary of the compensatory measures necessary to conclude that there is a reasonable
assurance that the COTS item can be used as a basic component, that it will perform its intended
safety function, and, in this respect, is deemed equivalent to an item designed and manufactured
under a nuclear quality assurance program.
One method of documenting the review of the design analyses for the technical evaluation is described in
EPRI TR-106439 [B9] and further defined in EPRI TR-1011710 [B7].
Performing and documenting a complete critical digital review (CDR) is one method to provide sufficient
design analysis for the COTS item. 14 The CDR should not focus solely on the software but should consider
the integrated hardware, software, interfaces, and all other aspects of the COTS item that will be used in the
planned application. Using the CDR methods provides an evaluation of the subtle differences introduced in
the COTS system software, including the myriad of possible paths through the software, stored states
within the system, and execution of instructions. The CDR also improves the estimate of the dependability
of the digital-based COTS item. The CDR shall include evaluation of the application software, hardware
and software platform upon which the software runs, user tools supplied with the equipment, tools used by
the vendor to create the platform software and user tools, function libraries, and vendor plans, procedures,
programs, and practices in the system development.
The CDR shall make use of failure analyses preferably performed by the vendor and performed or
augmented as necessary by the dedicating entity and combined with the system faults and failures analyses
from the preparatory phase and the safety functions performed by the system. This analysis shall determine
if additional requirements exist for compensatory measures, actions, or re-design of the COTS item or its
intended application. This analysis shall include the system, the interfaces to other systems, the interfaces
to operators and maintainers, and the final integrated plant and system to confirm that the goals for safety,
reliability, availability, maintainability, and testability are met.
Engineering judgment plays a key role in this analysis. The dedicating entity shall have a complete
understanding of the vendor’s system, hardware, and software life cycle processes from the initial design of
the COTS item through the time of the evaluation.
5.17.4.1 Developing compensatory measures
Compensatory measures shall include restrictions on use and application of the evaluated item; and the
need for changes, enhancements, or creation of operation and maintenance procedures, as appropriate.
14
Current guidance for performing a CDR is provided in EPRI TR-1011710 [B7].
34
IEEE Std 7-4.3.2-2010
Other compensatory measures under a nuclear quality assurance program could include creation of after-
the-fact design documents, generation of specific test cases to address critical characteristics, or
performance of verification and validation activities. The compensatory measures become part of the
critical characteristics.
5.17.4.2 Interfacing with equipment qualification testing and analyses
Equipment qualification testing (see 5.4) may identify the need for additional compensatory measures,
which shall define additional critical characteristics. These additional critical characteristics shall be
evaluated for possible impacts on the software or system configuration as well as on the documented
system evaluations. Similarly, critical characteristics defined by the design analysis activities may generate
additional equipment or considerations for equipment qualification testing.
5.17.4.3 Goal for design analysis and equipment acceptance
The goal is to prevent the identified system faults and failures, when applied in the plant application in the
presence of the identified faults and failures from plant equipment and staff, from resulting in failures to
perform the safety function and should not result in false initiations of the safety function(s). The identified
faults and failures shall be considered in developing the equipment acceptance tests, to confirm the correct
and appropriate performance of safety functions. These results shall be documented, and provided to the
utility for use in development of evaluations for licensing.
5.17.5 Maintenance of commercial dedication
There are two possible paths forward for COTS items, either maintaining the dedication current or
repeating appropriate dedication activities as required for each purchase of equipment. The entity
performing the dedication activities may choose not to maintain the dedication for updated equipment.
Replacement parts will then have to be evaluated for required acceptance activities, to demonstrate that the
modified equipment can perform the safety function(s). The entity performing these activities may choose
to maintain the dedication of updated equipment, analyzing the requirements for acceptance activities on an
on-going basis. In either case, this subclause shall apply.
5.17.5.1 Maintenance of traceability
If computer hardware or software has been procured as a COTS item and accepted through a dedication
process, then evaluation and acceptance of the changes to the commercially dedicated computer hardware
or software as well as any required evaluations, inspections, tests, and associated activities shall be
traceable through formal documentation.
5.17.5.2 Evaluation of changes
All changes to the commercially dedicated COTS item shall be evaluated in accordance with the process
that formed the basis for the original acceptance. Included in this technical equivalency evaluation shall be
consideration of the impact from changes in hardware, software, vendor procedures, vendor practices, or
vendor staff. Further evaluation shall be required if any elements of the approved process have been
omitted or modified during revision processes. This process should be based on the vendor’s change
control process, or an equivalent established by the accepting, qualifying, or dedicating entity.
The equivalency evaluation shall include the following:
35
IEEE Std 7-4.3.2-2010
⎯ Identification of any changes in design, material, manufacturing processes, configuration, form, fit,
or function of the replacement item from the original item.
⎯ Evaluation of the changes.
⎯ Confirmation that the changes do not adversely affect the current design or safety function of the
item.
If the changes adversely affect or are not bounded by the current approved design bases, the replacement
item is not equivalent and shall be either rejected or processed as a design change.
Equivalency evaluations are not to be used as the sole basis to accept a commercial grade item. Selection
and verification of the critical characteristics by appropriate dedication methods is required.
5.17.5.3 Maintenance of the documentation
All documentation supporting the commercial grade item acceptance, environmental qualification, and
dedication shall be maintained as configuration items. This documentation shall be revised appropriately to
reflect any changes in the configuration or in environmental qualification and dedication of the COTS item.
5.17.5.4 Maintenance of error reporting
Commercial terms and conditions shall be established and maintained between the entities responsible for
defect reporting and the commercial equipment vendor.
6. Sense and command features—functional and design requirements

7. Execute features—functional and design requirements

8. Power source requirements

36
IEEE Std 7-4.3.2-2010
Annex A
(informative)
Mapping of IEEE Std 603-2009 to IEEE Std 7-4.3.2
NOTE—Clause 4 through Clause 8 of this standard coincide with Clause 4 through Clause 8 in IEEE Std 603-2009.
Table A.1—Mapping of IEEE Std 603-2009 to IEEE Std 7-4.3.2
Annex for
IEEE Std 603-2009 criteria IEEE Std 7-4.3.2 additional requirements
guidance
4. Safety system design basis None —
5. Safety system criteria None —
5.1 Single-failure criterion 5.1 Single-failure criterion —
5.2 Completion of protective action None —

5.3 Quality • Software development (see 5.3.1), Annex D
• Software tools (see 5.3.2),
• Verification and validation (see 5.3.3),
• Independent V&V (IV&V) requirements (see
5.3.4),
• Software configuration management (see
5.3.5),
• Software project risk management (see 5.3.6)
5.4 Equipment qualification Equipment qualification (see 5.4)
5.5 System integrity • Design for computer integrity (see 5.5.1), Annex C
• Design for test and calibration (see 5.5.2),
• Fault detection and self-diagnostics (see 5.5.3)
5.6 Independence Independence (see 5.6) Annex E
5.7 Capability for test and calibration Capability for test and calibration (see 5.7) —
5.8 Information displays Information displays (see 5.8) —
5.9 Control of access Control of access (see 5.9) —
5.10 Repair None —
5.11 Identification Identification (see 5.11) —
5.12 Auxiliary features None —
5.13 Multi-unit stations None —
5.14 Human factors considerations None —
5.15 Reliability Reliability (see 5.15) —
5.16 Common Cause Failure criteria Common Cause Failure criteria (see 5.16) —
6. Sense and command feature—
None —
Functional design requirements
7. Execute feature—Functional design
None —
requirements
8. Power source requirements None —
37
IEEE Std 7-4.3.2-2010
Annex B
(informative)
Diversity requirements determination
The information in this annex has been made normative and moved to 5.16.
38
IEEE Std 7-4.3.2-2010
Annex C
(informative)
Dedication of existing commercial computers
C.1 Background
When the U.S. was actively constructing nuclear plants in the 1960s, 1970s, and into the 1980s, there were
many suppliers with nuclear quality assurance programs. Many suppliers discontinued their nuclear quality
assurance programs after this construction period. This reduced the available sources of qualified safety
grade equipment and the types of equipment available for purchase from suppliers with nuclear QA
programs. The nuclear industry found it necessary to establish programs to use commercial grade
equipment in safety systems.
The nuclear industry needed a way to apply commercial grade items as basic components. The United
States (U.S.) nuclear industry and the Nuclear Regulatory Commission (NRC) worked together to establish
the commercial grade dedication criteria and acceptance methods for replacement equipment. The Electric
Power Research Institute (EPRI) wrote EPRI NP-5652 [B3], which established a process for acceptance of
traditional commercial grade items.
Generic Letter 89-02 states the following:
“The NRC staff believes that licensees who use methods similar to those described in EPRI
NP-5652 to verify the critical characteristics for commercial grade items intended for safety-
related applications have the basis for effective dedication programs.
Properly implemented, the EPRI guidelines, as modified below, establish methods which
satisfy existing requirements to Appendix B to 10 CFR Part 50 [B37] as they apply to the
dedication process of commercial grade items.
1. Acceptance Method 2, “Commercial Grade Survey of Supplier,” should not be

employed as the basis for accepting items from suppliers with undocumented
commercial quality control programs or with programs that do not effectively
implement their own necessary controls. Likewise, Method 2 should not be employed
as the basis for accepting items from distributors unless the survey include the part
manufacturer(s) and the survey confirms adequate controls by both the distributor and
the part manufacturer(s).
2. Acceptance Method 4, “Acceptable Supplier/Item Performance Record,” should not be

employed alone unless:
a. The established historical record is based on industry wide performance data that
is directly applicable to the item’s critical characteristics and the intended safety-
related application; and
b. The manufacturer’s measures for the control of design, process, and material
changes have been adequately implemented as verified by audit (multi-utility team
audits are acceptable).”
The Generic Letter provided three additional characteristics of an effective procurement and dedication
program, including the following:
39
IEEE Std 7-4.3.2-2010
1) The involvement of engineering staff in the procurement and product acceptance process,
2) Effective source inspection, receipt inspection, and testing programs; and
3) Thorough, engineering-based programs for review, testing, and dedication.
EPRI then produced several reports on processes for acceptance, qualification, and dedication. The U.S.
NRC Safety Evaluation Report for EPRI TR-106439 [B9] provides a review of the purposes of each report
along with the regulator’s view of those reports. EPRI NP-6406 [B4] was published in August 1989.
A key report is EPRI TR-102260 [B8], which explains the process and the methods used to implement
acceptance. In practice, EPRI does not submit technical reports that define methods to the NRC for formal
review and issuance of a Safety Evaluation Report (SER). However, EPRI TR-102260 [B8] is widely used
for commercial grade dedication.
The methods as documented are suitable for application to mechanical structures, systems, and
components, where traditional tests, inspections, and analyses are sufficient to assess quality. The methods
are not sufficient to evaluate devices containing software, since software depends on quality processes for
implementation. Additional guidance was required.
C.2 Discussion
As digital equipment became prevalent in the marketplace, the nuclear industry and the NRC realized the
need for a defined set of additional criteria and methods to support use of software in nuclear safety-related
use, including both equipment developed under an Appendix B quality program and commercial equipment
not developed under an 10 CFR 50 Appendix B [B37] quality program.
The first document produced to address digital concerns was a guide to licensing equipment with digital
content, extending the 10 CFR 50.59 licensing process to include the additional questions needed to
complete an evaluation of digital equipment. The industry and the NRC documented an acceptable process
in EPRI TR-102348, “Guideline on Evaluation and Acceptance of Commercial Grade Digital Equipment
for Nuclear Safety Applications.” (This document is no longer available, and provided solely as part of the
development of digital I&C in the U.S. nuclear power industry.) Because this document was submitted for
review, this document became a public document, available through the NRC Public Document Room,
along with the NRC SER accepting its use.
This report provided the first mutually acceptable descriptions of the new issues created by digital
equipment, and the first mutually acceptable definition of the possible effects of the differences between
the analog and relay equipment in use in nuclear power plants and the digital equipment that industry was
introducing. This difference is referred to as the “digital delta” and the impact on digital differences on
licensing is the focus of this EPRI technical report.
Reference is made in many of these reports and evaluations to the “digital delta.” Some of the important
aspects, where the digital system hides issues, include the following:
⎯ Complexity is hidden “inside the box” rather than visible as large amounts of modules,
components, and wiring. This complexity may be in the form of thousands of lines of software,
multi-tasking operating systems, and complex logic.
⎯ An analog or relay based system can be tested easily, and completely. The software industry states
that software-based systems cannot be completely tested.
⎯ Evaluating a digital system’s quality requires evaluating the plans, procedures, practices, and staff
capabilities within the organization developing the software.
⎯ Based on the complexity and architecture, software-based systems can exhibit subtle, unexpected
behaviors, resulting from faults, and failures within the system. The consequences and severity of
40
IEEE Std 7-4.3.2-2010
those faults and failures are difficult to remove or predict. Software that works correctly in one
environment may not work reliably when faced with a different configuration or different
environmental stressors.
⎯ Understanding the intentional and unintentional limitations in the system, based on the developer’s
designs, and the limitations of the software-based system are required before attempting new
system applications. Systems should not be applied beyond the boundaries the system developers’
envisioned.
The NRC issued Generic Letter 95-02, “Use OF NUMARC/EPRI REPORT TR-102348, “Guideline on
Licensing Digital Upgrades,” in Determining the Acceptability of Performing Analog-to-Digital
Replacements under 10 CFR 50.59,” that stated the following:
“Nuclear Management and Resources Council/Electrical Power Research Institute

(NUMARC/EPRI) Report TR-102348, "Guideline on Licensing Digital Upgrades," dated
December 1993, as acceptable guidance for determining when an analog-to-digital
replacement can be performed without prior NRC staff approval under the requirements of
Section 50.59 of Title 10 of the Code of Federal Regulations (10 CFR 50.59). The report
applies to all digital equipment that uses software and, in particular, to microprocessor-based
systems. The report, together with the clarifications discussed in this generic letter,
represents a method acceptable to the staff for use in making a determination of whether or
not an unreviewed safety question exists with respect to 10 CFR 50.59 requirements.”
“After reviewing a number of these digital system replacements and digital equipment
failures in both nuclear and non-nuclear applications, the staff has identified potentially
safety-significant concerns pertaining to digital systems in nuclear power plants. The
concerns of the staff stem from the design characteristics specific to the new digital
electronics that could result in failure modes and system malfunctions that either were not
considered during the initial plant design or may not have been evaluated in sufficient detail
in the safety analysis report. These concerns include potential common mode failures due to
(1) the use of common software in redundant channels, (2) increased sensitivity to the effects
of electromagnetic interference, (3) the improper use and control of equipment used to
control and modify software and hardware configurations, (4) the effect that some digital
designs have on diverse trip functions, (5) improper system integration, and (6) inappropriate
commercial dedication of digital electronics.”
Joint work between the nuclear industry and the U.S. NRC resulted in methods to extend the commercial
grade dedication processes to account for the differences between traditional analog and relay equipment
and digital concerns. EPRI TR-106439 [B9] defined processes for evaluation of digital equipment, using
the four methods of EPRI NP-5652 [B3]. EPRI TR-106439[B9] was published in October 1996, submitted
for NRC review and approval, with an NRC Safety Evaluation Report (SER) issued in July 1997. This
technical report has been incorporated into NRC inspection guidance as one acceptable method for
implementing commercial grade dedication.
Methods for implementing the process defined in EPRI TR-106439 [B9] were produced in EPRI
TR-107339, [B11] published in October 1996. As a methods document, EPRI chose not to submit the
report to the NRC for review. This report provides detailed approaches for evaluation and acceptance of
software-based systems and maintenance of commercial grade dedications. Vendors working with a utility
that is an EPRI sponsor, or vendors working with EPRI can gain access to this documentation. This
documentation is not required to perform commercial grade dedication, but provides extensive guidance for
evaluation of digital I&C.
Jointly, the nuclear industry and the U.S. NRC generated additional guidance EPRI TR-107330 [B10]
provides guidance for environmental qualification and software support of the environmental qualification
process. EPRI published the report in December 1996 and the NRC published their SER in July 1998. This
report defines the tests and analyses requirements for Programmable Logic Controllers (PLCs). EPRI TR-
41
IEEE Std 7-4.3.2-2010
107330 [B10] should be used with EPRI TR-106439 [B9], which is used to evaluate the application,
platform, software tools supplied with the platform, and software tools used by the vendor to create the
platform and application support libraries. This report has been applied to other programmable devices.
Some of the guidance in this report is dated. Applying this report requires use of more current NRC
guidance on electro-magnetic compatibility qualification and IEEE guidance to correct the EPRI report’s
incorrect requirement for aging equipment for application in mild nuclear environments. Vendors working
with a utility that is an EPRI sponsor, or vendors working with EPRI can gain access to this documentation.
This documentation is not required to perform commercial grade dedication, but provides extensive
guidance generic acceptance of programmable systems and components.
With the changes to the 10 CFR 50.59 rules for licensing Changes, Test, and Experiments, EPRI and the
Nuclear Energy Institute (NEI) revised EPRI TR-102348. EPRI TR-1002833 [B6] was published in
March 2002. NRC acceptance was provided in November 2002 in NRC Regulatory Issue Summary
2002-22. The EPRI/NEI document provides suitable guidance for both designing a digital replacement and
determining whether the digital replacement can be installed under 10 CFR 50.59 without prior staff
approval and the degree to which documented evaluation is required.
The NRC has published additional guidance in NUREG-0800, “Standard Review Plan,” in Chapter 7,
“Instrumentation and Controls,” in several Branch Technical Positions (BTPs) and Regulatory Guides
(RGs).
NRC BTP 7-14, “Guidance on Software Review for Digital Computer-Based Instrumentation and Control
Systems,” states:
“Commercial-off-the-shelf software and software embedded in commercial-off-the-shelf

components, such as meters, circuit breakers, or alarm modules, should be appropriately
evaluated to confirm that required characteristics are met.”
NRC BTP 7-18, “Guidance on the Use of Programmable Logic Controllers in Digital Computer-Based
Instrumentation and Control Systems,” states:
“The purpose of this BTP is to provide guidance for NRC staff to verify conformance with
the previously cited regulatory bases and standards in the design of digital computer systems
using PLCs. This BTP has the following two objectives:
⎯ To assure that embedded and operating systems software, programming tools, and peripheral
components are reviewed, and the appropriate acceptance criteria are applied.
⎯ To assure that the PLC application software (e.g., ladder-logic software) are developed using
an appropriate software development process.”
The NRC has also recently published Inspection Procedure 43004, which contains the dedication methods
previously endorsed and adds:
“Additional considerations for dedication of” commercial-grade items (CGI) “for

applications requiring environmental or seismic qualification:
(a) Utilization of non-destructive methods to verify the critical characteristics of the item to
provide reasonable assurance that each individual commercial-grade item will perform
in the design-bass accident/even harsh environment (e.g., loss of coolant accident, high
energy line break, operating-basis earthquake, safe-shutdown earthquake). Like-for-like
replacements should demonstrate performance equal to or better than the qualified
prototype.
42
IEEE Std 7-4.3.2-2010
(b) The commercial-grade item’s safety function(s), functional performance requirements,

and success criteria determination should include design service conditions (harsh
environment, seismic).
(c) Seismic and environmental qualification should be treated as critical characteristics to be

verified.”
After 10 years of application of critical digital review techniques, EPRI published an update to the
methodology provided in EPRI TR-107339 [B11] as EPRI TR-1011710 [B7]. This handbook provides
updated design, analysis, and critical digital review guidance. The document was written by two industry
experts from Electricité de France (EdF) and a U.S. consulting firm. The handbook combines the similar
methods used in both countries for reviews of digital equipment [critical digital review and reinforced
functional qualification (QFR)], incorporating the lessons learned and best practices from both countries.
This documentation is not required to perform commercial grade dedication, but provides extensive
updated guidance for documented design analysis of digital I&C as part of commercial grade dedication.
43
IEEE Std 7-4.3.2-2010
Annex D
(informative)
Identification and resolution of hazards
D.1 Background
Computer development requires identification of hazards (i.e., abnormal conditions and events) that have
the potential for defeating a safety function. A hazard is a condition that is a prerequisite to an accident.
Hazards include external events as well as conditions internal to the computer hardware or software. This
annex provides guidance for identifying, evaluating, and resolving hazards. It presents a brief discussion on
the use of fault tree analysis (FTA), failure modes and effects analysis (FMEA), and an adaptation of the
concepts presented in IEEE Std 1228™-1994 [B24] and MIL-Std-882B [B27] in the form of considerations
that might be used during the design process. The concepts from these standards include various design
analyses and checklist issues. Additionally, this annex presents guidelines for the resolution of hazards
once they are identified. Identified hazards should serve as input to appropriate V&V activities (see 5.3.3)
and reliability calculations.
One method of determining hazards is through the use of analysis techniques such as FTA and FMEA.
IEEE Std 603-2009 (5.15 through reference to IEEE Std 352™-1987 [B15]) suggests using an FMEA for
performing reliability analyses. These techniques can be useful for identifying potential hazards. IEEE Std
1228-1994 [B24], and MIL-Std-882B [B27], identify a different technique for identifying hazards. This
technique is one that attempts to identify the introduction of hazards during the design process.
D.2 Discussion
Hazards can result from system considerations (design bases conditions, failure modes of system com-
ponents, human error, etc.), or from the specific design and implementation interactions (subsystem
interface incompatibility, buffer overflows, input/output timing, initiation states, out-of-sequence events,
etc.). Design and V&V activities should provide adequate confidence that the identified hazards have been
appropriately addressed.
Subclause 5.5.1 requires consideration of hazards that have significant potential for adversely affecting
computer hardware or software elements that are essential for performing safety functions. The significance
of a hazard is based upon the probability of occurrence and the consequences of the occurrence. Only those
events that produce consequences that could defeat required safety functions should be considered. Either
quantitative or qualitative judgment of the probability of occurrence should be sufficient to determine if fur-
ther action is required. Only those conditions with significant consequences and significant probability of
occurrence need to be resolved in the design process. The conditions considered and the basis for signifi-
cance determination should be documented. This annex does not supersede the requirements of IEEE Std
603-2009.
D.3 Purpose of hazard analysis
The purpose of a hazard analysis is to explore and identify conditions that are not identified by the normal
design review and testing process. The normal design verification and validation process confirms that the
design requirements are met by the safety system. Normally this process will evaluate different combina-
tions of failures as required by the plant design basis and the effect of failures on the system. The scope of
hazard analysis extends beyond plant design basis events by including abnormal events and plant
44
IEEE Std 7-4.3.2-2010
operations with degraded equipment and plant systems. Hazard analysis focuses on system failure
mechanisms rather than verifying correct system operation. The critical failure modes that could result in
hazards are identified and then evaluated to determine the associated risk level (e.g., high/unacceptable or
low/acceptable risk) based upon both the probability of occurrence and the consequence of occurrence. The
failure modes that are classified as having unacceptable risks can be further evaluated to determine the
causes of the specific failure modes. The probability of occurrence can be determined quantitatively or
qualitatively. Most hazard analyses should be qualitative, while a quantitative analysis can be used to
determine prioritization.
D.4 Hazard analysis implementation guidelines
The following guidelines should be considered when performing a hazard analysis:
⎯ Avoidance of hazards
⎯ Identification and evaluation of hazards
⎯ Identification of hazards throughout the system life cycle
⎯ Resolution of hazards
⎯ Evaluation of hazards in previously developed systems
⎯ Documentation of hazard analysis plans, responsibilities, and results
D.4.1 Avoidance of hazards
The following good engineering practices are normally used in the design process to reduce the number of
hazards during the system design phase:
⎯ Use of industry standards as guidelines to avoid hazards. Industry experts have developed standards
that define methods on avoiding some of the hazards that have been observed.
⎯ Use of checklists. Using technical checklists is another method of hazard avoidance. Technical
checklists are listings of known hazards or methods on how to avoid hazards. Checklists are nor-
mally developed from past hazard experiences. Because checklists may not capture all hazards,
checklists should be used to supplement a structured hazard analysis.
⎯ Use of experts in the different development areas such as software development, systems mainte-
nance, design engineering, and operations.
⎯ Use of requirements analysis can assist in the early identification of system hazards.
D.4.2 Identification and evaluation of hazards during the detailed design phase
During the detailed design phase, the system hazard analysis process should be structured to maintain a
minimal impact on system development activities (e.g., no organizational changes, minimal process
changes). Additionally, the process should be adaptable for either a life cycle or a post-design analysis.
This process should begin early in the plant upgrade process (life cycle approach) with development of a
plan describing the anticipated project-specific hazard analysis activities. Life cycle hazard analysis
processes are described in D.4.3.
45
IEEE Std 7-4.3.2-2010
D.4.2.1 Structure
To facilitate the hazard identification process, hazard identification should be an integral part of the normal
design process. Hazards identification becomes part of the life cycle process by making it part of the
normal design process in the early stages of system development as opposed to making it a back-fit process
after the system has been developed. Hazards that are identified early in a system life cycle (e.g., in the
design phase of the life cycle) can be corrected more easily and for less cost than those hazards identified in
a back-fit analysis process. The hazard identification process should use the same system development and
maintenance elements that are used during the normal design process, such as the following:
⎯ Project structure and organizations

⎯ Design verification
⎯ Review meetings
⎯ Documentation (10 CFR 50 Appendix B process) [B37]
⎯ Configuration management
⎯ Testing (factory acceptance, simulation, and post-modification testing)
⎯ Quality assurance
Life cycle hazards analyses should be designed to address changes during the development, testing, and
implementation of the system.
D.4.2.2 Planning
One may encounter resistance to hazard analyses at the beginning of system development stemming from a
desire to keep development costs as low as possible. Real and identifiable hazards do not exist at the start of
the design process, so justifying or assigning resources to the hazard analysis process can be difficult to
quantify or justify. However, as discussed in D.4.2.1 above, there are significant advantages to
incorporating hazard identification into the normal design process early on.
At the start of the design project, a hazards identification and evaluation plan should be developed that
includes the following steps:
⎯ Identify critical functions such as reactor trip, emergency coolant injection, etc.
⎯ Identify top-level undesired events (events that could lead to a loss of a critical function)
⎯ Identify organizational responsibilities
⎯ Select the techniques to be used
⎯ Identify analysis assumptions
⎯ Perform a hazards identification analysis
⎯ Evaluate identified hazards for consequences and probability of occurrence
⎯ Perform needed corrective actions and re-evaluate the impact of any changes with respect to the
critical functions
46
IEEE Std 7-4.3.2-2010
D.4.2.3 Hazards identification
The first step in the hazards identification process should be to identify the critical functions of the subject
system. A multi-discipline team approach should be used for the identification of the critical functions in all
areas of the system development process (e.g., hardware and software development, operations, design,
maintenance, and testing). Once the critical functions are identified, further analyses can be performed to
identify events that would prevent these critical functions from occurring upon demand. Hazard identifica-
tion should not rely on a single technique, but should use several different techniques during the course of
the analysis. Techniques that can be used in the identification of potential hazards include:
⎯ Preliminary hazard analysis (PHA)

⎯ Fault tree analysis and failure modes and effects analysis
⎯ System modeling
⎯ Software requirements hazard analysis
⎯ Walkthroughs (e.g., design reviews and code reviews)
⎯ Simulator/plant model testing
D.4.2.3.1 Preliminary hazard analysis
Preliminary hazard analysis (PHA) is an initial identification technique that is similar to a brainstorming
session among experts on various portions of the system. The list of critical functions and undesired
functions of the system identified during the hazards identification planning process provides a starting
point and scope of the PHA. A list of questions or a checklist can also be used to guide and focus the PHA
discussions. A key to a successful PHA is choosing the participants, who should have a variety of
backgrounds and perspectives of the system. The PHA team members could include the following:
⎯ System engineers
⎯ Design engineers
⎯ Operators
⎯ Maintenance personnel from the appropriate disciplines
⎯ Software and system developers
⎯ Probability risk assessment analysts
The listing of critical functions developed during the PHA process is used to focus on the safety significant
areas of concern. The possible failure modes of these critical functions are then determined, prioritized by
safety significance, and evaluated for probability of occurrence.
D.4.2.3.2 Fault tree analysis and failure modes and effects analysis
Fault tree analysis (FTA) and failure modes and effects analysis (FMEA) are techniques that can be used to
determine hazards. These techniques address the introduction of hazards during the design process. FTA
and FMEA are structured development methods that use the highest priority failures identified during a
PHA. FTA is a top-down approach that focuses the analysis in the specific area of the cause of a hazard. A
FMEA is a bottom-up approach that addresses a much broader area and can be evaluated against identified
hazards to identify potential causes. Suppliers may be more comfortable performing FMEAs, although
FMEAs do not address multiple failures such as common-cause failures, which should be evaluated. Both
of these techniques can be useful for the identification of potential hazards.
47
IEEE Std 7-4.3.2-2010
A technique for identifying hazards is to enumerate failures and undesired consequences and then identify
the specific system design or implementation that creates each failure or consequence. For example, an
undesired consequence might be the failure to open a valve under specified conditions. This consequence
may in turn be used as the top event in a FTA, which would then be decomposed to lower-level
intermediate events and terminated in the lowest level of design for which qualitative or quantitative
probabilities could be assessed. In this example, lower-level events might be hardware failures, operating
system failures, sensor failures, device driver failures, or faults in the application software decision logic. If
this high-level analysis identifies the software as a possible contributor to the undesired consequence, the
FTA would then be expanded into the code modules and, if necessary, lower in the software design. This
method serves as a tool to identify the most vulnerable sections of the design, which, if a design error or
random fault were to occur, would be a significant contributor to the undesirable consequence.
D.4.2.3.3 System modeling
The system modeling technique is used to identify hazards in the system design by creating and subse-
quently executing software models of the system design. With this modeling approach, abnormal
conditions can be introduced to determine the effect of the conditions on system performance.
D.4.2.3.4 Software requirements hazard analysis
This activity is similar to PHA, except the focus is on the software requirements and the interfaces between
the software and other components. Additionally, a software requirements hazard analysis checklist can be
used to identify omissions and inconsistencies in the documented software requirements. After the software
requirements hazard analysis is performed, all potential hazards should be prioritized according to their
potential affect on critical functions. If a high priority hazard directly affects the software, the hazard
should be further defined and evaluated.
D.4.2.3.5 Walkthroughs
Requirements, design, and code walkthroughs should be a part of the software development process. Walk-
throughs focus on the thorough examination of a specific portion of a system, and should involve personnel
representing diverse areas of engineering expertise. The typical focus of a walkthrough is on correctness
(e.g., confirming that the design accurately addresses the requirements allocated to it). This focus should be
extended to address hazard concerns (e.g., assuring the design does not allow the system to operate in an
undesired or unexpected way).
D.4.2.3.6 Simulator/plant model testing
Test cases can be performed by connecting the digital system to a plant simulator or a plant computer
model. During this testing, not only can the design requirements be verified but also potential hazards can
be further explored and tested for validity and system response.
D.4.2.4 Hazards evaluation
Hazards evaluation activities focus on assessing the credibility of potential hazards. All potential hazards
should be evaluated as early in the life cycle as possible to maximize the benefits of early hazard identifica-
tion. The following steps are recommended for hazards evaluation:
⎯ Evaluate hazard cost tradeoffs
48
IEEE Std 7-4.3.2-2010
⎯ Determine the potential effects of a hazard

⎯ Determine the category and type of hazards
⎯ Identify and evaluate the system-level impact of hazards
⎯ Determine the disposition of hazards
D.4.2.4.1 Evaluate hazard cost tradeoffs
The analyst should determine whether it is more efficient to eliminate a potential hazard than to evaluate
whether the hazard poses a significant risk to the system.
D.4.2.4.2 Determine the potential effects of a hazard
There are two parts to establishing the potential effects of a hazard. Once a potential hazard has been identi-
fied, the analyst should determine if the system is capable of producing the hazard. The analyst should then
assess the possibility of an error or fault occurring as a result of the hazard. The results of a FTA could then
be used to determine the relative importance of each hazard. This can be done by evaluating the proba-
bilities of the minimal probability risk analysis cut sets or the sizes of the cut sets (see IEEE Std 352-1987
[B15]). If the probability of a fault or error is acceptably low for the occurrence of the undesirable conse-
quence, no further action should be required. If not, a design change might be required or a safety
evaluation of the total system may be needed.
Secondly, the analyst should determine (qualitatively or quantitatively) the probability that the potential
hazard will occur in an operational situation. This may require reliability data for hardware components.
For software, this may involve an estimate of the probability that the software will be subjected to
conditions or inputs that could cause the hazard to occur.
D.4.2.4.3 Determine the category and type of hazards
The hazards analyst should determine in which of the following categories the hazard originated:
⎯ Hardware only
⎯ Software only
⎯ Both hardware and software (i.e., a system level problem)
⎯ System development environment (e.g., faulty diagnostic equipment that results in an inaccurate
hazard identification)
For root-cause determination, the analyst should also determine the development phase during which the
hazard was incorporated into the system. For example, a hazard identified during the hardware implementa-
tion phase may actually trace to a problem in the hardware design, which may trace to a problem in the
hardware requirements specification. In this example, the type of hazard is a requirements hazard. Other
types of hazards include design, implementation, test, installation, maintenance and operation hazards. This
information can be used to identify appropriate personnel for resolution of the hazard. Records of the types
of hazards can be compared to identify weaknesses in the development process.
49
IEEE Std 7-4.3.2-2010
D.4.2.4.4 Identify and evaluate the system-level impact of hazards
The system-level impact of a hazard may be subtle, such as the display of an erroneous value that subse-
quently causes an operator to take an inappropriate action. Conversely, the hazard may be more obvious,
such as causing the system to fail at an inappropriate time. Alternatively, higher-level logic or interlocks
may prevent a potential hazard from having an undesired effect. The system level impact can be determined
using an informal general analysis, or as part of an FMEA. Functional FTA may also be useful. Potential
hazards should be prioritized based on a comparison and evaluation of system-level impacts. For example,
a single random failure of a hardware module that causes an undesirable consequence for any single
computer may be acceptable in a system design that has sufficient redundancy. Another example is the use
of diversity and defense in depth to compensate for common-mode software vulnerability. The effect of the
hazard on the overall system can be used to prioritize hazards.
D.4.2.4.5 Determine the disposition of hazards
Dispositioning a hazard requires confirmation that the hazard exists and actions to mitigate or remove the
hazard. The system developer should evaluate the system-level impact and credibility of the hazard and
determine whether the hazard should be withdrawn or confirmed. Several methods are used to address haz-
ards such as elimination, reduction of exposure, and controlling or minimizing the effects of a hazard. If
eliminating a hazard is not cost beneficial, then the hazard should be addressed by redesigning the system.
Controlling the hazard should not be the responsibility of the nuclear plant operator. The hazard analysis
should be revised to address design changes to identify newly created hazards.
D.4.3 Identification of hazards throughout the system life cycle
The following sections provide specific guidance for evaluating hazards throughout the system life cycle.
D.4.3.1 Safety system hazards identification
The safety system hazards identification process begins with an understanding of the required safety func-
tions, design basis conditions, selected system design elements (subsystems, diverse systems, etc.), and
regulatory requirements.
The process should consider the following:
⎯ Occurrence of design basis conditions identified in the plant safety analysis report
⎯ Possible independent, dependent, and simultaneous hazards events considering failures of safety
equipment, including power supplies and common-cause conditions that could create a hazard
⎯ Interface considerations among various elements of the system, (e.g., electromagnetic interference,
inadvertent actuations of hardware and software controls). This should include consideration of the
potential contribution by software (including software developed by others) to subsystem/system
mishaps. Safety design criteria to control safety software commands and responses (e.g.,
inadvertent command, failure to command, untimely command or responses, or undesired events)
should be identified and appropriate action taken to incorporate the safety design criteria in the
software (and related hardware) specifications.
⎯ Environmental constraints including the operating environments (e.g., seismic, temperature, rapid
temperature changes, noise, exposure to foreign substances, fire, electrostatic discharge, lightning,
electromagnetic environmental effects, and radiation)
50
IEEE Std 7-4.3.2-2010
⎯ Operating, test, maintenance, and emergency procedures (e.g., human factors engineering; human
error analysis of operator functions, tasks, and requirements; effects of factors such as equipment
layout, lighting requirements; effects of noise or elevated temperature)
⎯ Design and use of test and maintenance equipment that has the potential for introducing faults and
software errors
⎯ Safety equipment design and possible alternate approaches (e.g., interlocks, system redundancy,
hardware or software fail safe design considerations, and subsystem protection)
⎯ Degradation in a system caused by the operation of another subsystem (including non-safety
systems)
⎯ Modes of failure, including reasonable human errors as well as single point failures, and hazards
created when failures occur in subsystem components
⎯ Potential contribution of software (including software that is developed by others), events, faults,
and occurrences (such as improper timing) on safety of the system
⎯ Potential common-mode failures
⎯ The method of implementing the software design requirements and corrective actions that could
impair or degrade the safety system or introduce new hazards
⎯ The method of controlling design changes during and after system acceptance to confirm that the
safety system is not degraded and new hazards are not created
D.4.3.2 Computer hazards identification
As a result of the safety system analysis, certain safety functions, design conditions, limitations, and unre-
solved hazards may be identified for the computer system. The computer system design should specify
those functions that will be required of the hardware or software to a) prevent the system from entering a
hazards state, or b) move the system from a hazards state to a non-hazards state. Additionally, the interfaces
between the software and the computer system should be identified and specified. Identification of
computer-level hazards should consider items similar to those described in D.4.3.1, except the focus should
be on the conceptual design of the hardware and software. Additionally, the following should be considered
as potential hazards:
a) Interdependencies between hardware and software such as interrupts and the operating system
b) Sequences of actions that can cause the system to enter a hazard state
c) System-specific credible hazards, such as the following:
⎯ Early or late outputs
⎯ Sensor input processing failures
⎯ recision or round-off problems
⎯ Improper handling of exceptions
⎯ Recovery actions
⎯ System interrupts
⎯ Electrical input voltage and frequency fluctuations
⎯ Maximum credible number of coincident signal changes
⎯ Electromagnetic interference
⎯ Out-of-range values (e.g., dividing by zero or non-initialized pointers)
51
IEEE Std 7-4.3.2-2010
D.4.3.3 Software requirements hazards identification
The software requirements hazards identification process evaluates software and interface requirements and
identifies errors and deficiencies that could contribute to a hazard. The compatibility of software require-
ments with the hardware design should be an underlying issue in the performance of software requirements
hazards identification, which include the following activities:
a) Software requirements should be evaluated to identify those that are essential to accomplishing the
safety function (i.e., critical requirements). These critical requirements should be evaluated to
assess the significance of hazard conditions.
b) Timing and size requirements should ensure adequate resources for execution time, clock time, and
memory allocation are provided to support the critical requirements, including maximum loading
under worst-case conditions.
c) In designs involving the integration of multiple software systems, consideration should be given for
interdependencies and interactions between the components of the systems.
d) Existing software should be evaluated to provide reasonable assurance that no “unintended
functions” detrimental to the operation of the safety system are introduced. Possible interpretations
of unintended functions include:
⎯ Unused resident functions. The design process should address any unused resident functions.
In some cases, such as for operating systems and compilers, the V&V process is unsuitable
for addressing unused resident functions as the total number may be unknown.
⎯ Unpredictable responses to external or internal conditions. A documented effort to identify
unpredictable responses to external or internal conditions should be made during the design
process, and appropriate actions should be taken to resolve these hazards. The V&V process
should then confirm proper response to these hazards.
⎯ Defects due to design or implementation errors. The V&V process should address defects due
to design or implementation errors.
⎯ Development aids not removed from the software. A documented decision should be made to
state whether development aids will remain in the software. If the decision is made to leave
the development aids in the software, they could be left active or made inactive. In either case,
if development aids are to remain in the software, V&V activities should be performed.
D.4.3.4 Software design hazards identification
Software design hazards identification consists of activities that provide adequate confidence that no new
hazards are introduced. Potential computational problems, including incorrect equations, insufficient preci-
sion, scan rate, and sign convention faults should be evaluated. Equations, algorithms, and control logic
should be evaluated for potential problems including the following:
⎯ Logic errors
⎯ Cases or steps that have not been addressed
⎯ Duplicate logic
⎯ Extreme conditions neglected
⎯ Unnecessary functions
⎯ Misinterpretation of requirements
⎯ Missing condition tests
52
IEEE Std 7-4.3.2-2010
⎯ Checking wrong variable

⎯ Incorrect loop iterations
Evaluation of data structures and their intended use should be performed for data dependencies that circum-
vent isolation partitioning, data aliasing, and fault containment issues affecting safety and the control or
mitigation of hazards. Potential data handling problems, including incorrect initialized data, accessed or
stored data, scaling or units of data, dimensioned data, and scope of data should be evaluated.
Interface design considerations, including internal and external interfaces with other modules of the system,
should be reviewed. The major areas of concern with interfaces are properly defined protocols, and control
and data linkages. External interfaces should be evaluated to verify that communication protocols in the
design are compatible with interfacing requirements. The interfaces evaluation should support claims of
redundancy management partitioning, and hazards containment. Potential interface and timing problems
include interfaces addressed incorrectly, incorrect input and output timing, and subroutine/module mis-
matches.
Confirm that the design is enveloped within the identified system constraints. The impacts of the physical
environment on this hazard analysis can include such items as the location and relation of high-frequency
clocks to circuit cards and the timing of bus latches when using the longest safety timing constraints to
fetch data from the most remote circuit card.
Software modules that implement critical functions should be identified. Potential problems may occur in
interfacing and communicating data to other modules, incompatibility of word format or data structure,
synchronization with other modules for purposes of data sharing, etc. Additionally, non-safety modules
should be evaluated to confirm that they do not adversely affect safety software.
D.4.3.5 Software implementation hazards identification
Hazards can be created during the software implementation life cycle phase. The following activities
should be performed during software implementation:
⎯ Evaluate equations, algorithms, and control logic for potential problems including logic errors,
omitted cases or steps, duplicate logic, omission of extreme conditions, unnecessary functions, mis-
interpretation of requirements, missing condition tests, variables not checked, and incorrect
iteration of loops.
⎯ Confirm the correctness of algorithms including accuracy, precision, and equation discontinuities,
out of range conditions, breakpoints, erroneous inputs, scan rates, etc.
⎯ Evaluate the data structure and usage in the code to confirm the data items are defined and used
properly.
⎯ Confirm interface compatibility of software modules with external hardware and software.
⎯ Confirm the software operates within the constraints imposed upon it by the requirements, the
design, and the target computer system.
⎯ Examine non-critical code to confirm the code does not adversely affect the function of critical
software.
⎯ Verify the software code is within timing and sizing constants.
⎯ Verify the use of good software practices such as limits on code size, avoidance of multi-use regis-
ters, control of reusable code, initialization of code, etc.
53
IEEE Std 7-4.3.2-2010
D.4.3.6 Computer system integration testing for hazards conditions
Computer integration testing verifies that hazards requirements (e.g., inhibits, traps, and interlocks) have
been correctly implemented. This testing verifies the software functions properly within its specified
environment. This testing should occur as an inherent part of testing activities performed during computer
development. The following activities should be performed during computer system integration testing:
⎯ Computer software unit level testing to verify correct execution of safety software elements
⎯ Interface testing to verify safety software units operate as expected
⎯ Computer software configuration item testing to verify the execution of the software as a unit
⎯ System-level testing to verify software performance within the overall system
⎯ Stress testing to verify the software will not cause a hazard under abnormal circumstances, such as
unexpected input values
D.4.3.7 Computer system validation testing
Tests similar to those described in D.4.3.6 should be performed on the software operating in the final hard-
ware configuration as part of the overall V&V process to provide reasonable assurance that identified
hazards have been addressed.
Software FTA (see D.4.2.3.2) can be useful for identifying software faults that could cause the loss of a
safety function, or to validate that such faults do not exist.
D.4.3.8 Maintenance and modification hazard analysis
Consideration should be given to identification of hazards that could be introduced as a result of mainte-
nance and modifications made after system acceptance. The extent of the analysis is determined by the
scope of the maintenance and modification. Guidelines from D.4.4 should be followed to address these
hazards.
D.4.4 General guidelines for hazards resolution
Computer-based safety systems consist of hardware and software components whose functions are essential
to accomplishing safety functions. Additionally, the computer system may contain components that are not
essential to accomplishing safety functions (e.g., self-tests). The focus of hazards identification and resolu-
tion is to confirm that the safety functions are protected from identified hazards, and that nonsafety
functions do not create hazards for the safety functions when the nonsafety components are subjected to
identified hazards. The following general guidelines should be addressed:
⎯ Identify, evaluate, and eliminate hazards associated with each system throughout the entire life
cycle of the system. At each phase of the development life cycle, resolve hazards that were
unresolved in earlier phases and analyze the design existing in the current development phase to
identify new hazards.
⎯ Minimize risks resulting from excessive environmental conditions (e.g., temperature, pressure, seis-
mic, vibration humidity, radiation, and electromagnetic interference).
⎯ Address in the system design risks created by human errors in the operation and support of the
system.
54
IEEE Std 7-4.3.2-2010
⎯ Create unambiguous requirements definitions to minimize the probability of misinterpretation by

developers. Potential problems include ambiguous statements, unspecified conditions, precision
requirements not defined, response to hazards not defined, and requirements that are: incomplete,
incorrect, conflicting, difficult to implement, illogical, unreasonable, not verifiable, or not
achievable.
⎯ Consider and use historical hazards data, including lessons learned from other systems.
⎯ Minimize risk by using existing designs and test techniques wherever possible.
⎯ Analyze for hazards and document changes in design configuration or system requirements (see
D.4.6).
⎯ Document identified hazards and their resolution (i.e., design changes or determination of no
further action) (see D.4.6).
Once a hazard is identified, the resolution of the hazard should be addressed. The following guidelines for
resolving identified hazards should be addressed:
⎯ Eliminate identified hazards or reduce the associated risk through design, if possible.
⎯ If an identified hazard cannot be eliminated by changing the system design, reduce the associated
risk to an acceptable level by adding safety devices.
⎯ When neither design nor safety devices can effectively eliminate an identified hazard or adequately
reduce the associated risk, devices should be used to detect the condition and to produce an
adequate warning signal to alert personnel of the hazard. Warning signals and their application
should be designed to minimize the probability of incorrect personnel reaction to the signals and
should be standardized within like types of systems.
⎯ Where it is impractical to eliminate hazards through design selection or adequately reduce the
associated risk with safety and warning devices, develop procedures and training to address
reactions to the occurrence of the hazard.
D.4.5 Evaluation of hazards in previously developed systems
Previously developed computers, hardware, or software components of developed systems may be used in
the design of safety systems. Subclause 5.17 requires that previously developed systems be qualified using
a commercial grade item dedication process. Annex C provides guidance for commercial grade item
dedication, including consideration of hardware, software, or firmware failures (i.e., hazards that could
interfere with accomplishing the safety function). The guidelines of D.4.3 and D.4.4 should be applied to
the extent possible, realizing that extensive software design hazards identification and software code
hazards identification may not be achievable or necessary.
D.4.6 Documentation of hazard analysis plans, responsibilities, and results
Documentation of hazard analysis plans, responsibilities, and results is important to ensure that these activi-
ties are conducted in an orderly manner and the results are auditable. The activities described in this annex
should be integrated into the computer development process. The activities may be documented in those
documents that govern and record the development process possible in the form of a checklist. A separate
set of documents is not recommended.
D.4.7 Preliminary hazard analysis questions
The following example questions provide guidance for conducting a hazards analysis:
55
IEEE Std 7-4.3.2-2010
1) How could the system malfunction in a way that will create a significant economic liability?
2) How could the system malfunction in a way that would defeat the safety function?
3) Does the way the user will interact with the new system differ significantly or subtly from the
way the user interacts with the existing system?
4) What would happen if the operator followed the old procedures while using the new system?
5) What would happen if a maintenance technician followed the old procedures while using the
new system?
6) What would happen if a maintenance technician made online changes to the system?
7) Are the system inputs and outputs incompatible (electrically and mechanically) with the
corresponding plant interfaces (i.e., is there an interface problem)?
8) Is there any potential failure of the system (especially a failure that causes a system lock-up)
that is not obviously indicated to the operator?
9) Are bus contentions and timing problems possible under any operating conditions (within the
operations environment specified in the requirements specification)?
10) Are the new operations, maintenance, or training procedures incompatible with the current
procedures? (Will the plant personnel have a problem knowing what to do with the new
system?)
11) Is there a potential for new system test procedures to introduce new hazards into the system
(e.g., a test that leaves a safety system function inhibited after the test is completed)?
12) Are the system self-diagnostics active or passive? How do the self-diagnostics affect the
system?
13) Does the system have hardware or software interrupts? If it does, how do they affect the
system? Are unused hardware interrupts tied to a reference potential such as ground or are
they left floating, which could result in a system failure?
NOTE—Independence and peer review are important for completeness, so completing this checklist should be a team
activity.
56
IEEE Std 7-4.3.2-2010
Annex E
(informative)
Communication independence
E.1 Background
Communications independence between separate divisions of a safety system and communications

independence of the safety system from non-safety systems is required to mitigate the risk of safety system
failure during a design basis event. The level of independence mandated by this standard is intended to
minimize the risk of data corruption resulting from outside system (i.e., non-safety system) failures, or
failure of an individual safety division propagating to other safety divisions causing the failure of the entire
safety system. The communication methods described below are intended to mitigate the risk of a common
cause failure.
There are four categories of communications relevant to discuss and they include communications between
safety and non-safety computers versus communications between safety computers contained in separate
divisions of the safety system and whether the method of communication is two-way or unidirectional. The
methods of communication in each category allow varying functionality for system architectures. However,
the licensing review of the communication methods of the different categories will differ drastically.
Licensing reviews of unidirectional communication usually entail insuring that the implementation is truly
unidirectional. A licensing review of an architecture containing two-way communication between safety
computers in separate safety divisions would require much greater scrutiny to insure that all requirements
were identified and met. As such the digital safety system architect should balance the improved
functionality, availability, maintainability, etc. of the proposed system that would require a more risk
inherent communication method with the ease of license approval of the communication system design.
E.2 Discussion
E.2.1 Communication between safety and non-safety computers
Communication between safety and non-safety computers may be desired for purposes of installation of
approved setpoint changes, installation of approved safety software upgrades, data collection, or other
reasons. However, at no time should the safety computer require input from the non-safety computer in
order to perform its safety function. The following figures depict ways communication between safety and
non-safety computers can be accomplished.
E.2.1.1 Unidirectional communication from safety to non-safety computers
Figure E.1 graphically shows a broadcast communication from the safety computer to the non-safety
computer. Use of this method of communication may be utilized in data logging or remote display
applications.
57
IEEE Std 7-4.3.2-2010
Figure E.1—Communication between safety and non-safety computers (one-way

communication)
The one-way communication path provides for communication isolation. Communication isolation is a
functional separation within the safety system such that the safety-critical functions are not adversely
impaired by faults and failures in the safety system’s communication processor, functions, and/or
interfaces. The physical link(s) between computers might provide both electrical and communications
isolation as required. Electrical isolation may be accomplished optically (i.e., fiber-optic cable or optical
isolators) or by more traditional electrical isolation (i.e., fuses and surge suppressors). Communications
isolation is provided through the broadcast communication path. This broadcast path is completely
unidirectional such that either connecting or disconnecting the communications path at any time has no
negative effect on the safety computer. There should be no resolution of MAC or IP addresses required by
the safety system. The protocol should have no handshaking, ready to receive or improper receipt of
message response from the non-safety computer. Furthermore, these signals should be physically prevented
from being transmitted to the safety computer (i.e., a dual fiber communication channel with the receive
connection on the safety computer removed or the receive connection on an RS-232 port removed on the
safety computer). In this method of communication, the safety computer transmits the required data
regardless of whether the non-safety computer is physically connected or disconnected since there is no
method for information about the connection status to be conveyed to the safety computer.
E.2.1.2 Two-way communication between safety and non-safety computers
Figure E.2 depicts a method with two separate points of isolation, one electrical and one communications.
This method allows two-way communication between the safety computer and the non-safety computer,
and uses a dual-ported random access memory (DPRAM) and a communications controller/processor as a
buffering circuit in the safety computer. Use of this method may be necessary when a separate non-safety
workstation is used to alter approved addressable parameters or setpoints while the computer in the
attached safety division is performing its safety function. This method may be used when a separate
computer is used for test and calibration purposes while the safety computer is not performing its safety
function (i.e., in maintenance bypass or out of service).
58
IEEE Std 7-4.3.2-2010
Figure E.2—Communication between safety and non-safety computers (dual one-way

communication)
The dual-ported memory and communications controller perform the buffering function, providing an
interface preventing the non-safety computer from inhibiting or delaying the safety function. The
Communications Controller/Processor receives the data transmitted from the non-safety computer, parses it
and performs error checking in accordance with its communications protocol. If the message meets all the
checks required of the defined protocol including but not limited to the checks in 5.6.4.2 item j), then the
Communications Controller/Processor writes the data to the appropriate predetermined location in the dual-
ported memory. The Buffering Function of the Communications Controller/Processor and the Dual-ported
Memory protects the Processor Performing the Safety Function from the effects of message corruption and
from the effects of malfunctions of the non-safety computer.
The Communications Controller/Processor and the Processor Performing the Safety Function operate
asynchronously and if at any time during their operation they are both simultaneously addressing the dual-
ported memory, the processor performing the safety function should access the memory such that its data
transfer may occur in a manner designed and validated to not adversely affect the safety function (e.g., the
worst case transfer time is included in the cycle time requirement).deterministic fashion. Before the safety
division utilizes the data received from the non-safety computer in its safety function, that data should be
verified and enabled. This enablement could occur by manual operator verification and then operator
acceptance or could occur by automated logic checks and validation within the safety division.
The outgoing communication (i.e., from safety computer to non-safety computer) can simply be data for
collection or could be the transmitted handshakes or message not received signals from the safety
processor. This method of communications could be used while the associated safety division is offline
(e.g., in maintenance bypass) or when the associated safety division is performing its safety function (e.g.,
online, operational and not in maintenance bypass). If the system design allows data to be received by the
processor performing the safety function while that processor is online (e.g., operational and not in
maintenance bypass), then the safety algorithm should either query the dual-ported memory every logic
cycle to insure deterministic system operation or assume the worst case logic path, which probably assumes
receipt and processing of data from the non-safety computer, when determining the system response time.
The same hardware/software development procedures, testing and V&V activities should be used to
develop safety functional processor/code, the output communication circuit/code and the circuits and
software performing the buffering function in the safety system.
Per 5.6, the safety system shall be designed such that no input from non-safety systems is required for the
safety system to perform its safety functions. In architectures allowing communication from non-safety
computers to the safety computer while the safety computer is performing its safety function (e.g., online
and not in maintenance bypass), message loss/corruptions, data errors, or malicious failures of the non-
safety computer should be assumed in the system design and the logic of the safety function should proceed
without an adverse effect. It the error can not be resolved (e.g., the data cannot be recovered through error
correction or the message cannot be resent in a sufficiently timely fashion), then the safety system should
execute the conservative decision.
59
IEEE Std 7-4.3.2-2010
The key lock switch shown above is used to physically prohibit the non-safety computer from transmitting
to more than a single safety division at one time.
Figure E.3 depicts a second method with two separate points of isolation, one electrical and one
communications. This method allows two-way communication between the safety computer and the non-
safety computer, and uses a separate Communication Module including a communication controller and
DPRAM as a buffering circuit. Use of this method may be either required or utilized in a similar fashion to
the system shown in Figure E.4.
Figure E.3—Communication between safety and non-safety computers
Messages from the non-safety Gateway Computer are transmitted to the Communication Module where all
handshaking and address resolution occurs in the communication controller. The communication controller
also performs the required error checking, timeliness verification and message validation of the
communications protocol before loading the parsed data into the dual-ported random access memory
(DPRAM). The processor in the Function Computer executes the code that determines the need for a safety
trip and loads the required data from the DPRAM to the input buffers for use in the logic state
determination (e.g., whether a trip or actuation is required). In this architecture similar to the design above,
the processor in the Function Computer is protected from data overruns, data bursts and other
communication errors by the communication controller. Any output data from the Function Computer is
written to the predetermined locations in the DPRAM for use or transmission by the Communication
Controller.
E.2.2 Communication between computers in different safety divisions
Communication between computers in different safety divisions may be desired for purposes of improved
overall system availability, ease of maintenance and enhanced capabilities for system monitoring.
However, when determining a particular computer architecture for a digital safety system, these possible
advantages should be weighted against the increased software complexity required to mitigate the risk of
reduced independence and the increased risk of propagating software failure. Because of these risks,
architectures utilizing communication across safety divisions incur increased scrutiny in the licensing
60
IEEE Std 7-4.3.2-2010
phase. The underlying premise with communications between computers in different safety divisions is that
there should be no detrimental effect on the safety division in question due to any failure or error in
communications either from or to another division.
E.2.2.1 Unidirectional communication between computers in different safety divisions
Figure E.4 graphically shows a broadcast communication from the safety computer in one safety division to
a safety computer in a second division. Use of this method of communication may be utilized in a
watchdog timer check where a stay-alive/status message from one division is transmitted to the second
division for monitoring.
Safety copper Optical Optical copper Safety

Computer cable Isolator Isolator cable Computer
Division X Division Y
Figure E.4—Communication between safety divisions (one-way communication)
The one-way communication path provides for communication isolation. The physical link(s) between
computers would provide electrical isolation as required. Electrical isolation may be accomplished optically
(i.e., fiber optic cable or optical isolators) or by more traditional electrical isolation (i.e., fuses and surge
suppressors). Communications isolation is provided through the broadcast communication path. This
broadcast path is completely unidirectional such that either connecting or disconnecting the
communications path at any time has no negative effect on the transmitting safety computer. There should
be no resolution of MAC or IP addresses required by the protocol. The protocol should have no
handshaking, ready to receive, improper receipt of message response or similar signals required by the
transmitting computer. In this method of communication, the transmitting safety computer transmits data
regardless of whether the receiving computer is physically connected or disconnected since there is no
method for information about the connection status to be conveyed to the transmitting computer.
The unidirectional broadcast method of communications provides communication isolation for the safety
computer in the division transmitting the message. A buffering circuit in the division receiving the
communication would provide communication isolation for that division. A dual-ported memory and
communications controller could perform the buffering function and thus provide an interface preventing
the incoming communication from inhibiting or delaying the safety function of the receiving division. The
Communications Controller/Processor receives the data, parses it and performs error checking in
accordance with the communications protocol. If the message meets all the checks required of the defined
protocol including but not limited to the checks in 5.6.4.2 item h), then the Communications
Controller/Processor writes the data to the appropriate predetermined location in the dual-ported memory.
The Buffering Function of the Communications Controller/Processor and the Dual-ported Memory protect
the Processor Performing the Safety Function from the affects of message corruption and from the affects
of malfunctions or failures of the transmitting computer and the communications channel. The
Communications Controller/Processor and the Processor Performing the Safety Function should operate
transfer may occur in a deterministic fashion.
The algorithms of the safety processor should address required conservative system responses in the event
of communication malfunctions and failures (i.e., what actions to take in the event of data errors or loss of
communication).
61
IEEE Std 7-4.3.2-2010
Figure E.5 shows an example of an architecture where the computer in safety division A is using a
unidirectional communication mode to transmit information to the computer in safety division B, while
simultaneously the computer in safety division B is using a unidirectional communication mode to transmit
information to the computer in safety division A. Physically this architecture could be dual examples of
unidirectional communication or could be two-way communication. An architecture utilizing dual
examples of unidirectional communication is different from two-way communication between computers in
different safety divisions only in the use of the information transmitted. For this architecture to be
considered unidirectional from each safety division, there should not be any acknowledge or handshake
signals in the communications protocol. Furthermore, the information transmitted from the outside division
should not be required by the receiving division in its determination of the safety state (i.e., whether to
initiate a trip or not). Due to the increased risk of a propagating failure between computers in different
safety divisions and due to the software complexity required to insure information independence, this
architecture would most likely require significantly more verification and testing effort on the design
agency and would require considerably more review by the regulator.
Figure E.5—Communication between computers in different safety divisions using dual

unidirectional communication
E.2.2.2 Two-way communication between computers in different safety divisions
Figure E.6 graphically shows two-way communication between computers in different safety divisions
(i.e., communication in which the transmitter is dependent on the presence of the receiver). This method of
communication may be used to increase the availability of the safety system by validating a detector input
via comparisons to the inputs to the other safety divisions. Two-way communication between computers in
different safety divisions is the most complicated of these methods and it carries the most risk to the safety
system in total.
62
IEEE Std 7-4.3.2-2010
Figure E.6—Communication between safety channels (two-way communication)
As shown in this graphic this method of communication requires a buffering circuit in both divisions. These
buffering circuits are analogous to the circuits described in E.2.1.2 and use a Communications
Controller/Processor to perform the actual transmission, receipt and validation of data. The
Communications Controller/Processor then writes the data to the appropriate predetermined location in the
dual-ported memory. The Buffering Function of the Communications Controller/Processor and the Dual-
ported Memory protects the Processor Performing the Safety Function from the affects of message
corruption.
The Communications Controller/Processor and the Processor Performing the Safety Function operate
transfer may occur in a deterministic fashion.
In this example, the division assignment for the fiber optic cable could be A or B as long as the single
failure criterion is satisfied. Fiber optic cables should be assigned to divisions in a consistent manner.
E.2.2.3 Communication between computers in multiple safety division
Architectures utilizing a central hub or router where communications from multiple safety division are
transmitted across a single channel should not be used.
63
IEEE Std 7-4.3.2-2010
Annex F
(informative)
Computer reliability
This annex has been deleted because various regulatory and industry efforts are underway to determine the
methodologies for establishing computer reliability. The material in this annex therefore may become
obsolete in its current form. This annex will be reinstated in a future edition of this standard.
64
IEEE Std 7-4.3.2-2010
Annex G
(informative)
Glossary
application software: Software designed to fulfill specific needs of a user; for example, software for
navigation, payroll, or process control. (The IEEE Standards Dictionary: Glossary of Terms & Definitions,
IEEE Std 610.12-1990 [B19] )
architecture: The organizational structure of a system or component. (The IEEE Standards Dictionary:
Glossary of Terms & Definitions, IEEE Std 610.12-1990 [B19])
channel: An arrangement of components and modules as required to generate a single protective action
signal when required by a generating station condition. A channel loses its identity where single protective
action signals are combined. (IEEE Std 603-2009)
common cause failure: Loss of function to multiple structures, systems, or components due to a shared
root cause. (IEEE Std 603-2009). Multiple failures of structures, systems, or components as a result of a
single phenomenon. (IEEE Std 497™-2002 [B18]) Multiple failures attributable to a common cause. (IEEE
Std 379-2000 [B16])
complexity: (A) The degree to which a system or system component has a design or implementation that is
difficult to understand and verify. (B) Pertaining to any set of structure-based metrics that measure the
attribute in definition (A). (The IEEE Standards Dictionary: Glossary of Terms & Definitions, IEEE Std
610.12-1990 [B19])
component: One of the parts that make up a system. A component may be hardware or software and may
be subdivided into other components. (The IEEE Standards Dictionary: Glossary of Terms & Definitions,
IEEE Std 610.12-1990 [B19])
NOTE—The terms “module,” “component,” and “unit” are often used interchangeably or defined to be supplements of
one another in different ways dependent upon the context. The relationship of these terms is not yet standardized.
computer: A functional programmable unit that consists of one or more associated processing units and
peripheral equipment, that is controlled by internally stored programs, and that can perform substantial
computation, including numerous arithmetic or logic operations, without human intervention. (The IEEE
Standards Dictionary: Glossary of Terms & Definitions.)
computer instruction: (A) A statement in a programming language, specifying an operation to be per-

formed by a computer and the addresses or values of the associated operands; for example, Move A to B.
(B) Loosely, any executable statement in a computer program. (The IEEE Standards Dictionary: Glossary
of Terms & Definitions, IEEE Std 610.12-1990 [B19])
computer program: A combination of computer instructions and data definitions that enable computer
hardware to perform computational or control functions. (The IEEE Standards Dictionary: Glossary of
Terms & Definitions, IEEE Std 610.12-1990 [B19])
computer system: A system containing one or more computers and associated software. (The IEEE
Standards Dictionary: Glossary of Terms & Definitions, IEEE Std 610.12-1990 [B19])
65
IEEE Std 7-4.3.2-2010
correctness: (A) The degree to which a system or component is free from faults in its specification, design,
and implementation. (B) The degree to which software, documentation, or other items meet the specified
requirements. (C) The degree to which software, documentation, or other items meet user needs and
expectations, whether specified or not. (The IEEE Standards Dictionary: Glossary of Terms & Definitions,
IEEE Std 610.12-1990 [B19])
data: A representation of facts, concepts, or instructions in a manner suitable for communication,

interpretation, or processing by humans or by automatic means.
data structure: A physical or logical relationship among data elements, designed to support specific data
manipulation functions. (The IEEE Standards Dictionary: Glossary of Terms & Definitions)
design: (A)The process of defining the architecture, components, interfaces, and other characteristics of a
system or component. (B) The result of the process in definition (A). (The IEEE Standards Dictionary:
division: The designation applied to a given system or set of components that enables the establishment
and maintenance of physical, electrical, and functional independence from other redundant sets of
components.
NOTE—A division can have one or more channels. (IEEE Std 603-2009)
document: (A) A medium and the information recorded on it, that generally has permanence and can be
read by a person or a machine. Examples in software engineering include project plans, specifications, test
plans, user manuals. (B) To create a document as in definition (A). (C) To add comments to a computer
program. (The IEEE Standards Dictionary: Glossary of Terms & Definitions, IEEE Std 610.12-1990
[B19])
documentation: (A) A collection of documents on a given subject. (B) Any written or pictorial infor-
mation describing, defining, specifying, reporting or certifying activities, requirements, procedures, or
results. (C) The process of generating or revising a document. (D) The management of documents,
including identification, acquisition, processing, storage, and dissemination. (The IEEE Standards
Dictionary: Glossary of Terms & Definitions, IEEE Std 610.12-1990 [B19])
error: (A) The difference between a computed, observed, or measured value or condition and the true,
specified, or theoretically correct value or condition. For example, a difference of 30 meters between a
computed result and the correct result. (B) An incorrect step, process, or data definition. For example, an
incorrect instruction in a computer program. (C) An incorrect result. For example, a computed result of 12
when the correct result is 10. (D) A human action that produces an incorrect result. For example, an
incorrect action on the part of a programmer or operator. (The IEEE Standards Dictionary: Glossary of
Terms & Definitions, IEEE Std 610.12-1990 [B19])
NOTE—While all four definitions are commonly used, one distinction assigns definition (A) to the word “error,”
definition (B) to the word “fault,” definition (C) to the word “failure,” and definition (D) to the word “mistake.”
execution: The process of carrying out an instruction or the instructions of a computer program by a
computer. (The IEEE Standards Dictionary: Glossary of Terms & Definitions, IEEE Std 610.12-1990
[B19])
failure: The inability of a system or component to perform its required functions within specified per-
formance requirements. (The IEEE Standards Dictionary: Glossary of Terms & Definitions, IEEE Std
610.12-1990 [B19])
NOTE—The fault tolerance discipline distinguishes between a human action (a mistake), its manifestation (a hardware
or software fault), the result of the fault (a failure), and the amount by which the result is incorrect (the error).
66
IEEE Std 7-4.3.2-2010
fault: (A) A defect in a hardware device or component; for example, a short circuit or broken wire. (B) An
incorrect step, process, or data definition in a computer program. (The IEEE Standards Dictionary:
NOTE—This definition is used primarily by the fault tolerance discipline. In common usage, the terms “error” and
“bug” are used to express this meaning.
function: A defined objective or characteristic action of a system or component. For example, a system
may have inventory control as its primary function. (The IEEE Standards Dictionary: Glossary of Terms &
Definitions, IEEE Std 610.12-1990 [B19])
functional unit: An entity of hardware, software, or both capable of accomplishing a specified purpose.
(The IEEE Standards Dictionary: Glossary of Terms & Definitions, IEEE Std 610.12-1990 [B19])
hardware: Physical equipment used to process, store, or transmit computer programs or data. (The IEEE
Standards Dictionary: Glossary of Terms & Definitions, IEEE Std 610.12-1990 [B19])
implementation: (A) The process of translating a design into hardware components, software components,
or both. (B) The result of the process in definition (A). (The IEEE Standards Dictionary: Glossary of Terms
& Definitions, IEEE Std 610.12-1990 [B19])
interface: (A) A shared boundary across which information is passed. (B) A hardware or software
component that connects two or more other components for the purpose of passing information from one to
the other. (C) To connect two or more components for the purpose of passing information from one to the
other. (D) To serve as a connecting or connected component as in definition (B). (The IEEE Standards
Dictionary: Glossary of Terms & Definitions, IEEE Std 610.12-1990 [B19])
module: (A) A software program unit that is discrete and identifiable with respect to compiling, combining
with other units, and loading; for example, the input to, or output from an assembler, compiler, linkage edi-
tor, or executive routine. (B) A logically separable part of a software program. (C) For hardware module
see the definition for component. (The IEEE Standards Dictionary: Glossary of Terms & Definitions, IEEE
Std 610.12-1990 [B19])
procedure: (A) The course of action taken for the solution of a problem. A course of action taken to
perform a given task. (B) A written description of a course of action as in definition (A) for example, a
documented test procedure. (C) A portion of a computer program that is named and that performs a specific
action. (The IEEE Standards Dictionary: Glossary of Terms & Definitions, IEEE Std 610.12-1990 [B19])
requirement: (A) A condition or capability needed by a user to solve a problem or achieve an objective.
(B) A condition or capability that must be met or possessed by a system or system component to satisfy a
contract, standard, specification, or other formally imposed documents. (C) A documented representation
of a condition or capability as in definition (A) or definition (B). (The IEEE Standards Dictionary:
Glossary of Terms & Definitions, IEEE Std 610.12-1990 [B19], IEEE Std 1233™-1998 [B25])
requirements specification: A document that specifies the requirements for a system or component.
Typically included are functional requirements, performance requirements, interface requirements, design
requirements, and development standards. (The IEEE Standards Dictionary: Glossary of Terms &
safety system: A system that is relied upon to remain functional during and following design basis events
to ensure: a) the integrity of the reactor coolant pressure boundary, b) the capability to shut down the
reactor and maintain it in a safe shutdown condition, or c) the capability to prevent or mitigate the
consequences of accidents that could result in potential off-site exposures comparable to the 10 CFR Part
100 guidelines. (IEEE Std 603-2009)
NOTE 1—The electrical portion of the safety systems that perform safety functions, is classified as Class IE.
67
IEEE Std 7-4.3.2-2010
NOTE 2—This definition of “safety system” agrees with the definition of “safety-related systems” used by the
American Nuclear Society (ANS) and IEC 60231A (1969-01) [B12].
software: Computer programs, procedures, and possibly associated documentation and data pertaining to
the operation of a computer system. (The IEEE Standards Dictionary: Glossary of Terms & Definitions,
IEEE Std 610.12-1990 [B19])
software maintenance: (A) Modification of a software product after delivery to correct faults, to improve
performance or other attributes, or to adapt the product to a modified environment. (B) The set of activities
that takes place such that software installed for operational use continues to perform as intended and fulfill
its intended role in system operation. Software maintenance includes improvements, aid to users, and
related activities. (The IEEE Standards Dictionary: Glossary of Terms & Definitions, IEEE Std 610.12-
1990 [B19])
specification: A document that specifies, in a complete, precise, verifiable manner, the requirements,
design, behavior, or other characteristics of a system or system, and, often, the procedures for determining
whether these provisions have been satisfied. (The IEEE Standards Dictionary: Glossary of Terms &
system: A collection of components organized to accomplish a specific function or a set of functions. (The
IEEE Standards Dictionary: Glossary of Terms & Definitions)
system software: Software designed to facilitate the operation and maintenance of a computer system and
its associated programs, including operating systems, drivers, libraries, and utilities. (Adapted from IEEE
Std 610.12-1990 [B19], The IEEE Standards Dictionary: Glossary of Terms & Definitions)
system testing: Testing conducted on a complete, integrated system to evaluate the system’s compliance
with its specified requirements. (The IEEE Standards Dictionary: Glossary of Terms & Definitions)
testing: (A) The process of operating a system or component under specified conditions, observing or
recording the results, and making an evaluation of some aspect of the system or component. (B) The
process of analyzing a software item to detect the difference between existing and required conditions (that
is, bugs) and to evaluate the features of the software items. (IEEE Std 610.12-1990 [B19])
test plan: (A) A document describing the scope, approach, resources, and schedule of intended test
activities. It identifies test items, the features to be tested, the testing tasks, who will do each task, and any
risks requiring contingency planning. (B) A document that describes the technical and management
approach to be followed for testing a system or component. Typical contents identify the items to be tested,
tasks to be performed, responsibilities, schedules, and required resources for the testing activity. (IEEE Std
610.12-1990 [B19])
verification: The process of evaluating a system or component throughout the life cycle process to confirm
that the products of a given development phase satisfy the conditions imposed at the start of that phase.
(The IEEE Standards Dictionary: Glossary of Terms & Definitions, IEEE Std 610.12-1990 [B19], IEEE
Std 1233-1998 [B25])
verification and validation (V&V): The process of confirming that the requirements for a system or
component are complete and correct, the products of each development phase fulfill the requirements or
conditions imposed by the previous phase, and the final system or component complies with specified
requirements. (The IEEE Standards Dictionary: Glossary of Terms & Definitions, IEEE Std 610.12-1990
[B19])
68
IEEE Std 7-4.3.2-2010
Annex H
(informative)
Bibliography
[B1] ANSI/ANS 51.1-1983 (R1988), Nuclear Safety Criteria for the Design of Stationary Pressurized
Water Reactor Plants.
[B2] ANSI/ANS 52.1-1983 (R1988), Nuclear Safety Criteria for the Design of Stationary Boiling
Water Reactor Plants.
[B3] EPRI NP-5652, Guideline for the Utilization of Commercial Grade Items in Nuclear Safety
Related Applications (NCIG-07), June 1988.
[B4] EPRI NP-6406, Guidelines for the Technical Evaluation of Replacement Items for Nuclear Power
Plants (NCIG-11), December 1989.
[B5] EPRI TR-1001045, Guideline on the Use of Pre-Qualified Digital Platforms for Safety and Non-
Safety Applications in Nuclear Power Plants, December 2000.
[B6] EPRI TR-1002833, Guideline on Licensing Digital Upgrades, EPRI TR-102348 Revision 1,
NEI 01-01, A Revision of EPRI TR-102348 to Reflect Changes to the 10 CFR 50.59 Rule, March
2002.
[B7] EPRI TR-1011710, Handbook for Evaluating Critical Digital Equipment and Systems, November
2005.
[B8] EPRI TR-102260, Supplemental Guidance for the Application of EPRI Report NP-5652 on the
Utilization of Commercial Grade Items, March 1994.
[B9] EPRI TR-106439, Guideline of Evaluation and Acceptance of Commercial Grade Digital
Equipment for Nuclear Safety Applications, October 1996.
[B10] EPRI TR-107330, Generic Requirements Specification for Qualifying a Commercially Available
PLC for Safety-Related Applications in Nuclear Power Plants, December 1996.
[B11] EPRI TR-107339, Evaluating Commercial Digital Equipment for High Integrity Applications, A
Supplement to EPRI Report TR-106439, December 1997.
[B12] IEC 60231A (1969-01), First Supplement to General Principles of Nuclear Reactor
Instrumentation.
[B13] IEC 60880 Edition 2, (2006-05), Software for Computers in the Safety Systems of Nuclear Power
Stations.
[B14] IEC 61784-3, (2007-12), Industrial communication networks—Profiles—Part 3: Functional safety
fieldbuses—General rules and profile definitions.
[B15] IEEE Std 352-1987 (Reaff 1999), IEEE Guide for General Principles of Reliability Analysis of
Nuclear Power Generating Station Safety Systems.
[B16] IEEE Std 379-2000 (Reaff 2008), IEEE Standard Application of the Single-Failure Criterion to
Nuclear Power Generating Station Safety Systems.
[B17] IEEE Std 384™-1992, IEEE Standard Criteria for Independence of Class 1E Equipment and
Circuits.
[B18] IEEE Std 497-2002 (Reaff 2008), IEEE Standard Criteria for Accident Monitoring
Instrumentation for Nuclear Power Generating Stations.
69
IEEE Std 7-4.3.2-2010
[B19] IEEE Std 610.12-1990 (Reaff 2002), IEEE Standard Glossary of Software Engineering
Terminology.
[B20] IEEE Std 730-2002, IEEE Standard for Software Quality Assurance Plans.
[B21] IEEE Std 828-2005, IEEE Standard for Software Configuration Management Plans.
[B22] IEEE Std 1012a™-1998, IEEE Standard for Software Verification and Validation—Content Map
to IEEE/EIA 12207.1.
[B23] IEEE Std 1061-1998 (Reaff 2004), IEEE Standard for a Software Quality Metrics Methodology.
[B24] IEEE Std 1228-1994 (Reaff 2002), IEEE Standard for Software Safety Plans.
[B25] IEEE Std 1233-1998 (Reaff 2002), IEEE Guide for Developing System Requirements
Specifications.
[B26] ISO/IEC 15288:2008 (Second Edition), Systems and Software Engineering—System Life Cycle
Processes.
[B27] MIL-STD-882B, System Safety Program Requirements.
[B28] NRC Interim Staff Guidance DI&C-ISG-01, Revision 0, December 2007.
[B29] NRC Interim Staff Guidance DI&C-ISG-02, Revision 2, June 2009.
[B30] NRC Interim Staff Guidance DI&C-ISG-04, Revision 1, March 2009.
[B31] USNRC Generic Letter 85-06, “Quality Assurance Guidance for ATWS Equipment That Is Not
Safety-Related,” April 16, 1985 (Accession No. ML031140390).
[B32] USNRC NUREG-0800, Standard Review Plan, BTP 7-19, Guidance for Evaluation of Defense-in-
Depth and Diversity in Digital Computer-Based Instrumentation and Control Systems, March
2007.
[B33] USNRC NUREG/CR-6082, Data Communications, August 1993.
[B34] USNRC NUREG/CR-6303, Method for Performing Diversity and Defense-in-Depth Analyses of
Reactor Protection Systems, December 1994.
[B35] U.S. Code of Federal Regulations, Title 10, Energy, Part 50, Section 62, Requirements for
Reduction of Risk from Anticipated Transient Without Scram (ATWS) Events for Light-Water-
Cooled Nuclear Power Plants.
[B36] U.S. Code of Federal Regulations, Title 10, Part 50, Appendix A, Criterion 4, Environmental and
dynamic effects design bases.
[B37] U.S. Code of Federal Regulations, Title 10, Part 50, Appendix B, Quality Assurance Criteria for
Nuclear Power Plants and Fuel Reprocessing Plants.
[B38] U.S. Code of Federal Regulations, Title 10, Part 73, Physical Protection of Plants and Materials.
[B39] U.S. Code of Federal Regulations, Title 10, Part 100, Reactor Site Criteria.
70

Get PDF

Uploaded by

Copyright:

Available Formats

Get PDF

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Get PDF

Uploaded by

Copyright:

Available Formats



IEEE Standard Criteria for Digital

Nuclear Power Engineering Committee

Approved 17 June 2010

The Institute of Electrical and Electronics Engineers, Inc.

Copyright © 2010 by the Institute of Electrical and Electronics Engineers, Inc.

PDF: ISBN 978-0-7381-6316-1 STD96076

Secretary, IEEE-SA Standards Board

⎯ The references were updated to include current IEEE standards.

Laws and regulations

Updating of IEEE documents

Warren Odess-Gillett, Chair, Secretary

David Curbo David Herrell Mark Santschi

David J. Zaprazny, Chair

Ijaz Ahmad David Herrell Ifti Rana

John D. MacDonald, Chair

Ijaz Ahmad Robert J. Fletcher Alexander Marion

William J. Ackerman Gary Engmann G. Lang

Robert M. Grow, Chair

Karen Bartleson Young Kyun Kim Ronald C. Petersen

Satish Aggarwal, NRC Representative

3. Definitions and abbreviations..................................................................................................................... 2

4. Safety system design basis ......................................................................................................................... 5

5. Safety system criteria ................................................................................................................................. 5

6. Sense and command features—functional and design requirements........................................................ 36

7. Execute features—functional and design requirements............................................................................ 36

8. Power source requirements....................................................................................................................... 36

Annex B (informative) Diversity requirements determination ..................................................................... 38

Annex C (informative) Dedication of existing commercial computers ........................................................ 39

Annex D (informative) Identification and resolution of hazards .................................................................. 44

Annex F (informative) Computer reliability................................................................................................. 64

Annex G (informative) Glossary .................................................................................................................. 65

Annex H (informative) Bibliography ........................................................................................................... 69

3. Definitions, acronyms and abbreviations

⎯ The integrity of the reactor coolant pressure boundary;

NOTE—Adapted from EPRI NP-5652 [B3]. 4

NOTE—Adapted from EPRI NP-5652 [B3].

NOTE—Adapted from IEEE Std 610.12™-1990 [B19].

NOTE—Adapted from IEEE Std 610.12-1990 [B19].

3.2 Acronyms and abbreviations

The following abbreviations and acronyms appear in this standard:

ATWS anticipated transient without scram

4. Safety system design basis

No requirements beyond IEEE Std 603-2009 are necessary.

5. Safety system criteria

5.1 Single-failure criterion

5.2 Completion of protective action

No requirements beyond IEEE Std 603-2009 are necessary.

5.3.1 Software development

5.3.1.1 Software quality metrics

⎯ Correctness/Completeness (Requirements phase)

5.3.2 Software tools

5.3.3 Verification and validation

5.3.4 V&V independence requirements

Annex C of IEEE Std 1012-2004 provides additional guidance.

5.3.5 Software configuration management

The minimum set of activities shall address the following:

a) Identification and control of all software designs and code

5.3.6 Software project risk management

Risk management shall include the following steps: