licensing topical report spinline 3 nrc qualification ... · nuclear sas, be used or reproduced, in...

[ a+xzH Rol ls-Royce

Designation du document Document name

Licensing Topical Report

Affaire Product

rn Equipement Equipment

KI

Sous-ensem ble Subassembly

U

Classe 1 E ou equiv. rn Safety classification

SPINLINE 3 NRC Qualification

SPINLINE 3 Digital Safety I&C Platform

Document contractuel (pour le client) oui non Nbre de pages 11 Contractual document (for customer) yes no Number of pages

Code projet Project code

Diffusion interne: Internal distribution

Nivl / Level1 Niv2 / Level2 1 RNDFR I TEMI.P~

1 ICC. LOG. QUA. MKT

Diffusion externe: External distribution

I NRC

Redige par Written bv

Nom :

Visa : Signature

Tampon archivage I Archive stamp 1 I Version frangaise

Verifie par Checked bv

Nom :

Visa : Signature

Approuve par I . .

Approved by

Nom : Name

I Nom : P. Barqnek

English version

Name Visa : ? . .---- Signature q~ Date: 2z)/0-1 \?0d f l

1 Date

Approuve par Approved by

Redige ou traduit par Written or translated by

Nom : P. Lobner I Nom : C. Caillet A I

Verifie par Checked by

,Name Visa : Signature Date : 28 Jan. 201 1 Date : Date Date 3~/1rl\ZsC/r

The document contains information which is proprietary and confidential to Rolls-Royce Civil Nuclear SAS which may not, without the prior written consent of Rolls-Royce Civil Nuclear SAS, be used or reproduced, in whole or in part, or communicated to any person not employed by Rolls-Royce Civil Nuclear SAS. O Rolls-Royce plc 2009 Le document contient des informations confidentielles et propriete de Rolls-Royce Civil Nuclear SAS et ne peut, sans I'accord ecrit prealable de Rolls-Royce Civil Nuclear SAS, btre utilise ou reproduit, en totalite ou en partie, ou 6tre communique a un tiers. O Rolls-Royce plc 2009

lrnprirne no 8303090 F 3 008 503C - NP

Licensing Topical Report - SPINLINE 3 NRC Qualification 3 008 503C - NP Imprimé n° 8303090 F

TABLEAU DE MISE A JOUR Record of revisions

Indice /date Rédigé par Pages modifiées Origine et désignation de la modification

Revision letter / date Modified pages Origin and designation of the modification Written by

A / 18 Dec 2008 Edition originale / First issue P. Lobner B / 30 June 2009 All pages Modification from Data Systems and

Solutions to Rolls-Royce P. Lobner General technical and editorial update C / 27 Jan 2011 §1.1, §1.3, §4.1.2, §6.3 Dedication approach clarified P. Baranek §1.3, §3.7.4 Reference to document 3 011 552 added §1.4.1 Description of I&C France quality program

clarified (originally based on European nuclear QA standards)

§1.2, §3, Appendix A Compliance tables moved from Chapter 3 to Appendix A

§3.1, §3.3.12, §3.3.13, §3.8.10,§3.8.11, §3.8.15, §6.2.2, Appendix A

Incorporation of tables in response to the NRC request for supplemental information(NRC letter dated May 14, 2010 - ADAMS Accession No. ML101300192)

§3.1, §3.2.2, §3.3.10, §3.3.20, §3.7.1,§3.8.1, §4.1.1, §4.7, §6.4, §6.5

“Cyber security” no longer addressed in LTR. Focus is on secure development environment, as expressed in DG-1249 (draf RG 1.152 rev 3)

§3.12.2 New section created for EPRI TR-106439 §4.1 Platform software and hardware identified §4.3.3, §4.3.4.8, §4.5.3 Description of Nervia+ daughter board and

Nervia+ interface board updated §4.3.4.4 Description of OSS modes of operation

updated §4.4.3.5.2, §4.4.3.5.3, §4.4.3.5.4,

§4.4.3.6.1, §4.5.4.2 Action upon failure clarified

§4.5.2.1 Figure 4.5-1 updated (media occupation is always the same)

§4.5.2.6, §4.5.3 Description of communication between Unitand Station updated

§4.5.4.3 Dual port memory protocol managementadded

§6.2.2, §6.2.2.1, §6.2.5 Role of Software General Requirements, document 1 207 101 clarified

All other pages Update of proprietary marking Update of references Correct use of Rolls-Royce brand Editorial update Datasheets moved to Appendix B

Identification des moyens de production de ce document

Identification of document production means Outils : Microsoft Office Word 2003 Fichier : LTR_3008503C_NP.doc Tools File


Abstract

This Licensing Topical Report (LTR) presents design, performance, and qualification information for the SPINLINE 3 digital safety instrumentation and control (I&C) platform developed by Rolls-Royce. SPINLINE 3 is a generic digital safety I&C platform dedicated to the implementation of Class 1E safety I&C functions. SPINLINE 3 builds on the digital safety I&C systems developed by Rolls-Royce for the Électricité de France (EDF) P4 and N4 pressurized water reactor (PWR) fleet.

This LTR is the summary licensing document for the SPINLINE 3 digital safety I&C platform and is organized as follows:

• Chapter 1, Introduction • Chapter 2, SPINLINE 3 Development and Operational History • Chapter 3, Compliance With Regulations, Codes and Standards • Chapter 4, Description of the SPINLINE 3 Digital Safety I&C Platform • Chapter 5, Equipment Qualification • Chapter 6, Software Development Process for SPINLINE 3 Platform Software and Application Software • Appendix A, Compliance Matrices • Appendix B, Hardware Data Sheets The following additional documentation supports the Rolls-Royce application for NRC approval of the SPINLINE 3 digital safety I&C platform:

• Hardware Qualification Documents • Hardware Analysis Documents • Quality Plans • SPINLINE 3 Platform Software Life Cycle Plans • Design Analysis Report • SPINLINE 3 Application Software Life Cycle Plans


TABLE DES MATIERES Table of contents

0 Abbreviations and Acronyms...............................................................................................................14

1 Introduction ..........................................................................................................................................19

1.1 Purpose .....................................................................................................................................19

1.2 Organization of this Licensing Topical Report...........................................................................20

1.3 Supporting SPINLINE 3 Licensing Documents .........................................................................21

1.4 QUALITY PROGRAM .....................................................................................................................22 1.4.1 Rolls-Royce Nuclear Quality Program in France .......................................................23 1.4.2 Rolls-Royce Nuclear Quality Program in the USA.....................................................23

1.5 Chapter 1 References ...............................................................................................................23

2 SPINLINE 3 Development and Operational History ............................................................................25

2.1 Overview....................................................................................................................................25

2.2 Evolution of the SPINLINE 3 Digital Safety I&C Platform .........................................................26 2.2.1 Non Software-Based Safety I&C................................................................................26 2.2.2 First Generation of Software-Based Safety I&C ........................................................26 2.2.3 Second Generation of Software-Based Safety I&C ...................................................27 2.2.4 Third Generation of Software-Based Safety I&C - SPINLINE 3 ................................28

2.3 Rolls-Royce Safety I&C Installations.........................................................................................29


3 Regulations, Codes and Standards.....................................................................................................37

3.1 Compliance Summary ...............................................................................................................37

3.2 10 CFR , Code of Federal Regulations .....................................................................................38 3.2.1 10 CFR 50, Domestic Licensing of Production and Utilization Facilities ...................38 3.2.2 Title 10 CFR 73.54, Protection of Digital Computer and Communication

Systems and Networks ..............................................................................................42

3.3 USNRC Division 1 Regulatory Guides ......................................................................................43 3.3.1 Regulatory Guide (RG) 1.22, Revision 0, Periodic Testing of Protection

System Actuation Functions.......................................................................................43 3.3.2 Regulatory Guide 1.47, Revision 0, Bypassed and Inoperable Status

Indication for Nuclear Power Plant Safety System ....................................................43 3.3.3 Regulatory Guide 1.53, Revision 2, Application of the Single-Failure Criterion

to Safety Systems ......................................................................................................43 3.3.4 Regulatory Guide 1.62, Revision 0, Manual Initiation of Protection Actions..............43


3.3.5 Regulatory Guide 1.75, Revision 3, Criteria for Independence of Electrical Safety Systems ..........................................................................................................44

3.3.6 Regulatory Guide 1.89, Revision 1, “Environmental Qualification of Certain Electric Equipment Important to Safety for Nuclear Power Plants” ...........................44

3.3.7 Regulatory Guide 1.100, Revision 2, Seismic Qualification of Electric and Mechanical Equipment for Nuclear Power Plants......................................................44

3.3.8 Regulatory Guide 1.105, R3, Setpoints for Safety-Related Instrumentation .............45 3.3.9 Regulatory Guide 1.118, Revision 3, Periodic Testing of Electric Power and

Protection Systems ....................................................................................................45 3.3.10 Regulatory Guide 1.152, Criteria for Use of Computers in Safety Systems of

Nuclear Power Plants.................................................................................................45 3.3.11 Regulatory Guide 1.153, Revision 1, Criteria for Safety Systems .............................45 3.3.12 Regulatory Guide 1.168, Revision 1, Verification, Validation, Reviews and

Audits for Digital Computer Software Used in Safety Systems of Nuclear Power Plants ..............................................................................................................46

3.3.13 Regulatory Guide 1.169, Revision 0, Configuration Management Plans for Digital Computer Software Used in Safety Systems of Nuclear Power Plants..........46

3.3.14 Regulatory Guide 1.170, Revision 0, Software Test Documentation for Digital Computer Software Used in Safety Systems of Nuclear Power Plants.....................46

3.3.15 Regulatory Guide 1.171, Revision 0, Software Unit Testing for Digital Computer Software Used in Safety Systems of Nuclear Power Plants.....................47

3.3.16 Regulatory Guide 1.172, Revision 0, Software Requirements Specifications for Digital Computer Software Used in Safety Systems of Nuclear Power Plants..........47

3.3.17 Regulatory Guide 1.173, Revision 0, Developing Software Life Cycle Processes for Digital Computer Software Used in Safety Systems of Nuclear Power Plants ..............................................................................................................47

3.3.18 Regulatory Guide 1.180, Revision 1, Guidelines for Evaluating Electromagnetic and Radio- Frequency Interference in Safety-Related Instrumentation and Control Systems........................................................................48

3.3.19 Regulatory Guide 1.209, Revision 0, Guidelines for Environmental Qualification of Safety-Related Computer-Based Instrumentation and Control Systems in Nuclear Power Plants..............................................................................48

3.3.20 Regulatory Guide 5.71, Revision 0, Cyber Security for Nuclear Facilities.................48

3.4 NUREG-0800, Chapter 7, Revision 5 Branch Technical Positions (BTPs)...............................48 3.4.1 BTP 7-8, Revision 5, Guidance on Application of Regulatory Guide 1.22.................48 3.4.2 BTP 7-11, Revision 5, Guidance on Application and Qualification of Isolation

Devices.......................................................................................................................48 3.4.3 BTP 7-12, Revision 5, Guidance on Establishing and Maintaining Instrument

Setpoints ....................................................................................................................49 3.4.4 BTP 7-14, Revision 5, Guidance on Software Reviews for Digital Computer-

Based Instrumentation and Control Systems.............................................................49 3.4.5 BTP 7-17, Revision 5, Guidance on Self-Test and Surveillance Test

Provisions...................................................................................................................49 3.4.6 BTP 7-19, Revision 5, Guidance on Evaluation of Diversity and Defense-in-

Depth in Digital Computer-Based Instrumentation and Control Systems..................49 3.4.7 BTP 7-21, Revision 5, Guidance on Digital Computer Real-Time Performance .......49


3.5 USNRC Staff Requirements Memos (SRMs)............................................................................50 3.5.1 SRM to SECY 93-087, II.Q, Defense Against Common-Mode Failures in

Digital Instrumentation and Control Systems.............................................................50

3.6 USNRC NUREGs and NUREG/CRs.........................................................................................50 3.6.1 NUREG/CR 6082, Data Communications .................................................................50

3.7 USNRC Digital I&C Interim Staff Guides (ISGs) .......................................................................50 3.7.1 DI&C-ISG-01, Rev. 0, Cyber Security........................................................................50 3.7.2 DI&C-ISG-02, Rev. 1, Diversity and Defense-in-Depth (D3) .....................................50 3.7.3 DI&C-ISG-04, Rev. 1, Highly Integrated Control Rooms – Digital

Communication Systems ...........................................................................................50 3.7.4 DI&C-ISG-06, Draft, Licensing Process.....................................................................51

3.8 Institute of Electrical & Electronics Engineers (IEEE) Standards..............................................51 3.8.1 IEEE Standard 7-4.3.2-2003, Standard Criteria for Digital Computers in Safety

Systems of Nuclear Power Generating Stations........................................................51 3.8.2 IEEE Standard 279-1971, Criteria for Protection Systems for Nuclear Power

Generating Stations ...................................................................................................51 3.8.3 IEEE Standard 323-2003, IEEE Standard for Qualifying Class 1E Equipment

for Nuclear Power Generating Stations .....................................................................51 3.8.4 IEEE Standard 338-1987, Criteria for the Periodic Surveillance Testing of

Nuclear Power Generating Station Safety Systems ..................................................52 3.8.5 IEEE Standard 344-1987, IEEE Recommended Practice for Seismic

Qualification of Class 1E Equipment for Nuclear Power Generating Stations...........52 3.8.6 IEEE Standard 352-1987, Guide for General Principles of Reliability Analysis

of Nuclear Power Generating Station Safety Systems ..............................................52 3.8.7 IEEE Standard 379-2000, Application of the Single-Failure Criterion to Nuclear

Power Generating Station Safety Systems................................................................52 3.8.8 IEEE Standard 384-1992, Standard Criteria for Independence of Class 1E

Equipment and Circuits ..............................................................................................52 3.8.9 IEEE Standard 603-1991, Criteria for Safety Systems for Nuclear Power

Generating Stations ...................................................................................................53 3.8.10 IEEE Standard 730-1998, IEEE Standard for Software Quality Assurance

Plans ..........................................................................................................................53 3.8.11 IEEE Standard 828-1990, IEEE Standard for Software Configuration

Management Plans ....................................................................................................53 3.8.12 IEEE Standard 829-1983, IEEE Standard for Software Test Documentation ...........54 3.8.13 IEEE Standard 830-1993, IEEE Recommended Practice for Software

Requirements Specifications......................................................................................54 3.8.14 IEEE Standard 1008-1987, IEEE Standard for Software Unit Testing ......................54 3.8.15 IEEE Standard 1012-1998, IEEE Standard for Software Verification and

Validation Plans .........................................................................................................54 3.8.16 IEEE Standard 1028-1997, IEEE Standard for Software Reviews and Audits..........54 3.8.17 IEEE Standard 1042-1987, IEEE Guide to Software Configuration

Management ..............................................................................................................54


3.8.18 IEEE Standard 1050-1996, Guide for Instrumentation and Control Equipment Grounding in Generating Stations..............................................................................54

3.8.19 IEEE 1074-1995, IEEE Standard for Developing Software Life Cycle Processes...................................................................................................................55

3.9 Instrument Society of America (ISA) Standards........................................................................55 3.9.1 ISA Standard S67.04-1994, Setpoints for Nuclear Safety-Related

Instrumentation Used in Nuclear Power Points .........................................................55

3.10 International Electrotechnical Commission (IEC) Standards ....................................................55 3.10.1 IEC 880-1986, Software for Computers in the Safety Systems of Nuclear

Power Stations ...........................................................................................................55 3.10.2 IEC 61000, Electromagnetic Compatibility (EMC) .....................................................56 3.10.3 IEC TR 62380, Reliability Data Handbook, Universal Model for Reliability

Prediction of Electronics Components, PCBs and Equipment ..................................56

3.11 U.S. Military Standard................................................................................................................56 3.11.1 MIL-STD-461E, DOD Interface Standard Requirements for the Control of

Electromagnetic Interference Characteristics of Subsystems and Equipment ..........56

3.12 Electric Power Research Institute (EPRI) Technical Reports and Handbooks .........................56 3.12.1 EPRI TR-107330, Generic Requirements Specification for Qualifying a

Commercially Available PLC for Safety-Related Applications in Nuclear Power Plants ..............................................................................................................56

3.12.2 EPRI TR-106439, Guideline on Evaluation and Acceptance of Commercial Grade Digital Equipment for Nuclear Safety Applications .........................................57

3.12.3 EPRI Handbook 1011710, Handbook for Evaluating Critical Digital Equipment and Systems ..............................................................................................................57

3.13 American Society of Mechanical Engineers (ASME) ................................................................57 3.13.1 ASME NQA-1-1994, Quality Assurance Program Requirements for Nuclear

Facilities .....................................................................................................................57


4 Description of the SPINLINE 3 Digital Safety I&C Platform ................................................................59

4.1 Overview....................................................................................................................................59 4.1.1 Design Criteria ...........................................................................................................60 4.1.2 Dedication and Qualification ......................................................................................61 4.1.3 Operation and Maintenance.......................................................................................62 4.1.4 State-of-the-Art Performance.....................................................................................62 4.1.5 Quality ........................................................................................................................62

4.2 Main Features of SPINLINE 3 ...................................................................................................62 4.2.1 Introduction ................................................................................................................62 4.2.2 Software Based Digital Technology ...........................................................................63 4.2.3 Standardized Components.........................................................................................63 4.2.4 Architectures ..............................................................................................................64 4.2.5 Redundancy ...............................................................................................................69


4.2.6 Deterministic Behavior ...............................................................................................69 4.2.7 Separation..................................................................................................................70 4.2.8 Safety-oriented Features............................................................................................71 4.2.9 Alarms and Signaling on Failure ................................................................................71

4.3 Hardware ...................................................................................................................................71 4.3.1 Introduction ................................................................................................................71 4.3.2 Description of the chassis and backplane bus...........................................................72 4.3.3 Summary of Electronic Boards and Electronic Modules............................................75 4.3.4 Description of the SPINLINE 3 Hardware Building Blocks ........................................78

4.4 SPINLINE 3 Software ................................................................................................................86 4.4.1 Introduction ................................................................................................................86 4.4.2 SPINLINE 3 General Software Architecture ..............................................................87 4.4.3 Operational System Software (OSS) .........................................................................88 4.4.4 System and Software Development Environment (SSDE) ......................................110 4.4.5 Application Software ................................................................................................113 4.4.6 Generic Design Elements Against Software Common Cause Failure (CCF)..........114

4.5 Communications......................................................................................................................115 4.5.1 The Open Systems Interconnection (OSI) Model ....................................................115 4.5.2 NERVIA Basic Concepts..........................................................................................116 4.5.3 NERVIA Hardware ...................................................................................................121 4.5.4 NERVIA Software.....................................................................................................124 4.5.5 Detailed Operation ...................................................................................................126 4.5.6 Communication Failures Detection ..........................................................................128 4.5.7 Isolation and Independence Enforced on Data “Gateways” to Non-Class 1E

Computer Systems...................................................................................................128 4.5.8 Compliance With NRC Communications Requirements..........................................129

4.6 Testability.................................................................................................................................130 4.6.1 Overall Strategy for Testing .....................................................................................130 4.6.2 Basic Concepts ........................................................................................................131 4.6.3 Design Principles for Testability...............................................................................131 4.6.4 Functional Verification Surveillance .........................................................................132 4.6.5 Self-diagnostic Tests................................................................................................133 4.6.6 Surveillance Functions .............................................................................................134 4.6.7 Periodic Tests ..........................................................................................................134 4.6.8 Description Self-diagnostic Testing Features of SPINLINE 3 Equipment ...............135 4.6.9 Automated Testing Units (ATU) ...............................................................................140 4.6.10 Monitoring and Maintenance Unit (MMU) ................................................................141

4.7 Secure Development and Operational Environment...............................................................142


4.8 Chapter 4 References .............................................................................................................142

5 Equipment Qualification and Analysis ...............................................................................................145

5.1 Equipment Qualification...........................................................................................................145 5.1.1 Equipment to be Tested ...........................................................................................146 5.1.2 Equipment Qualification (EQ) Testing......................................................................147 5.1.3 Generic Qualification Envelope................................................................................152

5.2 Equipment Analysis .................................................................................................................159 5.2.1 Predictive reliability and safety analysis...................................................................159 5.2.2 Setpoint Analysis Support ........................................................................................162 5.2.3 Limited Life Parts Analysis .......................................................................................163

5.3 Chapter 5 References .............................................................................................................164

6 Software Development Process for SPINLINE 3 Platform Software and Application Software........167

6.1 SPINLINE 3 Platform Software Development History.............................................................167

6.2 SPINLINE 3 Operational System Software (OSS) Development Process..............................168 6.2.1 OSS Software Life Cycle Process ...........................................................................168 6.2.2 SPINLINE 3 OSS Life Cycle Activities .....................................................................170 6.2.3 SPINLINE 3 OSS Quality Assurance Plan...............................................................183 6.2.4 SPINLINE 3 OSS Project Management...................................................................184 6.2.5 SPINLINE 3 OSS Verification and Validation Program ...........................................185 6.2.6 SPINLINE 3 OSS Configuration Management Program..........................................186 6.2.7 SPINLINE 3 Platform Software Tools Procurement, Development and

Validation Processes................................................................................................188 6.2.8 SPINLINE 3 Platform Software Embedded in I/O and Communication Boards ......188 6.2.9 SPINLINE 3 Platform Application-Oriented Library of Re-usable Software

Components.............................................................................................................190 6.2.10 SPINLINE 3 Platform PLD and FPGA embedded in electronic boards...................190

6.3 SPINLINE 3 Platform Software Design and Development Analyses – IEC 880 and BTP 7-14..........................................................................................................................................191

6.4 SPINLINE 3 Application Software Development Process.......................................................195 6.4.1 Software Quality Assurance Plan ............................................................................198 6.4.2 Software Development Plan.....................................................................................200 6.4.3 Software Configuration Management Plan ..............................................................201 6.4.4 Software Verification and Validation Plan ................................................................202 6.4.5 System Integration and Factory Test Plan...............................................................204 6.4.6 System Installation and Site Test Plan ....................................................................205 6.4.7 System Training Plan ...............................................................................................206 6.4.8 System Operation and Maintenance Plan ...............................................................207 6.4.9 SPINLINE 3 Application Software Life Cycle Process Implementation Reports .....207


6.4.10 SPINLINE 3 Application Software Design Outputs..................................................208

6.5 Secure Development and Operational Environment...............................................................209

6.6 Chapter 6 References .............................................................................................................209 Appendix A Compliance Tables……………………………………………….…..........................................214

Appendix B Hardware Data Sheets……………………………………………………………………………..442


LISTE DES FIGURES List of Figures

Figure 4.2-1. Representative Single Division Architecture 65 Figure 4.2-2 Representative Four Division Architecture 68 Figure 4.3-1. Front view of the chassis equipped with its boards 73 Figure 4.3-2. Rear view of the chassis equipped with its interface boards 73 Figure 4.3-3. Example of Manual Actuation and Inhibition Interface with Actuator Drive Hardware 82 Figure 4.4-1. Processing Unit: Hardware / Software Architecture 87 Figure 4.4-2. SPINLINE 3 Software Cycle 89 Figure 4.4-3. Relationships among the OSS operating modes 91 Figure 4.4-4. Initialization 94 Figure 4.4-5. Tests and Self-diagnostic Tests 97 Figure 4.4-6. Cycle Time Management 99 Figure 4.4-7 Processing Cycle 100 Figure 4.4-8. Acquiring Information 101 Figure 4.4-9. Transmitting Information 103 Figure 4.4-10. Component Interfaces Managed by CLARISSE 111 Figure 4.4-11. SCADE Data-Flow Diagram Example 112 Figure 4.5-1. Sequence of Activities During a Network Cycle for a Network Composed of Three

Transmitting Stations 119 Figure 4.5-2. Basic Architecture for Data Exchange Between a Station and a Unit 122 Figure 4.5-3. Example of a Simple NERVIA Network 123 Figure 4.5-4. Representative Gateway Configuration for Delivering Data from a SPINLINE 3

System to a Non-Class 1E System 129 Figure 5.1-1. SPINLINE 3 QTS Qualification Testing Sequence 147 Figure 6.2-1. OSS Life Cycle Process 169 Figure 6.3-1. Alignment of BTP 7-14 Plans and SPINLINE 3 Platform Software Documentation 193 Figure 6.4-1. Application Software Life Cycle Overview 196 Figure 6.4-2. Alignment of BTP 7-14 Plans and SPINLINE 3 Application Software and System

Plans 197


LISTE DES TABLEAUX List of Tables

Table 2.3-1. Rolls-Royce Nuclear I&C Installations 30

Table 4.3-1. SPINLINE 3 Electronic Boards and Electronic Modules 75 Table 4.3-2. 8SRELAY1 & 8SRELAY2 Terminal Block Relay Characteristics 81 Table 4.4-1. Summary of OSS operating modes and conditions for transitions between operating modes 92 Table 4.6-1. Coverage of Self-diagnostic Tests and Periodic Tests 139 Table 5.1-1. Standard Review Plan Table 7-1 Compliance Summary 153

Table 5.1-2. Standard Review Plan Table 7-1 Compliance Summary 160

Table 6.2-1. Evolution of Selected SPINLINE 3 Software Life Cycle Documents 172 Table 6.4-1. Types of Factory Tests 204

In Appendix A

Table 3.1-1. Standard Review Plan Table 7-1 Compliance Summary 215

Table 3.2-1. 10CFR50 Appendix B and ASME NQA-1-1994 Map to Corresponding I&C France QA Plans & Procedures 228

Table 3.2-2. 10CFR50 Appendix B and ASME NQA-1-1994 Map to Corresponding I&C US QA Plans & Procedures 240

Table 3.6-1. Responses to NUREG/CR-6082 Communications System Questions 253

Table 3.7-1. Interim Staff Guide DI&C-ISG-04 Compliance Matrix 256

Table 3.8-1. IEEE 7-4.3.2-2003 Compliance Matrix 284

Table 3.8-2. IEEE 603-1991 Compliance Matrix 293

Table 3.8-3. Mapping SPINLINE 3 SQP MC3 and Other Content to IEEE 730-1998 SQAP Content Guidance 305

Table 3.8-4. Mapping SPINLINE 3 SMQP and Other Content to IEEE 730-1998 SQAP Content Guidance 318

Table 3.8-5. Mapping SPINLINE 3 Application SQAP and Other Content to IEEE 730-1998 SQAP Content Guidance 332

Table 3.8-6. Mapping SPINLINE 3 SQP MC3 and Other Content to IEEE 828-1998 SCMP Content Guidance 343

Table 3.8-7. Mapping SPINLINE 3 Platform SCMP and Other Content to IEEE 828-1998 SCMP Content Guidance 348

Table 3.8-8. Mapping SPINLINE 3 Application SCMP and Other Content to IEEE 828-1998 SCMP Content Guidance 354

Table 3.8-9. Mapping SPINLINE 3 SQP MC3 and Other Content to IEEE 1012-1998 SVVP Content Guidance 360

Table 3.8-10. Mapping SPINLINE 3 SMQP and Other Content to IEEE 1012-1998 SVVP Content Guidance 370

Table 3.8-11. Mapping SPINLINE 3 Application SVVP and Other Content to IEEE 1012-1998 SVVP Content Guidance 383


Table 3.8-12. Alignment of IEEE 1074-1995 Activities, ISG-06 Tier 3 Document Guidance, and SPINLINE 3 Documents 393

Table 3.10-1. IEC 880-1986 Appendix B Compliance Matrix 419

Table 3.10-2. Comparison of IEC 880-1986 and NRC Branch Technical Position 7-14 Requirements 438


0 Abbreviations and Acronyms

Term Definition

10 CFR Title 10 of the Code of Federal Regulations

A/D Analog-to-Digital

ac Alternating Current

ALARA As Low As Reasonably Achievable

ALWR Advanced Light Water Reactor

ANS American Nuclear Society

ANSI American National Standards Institute

AOO Anticipated Operational Occurrence

API Application Programming Interface

ATU Automated Testing Unit

ATWS Anticipated Transients Without Scram

BAP Backplane (Bus)

BF Basic Functions

BOC Beginning of Cycle

BOP Balance of Plant

BTP NRC Branch Technical Position

BTU British Thermal Unit

BWR Boiling Water Reactor

CAD Computer Aided Design

CCF Common Cause Failure

CDF Core Damage Frequency

CDR Critical Digital Review

CEZ Ceske Energeticke Zavody

CFR Code of Federal Regulations

CNET French National Telecommunications Studies Center

COL Combined Operating License

COTS Commercial-Off-The-Shelf

CPU Central Processing Unit

CRC Cyclic Redundancy Checks

CRT Cathode Ray Tube


Term Definition

DAC Design Acceptance Criteria

DAR Design Analysis Report

DBA Design Basis Accident

DBE Design Basis Event or Design Basis Earthquake

dc Direct Current

DCD Design Control Document

DG Diesel-Generator

DI&C-ISG Digital Instrumentation and Controls Interim Staff Guide

DPM Dual Port Memory

DPS Diverse Protection System

DTM Digital Trip Module

EDF Électricité de France

EEPROM Electrically Erasable Programmable ROM

EMC Electromagnetic Compatibility

EMI Electromagnetic Interference

EPG Emergency Procedure Guidelines

EPRI Electric Power Research Institute

EQ Equipment Qualification

ESD Electrostatic Discharge

ESF Engineered Safety Feature

ESFAS Engineered Safety Feature Actuation System

FAT Factory Acceptance Test

FBD Functional Block Diagram

FCM File Control Module

FMECA Failure Modes and Effects Criticality Analysis

GDC General Design Criteria

GL Generic Letter

HEP Human Error Probability

HFE Human Factors Engineering

HMI Human/Machine Interface

HRA Human Reliability Assessment

HSI Human-System Interface

HVAC Heating, Ventilation, and Air Conditioning


Term Definition

I&C Instrumentation and Control

I&C France Instrumentation & Controls business of Rolls-Royce with office located in Meylan, France

I&C US Instrumentation & Controls business of Rolls-Royce with office located in Huntsville, Alabama, USA

I/O Input/Output

IAEA International Atomic Energy Agency

IEC International Electrotechnical Commission

IED Instrument and Electrical Diagram

IEEE Institute of Electrical and Electronic Engineers

iooj i-out-of-j. For example, voting using 2-out-of-3 logic is referred to as 2oo3

ISA International Society of Automation

ISI In-Service Inspection

ISO International Standards Organization

ITAAC Inspections, Tests, Analyses, and Acceptance Criteria

LAN Local Area Network

LCD Liquid Crystal Display

LCO Limiting Conditions for Operation

LD Logic Diagram

LDU Local Display Unit

LED Light Emitting Diode

LOCA Loss of Coolant Accident

LAR Licensing Amendment Request

LTR Licensing Topical Report

MC3 Modularité du Control Commande des Centrales

MCC Motor Control Center

MCL Master Configuration List

MCR Main Control Room

MMI Man-Machine Interface

MMIS Man-Machine Interface System

MMU Monitoring and Maintenance Unit

MTTR Mean Time To Repair

MW Megawatt

NDE Nondestructive Examination

NFPA National Fire Protection Association


Term Definition

NIS Nuclear Instrumentation System

NPP Nuclear Power Plant

NRC Nuclear Regulatory Commission

NSSS Nuclear Steam Supply System

O&M Operation and Maintenance

OBE Operating Basis Earthquake

OLU Output Logic Unit

OSS Operational System Software

P&ID Piping and Instrumentation Diagram

PAM Post Accident Monitoring

PC Personal Computer

PDD Preliminary Design Document

PFD Process Flow Diagram

PGA Peak Ground Acceleration

PHA Preliminary Hazard Analysis

PIE Postulated Initiating Event

PM Preventive Maintenance

PRC People’s Republic of China

PWR Pressurized Water Reactor

QA Quality Assurance

QAP QA Plan

QMS Quality Management System

RAM Random Access Memory

RCS Reactor Coolant System

RDF Recueil de Donnes de Fiabilité

REPROM Reprogrammable ROM

RG Regulatory Guide

RMBK Russian: Reaktor Bolshoy Moshchnosti Kanalniy (graphite-moderated reactor)

RMS Root Mean Square

ROM Read-Only Memory

RPS Reactor Protection System

RSS Remote Shutdown System

RTS Reactor Trip System


Term Definition

S/N Signal-to-Noise

SAR Safety Analysis Report

SCMP Software Configuration Management Plan

SDP Software Development Plan

SDS System Design Specification

SER Safety Evaluation Report

SFC Single Failure Criterion

SFTP Shielded Foil Twisted Pair

SOE Sequence of Events

SPIN Système de Protection Intégré Numérique, which is the French acronym for “Digital Integrated Protection System”

SQAP Software Quality Assurance Plan

SRM Source Range Monitor

SRP Standard Review Plan

SRS Software Requirements Specification

SSDE System and Software Development Environment

SSE Safe Shutdown Earthquake

SVVP Software Verification and Validation Plan

T/C Thermocouple

TS Technical Specification

TSAP Test Specimen Application Program

UL Underwriter's Laboratories Inc.

UPS Uninterruptible Power Supply

U.S. United States of America

USNRC United States Nuclear Regulatory Commission

UTE-C French Technical Institute of Electricity and Communication (French standards)

UV Ultraviolet

V&V Verification and Validation

v Volts

VDU Video Display Unit

VVER Russian: Voda-Vodyanoi Energetichesky Reaktor (Pressurized Water Reactor)

XFMR Transformer


1 Introduction

1.1 Purpose

This Licensing Topical Report (LTR) presents design, performance, and qualification information for the SPINLINE 3 digital safety instrumentation and control (I&C) platform developed by Rolls-Royce. SPINLINE 3 is a generic digital safety I&C platform designed specifically to implement Class 1E safety I&C functions. SPINLINE 3 builds on the digital safety I&C systems developed by Rolls-Royce for the Électricité de France (EDF) P4 and N4 pressurized water reactor (PWR) fleet.

Designed with flexibility and safety in mind, SPINLINE 3 meets the demanding functional and safety requirements for digital safety I&C systems employed in modern nuclear power plants (NPPs). This makes SPINLINE 3 ideally suited for use in a variety of safety I&C applications in both new NPPs and refurbished safety I&C systems in existing NPPs. Since its launch in 1997, Rolls-Royce has installed SPINLINE 3 digital safety I&C applications such as Reactor Trip System (RTS), Engineered Safety Features Actuation System (ESFAS), Post-Accident Monitoring System (PAMS), and Nuclear Instrumentation System (NIS) in several different international reactor designs, including PWRs, Russian-designed VVER and RBMK reactors, and research reactors. Rolls-Royce concludes that the SPINLINE 3 digital safety I&C platform is readily adaptable to the needs of U.S. nuclear safety I&C applications in PWRs, BWRs and other types of reactors and nuclear facilities.

A detailed listing of SPINLINE 3 and earlier generation Rolls-Royce safety I&C installations is provided in Section 2.3.

This document is a generic Licensing Topical Report (LTR) that is intended to be referenced by a licensee seeking NRC approval to employ SPINLINE 3 in a plant-specific nuclear safety application in the U.S. As such, this generic LTR focuses on the following:

• SPINLINE 3 hardware design, qualification and analysis

• SPINLINE 3 platform software design and software life cycle processes. The components of the generic platform software are:

The standardized, Class 1E configurable Operational System Software (OSS)

The Class 1E application-oriented library of re-usable software components,

The Class 1E software embedded in the NERVIA+ board and the ICTO Pulse Input board, and

A non-Class 1E set of tools integrated in a Software Development Environment (SSDE) called CLARISSE, which is used to design and implement the system architecture, configure the units and networks and develop the plant-specific application software.

• SPINLINE 3 application software life cycle processes for developing plant-specific applications.

Rolls-Royce is seeking U.S. Nuclear Regulatory Commission (NRC) generic approval for use of SPINLINE 3 in nuclear safety I&C systems in any U.S. commercial nuclear power plant, research reactor, or nuclear fuel cycle facility.

SPINLINE 3 originally was designed, qualified, and manufactured to meet European nuclear safety and quality standards. In addition, SPINLINE 3 systems have demonstrated compliance with the nuclear safety regulations in several nations outside of Europe. SPINLINE 3 now is managed under a quality assurance


program that complies with 10CFR50 Appendix B (Reference 1-1). The purpose of this LTR is to demonstrate that the SPINLINE 3 safety I&C platform and the associated quality and software life cycle processes comply with U.S. nuclear safety requirements. Compliance is demonstrated via the following licensing approach:

• Dedicate the generic SPINLINE 3 digital safety I&C platform, which was not originally developed

under a 10CFR50 Appendix B QA program.

Consistent with the basic requirements for commercial dedication as defined in 10CFR21 (Reference 1-12), Rolls-Royce is employing the commercial dedication processes described in EPRI TR-107330 (Reference 1-3) and TR-106439 (Reference 1-13) and approved by the NRC (References 1-4 and 1-14).

The suitability of SPINLINE 3 for dedication is documented in the Design Analysis Report (DAR, Reference 1-5) and the Dedication Plan (Reference 1-15)

The generic SPINLINE 3 platform is managed under a 10CFR50 Appendix B quality program during and after dedication.

• Qualify SPINLINE 3 hardware to meet U.S. standards. The SPINLINE 3 hardware will be qualified and maintained under the 10CFR50 Appendix B quality program. If new boards are developed or existing boards modified for obsolescence or other reasons, the new or modified hardware will be appropriately tested and/or analyzed to maintain equipment qualification to U.S. standards.

• Develop plant-specific application software in accordance with software life cycle plans that are compliant with NRC Branch Technical Position (BTP) 7-14 (Reference 1-2)

• The non-Class 1E set of software tools, which are used as design aids and not as a replacement for verification and validation (V&V), are not dedicated but continue to be subject to a configuration management program.

1.2 Organization of this Licensing Topical Report

This LTR is organized as follows:

• Chapter 1, Introduction: This chapter provides and overview of the LTR and identifies the

numerous supporting documents that will be submitted for NRC review. This chapter also provides an overview of the quality program and the quality process employed to dedicate the generic SPINLINE 3 platform software and hardware.

• Chapter 2, SPINLINE 3 Development and Operational History: This chapter provides an overview of SPINLINE 3 development and operational use in many French and international NPPs where it is currently deployed in a variety of digital safety I&C applications. This historical information is intended to illustrate the substantial legacy of safety I&C developments that led to the SPINLINE 3 digital safety I&C platform, which is the subject of this LTR.

• Chapter 3, Regulations, Codes and Standards: This chapter provides summaries of SPINLINE 3 compliance with the U.S. and international regulations, codes and standards listed or referenced in the NRC Standard Review Plan, Table 7-1, “Regulatory Requirements, Acceptance Criteria, and Guidelines for Instrumentation and Control Systems Important to Safety” (Reference 1-6) plus additional standards referenced in this LTR. Detailed compliance matrices for selected regulations, codes and standards are provided in Appendix A. This chapter and Appendix A serve as a


compliance roadmap and include references to where additional compliance details are provided in this LTR or other supporting documents submitted by Rolls-Royce for NRC review.

• Chapter 4, Description of the SPINLINE 3 Digital Safety I&C Platform: This chapter provides generic descriptions of the hardware and software that comprise the SPINLINE 3 digital safety I&C platform. In addition, details are provided on how digital communications and testability are implemented in SPINLINE 3. Data sheets for individual SPINLINE 3 hardware items are provided in Appendix B of this LTR.

• Chapter 5, Equipment Qualification and Analysis: This chapter provides an overview of the generic equipment qualification program, which is described in detail in the Equipment Qualification (EQ) Plan (Reference 1-7). The SPINLINE 3 qualification “envelope” is generic and is intended to meet or exceed the environmental qualification requirements for NPPs in the U.S using the EPRI TR-107330 criteria. The EQ Plan defines the Qualification Test Specimen (QTS) and the specific test procedures and the resulting test reports for each test. This chapter also provides: (1) a summary of the board / device-level reliability analysis process and results reported separately, and (2) an overview of the setpoint analysis support information reported separately.

• Chapter 6, Software Development Process for SPINLINE 3 Platform Software and Application Software: This chapter describes the development history and the software life cycle processes applicable to the SPINLINE 3 platform software (i.e., the standard OSS, the application-oriented library of re-usable software components, embedded software in the NERVIA+ board and ICTO Pulse Input board, and the CLARISSE SSDE). The software life cycle processes used for the SPINLINE 3 platform software were developed in the mid-1980s in connection with the development of digital safety I&C systems for the EDF P4 and N4 fleets of PWRs. These software life cycle processes are examined in more detail in the Design Analysis Report (DAR, Reference 1-5).This chapter also describes the separate software life cycle processes for plant-specific application software. These processes comply with NRC Branch Technical Position (BTP) 7-14 (Reference 1-2).

• Appendix A, Compliance Matrices: This appendix contains the detailed compliance matrices referenced in Chapter 3.

• Appendix B, SPINLINE 3 Hardware Data Sheets: This appendix contains the data sheets for SPINLINE 3 standard hardware items described in Section 4.3.

In this document, brackets (“[[ ]]”) denote proprietary information. In the proprietary document, the two brackets denoting the end of a proprietary segment of this report may appear one or more pages following the bracket indicating the start of the proprietary segment. In the nonproprietary edition of this document, the material within the brackets is removed.

1.3 Supporting SPINLINE 3 Licensing Documents

The NRC Interim Staff Guide DI&C ISG-06 (Reference 1-16) is intended to inform licensees of the information and documentation the NRC staff could need for its review of license amendment requests (LARs) for digital l&C upgrades and when the information should be provided. ISG-06 is intended for a plant-specific LAR for an actual digital safety I&C system upgrade. Some interpretation is needed to identify the subset of documentation that applies to a generic licensing review of a digital safety I&C platform, in this case, the SPINLINE 3 digital safety I&C platform produced by Rolls-Royce. This interpretation is made in Rolls-Royce document 3 011 552 A (Reference 1-17), which has been submitted to the NRC. As defined in more detail in document 3 011 552 A, Rolls-Royce will submit the following categories of licensing documents to the NRC:


• Hardware Qualification Documents: The key document is the Equipment Qualification (EQ) Plan (Reference 1-7), which describes the testing performed to qualify standard SPINLINE 3 hardware in accordance with NRC requirements. The specific hardware tested is defined in the EQ Plan and the System Specification for the Qualification Test Specimen (QTS) and Test System (Reference 1-8). The EQ Plan summarizes the many test procedures and identifies the resulting test reports, which will be submitted as separate documents.

• Hardware Analysis Documents: These analysis documents provide the generic foundations for plant-specific failure mode and effects criticality analysis (FMECA), reliability analysis, and setpoint analysis.

• Quality Plans: There are two relevant 10CFR50 Appendix B-compliant Quality Plans. The “Rolls-Royce Civil Nuclear SAS Quality Manual” (Reference 1-9) establishes the quality processes employed in the Meylan, France factory. The Rolls-Royce “Instrumentation & Controls US Quality Manual” (Reference 1-11) establishes the corresponding quality processes employed in the U.S. to deliver SPINLINE 3 systems to U.S. customers.

• Design Analysis Report (DAR): The DAR (Reference 1-5) examines how the platform software life cycle processes described in LTR Chapter 6, and the resulting software product described in LTR Chapter 4 compare to the product one would expect if development had been done originally under a 10CFR50 Appendic B quality program and BTP 7-14 software life cycle processes. In connection with the DAR, reviews were performed of the following:

o The processes under which the platform software was developed,

o The quality of the software tools used in developing the platform software,

o The processes used to generate the platform software,

o The quality and extent of the software documentation for the platform software,

o The quality of the software tools used in generating the application software

o The processes used to generate the application software, and

o The applicable processes used in designing the SPINLINE 3 hardware, including the use of programmable logic.

The favorable DAR findings on these matters support the Rolls-Royce decision to dedicate the SPINLINE 3 platform software.

• Dedication Procedure and Plan: These documents define the process employed by Rolls-Royce for commercially dedicating the generic SPINLINE 3 platform hardware and platform software and report the results of dedication.

• SPINLINE 3 Platform Software Life Cycle Plans: These Plans define the software life cycle processes that were used by Rolls-Royce to create the SPINLINE 3 generic platform software, which is commercially dedicated as defined in the Dedication Procedure and Plan.

• Application Software and Systems Life Cycle Plans: These Plans implement NRC BTP 7-14 (Reference 1-2) in the Rolls-Royce software and system life cycle processes employed for plant-specific SPINLINE 3 systems.

1.4 QUALITY PROGRAM

The Instrumentation & Controls business of Rolls-Royce with office located in Meylan, France (and refered to as I&C France) is the supplier, qualifier and dedicator of SPINLINE 3 hardware, software, and integrated systems. The Instrumentation & Controls business of Rolls-Royce with office located in Huntsville, Alabama, USA (and referered to as I&C US) will deliver SPINLINE 3 systems to U.S. customers.

Software quality plans and other software and system life cycle plans are addressed in Chapter 6.


1.4.1 Rolls-Royce Nuclear Quality Program in France

The nuclear QA program employed at I&C France originally was developed based on European nuclear QA standards. This original QA program has been improved to provide full compliance with 10CFR50 Appendix B (Reference 1-1) while preserving the basic structure of the original QA program.

To start the process of bringing the original nuclear QA program into compliance with 10CFR50 Appendix B, the firm MPR Associates performed a gap analysis in 2004 relative to EPRI TR-107330 (Reference 1- 3) and recommended several enhancements to the nuclear QA program, including 10CFR21.21 (b) (Reference 1-12) defect reporting. This gap analysis is discussed in the DAR (Reference 1-5), which has been submitted to the NRC.

Rolls-Royce made the corresponding changes to bring their nuclear QA program into compliance with 10CFR50 Appendix B and then submitted their nuclear QA program to an audit by the firm Global Quality Assurance. In addition, this quality program was audited by I&C US to qualify I&C France as a supplier of SPINLINE 3 hardware, software and systems. These audits demonstrated that the nuclear QA program employed at I&C France complies with the requirements of 10CFR50 Appendix B.

Rolls-Royce activities now are performed under the 10CFR50 Appendix B-compliant quality program documented in the “Rolls-Royce Civil Nuclear SAS Quality Manual” (Reference 1-9). The correspondence between 10CFR50 Appendix B, ASME NQA-1-1994 (Reference 1-10) and the Rolls-Royce quality procedures is described in Section 3.2.

1.4.2 Rolls-Royce Nuclear Quality Program in the USA

I&C US activities are performed under the 10CFR50 Appendix B-compliant quality program documented in the “Instrumentation & Controls US Quality Manual” (Reference 1-11). The correspondence between 10CFR50 Appendix B, ASME NQA-1-1994 and the I&C US quality procedures is provided in Section 3.2.

• I&C France was qualified as a supplier under this I&C US QA program.

• This quality program has been audited by U.S. utilities, NUPIC, and Department of Energy’s Idaho National Laboratory

I&C US will deliver SPINLINE 3 systems to U.S. customers, with I&C France acting as a supplier. I&C US will be responsible for defect reporting to the NRC, as required by 10CFR21.21 (b), with timely input from the I&C France.

1.5 Chapter 1 References

1-1 10CFR50 Appendix B, “Quality Assurances Requirements for Nuclear Power Plants and Fuel Reprocessing Plants”

1-2 NRC Branch Technical Position 7-14, Rev, 5, “Guidance on Software Reviews for Digital Computer Based Instrumentation and Control Systems,” US Nuclear Regulatory Commission, March 2007

1-3 EPRI TR-107330, “Generic Requirements Specification for Qualifying a Commercially Available PLC for Safety-Related Applications in Nuclear Power Plants,” Electric Power Research Institute, December 1996

1-4 USNRC Letter dated July 30, 1998 to Mr. J. Naser (EPRI), “Safety Evaluation by the Office of Nuclear Reactor Regulation Electric Power Research Institute (EPRI) Topical Report, TR-107330,


Final Report, “Generic Requirements Specification for Qualifying a Commercially Available PLC for Safety-Related Applications in Nuclear Power Plants.”

1-5 “SPINLINE 3 Design Analysis Report,” Document No. MPR-3337, MPR Associates, Inc., June 2009

1-6 NUREG-0800, USNRC Standard Review Plan, Table 7-1, “Regulatory Requirements, Acceptance Criteria, and Guidelines for Instrumentation and Control Systems Important to Safety,” Revision 5, March 2007

1-7 “Equipment Qualification Plan”, Document No. 3 006 501D, I&C France, May 2010

1-8 “System Specification of the Qualification Test Specimen and Data Acquisition System”, Document No. 3 006 404 E, I&C France, April 2010

1-9 “Rolls-Royce Civil Nuclear SAS Quality Manual”, Document No. 8 303 186 P, I&C France, June 2009

1-10 ASME NQA-1-1994, “Quality Assurance Program Requirements for Nuclear Facilities”, American Society of Mechanical Engineers

1-11 “Instrumentation & Controls US Quality Manual”, Revision C, Document 500-9600000-10, ICQ-005-C, I&C US, June 2009

1-12 10CFR21.21, “Notification of failure to comply or existence of a defect and its evaluation”

1-13 EPRI TR-106439, “Guideline on Evaluation and Acceptance of Commercial Grade Digital Equipment for Nuclear Safety Applications”, Electric Power Research Institute, October 1996

1-14 USNRC Letter dated July 17, 1997 to Mr. Raymond C. Torok (EPRI), “Review of EPRI Topical Report TR-106439, “Guideline on Evaluation and Acceptance of Commercial Grade Digital Equipment for Nuclear Safety Applications (TAC No. M94127)”

1-15 “Dedication Plan for the Generic SPINLINE 3 Digital Safety I&C Platform”, 3 010 794 A, I&C France, December 2009

1-16 Interim Staff Guide DI&C-ISG-06, Task Working Group #6: Licensing Process” (draft), U.S. Nuclear Regulatory Commission, March 2009

1-17 “Map of ISG-06 Tier 3 Submittal Guidance to Generic SPINLINE 3 Digital Safety I&C Platform Licensing Documents,” 3 011 552 A, I&C France, March 2010


2 SPINLINE 3 Development and Operational History

2.1 Overview

Rolls-Royce has been designing and manufacturing safety I&C systems for nuclear power plants for more than 30 years. Rolls-Royce originally developed non-software-based analog safety I&C systems for the Électricité de France (EDF) fleet of 900 MW PWRs. In the 1980s, Rolls-Royce designed and deployed two generations of software-based digital safety I&C systems for EDF’s later fleet of P4 and N4 PWRs. SPINLINE 3 is the next generation of Rolls-Royce digital safety I&C systems.

This chapter provides an overview of SPINLINE 3 development and operational use in the many French and international NPPs where it is currently deployed in a variety of digital safety I&C applications. This historical information is intended to illustrate the substantial legacy of safety I&C developments that led to the SPINLINE 3 digital safety I&C platform, which is the subject of this LTR.

From the beginning, Rolls-Royce hardware components and systems were designed, implemented and qualified in compliance with European nuclear standards, including the International Atomic Energy Agency (IAEA) 50-C-QA code for quality assurance (Reference 2-1) and the French national code RCC-E (Reference 2-2), which prescribes requirements for qualification of electrical equipment used in French-built nuclear power plants.

The Rolls-Royce safety software evolved in stages to adapt to the introduction of new digital components and software methods and tools. These evolutionary stages started with software development “from scratch” using low-level manual coding and have now matured into processes based on high-level languages, including application-oriented languages, code re-use and automated code generation. The SPINLINE 3 safety-related platform software was developed based on the guidance of the IEC 880-1986 (Reference 2-3) with enhancements to take into account the advances in software engineering, which were later reflected in the supplement to IEC 880 issued in 2000 (Reference 2-4) and in IEC 60880 Edition 2 (Reference 2-5).

As discussed in Chapter 1, the SPINLINE 3 platform software originally developed under European nuclear safety standards has been dedicated and is now managed under the Rolls-Royce Civil Nuclear SAS 10CFR50 Appendix B-compliant QA program. As described in Section 5.1, the standard SPINLINE 3 hardware is qualified to meet current U.S. regulatory requirements. New plant-specific application software will be developed using the BTP 7-14-compliant software life cycle processes described in Section 6.4.


2.2 Evolution of the SPINLINE 3 Digital Safety I&C Platform

2.2.1 Non Software-Based Safety I&C

Based on a Westinghouse design, 34 three-loop 900 MW pressurized water reactors were commissioned in France by EDF between 1978 and 1987. Rolls-Royce designed, manufactured, and is still maintaining nonsafety and safety I&C systems developed using non-software-based technologies such as MULTIBLOC for nuclear instrumentation and SILIMOG for logic functions.

2.2.2 First Generation of Software-Based Safety I&C

The EDF P4 project resulted in commissioning 20 four-loop 1,300 MW PWRs in France between 1984 and 1993. The overall I&C design made intensive use of software-based technologies for control and protection functions. In particular, Rolls-Royce developed a modular software-based technology to implement the Reactor Protection System (RPS) and Engineered Safety Features Actuation System (ESFAS). When combined, these two systems are known as the SPIN (Système de Protection Intégré Numérique), which is a French acronym for “Digital Integrated Protection System”.

This technology uses the Motorola 6800 microprocessor with unidirectional and asynchronous communication links for data exchange. A single P4 unit’s SPIN system has 52 safety processing units distributed in a four channel architecture. Today, 20 P4 SPIN systems are in operation with a total of 1,040 safety processing units. P4 SPIN systems have accumulated 450 reactor-years of operation as of December 2009.

The P4 SPIN software consists of about 40,000 instructions written in 6800 assembly code. This software includes the application software performing the processing of the safety functions, and the Operational System Software (OSS) that performs data acquisition, actuator control, data communication, and hardware self-supervision functions.

The P4 SPIN software was developed using life cycle processes targeted to produce “close to zero faults” software. The main features are:

• A “V” model software development cycle;

• A top-down modular design;

• Design and coding rules aimed at developing reliable software;

• A Verification and Validation (V&V) team independent of the software design team;

• The verification of all design documents and source code;

• “White box” unit testing of all the software modules, achieving 100% branch coverage; and

• “Black box” validation testing performed at the processing unit level, channel/division/train level, and system level.

This main software development effort took place during the years 1981 and 1982 and was performed according to the guidance in working drafts of the future IEC 880 standard, which was intended to


significantly improve the reliability of software used for the implementing nuclear safety functions. The feedback of experience gained on the P4 project was a major input to this IEC 880 standard which was eventually issued in 1986 (Reference 2-3).

2.2.3 Second Generation of Software-Based Safety I&C

The EDF N4 project deployed 1450 MW four-loop PWRs with a fully-computerized Main Control Room (MCR) that implemented new I&C technologies.

For the N4 NPPs, Rolls-Royce developed a new generation of its software-based safety I&C system technology, called N4 SPIN, which is based on the Motorola (now Freescale) MC68000 family of microprocessors and on an Rolls-Royce proprietary high-speed deterministic communications network called NERVIA. The main improvements relative to the P4 SPIN technology were:

• A reduction in the number of separate functional processing units, from seven for P4 to five for N4,

enabled by the greater processing power of the 68000 microprocessor;

• The NERVIA digital communications network, which allowed for a significant reduction of electronic boards and wiring; and

• The implementation of software-based voting units for both the RPS and the ESFAS actuators.

A single N4 unit’s SPIN system uses 40 safety processing units used in a four channel / two output train system architecture. Today, four N4 SPIN systems are in operation with a total of 160 safety processing units. The same digital safety I&C technology is also employed in the protection systems of 11 research reactors.

The N4 SPIN has been in operational use since the first N4 plant commissioning tests in 1991 and has been in commercial operation since 1996. N4 SPIN systems have accumulated 50 reactor-years of operation as of December 2009.

The N4 SPIN software consists of about 200,000 instructions implemented in C language, most of them generated from 200 graphical views created using a proprietary Functional Block Diagram (FBD) language named SAGA.

As for the P4 project, the N4 software was developed with the objective of producing “close to zero faults” software, using basically the same software life cycle processes, but with intensive use of software tools for the tasks that could be automated or assisted.

This main software development effort for the N4 project took place during the years 1988 and 1989 and was performed according to the guidance provided in IEC 880-1986 (Reference 2-3). The basic processes for developing the N4 safety software have not changed since the P4 project. However, process changes were made to take into account the evolution in languages and tools used for the N4 project and evolution in software engineering processes not explicitly required in IEC 880-1986, such as requirements for dedicated software plans.

Section 6.1 provides insights into the N4 software development process and its relevance to the SPINLINE3 platform.


2.2.4 Third Generation of Software-Based Safety I&C - SPINLINE 3

After the N4 project, the Rolls-Royce software-based I&C technology was enhanced to improve performance and quality while simplifying the manufacturing processes. The main improvements relative to the N4 SPIN technology are:

• Hardware:

• New electromagnetic compatibility (EMC) proofed chassis, cabling, and terminal blocks, and

• Additional CPU, input / output (I/O) and communication boards

• Software:

• Configurable Operational System Software (OSS),

• An enhanced software engineering tool set, including a platform-dedicated tool to configure and set the parameters for the processing units and NERVIA networks, and

• A non-proprietary version of the SAGA environment called the Safety Critical Application Development Environment (SCADE), developed and maintained by the software company Esterel Technologies.

This technology is referred to as SPINLINE 3.

SPINLINE 3 has been implemented successfully for the refurbishment of Class 1E I&C systems on several models of PWR NPPs and on several Russian-designed NPPs, including both VVER and RBMK. SPINLINE 3 also is deployed in safety I&C systems on several new PWRs in the Republic of China. SPINLINE 3 systems have accumulated 200 reactor-years of operation as of December 2009.

The SPINLINE 3 platform was developed between 1993 and 1996, based on the N4 technology. It includes enhancements to the N4 hardware and the development of platform software and tools needed to produce an adaptable safety I&C platform suitable for use worldwide in refurbishment of existing NPP safety I&C systems and for new construction safety I&C systems.

The life cycle processes for the SPINLINE 3 platform software were established according to the guidance provided in IEC 880-1986 (Reference 2-3), and were documented in dedicated software plans. The SPINLINE 3 software life cycle processes also took into account additional process enhancements employed on the N4 project and ongoing standardization works for a supplement to IEC 880, which was issued in 2000 (Reference 2-4). The SPINLINE 3 software life cycle processes are further described in Section 6.2. As described in Chapter 1, the SPINLINE 3 platform software has been dedicated for use in systems delivered to U.S. customers and is now managed under the Rolls-Royce Civil Nuclear SAS 10CFR50 Appendix B QA Program.

The application software for a nuclear safety I&C system implemented using the SPINLINE 3 platform is developed according to a set of plant-specific software life cycle plans that are consistent with current NRC guidance in BTP 7-14 (Reference 2-6). Details on these SPINLINE 3 application software plans are presented in Section 6.4.

The experience gained at Rolls-Royce in developing several safety I&C systems using the SPINLINE 3 digital I&C platform was an input to the revision of IEC 880-1986, which started in 2001 and was completed in 2006 as IEC 60880 Edition 2 (Reference 2-5). The project leader for this revision was from Rolls-Royce


2.3 Rolls-Royce Safety I&C Installations

By the end of 2009, the main safety I&C systems implemented with the SPINLINE 3 technology are:

• New Nuclear Instrumentation Systems (NIS) for two Chinese PWRs • Modernized NIS for six French PWRs and for one Belgian PWR • Modernized safety I&C including RTS, ESFAS and support functions for four Czech VVER 440/213

NPPs • A new diverse protection system for one Lithuanian RBMK

Other SPINLINE 3 installations include source range NIS modernization at two VVER 440/213 NPPs in Bulgaria and Safety Relief Valve Control and NIS system modernization at one VVER 440/213 NPP in Armenia.

A summary of Rolls-Royce nuclear I&C references collectively implemented with all technologies is provided in Table 2.3-1.


2-1 IAEA Safety Series 50-C-QA, Rev. 1 , “Code on the Safety of Nuclear Power Plants: Quality Assurance,” International Atomic Energy Agency (IAEA), 1988

2-2 French National Code RCC-E (Règles de Construction et de Conception des Matériels Electriques), Chapter B, “Design and Construction Rules for Electronic Components of PWR Nuclear Islands”

2-3 IEC 880-1986, “Software for Computers in the Safety Systems of Nuclear Power Stations,” International Electrotechnical Commission

2-4 IEC 60880-2000, “Software for Computers important to safety for Nuclear Power Plants – part 2: Software aspects of defense against common cause failure, use of software tools and of pre-developed software”, International Electrotechnical Commission

2-5 IEC 60880-2006, “Software for Computers in the Safety Systems of Nuclear Power Plants”, International Electrotechnical Commission

2-6 NRC Branch Technical Position 7-14, Rev, 5, “Guidance on Software Reviews for Digital Computer Based Instrumentation and Control Systems,” US Nuclear Regulatory Commission, March 2007


Table 2.3-1: Rolls-Royce Nuclear I&C Installations

Safety Class 1E Equipment

Cou

ntry

Util

ity

NP

P ID

Rea

ctor

Ty

pe

Sta

rt of

O

ps.

Tech

nolo

gy

RTS

&

ESFA

S

Neu

tron

Det

ecto

rs

Neu

tron

Inst

r. D

iese

l S

eque

ncin

g

Rea

ctor

Trip

Br

eake

rs

Armenia JSC Armenia NPP Metsamor VVER 5/31/1980 SPINLINE 3 × ×

Electrabel Doel 1 PWR 8/28/1974 ANALOG ×




Electrabel Tihange 1 PWR 3/7/1975 SPINLINE 3 × ×

Electrabel Tihange 2 PWR 10/13/1982 ANALOG ×

Belgium

Electrabel Tihange 3 PWR 6/14/1985 ANALOG ×

National Electricity Co Kozloduy 3 VVER 12/17/1980 SPINLINE 3 × × Bulgaria

National Electricity Co Kozloduy 4 VVER 5/1/1982 SPINLINE 3 × ×

Brazil CTMSP Copesp R&D N4 × ×

GNP JVC Daya Bay 1 PWR 8/31/1993 ANALOG × ×

GNP JVC Daya Bay 2 PWR 2/7/1994 ANALOG × ×

Ling Ao Nuclear Power Co

Ling Ao 1 PWR 2/4/2002 ANALOG × × ×

China

Ling Ao Nuclear Power Co

Ling Ao 2 PWR 12/1/2002 ANALOG × × ×




Cou

ntry

Util

ity

NP

P ID

Rea

ctor

Ty

pe

Sta

rt of

O

ps.

Tech

nolo

gy

RTS

&

ESFA

S

Neu

tron

Det

ecto

rs

Neu

tron

Inst

r. D

iese

l S

eque

ncin

g

Rea

ctor

Trip

Br

eake

rs

Qinshan Nuclear Power Co

Qinshan II 1 PWR 2/6/2002 SPINLINE 3 × ×

Qinshan Nuclear Power Co

Qinshan II 2 PWR 2/4/2004 SPINLINE 3 × ×

Ceske Energeticke Zavody (CEZ)

Dukovany 1 VVER 2/24/1985 SPINLINE 3 × × × × ×





Czech Republic



France EDF Belleville 1 PWR 10/14/1987 P4 × × × ×

EDF Belleville 2 PWR 7/6/1988 P4 × × × ×

EDF Blayais 1 PWR 6/12/1981 ANALOG × × ×




EDF Bugey 2 PWR 5/10/1978 SPINLINE 3 × × ×




Cou

ntry

Util

ity

NP

P ID

Rea

ctor

Ty

pe

Sta

rt of

O

ps.

Tech

nolo

gy

RTS

&

ESFA

S

Neu

tron

Det

ecto

rs

Neu

tron

Inst

r. D

iese

l S

eque

ncin

g

Rea

ctor

Trip

Br

eake

rs




CEA Cadarache / Cabri R&D N4 × × ×

CEA Cadarache / Eole R&D N4 × × ×

CEA Cadarache / Mazurka

R&D N4 × × ×

CEA Cadarache / Minerve

R&D N4 × × ×

CEA Cadarache / Phoebus

R&D N4 × × ×

EDF Cattenom 1 PWR 11/13/1986 P4 × × × ×




EDF Chinon B1 PWR 11/30/1982 ANALOG × × ×






Cou

ntry

Util

ity

NP

P ID

Rea

ctor

Ty

pe

Sta

rt of

O

ps.

Tech

nolo

gy

RTS

&

ESFA

S

Neu

tron

Det

ecto

rs

Neu

tron

Inst

r. D

iese

l S

eque

ncin

g

Rea

ctor

Trip

Br

eake

rs


EDF Chooz B1 PWR 8/30/1996 N4 × × × × ×

EDF Chooz B2 PWR 4/10/1997 N4 × × × × ×

EDF Civaux 1 PWR 12/24/1997 N4 × × × × ×

EDF Civaux 2 PWR 12/24/1999 N4 × × × × ×

EDF Creys-Malville FBR ANALOG × ×

EDF Cruas 1 PWR 4/29/1983 ANALOG × × ×




EDF Dampierre 1 PWR 3/23/1980 ANALOG × × ×




EDF Fessenheim 1 PWR 4/6/1977 SPINLINE 3 × × ×

EDF Fessenheim 2 PWR 10/7/1977 SPINLINE 3 × × ×

EDF Flamanville 1 PWR 12/4/1985 P4 × × × ×




Cou

ntry

Util

ity

NP

P ID

Rea

ctor

Ty

pe

Sta

rt of

O

ps.

Tech

nolo

gy

RTS

&

ESFA

S

Neu

tron

Det

ecto

rs

Neu

tron

Inst

r. D

iese

l S

eque

ncin

g

Rea

ctor

Trip

Br

eake

rs

EDF Flamanville 2 PWR 7/18/1986 P4 × × × ×

EDF Golfech 1 PWR 6/7/1990 P4 × × × ×

EDF Golfech 2 PWR 6/18/1993 P4 × × × ×

EDF Gravelines 1 PWR 3/13/1980 ANALOG × × ×






CEA Marcoule / Celestin 1

R&D N4 × × ×

CEA Marcoule / Celestin 2

R&D N4 × × ×

EDF Nogent 1 PWR 10/21/1987 P4 × × × ×

EDF Nogent 2 PWR 12/14/1988 P4 × × × ×

EDF Paluel 1 PWR 6/22/1984 P4 × × × ×

EDF Paluel 2 PWR 9/14/1984 P4 × × × ×

EDF Paluel 3 PWR 9/30/1985 P4 × × × ×




Cou

ntry

Util

ity

NP

P ID

Rea

ctor

Ty

pe

Sta

rt of

O

ps.

Tech

nolo

gy

RTS

&

ESFA

S

Neu

tron

Det

ecto

rs

Neu

tron

Inst

r. D

iese

l S

eque

ncin

g

Rea

ctor

Trip

Br

eake

rs

EDF Paluel 4 PWR 4/11/1986 P4 × × × ×

EDF Penly 1 PWR 5/4/1990 P4 × × × ×

EDF Penly 2 PWR 2/4/1992 P4 × × × ×

EDF Phénix FBR 12/13/1973 ANALOG × ×

CEA Saclay / Isis R&D N4 × × ×

CEA Saclay / Osiris R&D N4 × × ×

CEA Saclay / Orphée R&D N4 × × ×

EDF Saint Alban 1 PWR 8/30/1985 P4 × × × ×

EDF Saint Alban 2 PWR 7/3/1986 P4 × × × ×

EDF Saint Laurent B1 PWR 1/21/1981 ANALOG × × ×

EDF Saint Laurent B2 PWR 6/1/1981 ANALOG × × ×

EDF Tricastin 1 PWR 5/31/1980 ANALOG × × ×




Lithuania Ignalina NPP Ignalina 2 RBMK 8/20/1987 SPINLINE 3 × × ×

South Eskom Koeberg 1 PWR 4/4/1984 ANALOG × ×




Cou

ntry

Util

ity

NP

P ID

Rea

ctor

Ty

pe

Sta

rt of

O

ps.

Tech

nolo

gy

RTS

&

ESFA

S

Neu

tron

Det

ecto

rs

Neu

tron

Inst

r. D

iese

l S

eque

ncin

g

Rea

ctor

Trip

Br

eake

rs

Africa Eskom Koeberg 2 PWR 7/25/1985 ANALOG × ×

Korea Hydro Ulchin 1 PWR 4/7/1988 ANALOG × x South Korea

Korea Hydro Ulchin 2 PWR 4/14/1989 ANALOG × x

Centrales Nucleares Almaraz-Trillo

Almaraz 1 PWR 5/1/1981 ANALOG ×

Centrales Nucleares Almaraz-Trillo

Almaraz 2 PWR 10/8/1983 ANALOG ×

Asociación Nuclear Asco-Vandellos A.I.E.

Asco 1 PWR 8/13/1983 ANALOG ×


Asco 2 PWR 10/23/1985 ANALOG ×

Spain


Vandellos 2 PWR 12/12/1987 ANALOG ×

Number of NPPs 101 Number 39 101 88 8 64


3 Regulations, Codes and Standards

3.1 Compliance Summary

A summary of NRC regulatory requirements and acceptance criteria for instrumentation and control (I&C) systems important to safety is found in Standard Review Plan Table 7-1 (Reference 3-1). Rolls-Royce reviewed this table to define the scope of the regulatory requirements and acceptance criteria that applied to the generic SPINLINE 3 digital safety I&C platform. Several of the items listed in SRP Table 7-1 apply to application-specific safety I&C systems. Compliance with application-specific regulatory requirements cannot be assessed in the context of a generic digital safety I&C platform that does not include the specific applications. The screening performed by Rolls-Royce of the SRP Table 7-1 regulatory requirements to identify the subset that is applicable to the generic SPINLINE 3 digital safety I&C platform is documented in Table 3.1-1 in Appendix A.

Also included in Table 3.1-1 are the following addition items not found in SRP Table 7-1:

• 10 CFR 50.49

• 10 CFR 50 Appendix B

• 10 CFR 73.54

• Regulatory Guides 1.89, 1.100, 1.153, and 1.209

• Digital Instrumentation and Controls Interim Staff Guides (DI&C-ISGs)-01, -02, -04, -05, and -06

This chapter provides summary compliance statements for the applicable NRC regulatory requirements listed in Table 3.1-1, including the industry standards and other documents that are endorsed by Regulatory Guides or referenced in Branch Technical Positions. Table 3.1-1, which identifies the LTR sections where the compliance statement can be found, and the following supporting tables are provided in Appendix A.

• Table 3.2-1 10 CFR 50 Appendix B and ASME NQA-1-1994 Map to Corresponding I&C France QA Plans & Procedures

• Table 3.2-2 10 CFR 50 Appendix B and ASME NQA-1-1994 Map to Corresponding I&C US QA Plans & Procedures

• Table 3.6-1 Responses to NUREG/CR-6082 Communications System Questions

• Table 3.7-1 Interim Staff Guide DI&C-ISG-04, Revision 1 Compliance Matrix

• Table 3.8-1 IEEE Standard 7-4.3.2-2003 Compliance Matrix

• Table 3.8-2 IEEE Standard 603-1991 Compliance Matrix

• Table 3.8-3 Mapping SPINLINE 3 SQP MC3 and Other Content to IEEE 730-1998 SQAP Content Guidance

• Table 3.8-4 Mapping SPINLINE 3 SMQP and Other Content to IEEE 730-1998 SQAP Content Guidance


• Table 3.8-5 Mapping SPINLINE 3 Application SQAP and Other Content to IEEE 730-1998 SQAP Content Guidance

• Table 3.8-6 Mapping SPINLINE 3 SQP MC3 and Other Content to IEEE 828-1998 SCMP Content Guidance

• Table 3.8-7 Mapping SPINLINE 3 Platform SCMP and Other Content to IEEE 828-1998 SCMP Content Guidance

• Table 3.8-8 Mapping SPINLINE 3 Application SCMP and Other Content to IEEE 828-1998 SCMP Content Guidance

• Table 3.8-9 Mapping SPINLINE 3 SQP MC3 and Other Content to IEEE 1012-1998 SVVP Content Guidance

• Table 3.8-10 Mapping SPINLINE 3 SMQP and Other Content to IEEE 1012-1998 SVVP Content Guidance

• Table 3.8-11 Mapping SPINLINE 3 Application SVVP and Other Content to IEEE 1012-1998 SVVP Content Guidance

• Table 3.8-12 Alignment of IEEE 1074-1995 Activities, ISG-06 Tier 3 Document Guidance, and SPINLINE 3 Documents

• Table 3.10-1 IEC 880-1986 Appendix B Compliance Matrix

• Table 3.10-2 Comparison of IEC 880-1986 and NRC Branch Technical Position 7-14 Requirements

3.2 10 CFR , Code of Federal Regulations

3.2.1 10 CFR 50, Domestic Licensing of Production and Utilization Facilities

3.2.1.1 50.34(f)(2)(v) [I.D.3], Bypass and Operable Status Indication

Plant-specific applications of the SPINLINE 3 digital safety I&C platform will comply with the requirement to provide automatic indication of the bypassed and operable status of safety systems. The generic SPINLINE 3 platform supports indications in the main control room and hardwired discrete outputs can be provided as described in Section 4.6.2.

3.2.1.2 50.49, Environmental Qualification of Electric Equipment Important to Safety for Nuclear Power Plants

50.49 identifies specific requirements for qualification of electric equipment important to safety. Regulatory Guide 1.89 describes methods acceptable to the NRC for complying with 50.49. SPINLINE 3 compliance with RG 1.89 is addressed in Section 3.3.6.

3.2.1.3 50.55a(a)(1), Quality Standards for Systems Important to Safety

The basic requirement is that structures, systems, and components must be designed, fabricated, erected, constructed, tested, and inspected to quality standards commensurate with the importance of the safety


function to be performed. The SPINLINE 3 digital safety I&C platform is intended for use in Class 1E safety I&C applications.

As described in Section 1.4, the I&C France and I&C US quality systems that governs all SPINLINE 3 activities are compliant with 10 CFR 50 Appendix B and ASME NQA-1-1994. See Sections 3.2.3 and 3.13 for compliance details.

3.2.1.4 50.55a(h)(2), Protection Systems (IEEE Standard 603-1991 or IEEE Standard 279-1971)

As required in 50.55a(h)(2), the SPINLINE 3 digital safety I&C platform complies with IEEE Standard 603-1991. IEEE Standard 603 compliance is addressed in Section 3.8.9 and in Table 3.8-2.

3.2.1.5 50.55a(h)(3), Safety Systems (IEEE Std 603-1991)

As required by 50.55a(h)(3), the SPINLINE 3 digital safety I&C platform complies with IEEE Standard 603-1991. IEEE Standard 603 compliance is addressed in Section 3.8.9 and Table 3.8-2.

3.2.1.6 10 CFR 50 Appendix A, General Design Criteria (GDCs)

3.2.1.6.1 GDC 1, Quality Standards and Records

The basic requirement is that structures, systems, and components shall be designed, fabricated, erected, constructed, tested, and inspected to quality standards commensurate with the importance of the safety function to be performed. The generic SPINLINE 3 digital safety I&C platform is intended for use in Class 1E safety I&C applications.

The SPINLINE 3 digital safety I&C platform complies with GDC 1. The applicable quality standards are 10 CFR 50 Appendix B and ASME NQA-1-1994. See Sections 3.2.3 and 3.13 for compliance details.

3.2.1.6.2 GDC 2, Design Bases for Protection Against Natural Phenomena

The basic requirement is that structures, systems, and components important to safety shall be designed to withstand the effects of a range of natural phenomena without loss of capability to perform their safety functions. The SPINLINE 3 digital safety I&C platform is intended for use in Class 1E safety I&C applications.

The SPINLINE 3 digital safety I&C platform complies with GDC 2. The generic qualification program for SPINLINE 3 is described in Section 5.1, with more details in the Equipment Qualification (EQ) Plan (Reference 3-2).

The licensee for a plant-specific application of the SPINLINE 3 digital safety I&C platform will address the correspondence of the generic qualification envelope for SPINLINE 3 with the site-specific qualification bounding envelopes.


3.2.1.6.3 GDC 4, Environmental and Dynamic Effects Design Bases

The basic requirement is that structures, systems, and components important to safety shall be designed to accommodate the effects of and to be compatible with the environmental conditions associated with normal operation, maintenance, testing, and postulated accidents, including loss-of-coolant accidents.

The SPINLINE 3 digital safety I&C platform complies with GDC 4. The SPINLINE 3 digital safety I&C platform is qualified for use in mild environments, as described in Section 5.1 and in the Equipment Qualification (EQ) Plan (Reference 3-2).

3.2.1.6.4 GDC 13, Instrumentation and Control

The SPINLINE 3 digital safety I&C platform complies with GDC 13. As described in Section 4.3, the standard input boards enable the design of SPINLINE 3 systems that can monitor a wide range of variables and systems over their anticipated ranges for normal operation, for anticipated operational occurrences, and for accident conditions as appropriate to assure adequate safety.

The licensee for a plant-specific application of the SPINLINE 3 digital safety I&C platform will address how the monitoring and control capability provided is appropriate to assure adequate safety.

3.2.1.6.5 GDC 20, Protection System Functions

Plant-specific safety I&C systems implemented on the generic SPINLINE 3 digital safety I&C platform will provide the capability to comply with GDC 20. The standard SPINLINE 3 hardware described in Section 4.3, the software described in Sections 4.4 to 4.6 and the software life cycle processes described in Chapter 6 are the foundations for designing and implementing plant-specific safety I&C systems that accomplish the GDC 20 safety functions.

The licensee for a plant-specific application of the SPINLINE 3 digital safety I&C platform will define the specific system functions to be performed.

3.2.1.6.6 GDC 21, Protection Systems Reliability and Testability

Plant-specific safety I&C systems implemented on the generic SPINLINE 3 digital safety I&C platform will comply with GDC 21.

SPINLINE 3 is designed for high functional reliability. A summary board/device-level hardware reliability is provided in Section 5.2 along with references to the separate detailed analyses.

The SPINLINE 3 software is designed to be highly reliable. The platform software life cycle processes are described in Sections 6.2 an 6.3 and are assessed in the Design Analysis Report (DAR, Reference 3-3). The BTP 7-14 compliant application software life cycle processes are described in Section 6.4.

The in-service testing and periodic testing features of SPINLINE 3 are described in Sections 4.4, 4.5 and 4.6.

The standard SPINLINE 3 hardware and software described in Section 4.3 can be readily employed in system architectures with redundant and independent divisions that comply with the single failure criterion.


The licensee for a plant-specific application of the SPINLINE 3 digital safety I&C platform will define the specific means for complying with the GDC 21 requirements for redundancy and independence.

3.2.1.6.7 GDC 22, Protection System Independence

Plant-specific safety I&C systems implemented on the generic SPINLINE 3 digital safety I&C platform can comply with GDC 22. SPINLINE 3 systems have the requisite independence of divisions to ensure that a fault in one independent division does not propagate and affect other redundant divisions. Representative SPINLINE 3 single division and four division architectures are described in Section 4.2.4. SPINLINE 3 inter-divisional communications also comply with Interim Staff Guide DI&C-ISG-04 recommendations, as described in Section 3.7.

Likewise, SPINLINE 3 systems have the requisite independence to ensure that a postulated fault in a connected non-safety I&C system does not propagate and affect the safety I&C system. As described in Section 4.5, this is accomplished by a one-way (broadcast only) communication link from the safety I&C system to the non-safety I&C system. In addition, SPINLINE 3 output relays can be connected to non-Class 1E systems. The Class 1E / non-Class 1E isolation capability of these relays is verified through qualification testing, which is described in Section 5.1 and the Equipment Qualification (EQ) Plan (Reference 3-2).

Standard SPINLINE 3 hardware is qualified for a mild operating environment, with a generic qualification envelope as described in Section 5.1 and in the EQ Plan. Operation within this envelope will not result in loss of the protection function.

The in-service testing and periodic testing features of SPINLINE 3 are described in Section 4.4, 4.5 and 4.6. With appropriate redundancy in an actual system, maintenance and testing activities will not result in loss of the protection function.

Diversity and defense-in-depth should be addressed in the context of an NPP’s suite of safety and non-safety I&C systems. SPINLINE 3 can employ signal diversity.

The design and implementation of SPINLINE 3 digital communications described in Section 4.5 enables independence to be maintained between redundant divisions and between the safety I&C system and non-safety I&C systems. The inter-divisional communications provisions also comply with Interim Staff Guide DI&C-ISG-04, as described in Section 3.7.4.

The licensee for a plant-specific application of the SPINLINE 3 digital safety I&C platform will address compliance with GDC 22 requirements for protection system independence. Diversity and defense-in-depth will be addressed in the context of the plant-specific suite of safety and non-safety I&C systems.

3.2.1.6.8 GDC 23, Protection System Failure Modes

Plant-specific safety I&C systems implemented on the generic SPINLINE 3 digital safety I&C platform have the capability to comply with GDC 23. Modes of operation of the SPINLINE 3 Operational System Software (OSS) are described in Section 4.4.3.4, which also explains the behavior of the OSS when a failure is detected.

As discussed in Section 5.2, board-level Failure Mode and Effects Analyses (FMEAs) are documented in separate reports. The licensee for a plant-specific application of the SPINLINE 3 digital safety I&C platform will address system-level failure modes.


3.2.1.6.9 GDC 24, Separation of Protection and Control Systems

The design and implementation of SPINLINE 3 digital communications described in Section 4.5 enables separation to be maintained between the safety I&C system and non-safety I&C systems. These communications provisions also comply with Interim Staff Guide DI&C-ISG-04, as described in Section 3.7.4.

The licensee for a plant-specific application of the SPINLINE 3 digital safety I&C platform will address compliance with GDC 24.

3.2.1.6.10 GDC 25, Protection System Requirements for Reactivity Control Malfunctions

Plant-specific safety I&C systems implemented on the generic SPINLINE 3 digital safety I&C platform have the capability to comply with GDC 25. The specific variables to be monitored and the associated processing logic must be determined on a plant-specific basis.

3.2.1.6.11 GDC 29, Protection Against Anticipated Operational Occurrences

The generic SPINLINE 3 digital safety I&C platform can comply with GDC 29. Operating experience with SPINLINE 3 systems and the previous generations of Rolls-Royce digital safety I&C systems described in Chapter 2 has shown no instances where the capability of the safety I&C system to perform its intended safety function(s) was compromised during an anticipated operational occurrence.

3.2.1.7 10 CFR 50 Appendix B, Quality Assurances Requirements for Nuclear Power Plants and Fuel Reprocessing Plants

As described in Section 1.4, the requirements of 10 CFR 50 Appendix B and NQA-1-1994 are implemented in the I&C France Quality Management Plan (Reference 3-4) and the I&C US Quality Manual (Reference 3-5). A map showing the correspondence between 10 CFR 50 Appendix B, ASME NQA-1-1994, and the I&C France quality procedures is provided in Table 3.2-1. A similar map showing the correspondence between 10 CFR 50 Appendix B, ASME NQA-1-1994, and the I&C US quality procedures is provided in Table 3.2-2.

3.2.2 Title 10 CFR 73.54, Protection of Digital Computer and Communication Systems and Networks

Cyber security is not addressed in this document. Refer instead to the compliance statement for Regulatory Guide 1.152 in Section 4.10. Cyber security for a plant-specific SPINLINE 3 system will be addressed by the licensee.


3.3 USNRC Division 1 Regulatory Guides

3.3.1 Regulatory Guide (RG) 1.22, Revision 0, Periodic Testing of Protection System Actuation Functions

The SPINLINE 3 digital safety I&C platform complies with RG 1.22. The periodic testing features of SPINLINE 3 are described in Section 4.6.

3.3.2 Regulatory Guide 1.47, Revision 0, Bypassed and Inoperable Status Indication for Nuclear Power Plant Safety System

Plant-specific applications of the SPINLINE 3 digital safety I&C platform will comply with the requirement to provide automatic indication of the bypass or inoperable status of portions of the protection system. This feature is described in Section 4.6.2.

In plant-specific applications, compliance with RG 1.47 requires further determinations that bypass or inoperable status is also provided for the following:

• Systems actuated or controlled by the protection system

• Auxiliary or supporting systems that must be operable for the protection system and the systems it actuates to perform their safety functions.

RG 1.47 endorses IEEE Standard 279-1971 with qualifications. As allowed in 50.55a(h)(2), the generic SPINLINE 3 digital safety I&C platform complies instead with IEEE Standard 603-1991, "Criteria for Safety Systems for Nuclear Power Generating Stations," and the correction sheet dated January 30, 1995. See Section 3.8.9 and Table 3.8-2 for IEEE 603-1991 compliance.

3.3.3 Regulatory Guide 1.53, Revision 2, Application of the Single-Failure Criterion to Safety Systems

RG 1.53 endorses IEEE 379-2000 with qualifications (see Section 3.8.7). The standard SPINLINE 3 hardware described in Section 4.3 and the software described in Sections 4.4 through 4.6 can be implemented in system architectures with redundant and independent channels, divisions and trains that comply with the single failure criterion. Representative SPINLINE 3 single division and four division architectures are described in Section 4.2.4. The specific means for complying with the single failure criterion must be assessed on a plant-specific basis.

3.3.4 Regulatory Guide 1.62, Revision 0, Manual Initiation of Protection Actions

The standard SPINLINE 3 hardware described in Section 4.3 and the software described in Sections 4.4 through 4.6 can be implemented with manual initiation features that comply with RG 1.62. The generic provisions for manual initiation are described in Section 4.3.4.5. Specific manual initiation features must be defined on a plant-specific basis.

RG 1.62 endorses IEEE Standard 279-1971 with qualifications. As allowed in 50.55a(h)(2), the SPINLINE 3 digital safety I&C platform complies with IEEE Standard 603-1991, "Criteria for Safety Systems for Nuclear


Power Generating Stations," and the correction sheet dated January 30, 1995. See Section 3.8.9 and Table 3.8-2 for IEEE 603-1991 compliance.

3.3.5 Regulatory Guide 1.75, Revision 3, Criteria for Independence of Electrical Safety Systems

RG 1.75 endorses IEEE Standard 384-1992 with qualifications (see Section 3.8.8). The standard SPINLINE 3 hardware described in Section 4.3 and the software described in Sections 4.4 through 4.6 are designed to establish and maintain the independence of safety-related equipment, circuits, and auxiliary supporting features by physical separation and electrical isolation. In a plant-specific application, this is accomplished by physically separating the redundant divisions of the safety system.

Representative SPINLINE 3 architectures are described in Section 4.2.4. These typical architectures include the inter-divisional communication interfaces that are needed to support voting logic. As described in Section 4.5, inter-divisional communications is accomplished using fiber optic links that maintain the electrical isolation between divisions and NERVIA communication boards that maintain the required logical data isolation between divisions.

Electrical independence between Class 1E and non-Class 1E digital systems also is established by means of fiber optic links. As described in Section 4.5.7, data isolation is assured by implementing logical data isolation in the Class 1E systems as well as providing only one-way (broadcast only) communication links from the Class 1E system to the non-Class 1E system.

3.3.6 Regulatory Guide 1.89, Revision 1, “Environmental Qualification of Certain Electric Equipment Important to Safety for Nuclear Power Plants”

This RG describes methods acceptable to the NRC for complying with 10 CFR 50.49 with regard to qualification of electric equipment important to safety for service in NPPs. These methods ensure the equipment can perform its safety function during and after a design basis accident. This RG endorses IEEE Standard 323-1974, “IEEE Standard for Qualifying Class 1E Equipment for Nuclear Power Stations” with qualifications (see Section 3.8.3).

As described in Section 5.1 and the Equipment Qualification (EQ) Plan (Reference 3-2), SPINLINE 3 is qualified for mild environments. Qualification testing of SPINLINE 3 is performed in accordance with the IEEE Standard 323-2003 subject to the enhancements and exceptions listed in Section C, “Regulatory Position” of RG 1.209, “Guidelines for Environmental Qualification of Safety Related Computer-Based Instrumentation and Control Systems in Nuclear Power Plants” (see Section 3.3.19)

3.3.7 Regulatory Guide 1.100, Revision 2, Seismic Qualification of Electric and Mechanical Equipment for Nuclear Power Plants

This RG endorses IEEE Standard 344-1987, “IEEE Recommended Practice for Seismic Qualification of Class 1E Equipment for Nuclear Power Generating Stations,” with qualifications (see Section 3.8.5).

As described in Section 5.1 and the Equipment Qualification (EQ) Plan (Reference 3-2), seismic qualification testing of SPINLINE 3 is performed in accordance with the IEEE Standard 344-1987 using the generic seismic spectra documented in EPRI technical report TR-107330 (see Section 3.12.1).


3.3.8 Regulatory Guide 1.105, R3, Setpoints for Safety-Related Instrumentation

This RG endorses Instrument Society of America (ISA) Standard S67.04-1994, “Methodology for the Determination of Setpoints for Nuclear Safety-Related Instrumentation,” with qualifications (see Section 3.9.1).

As described in Section 5.2.3, EPRI TR-107330, Section 4.2.4 requires the qualifier to provide information about the qualified hardware to support an application specific setpoint analysis per ISA S67.04. Section 5.2 describes the approach Rolls-Royce, as both vendor and qualifier, used for preparing the setpoint analysis support documentation for the SPINLINE 3 digital safety I&C platform. This documentation provides sufficient design specification data for a setpoint analysis to be performed on a plant-specific SPINLINE 3 system.

Compliance of actual system setpoints with ISA S67.04-1994 will be addressed by the licensee on a plant-specific basis.

3.3.9 Regulatory Guide 1.118, Revision 3, Periodic Testing of Electric Power and Protection Systems

This RG endorses IEEE Standard 338-1987 with qualifications. As provided in IEEE Standard 338, automatic testing provisions for programmable digital computer-based systems are subject to the testing provisions of this standard and IEEE Standard 7-4.3.2-2003. See Section 3.8.1 for compliance with IEEE Standard 7-4.3.2.

3.3.10 Regulatory Guide 1.152, Criteria for Use of Computers in Safety Systems of Nuclear Power Plants

Both the Revision 2 version of this RG and the proposed draft Revision 3 (DG-1249) version endorse IEEE Standard 7-4.3.2-2003 with qualifications.

Compliance of the SPINLINE 3 software design with IEEE Standard 7-4.3.2-2003, “Standard Criteria for Digital Computers in Safety Systems of Nuclear Power Generating Stations” is addressed in Section 3.8.1 and Table 3.8-1.

The software life cycle processes applied in Rolls-Royce provide protection against unauthorized, unintended, and unsafe modifications to the software, thereby promoting integrity and reliability during operation and maintenance,.

As described in Section 4.7, the generic SPINLINE 3 platform has been designed as the foundation for plant-specific digital safety I&C systems that will implement nuclear safety functions. The design of the generic SPINLINE 3 platform and the application software life cycle processes applied through the factory test phase also accomplish computer security functions by: (a) providing inherent protection against unauthorized, unintended, and unsafe modifications to the system, and (b) implementing design requirements that promote integrity and reliability during operation and maintenance in the event of inadvertent operator actions or undesirable behavior of connected equipment.

Compliance with Regulatory Guide 1.152 regulatory draft Revision 3 (DG-1249) positions 2.1 to 2.5 is documented separately in the document SPINLINE 3 Secure Development and Operational Environment (Reference 3-6).

3.3.11 Regulatory Guide 1.153, Revision 1, Criteria for Safety Systems

This RG endorses IEEE Standard 603-1991 and the correction sheet of January 30, 1995. Refer to Section 3.8.9 and Table 3.8-1 for compliance with IEEE Standard 603 and the correction sheet.


3.3.12 Regulatory Guide 1.168, Revision 1, Verification, Validation, Reviews and Audits for Digital Computer Software Used in Safety Systems of Nuclear Power Plants

This RG endorses IEEE Standard 1012-1998 and IEEE 1028-1997 with qualifications.

The verification and validation (V&V) process for the SPINLINE 3 platform software was established according to the guidance provided in IEC 880-1986 (see Section 3.10 for compliance matrix), and was documented in dedicated V&V plans and reports, which are described in Section 6.2. As described in Chapter 1, the SPINLINE 3 platform software has been dedicated for use in systems delivered to U.S. customers and is now managed under the I&C France 10CFR50 Appendix B QA Program.

As described in Section 6.4, the V&V process for the SPINLINE 3 application software complies with RG 1.168 and IEEE Standard 1012-1998. See Section 3.8.14 for a mapping of the generic SPINLINE 3 application software V&V process with IEEE Standard 1012-1998. The specific V&V activities for application software will be defined on a plant-specific basis in connection with implementation of a safety application.

3.3.13 Regulatory Guide 1.169, Revision 0, Configuration Management Plans for Digital Computer Software Used in Safety Systems of Nuclear Power Plants

This RG endorses IEEE Standard 828-1990 and IEEE Standard 1042-1987 with qualifications.

The configuration management (CM) process for the SPINLINE 3 platform software was established according to the guidance provided in IEC 880-1986 (see Section 3.10 for compliance matrix), and was documented in dedicated CM plans and reports, which are described in Section 6.2. As described in Chapter 1, the SPINLINE 3 platform software has been dedicated for use in systems delivered to U.S. customers and is now managed under the I&C France 10CFR50 Appendix B QA Program. See Section 3.8.10 for a mapping of the SPINLINE 3 platform software CM process with IEEE Standard 828-1990.

As described in Section 6.4, the configuration management process for the SPINLINE 3 application software complies with RG 1.169 and IEEE Standard 828-1990. See Section 9.11 for a mapping of the generic SPINLINE 3 application software CM process with IEEE Standard 828-1990. The specific configuration management activities for application software will be defined on a plant-specific basis in connection with implementation of a safety application.

3.3.14 Regulatory Guide 1.170, Revision 0, Software Test Documentation for Digital Computer Software Used in Safety Systems of Nuclear Power Plants

This RG endorses IEEE Standard 829-1983 with qualifications.

The test documentation for the SPINLINE 3 platform software was established according to the guidance provided in IEC 880-1986 (see Section 3.10 for compliance matrix), and was documented in dedicated test plans and reports, which are described in Section 6.2. As described in Chapter 1, the SPINLINE 3 platform software has been dedicated for use in systems delivered to U.S. customers and is now managed under the I&C France 10CFR50 Appendix B QA Program.

As described in Section 6.4, the test documentation for the SPINLINE 3 application software complies with RG 1.170. Test activities for SPINLINE 3 application software consist of the following: • Unit / component level tests

• Integration and system-level factory testing.

• System-level site acceptance testing


The specific testing activities for application software will be defined on a plant-specific basis in connection with implementation of a safety application.

3.3.15 Regulatory Guide 1.171, Revision 0, Software Unit Testing for Digital Computer Software Used in Safety Systems of Nuclear Power Plants


The SPINLINE 3 platform software and application software are subject to verification and validation (V&V) testing that includes unit (component) testing, as described in Section 6.2.2.5 (OSS) and 6.4.4 (application software). As described in Section 6.2.9, the application-oriented library of re-usable components were developed using the same software life cycle processes as the OSS.

3.3.16 Regulatory Guide 1.172, Revision 0, Software Requirements Specifications for Digital Computer Software Used in Safety Systems of Nuclear Power Plants


The Software Requirements Specification (SRS) for the SPINLINE 3 platform software described in Section 6.2 was established according to the guidance provided in IEC 880-1986 (see Section 3.10 for compliance matrix), As described in Chapter 1, the SPINLINE 3 platform software has been dedicated for use in systems delivered to U.S. customers and is now managed under the I&C France 10CFR50 Appendix B QA Program.

As discussed in Section 6.4, the application software SRS will be developed on a plant-specific basis. The licensee is responsible for demonstrating that the SRS follows the guidance contained in this RG and in the endorsed IEEE Standard 830.

3.3.17 Regulatory Guide 1.173, Revision 0, Developing Software Life Cycle Processes for Digital Computer Software Used in Safety Systems of Nuclear Power Plants

This RG endorses IEEE Standard 1074-1995 with qualifications. This RG, BTP 7-14 and the IEEE Standard 1074 provide a structured approach for developing a software life cycle program consistent with this regulatory guidance.

The life cycle processes for the SPINLINE 3 platform software were established according to the guidance provided in IEC 880-1986 (see Section 3.10 for compliance matrix), and were documented in dedicated software plans, which are described in Section 6.2. The SPINLINE 3 software life cycle processes also took into account additional process enhancements employed by Rolls-Royce on the EDF N4 project (the second-generation Rolls-Royce digital safety I&C system, which preceded SPINLINE 3) and ongoing standardization works for a supplement to IEC 880, which was issued in 2000. Based on the analysis reported in the SPINLINE 3 Design Analysis Report (DAR, Reference 3-3) and the IEEE Standard 1074-1995 compliance presented in Section 3.8.18, Rolls-Royce concludes that the platform software life cycle processes comply with the intent of IEEE Standard 1074, Regulatory Guide 1.173 and BTP 7-14. As described in Chapter 1, the SPINLINE 3 platform software has been dedicated for use in systems delivered to U.S. customers and is now managed under the I&C France 10CFR50 Appendix B QA Program.


The generic application software life cycle Plan templates described in Section 6.4 implement the structured approach, described in RG 1.173. While the RG and IEEE Standard 1074 do not specify the completion of specific documents, BTP 7-14 places emphasis on the output documents as a means to demonstrate successful completion of a life cycle process. The corresponding output documents for the SPINLINE 3 application software life cycle are identified in Section 6.4.

3.3.18 Regulatory Guide 1.180, Revision 1, Guidelines for Evaluating Electromagnetic and Radio- Frequency Interference in Safety-Related Instrumentation and Control Systems

This RG endorses IEC 61000, MIL-STD-461E, IEEE Standard 1050-1996, IEEE Standard C62.41-1991, and IEEE Standard C62.45-1992 with qualifications.

As described in Section 5.1 and in the Equipment Qualification (EQ) Plan (Reference 3-2), EMI/RFI testing of the SPINLINE 3 Qualification Test Specimen (QTS) will be performed in accordance with RG 1.180 revision 1. Grounding and shielding is in accordance with IEEE Standard 1050 (see Section 3.8.17). The specific test plans and test levels are described in the EQ Plan, Appendices F, G, H and I:

3.3.19 Regulatory Guide 1.209, Revision 0, Guidelines for Environmental Qualification of Safety-Related Computer-Based Instrumentation and Control Systems in Nuclear Power Plants

This RG endorses IEEE Standard 323-2003 with qualifications. As described in Section 5.1 and the Equipment Qualification (EQ) Plan (Reference 3-2), qualification testing of the SPINLINE 3 is performed in accordance with IEEE Standard 323-2003, subject to the enhancements and exceptions listed in Section C, “Regulatory Position” of RG 1.209.

3.3.20 Regulatory Guide 5.71, Revision 0, Cyber Security for Nuclear Facilities

Cyber security is not addressed in this LTR. Refer instead to the compliance statement for Regulatory Guide 1.152 in Section 3.3.10. Cyber security for a plant-specific SPINLINE 3 system will be addressed by the licensee.

3.4 NUREG-0800, Chapter 7, Revision 5 Branch Technical Positions (BTPs)

3.4.1 BTP 7-8, Revision 5, Guidance on Application of Regulatory Guide 1.22

As noted in Section 3.3.1, SPINLINE 3 complies with RG 1.22. The SPINLINE 3 digital safety I&C platform also complies with IEEE Standard 603. Refer to Section 3.8.9 for a discussion on IEEE Standard 603 compliance. The periodic testing features of SPINLINE 3 are described in Section 4.6.

3.4.2 BTP 7-11, Revision 5, Guidance on Application and Qualification of Isolation Devices

As described in Section 4.3, SPINLINE 3 uses the following types of qualified isolation devices: (1) fiber optic cables, and (2) relays. Signal isolation within the NERVIA network is discussed in the Digital Instrumentation and Controls Interim Staff Guidance (DI&C ISG)-4 compliance matrix in Section 3.7.4. Qualification is described in Section 5.1 and in the Equipment Qualification (EQ) Plan (Reference 3-2).


3.4.3 BTP 7-12, Revision 5, Guidance on Establishing and Maintaining Instrument Setpoints

EPRI TR-107330, Section 4.2.4 requires the qualifier to provide information about the qualified hardware to support an application specific setpoint analysis per ISA 67.04. Section 5.2. describes how Rolls-Royce, as both vendor and qualifier, applied this approach and prepared a setpoint analysis support document for the generic SPINLINE 3 digital safety I&C platform. This documentation is intended to provide sufficient design specification data for a plant-specific setpoint analysis to be performed.

3.4.4 BTP 7-14, Revision 5, Guidance on Software Reviews for Digital Computer-Based Instrumentation and Control Systems

BTP 7-14, Regulatory Guide 1.173 and IEEE Standard 1074-1995 provide a structured approach for developing software life cycle processes that are consistent with NRC regulatory guidance.

The life cycle processes for the SPINLINE 3 platform software were established according to the guidance provided in IEC 880-1986 (see compliance matrix in Section 3.10), and were documented in dedicated software plans, which are described in Section 6.2. The SPINLINE 3 software life cycle processes also took into account additional process enhancements employed by Rolls-Royce on the EDF N4 project and ongoing standardization works for a supplement to IEC 880, which was issued in 2000. Based on the analysis in the Design Analysis Report (DAR, Reference 3-3) and the IEEE Standard 1074-1995 compliance matrix presented in 3.8.18, Rolls-Royce concludes that the platform software life cycle processes comply with the intent of Regulatory Guide 1.173, IEEE Standard 1074, and BTP 7-14. As described in Chapter 1, the SPINLINE 3 platform software has been dedicated for use in systems delivered to U.S. customers and is now managed under the I&C France 10CFR50 Appendix B QA Program.

Rolls-Royce application software life cycle plans and processes comply with BTP 7-14. Refer to Section 6.4 for a mapping of the BTP 7-14 software plans to the equivalent Rolls-Royce software plans. Also in Section 6.4 is an identification of the outputs from the Rolls-Royce software life cycle processes.

3.4.5 BTP 7-17, Revision 5, Guidance on Self-Test and Surveillance Test Provisions

SPINLINE 3 self-diagnostic test and surveillance test provisions comply with BTP 7-17, as discussed in Sections 4.4, 4.5 and 4.6.

3.4.6 BTP 7-19, Revision 5, Guidance on Evaluation of Diversity and Defense-in-Depth in Digital Computer-Based Instrumentation and Control Systems

The licensee for a plant-specific application of the SPINLINE 3 digital safety I&C platform will address diversity and defense-in-depth in the context of the plant-specific suite of safety and non-safety I&C systems. SPINLINE 3 systems have the capability to implement signal diversity.

3.4.7 BTP 7-21, Revision 5, Guidance on Digital Computer Real-Time Performance

The generic SPINLINE 3 digital safety I&C platform addresses all of the concerns raised in this BTP:

• The SPINLINE 3 architecture provides for reliable system operation and appropriate separation and independence of divisions. See example architectures in Section 4.2.4. Specific system architecture will be determined on a plant-specific basis.

• Deterministic communications inherent in SPINLINE 3 systems guarantees system response time. See Section 4.5.


• The generic setpoint analysis support documentation described in Section 5.2 will provide a single, concise listing of the design specifications data for the SPINLINE 3 digital safety I&C platform. This will be an input to the setpoint analyses done for plant-specific SPINLINE 3 systems.

• The design basis for a SPINLINE 3 system will be defined on a plant-specific basis.

3.5 USNRC Staff Requirements Memos (SRMs)

3.5.1 SRM to SECY 93-087, II.Q, Defense Against Common-Mode Failures in Digital Instrumentation and Control Systems

Refer to the BTP 7-19 discussion in Section 3.4.6.

3.6 USNRC NUREGs and NUREG/CRs

3.6.1 NUREG/CR 6082, Data Communications

Section 2 of NUREG/CR-6082 has 15 questions intended to help focus reviews of data communication systems. Table 3.6-1 provides an evaluation the SPINLINE 3 platform for those questions.

3.7 USNRC Digital I&C Interim Staff Guides (ISGs)

3.7.1 DI&C-ISG-01, Rev. 0, Cyber Security

Cyber security is not addressed in this LTR. Refer instead to the compliance statement for Regulatory Guide 1.152. Cyber security for a plant-specific SPINLINE 3 system will be addressed by the licensee.

3.7.2 DI&C-ISG-02, Rev. 1, Diversity and Defense-in-Depth (D3)

The licensee for a plant-specific application of the SPINLINE 3 digital safety I&C platform will address diversity and defense-in-depth in the context of the plant-specific suite of safety and non-safety I&C systems. SPINLINE 3 systems can employ signal diversity.

3.7.3 DI&C-ISG-04, Rev. 1, Highly Integrated Control Rooms – Digital Communication Systems

The generic SPINLINE 3 digital safety I&C platform and application-specific SPINLINE 3 systems will comply with DI&C-ISG-04 requirements regarding inter-divisional communication. The generic SPINLINE 3 digital safety I&C platform does not include priority logic for command prioritization. The generic design supports


multi-divisional communication only in divisional voting logic and divisional display processors as described in Section 4.2.4. Refer to the DI&C-ISG-04 compliance matrix in Table 3.7-1.

3.7.4 DI&C-ISG-06, Draft, Licensing Process

The documents submitted by Rolls-Royce for the NRC generic review of the SPINLINE 3 digital safety I&C platform are consistent with the guidance in the May 2009 draft DI&C-ISG-06, which lists the documents expected for a plant-specific review. Many of the listed documents do not apply to the generic Tier 3 review of a digital safety I&C platform. Compliance with the ISG-06 guidance is reported in Rolls-Royce document “Mapping of Generic SPINLINE 3 Licensing Documents to the ISG-06 Submittal Guidance” (Reference 3-7).

3.8 Institute of Electrical & Electronics Engineers (IEEE) Standards

3.8.1 IEEE Standard 7-4.3.2-2003, Standard Criteria for Digital Computers in Safety Systems of Nuclear Power Generating Stations

This standard is endorsed by Regulatory Guide 1.152 with the exception of Annexes B to F. Conformance with the requirements of IEEE 7-4.3.2-2003 is a method that the NRC staff has deemed acceptable for satisfying the NRC’s regulations with respect to high functional reliability and design requirements for computers used in the safety systems of nuclear power plants.

The life cycle processes for the SPINLINE 3 platform software were established according to the guidance provided in IEC 880-1986 (see Section 3.10 for compliance matrix), and were documented in dedicated software plans, which are described in Section 6.2. The SPINLINE 3 software life cycle processes also took into account additional process enhancements employed by Rolls-Royce on the EDF N4 project and ongoing standardization works for a supplement to IEC 880, which was issued in 2000.

While not in strict compliance with the life cycle defined in IEEE Standard 7-4.3.2, the life cycle processes used in developing the SPINLINE 3 platform software provides equivalent protection and high quality through production of similar documents and performance of reviews, testing, verification, validation, and quality assurance activities. A mapping of IEEE Standard 7-4.3.2-2003 requirements to SPINLINE 3 platform software life cycle processes is presented in Table 3.8-1. As described in Section 1.1, Rolls-Royce has dedicated the SPINLINE 3 generic platform software. The technical basis for dedication is documented in a SPINLINE 3 Design Analysis Report (DAR, Reference 3-3).

3.8.2 IEEE Standard 279-1971, Criteria for Protection Systems for Nuclear Power Generating Stations

This standard is endorsed by 10CFR 50.55a(h)(2), Regulatory Guides 1.47 and 1.62. As required in 50.55a(h)(2), the SPINLINE 3 digital safety I&C platform complies with IEEE Standard 603-1991 instead of IEEE Standard 279-1971. See Section 3.8.9 for details.

3.8.3 IEEE Standard 323-2003, IEEE Standard for Qualifying Class 1E Equipment for Nuclear Power Generating Stations

This standard is endorsed by Regulatory Guide 1.209 with qualifications. An earlier edition, IEEE Standard 323-1974 is endorsed by RG 1.89.


As described in Section 5.1 and the Equipment Qualification (EQ) Plan (Reference 3-2), qualification testing of the SPINLINE 3 is performed in accordance with IEEE Standard 323-2003, subject to the enhancements and exceptions listed in Section C, “Regulatory Position” of RG 1.209.

3.8.4 IEEE Standard 338-1987, Criteria for the Periodic Surveillance Testing of Nuclear Power Generating Station Safety Systems

This standard is endorsed by Regulatory Guide 1.118 with qualifications.

As described in Section 4.6.7, periodic surveillance testing provisions of SPINLINE 3 comply with IEEE Standard 338-1987. A comparison of the coverage of self-diagnostic tests and periodic tests is provided in Section 4.6.8.4.

3.8.5 IEEE Standard 344-1987, IEEE Recommended Practice for Seismic Qualification of Class 1E Equipment for Nuclear Power Generating Stations


As described in Section 5.1 and the Equipment Qualification (EQ) Plan (Reference 3-2), seismic qualification testing of SPINLINE 3 is performed in accordance with IEEE Standard 344-1987.

3.8.6 IEEE Standard 352-1987, Guide for General Principles of Reliability Analysis of Nuclear Power Generating Station Safety Systems

As discussed in Section 5.2., generic board/module-level failure mode and effects analyses (FMEAs) meet the requirements of IEEE Standard 352, Sections 4.1, 4.4 and 4.5.

As discussed in Section 5.2, the methods of estimating reliability of components will be based on IEC TR 62380, “Reliability Data Handbook, Universal Model for Reliability Prediction of Electronics Components, PCBs and Equipment,” (see Section 3.10.3) instead of MIL HDBK 217F as suggested in IEEE Standard 352. The rationale for selecting IEC TR 62380 rather than MIL HDBK 217F is that the military handbook is significantly out of date, and has not been updated to reflect the evolution of modern electronics, while the IEC publication has been updated.

3.8.7 IEEE Standard 379-2000, Application of the Single-Failure Criterion to Nuclear Power Generating Station Safety Systems

IEEE Standard 379-2000 is endorsed by Regulatory Guide 1.53 with qualifications. The standard SPINLINE 3 hardware and software components described in Chapter 4 can be implemented in redundant and independent system architectures that comply with the single failure criterion. The specific means for complying with the single failure criterion must be assessed on a plant-specific basis.

3.8.8 IEEE Standard 384-1992, Standard Criteria for Independence of Class 1E Equipment and Circuits



The standard SPINLINE 3 hardware components described in Section 4.3 and software described in Section 4.4 through 4.6 are designed for establishing and maintaining the independence of safety-related equipment and circuits, and auxiliary supporting features by physical separation and electrical isolation. In a plant-specific application, this is accomplished by physically separating the redundant channels, divisions and trains of the safety system.

Example SPINLINE 3 architectures are described in Section 4.2.4. These typical architectures include the inter-divisional communication interfaces that are needed to support voting logics. Communications between redundant divisions and trains are isolated and designed to retain the required independence. As described in Section 4.5, inter-divisional communications is accomplished using fiber optic data links that maintain the electrical isolation between divisions.

The typical architectures described in Section 4.2.4 also include Class 1E to non-Class 1E communications interfaces. As described in Section 4.5.7, electrical isolation between the Class 1E system and the non-Class 1E system is accomplished using fiber optic data links and one-way (broadcast only) communications from the Class 1E system to the non-Class 1E system.

3.8.9 IEEE Standard 603-1991, Criteria for Safety Systems for Nuclear Power Generating Stations

This standard, with the January 30, 1995 correction sheet, is endorsed by 10 CFR 50.55a(h)(2) and Regulatory Guide 1.153. The generic SPINLINE 3 digital safety I&C platform and application-specific SPINLINE 3 systems comply with IEEE Standard 603. Refer to the IEEE Standard 603 compliance matrix in Table 3.8-2.

3.8.10 IEEE Standard 730-1998, IEEE Standard for Software Quality Assurance Plans

SPINLINE 3 SQAP documentation complies with the intent of IEEE 730-1998. A mapping of SPINLINE 3 software quality assurance plans to the SQAP content guidance in IEEE 730-1998 Section 4 is provided in the following tables, which provide maps for three distinctly different phases of SPINLINE 3 development:

• Table 3.8-3 addresses development of the original platform software in the mid-1990s

• Table 3.8-4 addresses future modifications of the generic platform software

• Table 3.8-5 addresses future development of plant-specific application software

3.8.11 IEEE Standard 828-1990, IEEE Standard for Software Configuration Management Plans

This standard is endorsed by Regulatory Guide 1.169 with qualifications. SPINLINE 3 SCMP documentation complies with the intent of IEEE 828-1990. A mapping of SPINLINE 3 software configuration management documentation to the SCMP content guidance in IEEE 828-1990 Section 4 is provided in the following tables, which provide maps for three distinctly different phases of SPINLINE 3 development:

• Tables 3.8-6 addresses development of the original platform software in the mid-1990s



Refer to the RG 1.169 compliance statement in Section 3.3.13.


3.8.12 IEEE Standard 829-1983, IEEE Standard for Software Test Documentation

This standard is endorsed by Regulatory Guide 1.170 with qualifications. Refer to the RG 1.170 compliance statement in Section 3.3.14.

3.8.13 IEEE Standard 830-1993, IEEE Recommended Practice for Software Requirements Specifications


3.8.14 IEEE Standard 1008-1987, IEEE Standard for Software Unit Testing


3.8.15 IEEE Standard 1012-1998, IEEE Standard for Software Verification and Validation Plans

This standard is endorsed by Regulatory Guide 1.168 with qualifications. SPINLINE 3 SVVP documentation complies with the intent of IEEE 1012-1998. A mapping of SPINLINE 3 software V&V documentation to the SVVP content guidance in IEEE1012-1998 Section 7 is provided in the following tables, which provide maps for three distinctly different phases of SPINLINE 3 development:

• Table 3.8-9 addresses development of the original platform software in the mid-1990s



Refer to the RG 1.168 compliance statement in Section 3.3.12.

3.8.16 IEEE Standard 1028-1997, IEEE Standard for Software Reviews and Audits


3.8.17 IEEE Standard 1042-1987, IEEE Guide to Software Configuration Management


3.8.18 IEEE Standard 1050-1996, Guide for Instrumentation and Control Equipment Grounding in Generating Stations

This standard is endorsed by Regulatory Guide 1.180, R1 with qualifications. The Qualification Test Specimen (QTS) grounding and shielding is described in the Equipment Qualification (EQ) Plan (Reference 3-2), in Appendices F, G, H, I and J. This grounding and shielding will be in accordance with the requirements of IEEE Standard 1050.


The licensee will describe the grounding and shielding for a plant-specific SPINLINE 3 system.

3.8.19 IEEE 1074-1995, IEEE Standard for Developing Software Life Cycle Processes


The SPINLINE 3 platform software was developed before this IEEE standard was published. The applicable life cycle processes are described in Section 6.2. The alignment of IEEE 1074-1995 activities and SPINLINE 3 life cycle process documents is presented in Table 3.8-11. This table also includes a mapping to ISG-06 software document guidance. Based on the mapping in this table and the analysis reported in the Design Analysis Report (DAR, Reference 3-3), Rolls-Royce concludes that the software life cycle processes software comply with the intent of IEEE Standard 1074 and with Regulatory Guide 1.173.

Also see Section 6.4 for a description of the application software life cycle processes, which comply with BTP 7-14.

3.9 Instrument Society of America (ISA) Standards

3.9.1 ISA Standard S67.04-1994, Setpoints for Nuclear Safety-Related Instrumentation Used in Nuclear Power Points


As described in Section 5.2.3, EPRI TR-107330, Section 4.2.4 requires the qualifier to provide information about the qualified hardware to support an application specific setpoint analysis per ISA S67.04. Section 5.2 describes the approach Rolls-Royce, as both vendor and qualifier, used to prepare the setpoint analysis support documentation for the SPINLINE 3 digital safety I&C platform. This documentation will provide sufficient design specification data for a setpoint analysis to be performed on a plant-specific SPINLINE 3 system.

3.10 International Electrotechnical Commission (IEC) Standards

3.10.1 IEC 880-1986, Software for Computers in the Safety Systems of Nuclear Power Stations

The life cycle processes for the SPINLINE 3 platform software were established according to the guidance provided in IEC 880-1986, and were documented in dedicated software plans, which are described in Section 6.2. The SPINLINE 3 software life cycle processes also took into account additional process enhancements employed by Rolls-Royce on the EDF N4 project and ongoing standardization works for a supplement to IEC 880, which was issued in 2000.


Table 3.10-1 provides the OSS compliance matrix with the design requirements of IEC 880-1986 Appendix B.

Table 3.10-2 provides a comparison of IEC 880-1986 requirements with the corresponding requirements from BTP 7-14.

3.10.2 IEC 61000, Electromagnetic Compatibility (EMC)

As described in the Section 5.1, EMI/RFI testing of the SPINLINE 3 Qualification Test Specimen (QTS) will be performed in accordance with RG 1.180, Revision 1, which endorses IEC 61000 and other standards. The Equipment Qualification Plan (Reference 3-2), Appendices F, G, H and I provide details on the specific IEC 61000 tests to be performed. Other EMI/RFI qualification tests are performed in accordance with MIL-STD-461E, which also is endorsed by RG 1.180, Revision 1.

3.10.3 IEC TR 62380, Reliability Data Handbook, Universal Model for Reliability Prediction of Electronics Components, PCBs and Equipment

As discussed in Section 5.2.2, the methods of estimating reliability of components will be based on IEC TR 62380 instead of MIL HDBK 217F, which is recommended in IEEE 352. The rationale for selecting IEC TR 62380 rather than MIL HDBK 217F is that the military handbook is significantly out of date, and has not been updated to reflect the evolution of modern electronics, while the IEC publication has been updated.

3.11 U.S. Military Standard

3.11.1 MIL-STD-461E, DOD Interface Standard Requirements for the Control of Electromagnetic Interference Characteristics of Subsystems and Equipment

EMI/RFI testing of the SPINLINE 3 Qualification Test Specimen (QTS) will be performed in accordance with USNRC RG 1.180, Revision 1, which endorses United States Military Standard 461, Revision E (MIL-STD-461E). See Section 5.1 and the Equipment Qualification (EQ) Plan (Reference 3-2), Appendix F, for the specific MIL-STD-461E tests to be performed. Other EMI/RFI qualification tests are performed in accordance with IEC 61000.

3.12 Electric Power Research Institute (EPRI) Technical Reports and Handbooks

3.12.1 EPRI TR-107330, Generic Requirements Specification for Qualifying a Commercially Available PLC for Safety-Related Applications in Nuclear Power Plants

The generic qualification approach described in Chapter 5 and in the Equipment Qualification (EQ) Plan (Reference 3-2) uses guidance from EPRI TR-107330, Section 4.3.9 to define the recommended seismic test levels for seismic testing in accordance with IEEE 344. These seismic test levels are implemented in EQ Plan Appendix E.


As described in Section 5.2.3, EPRI TR-107330, Section 4.2.4 requires the qualifier to provide information about the qualified hardware to support an application specific setpoint analysis per ISA S67.04. Section 5.2.3 describes the approach Rolls-Royce, as both vendor and qualifier, used to prepare the setpoint analysis support documentation for the SPINLINE 3 digital safety I&C platform. This documentation will not provide a setpoint methodology or generate setpoint values. Rather, this documentation provides sufficient design specification data for a setpoint analysis to be performed on a plant-specific SPINLINE 3 system

As described in Section 5.2.3, the component aging analysis described in EPRI TR-107330, Section 4.7.8.2 is not required for the standard SPINLINE 3 hardware, which will be installed in a mild environment, where repair is possible after an accident. Aging analysis is required only where equipment is installed in a harsh environment, where repair is not possible after an accident. Rolls-Royce will not comply with the incorrect guidance in EPRI TR-107330, Section 4.7.8.2.

The SPINLINE 3 platform software will be treated as the ‘legacy software’ described in Section 7.6 of EPRI TR-107330. Compensatory measures for legacy software are identified in EPRI TR-106439.

3.12.2 EPRI TR-106439, Guideline on Evaluation and Acceptance of Commercial Grade Digital Equipment for Nuclear Safety Applications

The dedication process defined in EPRI TR-106439 was implemented for the generic SPINLINE 3 digital safety I&C platform. Compliance with the EPRI TR-106439 process is demonstrated in the Dedication Plan (Reference 3-8). Appendix A of this Plan is a checklist that shows where the elements of the dedication process are addressed in SPINLINE 3 licensing documentation.

3.12.3 EPRI Handbook 1011710, Handbook for Evaluating Critical Digital Equipment and Systems

The generic SPINLINE 3 digital safety I&C platform and associated software life cycle processes were subject to a Critical Design Review (CDR) following the process defined in EPRI TR-1011710. The technical descriptive material to support the CDR was incorporated into this LTR. The results of the CDR are reported in the Design Analysis Report (Reference 3-3). A primary conclusion reported in the DAR was that, “…… there is more than sufficient evidence of design integrity, system integrity, and high quality development processes” for the SPINLINE 3 digital safety I&C platform. The CDR / DAR results support the Rolls-Royce decision to dedicate the generic SPINLINE 3 digital safety I&C platform.

3.13 American Society of Mechanical Engineers (ASME)

3.13.1 ASME NQA-1-1994, Quality Assurance Program Requirements for Nuclear Facilities

As described in Section 1.4, the requirements of 10CFR50 Appendix B and NQA-1-1994 are implemented in the I&C France Quality Management Plan (Reference 3-4) and the I&C US Quality Manual (Reference 3-5). A map showing the correspondence between 10CFR50 Appendix B, ASME NQA-1-1994, and the I&C France quality procedures is provided in Table 3.2-1. A similar map showing the correspondence between 10CFR50 Appendix B, ASME NQA-1-1994, and the I&C US quality procedures is provided in Table 3.2-2.



3-1 NUREG-0800, USNRC Standard Review Plan, Table 7-1, “Regulatory Requirements, Acceptance Criteria, and Guidelines for Instrumentation and Control Systems Important to Safety”, Revision 5, March 2007

3-2 “Equipment Qualification Plan”, Document No. 3 006 501 D, I&C France, May 2010

3-3 “SPINLINE 3 Design Analysis Report”, Document No. MPR-3337, MPR Associates, Inc., June 2009

3-4 “Rolls-Royce Civil Nuclear SAS Quality Manual”, Document No. 8 303 186 P, I&C France, June 2009

3-5 “Instrumentation & Controls US Quality Manual”, Revision C, Document 500-9600000-10, ICQ-005-C, I&C US, June 2009

3-6 “SPINLINE 3 Secure Development and Operational Environment”, Document No. 3 013 962 A, I&C France

3-7 “Mapping of Generic SPINLINE 3 Licensing Documents to the ISG-06 Submittal Guidance”, Document No. 3 011 552 A, I&C France, March 2010

3-8 “Dedication Plan for the Generic SPINLINE 3 Digital Safety I&C Platform”, Document No. 3 010 794 A, I&C France, 14 December 2009


4 Description of the SPINLINE 3 Digital Safety I&C Platform

4.1 Overview

The generic SPINLINE 3 digital safety I&C platform is comprised of standard hardware and software that forms the foundation for plant-specific SPINLINE 3 systems.

The generic SPINLINE 3 platform hardware is comprised of the following:

• Chassis

• Power Supply Modules

• Digital Processing Modules

• Communication Modules

• Signal Input Modules

• Signal Output Modules

• Signal Conditioning Modules

• Terminal Blocks

• Cable and Wire Sets

• Fan Cooling Hardware

• Power Distribution Hardware

The design and operation of these standard hardware items are described in Section 4.3. More details are provided in the hardware data sheets in Appendix B and in the set of board/device-level predictive reliability and safety analyses described in Section 5.2.

The generic SPINLINE 3 platform software is comprised of the following:

• The standardized, Class 1E configurable Operational System Software (OSS),

• The Class 1E application-oriented library of re-usable software components,

• The Class 1E software embedded in the NERVIA+ communications board,

• The Class 1E software embedded in the ICTO pulse input board.

The design and operation of these standard software items and their interfaces to the plant-specific application software are described in Section 4.4 to 4.6.

The particular hardware and software part / version numbers for these elements of the generic SPINLINE 3 digital safety I&C platform are specified in the Master Configuration List (MCL, Reference 4-18). Hardware part numbers also are included in the hardware data sheets in Appendix B.


4.1.1 Design Criteria

SPINLINE 3 has been designed to comply with U.S. and international nuclear safety I&C requirements. Compliance with 10 CFR 50, USNRC Regulatory Guides, Interim Staff Guides, and Branch Technical Positions, industry standards, and other guidance applicable to digital safety I&C systems is documented in Chapter 3. The resulting SPINLINE 3 digital safety I&C platform has the following general attributes:

• Fail-safe: SPINLINE 3 assures that, in case of detected failure, the outputs associated with a central

processing unit (CPU) achieve a pre-defined safe position.

• Fault-tolerance: SPINLINE 3 supports system architectures that meet the redundancy requirements of the single failure criterion. In addition, SPINLINE 3 microprocessors can automatically reconfigure their voting logic to accomplish the intended safety function with one or more divisions out of service.

• Diversity: SPINLINE 3 supports system architectures that employ signal diversity to defend against common cause failures. SPINLINE 3 also can be deployed as a diverse system as part of a plant-level defense-in-depth and diversity (D3) strategy.

• Functional isolation: SPINLINE 3 equipment and communications design prevents propagation of failures between redundant equipment in separate divisions. In addition, communication paths to non-safety I&C systems are electrically isolated with one-way communications from SPINLINE 3 to the non-safety I&C system. This prevents faults in a non-safety I&C system from affecting SPINLINE 3.

• Determinism: For all processing, the same inputs produce the same outputs within a guaranteed response time

• Ease of use: Operation and maintenance are simplified by automated on-line system supervision, fault detection and self-diagnosis.

• Flexibility: Through carefully controlled processes, many system operating characteristics can be updated without hardware modification.

• Modularity: SPINLINE 3 can be delivered either in standard chassis to be integrated into existing cabinets (for refurbishment purposes) or in new cabinets.

• Scalability: SPINLINE 3 has been deployed internationally in a wide variety of safety I&C applications, including Reactor Trip System (RTS), Engineered Safety Feature Actuation System (ESFAS), Nuclear Instrumentation System (NIS), and diverse trip system applications.

• Secure development and operational environment: The software life cycle processes applied by Rolls-Royce establish a secure development and operational environment for managing the generic SPINLINE 3 platform baseline and developing the plant-specific application software through the factory test phase. These processes protect against unauthorized, unintended, and unsafe modifications to the system, and support implementation of design requirements that promote integrity and reliability during operation and maintenance in the event of inadvertent operator actions or undesirable behavior of connected equipment.


4.1.2 Dedication and Qualification

The SPINLINE 3 digital safety I&C platform originally was designed, qualified, and manufactured to meet European nuclear safety and quality standards. This platform is being dedicated and qualified to demonstrate compliance with U.S. requirements as follows:

• Dedicate the generic SPINLINE 3 digital safety I&C platform, which was not originally developed

under a 10CFR50 Appendix B (Reference 4-7) QA program.

Consistent with the basic requirements for commercial dedication as defined in 10CFR21 (Reference 4-19), Rolls-Royce is employing the commercial dedication processes described in EPRI TR-107330 (Reference 4-3) and TR-106439 (Reference 4-20) and approved by the NRC (References 4-4 and 4-21).

The suitability of SPINLINE 3 for dedication is documented in the Design Analysis Report (DAR, Reference 4-5) and the Dedication Plan (Reference 4-22)

The generic SPINLINE 3 platform is managed under a 10CFR50 Appendix B quality program during and after dedication.

Qualify SPINLINE 3 hardware to meet U.S. standards. The SPINLINE 3 hardware will be qualified and maintained under the 10 CFR 50 Appendix B quality program. If new boards are developed or existing boards modified for obsolescence or other reasons, the new or modified hardware will be appropriately tested and/or analyzed to maintain equipment qualification to U.S. standards.

Develop plant-specific application software in accordance with software life cycle plans that are compliant with NRC Branch Technical Position (BTP) 7-14 (Reference 4-9)

The non-Class 1E set of software tools, which are used as design aids and not as a replacement for verification and validation (V&V), are not dedicated but continue to be subject to a configuration management program.

All SPINLINE 3 hardware is Class 1E qualified, as described in Chapter 5 and in the Equipment Qualification (EQ) Plan (Reference 4-1).

The SPINLINE 3 safety-related Operational System Software (OSS) and other SPINLINE 3 safety-related platform software were developed based on the guidance of the IEC 880-1986 (Reference 4-2) with enhancements to take into account the advances in software engineering as reflected in a later revision of the standard. Features of the SPINLINE 3 platform software are described in Section 4.4. The software life cycle processes that apply to SPINLINE 3 safety-related platform software are described in Section 6.2. The SPINLINE 3 platform software has been dedicated using the process defined in EPRI TR-107330 (Reference 4-3) and approved by the NRC (Reference 4-4). The technical basis for dedication is documented in the Dedication Plan for the Generic SPINLINE 3 Digital Safety I&C Platform (Reference 4-22). The dedicated platform hardware and software is managed under the I&C France Quality Management Program (Reference 4-6), which complies with 10 CFR 50 Appendix B (Reference 4-7).

Safety application software deployed on SPINLINE 3 systems will be developed on a plant-specific basis using the software life cycle processes described in Section 6.4. These processes meet the requirements of IEEE 7-4.3.2 and NRC Branch Technical Position 7-14 (References 4-8 and 4-9, respectively).


4.1.3 Operation and Maintenance

SPINLINE 3 has the following features to support operation and maintenance.

• Setpoint value adjustments may be needed during a reactor operating cycle or between cycles. These

adjustments are made using a Local Display Unit (LDU), which has the functionality described in Section 4.4.3.5.5, and a secure protocol and a consistency check that is performed between redundant parts. Setpoints are stored in EEPROM on the SPINLINE 3 processor board, so they are retained even after power is lost and restored.

• The Monitoring and Maintenance Unit (MMU) described in Section 4.6.10, supervises process information and failure signaling. The MMU delivers an automatic diagnosis to facilitate quick repair in case of a fault. This diagnosis indicates which board has failed or is failing. Periodic tests, initiated by plant operators, are automatically executed and provide a high degree of fault coverage.

4.1.4 State-of-the-Art Performance

The wide range of input/output (I/O) boards and their capabilities allows SPINLINE 3 to fit any nuclear safety I&C application need. The use of powerful CPU boards and high speed data networks assures rapid response times even for complex functions and, above all, the response time is guaranteed by the deterministic features of the SPINLINE 3 platform.

4.1.5 Quality

As described in Sections 1.4, the I&C France Quality Manual (Reference 4-6), which governs the SPINLINE 3 digital safety I&C platform complies with 10 CFR 50 Appendix B (Reference 4-7) and ASME NQA-1-1994 (Reference 4-17). Compliance with 10 CFR 50 Appendix B is described in more detail in Section 3.2 and NQA-1 compliance is described in more detail in Section 3.13.

4.2 Main Features of SPINLINE 3

4.2.1 Introduction

SPINLINE 3 provides a set of standardized, modular components and tools that were designed from the start as Class 1E I&C systems, including:

• Hardware components: chassis, I/O and processing boards, power supplies and other components. See

Section 4.3 for a description of SPINLINE 3 hardware components. Hardware data sheets are in Appendix B.

• Platform software, which is comprised of the Class 1E standardized Operational System Software (OSS), the Class 1E application-oriented library of re-usable software components, Class 1E software embedded in the NERVIA+ board, Class 1E software embedded in the ICTO Pulse Input board, and a non-Class 1E set of tools integrated in a Software Development Environment (SSDE) called CLARISSE. See Section 4.4 for a description of the SPINLINE 3 platform software.


The design and implementation of the hardware components and the platform software comply with US Nuclear Regulatory Commission (NRC) requirements. Compliance summaries for specific NRC codes, guides and endorsed industry standards are provided in Chapter 3.

4.2.2 Software Based Digital Technology

SPINLINE 3 is based on digital technology, which simplifies implementation of the functional requirements and avoids the need for certain specific hardware development. The main benefits of the SPINLINE 3 software-based approach are:

• Functional requirement implementation: The development of any kind of I&C function (e.g., logic

functions, analog functions, closed loop control, and computations) is possible without the need for specific hardware design, using the SPINLINE 3 hardware components and the CLARISSE System and Software Development Environment (SSDE).

• Stability and accuracy of analog values: SPINLINE 3 analog electronic concentrates in analog I/O boards. These boards are permanently monitored for drift and have a defined accuracy. They do not require operator adjustment or calibration during on site operation. Once digitized, the values of analog input signals and triggering thresholds can be processed without being subject to analog drift.

• Adaptability: Changes in functional requirements can be dealt with by software modifications when they do not affect the I/O interface. When I/O changes are needed, the system parameters are adapted accordingly and I/O boards can be added as necessary.

• System supervision: Supervision of the safety I&C system can be achieved without increasing the complexity of the safety classified units. With the isolation provided in a SPINLINE 3 system, data available on the safety networks may be sent via a one-way (broadcast only) data link to non-safety classified data systems for cross-comparisons and other diagnostic purposes.

• Automated periodic testing: SPINLINE 3 provides features that enable automation of comprehensive periodic testing of each function.

4.2.3 Standardized Components

SPINLINE 3 hardware and software components are standardized, mature products that are both modular and scaleable. The standardized hardware components are:

• 19 inch 6U chassis that can fit many standard cabinets

• A full range of input and output (I/O) boards for discrete and analog data, neutron instrumentation, thermodynamic instrumentation, actuator control, and other I&C functions.

• A 25 MHz 68040 Freescale microprocessor CPU board, with two megabytes of read-only flash memory, two megabytes of write-protected RAM for operational system software and application software execution, two megabytes of RAM for data space, and 64 kilobytes of non-volatile EEPROM memory. This board can support up to six NERVIA communication interfaces.

• High speed, deterministic Class 1E digital communications network: NERVIA is a 10 megabit/s, broadcast type network that implements a time-based token bus communications protocol. The medium is either optical fiber or Shielded-Foil Twisted-Pair (SFTP) cable. It is used for communications within the safety system and for one-way (broadcast only) communications to non-safety units. Both NERVIA hardware and software comply with Class 1E requirements.


• Interface to an external non-safety computer through the NERVIA digital communications network. SPINLINE 3 may also interface with other analog or digital systems using networks, serial links, or appropriately isolated wired links.

The hardware components are described in Section 4.3. Data sheets for SPINLINE 3 standard hardware components are in Appendix B

The components of the SPINLINE 3 platform software are:

• The standardized, Class 1E configurable Operational System Software (OSS), which provides the

interface between the local and remote data delivered by the I/O and communication link boards and the application software. The OSS also provides continuous self-diagnostic testing of the hardware and services to the application software.

• The Class 1E application-oriented library of re-usable software components,

• The Class 1E software embedded in the NERVIA+ board,

• The Class 1E software embedded in the ICTO Pulse Input board, and

• A non-Class 1E set of tools integrated in a Software Development Environment (SSDE) called CLARISSE, which is used to design and implement the system architecture, configure the units and networks and develop the plant-specific application software.

These components of the SPINLINE 3 platform software are described in Section 4.4 The Rolls-Royce software life cycle processes for the SPINLINE 3 platform software are described in Sections 6.2 and 6.3. The software life cycle processes for the plant-specific application software are described in Section 6.4.

4.2.4 Architectures

SPINLINE 3 has the flexibility to implement a variety of system architectures by combining standard components and modules in simple serial and parallel configurations to build plant-specific system architectures that are compliant with NRC requirements for safety I&C systems.

• Serial configuration: Units linked by hard-wired connections or a NERVIA network can work in series.

For instance, the first unit acquires inputs from sensors and delivers the values to the second unit, which processes these values and issues results, either directly toward actuators through output boards or on the network for a third unit.

• Parallel configuration: Units linked by a NERVIA network can work in parallel. For instance, the first unit issues data on the network, and then these data can be processed by two or more units, working in parallel. The parallel scheme is used to connect the outputs from more than one division to voting modules that implement specific safety logic.

4.2.4.1 Example Division-level Architecture

Figure 4.2-1 shows a representative single division that combines both serial and parallel architectural features to acquire data from external sensors, determine the existence of a trip condition, vote to determine if a safety actuation is required, and then actuate external devices.


[[


Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text]]

4.2.4.2 System-level Architecture

System-level architecture will be defined on an application-specific basis, with redundancy, diversity and other features appropriate to the specific application. To facilitate discussion of communications within a SPINLINE 3 system, a representative four division system is shown in Figure 4.2-1. Each division is a replicate of the single division shown in Figure 4.2-1. In this four division diagram, the conceptual arrangement of the three example NERVIA digital communications networks can be seen more clearly: • RTS or ESFAS Networks, dedicated to processing the trip function • Display Networks, dedicated to delivering data to divisional safety display processors • Gateway Networks, dedicated to one-way, isolated communications with external non-safety data

systems

Licensing Topical Report - SPINLINE 3 NRC Qualification 3 008 503 C - NP Imprimé n° 8303090 F

[[

]]

Figure 4.2-1 Representative Four Division Architecture


4.2.5 Redundancy

SPINLINE 3 modular architecture is convenient for building redundant systems. SPINLINE 3 provides two kinds of redundancy management:

• Hardware-based active redundancy management: Safety I&C systems typically are

comprised of several separate, independent divisions (typically three or four). Output signals from each division are issued through output boards into the hardware voting logic.

• Software-based active redundancy management: This is mainly implemented in units receiving data from several divisions, either from output units or functional processing units. Software-based redundancy provides for voting reconfiguration capability, with reconfiguration occurring upon detection of an inhibition signal or on detection of a failure of a division. For instance, a software two-out-of-four (2oo4) vote implemented in the voting unit will become a two-out-of-three (2oo3) vote when one division is unavailable (for instance during periodic testing). The general design principle of this reconfiguration, and of the redundant architecture, is to comply with the single failure criterion provided in IEEE Standard 379 (Reference 4-10). This feature also improves system reliability and availability without degrading safety.

4.2.6 Deterministic Behavior

Deterministic behavior is a key feature that enables SPINLINE 3 safety I&C systems to meet response time requirements and avoid overload situations. This deterministic behavior is based on the following characteristics:

• Software units run cyclically and sequentially

• A fixed-duration unit cycle is always composed of the following steps: • Self-monitoring • Cycle time management • Data acquisition • Application processing • Data output • Local terminal management

All unit cycle steps are always executed in the same order and each unit’s cycle time is fixed and monitored. The unit response time is bounded where:

• Minimum response time = the time for data acquisition + application processing + data output + input

board minimum response time + output board minimum response time,

• Maximum response time = the time for one cycle + the time for data acquisition + application processing + data output + input board maximum response time + output board maximum response time

Software units do not make use of interrupt-driven tasks or algorithms based on dynamic memory allocation. NERVIA networks run cyclically and sequentially. The network cycle is defined during design. The network design establishes the sequence of transmitting stations and assigns a pre-defined time window to each of


these stations. A station is allowed to transmit its data on the network only during its specified time window (i.e., when it has the token).

The cycle time of each network is fixed and monitored. The network stations always transmit in the same order and each station is allocated a fixed-length “time window.” As explained in Section 4.5.2.1, the station “time window” is fixed for a given station and may be different for other transmitting stations. The network response time is bounded by the following:

• Minimum response time = shortest station time window • Maximum response time = one network cycle time + longest station time window

Exchanges of data among units through networks are through pre-defined and systematic messages. All inter-unit data exchanges are configured in fixed tables. The maximum response time for a system is established using the maximum response time of each unit and network. SPINLINE 3 determinism guarantees that I&C outputs will always be delivered within the computed maximum response time limit.

4.2.7 Separation

Physical and electrical separation is implemented in the design of plant-specific SPINLINE 3 systems, with each division being powered from one or two separate and independent Class 1E power sources associated with that division. In addition, inter-divisional communication through NERVIA networks is implemented using optical fiber, which provides electrical isolation between divisions.

Exchange of data between units through NERVIA networks does not involve synchronisation mechanisms at protocol level (i.e.; no hand-shaking, no acknowledge, no synchronized clock time, no master station). This feature avoids the risk of disabling one or several units on a network as a consequence of the failure of a single unit or station. The management of redundant units is easy to achieve as networks work independently of the status of the connected units and units work independently of the status of the connected networks.

The NERVIA network provides flexibility. For instance, the NERVIA networks can be used to implement communication with divisional Class 1E video display units for information display and safety system control. The NERVIA network can be configured to supply data from all divisions to a single video display unit, as shown in

. Based on guidance from NRC Interim Staff Guide DI&C ISG-04 (Reference 4-11), the multi-divisional Class 1E video display unit can also provide control capabilities. As shown in the figure, these Display Networks can be implemented as one-way (broadcast only) communications paths to the display processor for data display only. With access to data from all divisions, each division display processor can perform a variety of calculations (i.e., average, maximum, minimum, deviations for alarming, etc.) or run applications that are not required as part of the basic trip functions of the system. The Class 1E digital video display unit (VDU) is not in the scope of the SPINLINE 3 digital safety I&C platform.

Non-Class 1E units are isolated from Class 1E units. Nevertheless, Class 1E units may need to transmit data to non-Class 1E units. SPINLINE 3 makes this possible through a one-way (broadcast only) NERVIA communications network from the Class 1E system to the Non-Class 1E system via a fiber-optic link. Non-Class 1E units can only receive data. Such units can read the data available on the NERVIA network but they cannot transmit data on the network. Therefore, they cannot interfere with the Class 1E functions. This design ensures that Non-Class 1E units cannot prevent Class 1E units from performing their safety function.

NERVIA communications are described in detail in Section 4.5.


4.2.8 Safety-oriented Features

From the beginning, SPINLINE 3 hardware and software components were designed to implement nuclear safety I&C functions. SPINLINE 3 includes appropriate features to defend (i.e. detect and act) against failures that may occur inside the system, due to causes from inside or outside of the I&C system. SPINLINE 3 safety-oriented features include:

• System safety-oriented features: sensor input values processed by SPINLINE 3 as well as safety

information transmitted by PUs to other PUs through NERVIA Network are associated with “validity” information providing a status “OK” or “Not OK” for these values. Application software process values according to their “validity.” When a value is marked as “Not OK”, the Application Software performs a safety-oriented exception processing, assuming worst case in order to provide safe outputs. A Monitoring and Maintenance Unit, which is a permanently connected non-Class 1E computer, is provided to perform division cross-checks and to alarm on significant deviations of similar sensors across safety divisions.

• Hardware safety-oriented features: Output boards produce fail-safe outputs following internal hardware failure, loss of power supply, or detection of CPU scanning disruption through hardware watchdog timers internal to each output board. The clock of the CPU board is monitored against frequency drifts

• Software safety-oriented features: The operational system software (OSS) includes appropriate defensive programming to make sure that there are no inconsistencies in the control and data flows. The detection of any inconsistencies will result in a CPU stop, which leads to a pre-defined state of each output. See Section 4.4.3 for additional details. In addition, the application software design typically includes consistency checks and property assertions in order to defend against possible design or operating faults.

4.2.9 Alarms and Signaling on Failure

A Class 1E application developed with SPINLINE 3 digital safety I&C platform will include alarms and signaling of detected failures in the Control Room. In order to help the maintenance operator, further detailed information can be obtained from the non-Class 1E Monitoring and Maintenance Unit (see Section 4.6.10).

4.3 Hardware

4.3.1 Introduction

The SPINLINE 3 hardware is built from a set of modular, standardized components, including chassis, electronic boards, and cabling, suitable to implement nuclear safety I&C systems in either new or refurbished NPPs. Data sheets for SPINLINE 3 standard hardware components are provided in Appendix B. Hardware compliance with applicable codes, guides and industry standards is summarized in Chapter 3. The hardware is qualified for nuclear power plant environmental conditions, as described in Chapter 5 and in the Equipment Qualification Plan (Reference 4-1).


4.3.2 Description of the chassis and backplane bus

4.3.2.1 19” 6U Chassis

The 19’’ 6U chassis is designed to host the SPINLINE 3 electronic boards. It can be mounted into standard cabinets for nuclear power plant instrumentation and control systems. The chassis is qualified, as described in Chapter 5, to meet USNRC qualification requirements.

The 19’’ 6U chassis includes: • A metallic frame consisting of riveted and bolted parts, galvanized and chromate passivated, designed

for EMI/RFI protection.

• Mounting rails for easy insertion and retrieval during maintenance.

• One or two printed circuit backplanes with board connectors. These connectors are equipped with keys matching their associated board types.

The 19’’ 6U chassis is designed to host the main electronics boards on the front side and complementary boards known as “Interface boards” on the rear side. • The main electronic boards, plugged from the front of the chassis, provide the function e.g. processing,

analog or discrete acquisition, and the displays and controls available to the maintenance staff.

• The Interface boards, plugged from the rear of the chassis, provide the connectors from sensors signals or to actuators control. Theses interfaces provide also adequate isolation and electrical adaptations between field signals and the main electronic boards.

The chassis mechanical specifications are: • Height: 6U (266 mm)

• Width: 19" (483 mm)

• Depth: 20" (504 mm)

• Weight (empty chassis): 44 lb (20 Kg)

• Available slots on the backplane: 21

Figure 4.3-1 and Figure 4.3-2 show respectively the front and the back view of a chassis equipped with boards.


Figure 4.3-1. Front view of the chassis equipped with its boards

Figure 4.3-2. Rear view of the chassis equipped with its interface boards

digital isolated input board

analog input board

calibrated pulse acquisition board

CPU board

power supply board

interface analog input board

interface calibrated pulse acquisition board

interface digital isolated input board interface

power supply board

interface NERVIA + board


4.3.2.2 Backplane Bus (BAP - for “Bus d’Acquisition Parallèle”)

The SPINLINE 3 21 slots Backplane Bus fits in the 19” 6U mechanical chassis and host a power supply board, a CPU board and up to 12 digital analog and discrete input and output boards.

The functions of the backplane bus are:

• To provide for the centralization of data acquisition performed by input boards across the BAP, whether the input boards use microprocessors or FPGA-logic for data acquisition

• To provide for the transmission of output signals established by the CPU board to the output actuation boards.

• To supply power generated by the ALIM 48V/5-24V power supply board to the CPU board and to the input output boards.

• To provide connectors to link main electronic boards to their associated Interface boards

The Backplane Bus is a Master/Slave parallel bus with one Master board and one or several Slave boards.

The backplane is available in several sizes with 21, 11, and 10 slots. Two of the smaller backplanes can be installed in a single chassis .The functionalities are the same for the different sizes.

4.3.2.3 SPINLINE 3 Chassis Electronic Boards

The following kinds of electronic boards can be installed in a SPINLINE 3 chassis: • Power Supply: provides power needed by one backplane from the cabinet power supply. Their is

one power supply board per backplane.

• ALIM 48V/5V-24V power supply board [[ ]]

• Master board: Functional board able to control data exchange on the Backplane bus. Only one master board can be installed in a backplane at a given time.

• CPU board: UC25 N+ – based on a MC68040 microprocessor hosting and running the Operational System Software and the Application Software. [[Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text ]] The UC25 N+ board communicates with Slave boards through the Backplane Bus and with the NERVIA+ daughter board through a dedicated bus.

• Slave boards: Functional boards which provide signal acquisition from sensors and generation of output Signals to actuators. These boards cannot perform alone. They need are controlled by a master board through the backplane bus.

• Analog input board (ISOlated) 16EANA ISO [[ ]]

• Digital isolated input board: 32ETOR TI SR [[Proprietary text Proprietary text Proprietary text Prop ]]

• Calibrated pulse acquisition board: ICTO [[Proprietary text Proprietary text Proprietary text Proprietary text]]

• Actuator drive board: 32ACT [[ ]]

• Analog output board (ISOlated): 6SANA ISO [[Proprietary text Proprietary text Proprietary text Propr]]

• Communication boards: Functional boards performing data reception and transmission functions.

• NERVIA+ daughter board – installed on the CPU board [[Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text P]]


• Conditioning Boards: Functional boards performing low level pulse or analog signal amplification and shaping. [[Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary t]]

• RTD conditioning board: 8PT100 [[ ]] This analog board provides analog signals to the 16EANA analog input board can be plugged into the backplane for access to the power supply and to its associated I.PT100 Interface board.

• Interface boards: plugged in the rear on the Backplane Bus. They are linked to their associated main electronic board through a dedicated connector on the backplane. They do not exchange information through the Backplane Bus. [[Proprietary text Proprietary text Proprietary text Proprietary text Pro]] – See Table 4.3-1 for the list of Interface Boards.

4.3.3 Summary of Electronic Boards and Electronic Modules

SPINLINE 3 electronic boards and other Electronic Modules are listed in Table 4.3-1 and are described in the following sections. Data sheets for these electronic components are provided in Appendix B.

All SPINLINE 3 hardware is designed to withstand the temperature, humidity, EMI/RFI, seismic and other environmental conditions as described in Chapter 5 and in the Equipment Qualification (EQ) Plan (Reference 4-1), except the PCI NERVIA+ board which is installed in non-Class 1E equipment.

Table 4.3-1. SPINLINE 3 Electronic Boards and Electronic Modules Electronic Boards - installed in the SPINLINE 3 chassis

Main function

RTD conditioning board: 8PT100 Acquires and conditions up to eight analog signals provided by PT100 platinum temperature sensors. Output delivered signals are given in both voltage and current

Installed with the I.8PT100 interface board

I.8PT100 Interface board Performs complementary interface functions for the 8PT100 board.

The outputs from I.8PT100 can be inputted to the 16EANA analog input board for digital processing.

Analog input board: 16E.ANA ISO (ISO is for isolated )

Acquires up to 16 analog signals and performs the analog-to-digital conversion.

Installed with the I.16EANA interface board.

I.16EANA interface board Performs complementary interface functions for the 16E.ANA ISO board • EMC filtering for all analog inputs • Forwards the analog inputs to the 16E.ANA acquisition board • Forwards analog inputs to its front panel connector for test

purposes • Checks the presence of analog inputs cables on its front panel

connectors Digital isolated input board: 32ETOR TI SR

Acquires up to 32 isolated ON-OFF signals.

Installed with the I.32ETOR TI interface board


Calibrated pulse acquisition board: ICTO

Part of the source-range-conditioning channel. Performs the following functions to provide count rate data to the UC25 N+ processor board: • Measures the count rate Installed with the I.ICTO interface board

I.ICTO interface board Performs complementary interface functions for the ICTO board: • Provides EMC filtering for pulse inputs

Actuator drive board: 32ACT

Manages up to 32 ON-OFF outputs according to commands sent by the UC25 N+ processor board. The 32 ON-OFF outputs drive actuators through relays. All ON-OFF outputs are insulated from each other.

Installed with the I.32ACT actuator drive interface board

I.32ACT interface board Performs complementary functions for the 32ACT. actuator drive board. • Forwards up to 32 ON-OFF outputs from the chassis backplane

to its front panel connectors. Analog output board: 6SANA ISO (ISO is for isolated )

This analog output board can supply the following outputs, based on data sent from the UC25 N+ processor board: • Five analog outputs, configurable to voltage (0 to 10 V) or

current (4 to 20 ma) • One analog output, configurable to voltage (0 to 10 V or -10 to

+10 V) Installed with I.6SANA interface board.

I.6SANA interface board Performs complementary functions for the 6SANA board, including: • EMC filtering for all analog outputs (voltage and current) • Performs the segregation function between cable types • Forwards the watchdog state from the associated board • Configuration of the voltage output range (channel 6) • Forwards outputs for test purposes

CPU board: UC25 N+ Performs the processing and control unit function. It is built around a 25 MHz 68040 microprocessor and a 68360 communication coprocessor.

Its main functions are: • Central processing unit (CPU) • Controls the backplane Parallel Acquisition Bus (BAP bus),

which is dedicated to the communication with the I/O SPINLINE 3 boards.

• Manages up to six NERVIA+ networks according to the daughter board configuration

• Manages two asynchronous serial links available on the front panel RJ45 connectors.

Installed with NERVIA+ daughter board and I.NERVIA+ interface board

NERVIA+ daughter board This board is installed on the UC25 N+ board and supports up to 2, 4, or 6 NERVIA networks with 1, 2, or 3 identical functional blocks based on an MPC860 microprocessor. Each microprocessor manages two NERVIA+ networks Also requires the I.NERVIA+ interface board

I.NERVIA+ interface board Performs the transceiver function of a NERVIA+ network. It is composed of three identical functional blocks. Each functional block is able to manage two serial links.


ALIM 48V/5V-24V power supply board

Generates two regulated power supply outputs (5 V dc, 24 V dc) and dispatches power to the backplane board. It also provides an ON-OFF status for both output voltages on two output relays.

Installed with I.ALIM 48 interface board

I.ALIM 48 interface board Performs complementary interface functions for the ALIM 48V/5V-24V power supply board, including: • EMC filtering • Dispatching the 48 V dc external power supply to SPINLINE 3

power supply boards. • Dispatching internal 5 V dc and 24 V dc power supplies to its

front panel connector for test and monitoring purposes. Electronic Modules - installed outside the SPINLINE 3 chassis

Main function

120VAC/48VDC power supply chassis

First stage of the power conversion chain. It converts external power levels into ranges that meet internal needs. It is based on a 3U mechanical chassis, filled with converters.

48VDC/48-24VDC power supply chassis

Second stage of the power conversion chain. It converts internal 48VDC into isolated 24VDC and 48VDC, used for internal needs and as loop power supplies.

10MBps Ethernet Hub: 4TP This is a passive hub that is dedicated to the NERVIA network. It has four Twisted Pair (TP) interfaces, which allow connecting up to four terminals or other TP segments.

10MBps Ethernet Hub: 3TP/2FL This is a passive hub that is dedicated to the NERVIA network. It allows Ethernet networks to be flexibly designed in accordance with IEEE standard 802.3 (Reference 4-12) using fiber-optic and copper technology. This hub has three Twisted Pair (TP) interfaces and two Fiber-optic Links (FL) equipped with Bayonet Fiber-Optic Connectors (BFOC).

Twisted-pair to fiber-optic (TP/FL) converter

This converter is dedicated to the NERVIA network. It allows Ethernet networks to be flexibly designed in accordance with IEEE Standard 802.3 (Reference 4-12) using fiber-optic or copper technology. This converter has one Twisted Pair (TP) copper interfaces and one Fiber-optic Links (FL) equipped with a Bayonet Fiber-Optic Connector (BFOC).

Actuation voting module: MV16 This module performs voting functions by combining ON-OFF outputs delivered by the I.32ACT actuator drive interface board.

Output relays terminal block: 8SRELAY1 and 8SRELAY2

This hardware drives actuators through eight relays. The 8SRelay terminal block can receive commands from both MV16 voting modules and from manual commands.

32ETOR input terminal block Terminal block specifically designed for discrete signals acquired by 32ETOR and I.32ETOR boards

8PT100 input terminal block Terminal block specifically designed for 8 PT100 thermodynamic channels


Electronic Boards - installed in a Personal Computer (PC)

Main function

PCI NERVIA+ board Establishes the interface between a Personal Computer (PC) and a NERVIA+ network. The PCI NERVIA+ board is installed in a PCI slot in the Monitoring and Maintenance Unit (MMU) and in the Automated Testing Unit (ATU).

4.3.4 Description of the SPINLINE 3 Hardware Building Blocks

4.3.4.1 Temperature Conditioning Hardware

The temperature conditioning channel processes up to eight PT100 platinum temperature sensors, translating changes in resistance to voltage or current levels. The hardware requires both the 8PT100 input terminal blocks and 8PT100 RTD conditioning boards that acquire a total of eight analog signals from PT100 platinum temperature sensors. The 8PT100 board manages the following functions: • Supplies the platinum temperature sensors with a bias current

• Conditions the analog input signals from sensors into voltage and current levels

• Isolates inputs from each other

[[

]]

The 8PT100 board must be implemented with the I.8PT100 interface board. This interface board is installed on the back of the BAP bus.

4.3.4.2 Analog Input Acquisition Hardware

The analog input acquisition hardware uses a SPINLINE 3 Terminal Block and a 16E.ANA ISO board, which acquires up to 16 current or voltage analog signals and performs the analog-to-digital conversion. The SPINLINE 3 Terminal Block is installed outside of the chassis. The 16E.ANA ISO board is installed in the chassis and connects to the front of the BAP bus.

Any 16E.ANA ISO analog input can be configured independently with its own acquisition range. [[

Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text

]]


When 8PT100 RTD conditioning board is used, the 16E.ANA ISO board performs the acquisition of the voltage signals originating from the 8PT100 RTD conditioning board. These signals are acquired in separate isolated groups to maintain isolation provided by the 8PT100 boards.

The 16E.ANA ISO board is implemented with the I.16EANA interface board, which performs EMC filtering for all analog inputs, provides connections for periodic tests, and checks the presence of analog input cables on its connectors. This interface board is installed on the back of the BAP bus.

4.3.4.3 Discrete Signal Acquisition Hardware

The discrete acquisition function is accomplished using the 32ETOR TI SR discrete acquisition board and the 32ETOR terminal block. The 32ETOR terminal block is installed outside of the chassis. The 32ETOR TI SR discrete acquisition board is installed in the chassis and connects to the front of the BAP bus.

The 32ETOR terminal block interfaces the external field ON-OFF discrete sensors and the 32ETOR TI SR board: • [[

•

•

•

•

•

•

•

• ]]

The 32ETOR TI SR board is implemented with the I.32ETOR TI interface board, which forwards the 32 ON-OFF inputs from the 32ETOR TI board to its front panel connectors.

This interface board is installed on the back of the BAP bus.

4.3.4.4 Pulse Input Acquisition Hardware

The ICTO board performs the acquisition of pulses with a count-rate ranging from 1 count per second (cps) up to 6.5 x 106 c/s.

The ICTO board performs the acquisition of two pulse signals. It collects both the number of pulses (N) and the duration of the counting time (T) and forwards these data to the UC25 N+ processor board, which performs the count rate calculation. [[


•

•

•

Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text

]]

The ICTO board is implemented with the I.ICTO interface board, which provides EMC filtering for the pulse inputs. This interface board is installed on the back of the BAP bus.

4.3.4.5 Actuator Driving Hardware

The actuator driving chain is implemented with the following components: • 32ACT actuator drive boards and I.32ACT interface boards,

• MV16 actuator voting modules,

• 8SRELAY terminal blocks, types 1 and 2

32ACT Actuator Drive Board

The 32ACT actuator drive board manages up to 32 discrete outputs according to commands sent by the CPU board of the processing unit. The 32 discrete outputs are insulated from each other and are directly connected to the MV16 voting module through two cables carrying 16 signals each.

[[Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Prop ]]

The 32ACT board is installed with the I.32ACT interface board, which performs EMC filtering and provides external power supplies for digital outputs.

The 32ACT board is installed in the chassis and connects to the front of the BAP bus. The 32ACT interface board is installed on the back of the BAP bus.


MV16 Actuator Voting Module

The MV16 voting module is intended to be used where multiple outputs are required to vote on individual actions within one division, to respond to concerns that single failures on output boards could result in false actuations. The MV16 is not intended to perform the division-level voting actions such as two-out-of-four voting, which are performed in application software within the SPINLINE 3.

The MV16 actuator voting module is located outside of the chassis. It accomplishes the voting function by combining discrete outputs from 32ACT actuator drive interface boards in selected voting configurations. [[

•

•

•

•

• ]]

The MV16 outputs drive directly two 8SRELAY terminal blocks through two cables carrying eight signals each. The MV16 includes a feature for inhibition of the control signal to the output relays. The conditions for implementing such an inhibition are plant-specific and are defined at the system level.

8SRELAY Terminal Blocks with Type 1 and Type 2 Relays

The SPINLINE 3 I&C platform does not use solid-state discrete output devices. The output function is accomplished by relays with outputs designed for 125VDC, 48VDC, 24VDC and 120VAC.

There are two types of 8SRELAY terminal blocks: 8SRELAY Type1 and 8SRELAY Type2, which are associated with two different kinds of relays; respectively Relay Type1 and Relay Type2. Relays characteristics for a life cycle of one million cycles are listed in Table 4.3-2. The surge protection is implemented on the 8SRELAY relays.

Table 4.3-2. 8SRELAY1 & 8SRELAY2 Terminal Block Relay Characteristics

[[

]] The 8SRELAY terminal block can receive commands either from MV16 actuator voting modules or directly from an independent manual switch that is installed in parallel with the automatic actuation signal path. The


manual commands are initiated by the operator in the main control room or other control locations. An example of this manual actuation interface and the interface for an inhibition input are shown in Figure 4.3-3. As described in Interim Staff Guide DI&C-ISG-02 (Reference 4-13), this manual actuation feature adds diversity in accident sequences that allow time for the operator to take manual protective actions.

[[

Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Propriet ]]

Figure 4.3-3. Example of Manual Actuation and Inhibition Interface with Actuator Drive Hardware

4.3.4.6 Analog Output Signal Generation Hardware

The analog output signal generation chain comprises 6SANA ISO boards and SPINLINE 3 terminal blocks. The 6SANA ISO board is installed in the chassis and connects to the front of the BAP bus. The SPINLINE 3 terminal blocks are located outside of the chassis.

The 6SANA ISO board generates up to six insulated analog signals, commanded by the UC25 N+ central processing unit. [[ •

• ]]

The 6SANA ISO board has to be implemented with the I.6SANA relevant interface board, which performs EMC filtering and allows the voltage output range for channel 6 to be configured. This interface board is installed on the back of the BAP bus.

4.3.4.7 Central Processing Hardware

The central processing function is implemented with the following component:

• Central Processing Unit (CPU) board: UC25 N+

The UC25 N+ board is installed in the chassis and connects to the front of the BAP bus.


The UC25 N+ board performs the processing and control unit functions. It is built around a 25MHz 68040 Freescale microprocessor supported by a 68360 communication coprocessor. It also has onboard memory for code and data in order to run software safety functions.

The UC25 N+ board also controls the backplane Parallel Acquisition Bus (BAP bus), which is dedicated to communication between the analog and discrete I/O boards in the chassis and the UC25 N+ CPU board.

[[ •

•

• Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Propriet]]

The UC25 N+ also manages an asynchronous serial link that is accessed through the front panel RJ45 connectors. This link is used during maintenance, to connect the Local Display Unit (LDU) directly to the UC25 N+ CPU of the processing unit.

4.3.4.8 Communications Hardware

The digital communications functions are implemented with the following components:

• NERVIA+ daughter board and I.NERVIA+ interface board

• Passive communications hubs and converters to support communication via copper and fiber-optic links

• NERVIA network media

• PCI NERVIA+ board

A description of how the above communications hardware works in the context of a NERVIA communications network is provided in Section 4.5.3. Communications software is described in Section 4.5.4. Compliance of NERVIA communication with NRC Interim Staff Guide DI&C-ISG-04 (Reference 4-11) is addressed in Section 3.7.

NERVIA+ daughter board and I.NERVIA+ interface board

The NERVIA+ daughter board is mounted directly onto the UC25 N+ processor board. The daughter board implements the NERVIA digital communications protocol and provides the separation between logic processing and communication processing required by DI&C-ISG-04. [[

]]


The I.NERVIA+ interface board is installed on the back of the backplane, in the slot corresponding to the UC25 N+ board mounted on the front of the backplane.

The NERVIA communications software is described in Section 4.5. The development process for software embedded on the NERVIA+ daughter board is described in Section 6.2.8.2.

Passive communication hubs and converters

Communications connections are implemented in the passive hubs and converters installed outside the SPINLINE 3 chassis as outlined below: • Communication between safety units in the same division use copper cables and 4TP hubs.

• Communication between safety units located in different divisions use optical fiber and 3TP/2FL hubs or TP/FL converters. The optical fiber provides electrical isolation between safety divisions.

Unidirectional communication between a Class 1E division and an external non-Class 1E unit use a fiber optic cable and 3TP/2FL hubs or TP/FL converters. The fiber-optic cable of this communication path provides electrical isolation between a Class 1E I&C system and a non-Class 1E I&C system.

Passive hubs and converters provide 10Mb/s connections between communications links and, where needed, make the transition between copper cables and optical fibers. The available hubs and converters are listed below. • The 3TP/2FL Ethernet hub allows Ethernet networks to be flexibly designed in accordance with IEEE

standard 802.3 (Reference 4-12) using fiber-optic and copper technologies. The hub is fitted with three Twisted Pair (TP) and two Fiber-optic Links (FL) providing several connections options in one piece of equipment.

• The 4TP Ethernet hub is fitted with four Twisted Pair (TP) interfaces that allow connecting up to four terminals or other TP segments.

• Twisted-Pair-to-Fiber–optic Link (TP/FL) converters allow Ethernet networks to be flexibly designed in accordance with IEEE Standard 802.3 (Reference 4-12) using fiber-optic and copper technologies. Two functionally equivalent models of TP/FL converters are described in the hardware data sheet in Appendix B. These converters have one twisted pair copper interface and one fiber-optic interface.

The passive communication hubs and converters are commercial grade electronic devices designed to meet the requirements of the Ethernet IEEE Standard 802.3. They do not embed microprocessors. They are powered from the cabinet power supplies, with adequate redundancy in case of failure of one power supply. These devices are not made by or designed for Rolls-Royce. They are procured and qualified according to the I&C France nuclear quality assurance program.

NERVIA Network Media

The NERVIA network uses two types of media: • Copper cable inside cabinets: Shielded Foil Twisted Pair (SFTP), Category 5 Class D (IEEE Standard

802.3i-1990); and

• Optical fiber 62.5/125 (10BaseFL) or copper cable between cabinets.

Optical fiber allows for electrical isolation between equipment of different safety classes and between redundant equipment within separate divisions.

PCI NERVIA+ board

This is a non-Class 1E board that establishes the physical interface between a non-Class 1E external computer and the SPINLINE 3 NERVIA+ communications network described in Section 4.5. The PCI NERVIA+ board is installed in a PCI slot on an external non-safety PC such as the Monitoring and


Maintenance Unit (MMU) described in Section 4.6.10. Refer to Section 4.5.7 for a description of how isolation and independence is enforced at data gateways to non-Class 1E computer systems.

4.3.4.9 Power Supplies

The elements of the SPINLINE 3 power supply system are the following: • Power supply board in the chassis: ALIM 48V/5V-24V • 120VAC/48VDC power supply chassis • 48VDC/48-24VDC power supply chassis The ALIM 48V/5V-24V is installed in the chassis and connects to the front of the BAP bus. The I-ALIM.48 interface board is installed on the back of the BAP bus.

The 120VAC/48VDC power supply and the 48VDC/48-24VDC power supply are in a separate chassis.

Chassis power supply: ALIM 48V/5V-24V

The ALIM 48V/5V-24V board is mounted in the chassis and generates two regulated power supply outputs (5VDC, 24VDC) from the 48VDC cabinet power supply and dispatches them on the backplane board. It also provides a Working or Faulted status for both output voltages on two output relays.

The main functions of the ALIM 48V/5V-24V power supply board are: • To provide 5VDC and 24 VDC voltages to CPU, I/O, network exchange modules and their relevant

interface boards plugged on to the backplane.

• To provide alarming of faults and failures in the power supplies

• To provide power supply protection by:

• Input surge protection

• Output short circuit and surge protection

• Over-temperature shutdown

The ALIM 48V/5V-24V power supply board is implemented with the I-ALIM.48 power supply interface board that performs the EMC filtering. The power supply provides internal 5VDC and 24VDC power supplies to the front panel connector for test and monitoring purposes.

120VAC/48VDC power supply chassis

The 120VAC/48VDC power supply chassis is the first stage of the power conversion chain. The power supply chassis is normally mounted in the same equipment cabinet as the SPINLINE 3 equipment it powers. It converts external power levels into ranges that meet internal needs such as power for the SPINLINE 3 chassis, hubs and cooling fans. The power supply for safety-related equipment is built with two redundant 120VAC/48VDC power supplies.

This chassis is designed as a 3U mechanical chassis, filled with converters: • Each converter performs the conversion from 120 VAC to 24 VDC

• Each converter has two 24 VDC voltage outputs

• The two 24 VDC outputs are connected in series to provide 48VDC.

The power supply chassis has several slots that can be filled according to the cabinet internal power needs.

For diagnostic purposes, the chassis provides a “correct operation” signal for all converters used, providing the means to externally indicate faults and failure in the primary power conversion.


48VDC/48-24VDC power supply chassis

The 48VDC/48-24VDC PS chassis is the second stage of the power conversion chain. It converts internal 48VDC into isolated 24VDC and 48VDC, used for internal needs and as loop power supplies.

The 48VDC/48-24VDC PS chassis is based on two kinds of converters: • converter with 2 connectors - 24V/96W

• converter with 4 connectors - 24V/48W

The converters can be connected in series to provide 48VDC if needed. The power supply chassis provides several slots that can be filled according to the cabinet internal power needs.

The chassis implements the following functions: • Protection of the power supply against downstream perturbations (such as short-circuits)

• Power supply output filtering for loop power supply to sensors and external use of the power. For cabinet internal use, no filter is implemented.

• For diagnostic purposes, the chassis provides a “correct operation” signal for all converters.

4.4 SPINLINE 3 Software

4.4.1 Introduction

SPINLINE 3 is designed to provide the building blocks for Class 1E systems composed of processing units and communications links working together to perform the application safety functions. At the level of an individual processing unit, the SPINLINE 3 safety software is a single loop running the same functions in a pre-defined and fixed time.

The SPINLINE 3 software is composed of the following parts:

• The dedicated platform software:

o The Class 1E standard Operational System Software (OSS), which is ready for use in a plant-specific safety I&C application after a simple configuration process. The configuration sets the input and output boards, network configuration, cycle time, and other OSS parameters, necessary for the unchanging OSS code. During operation, the OSS provides initialization, self-diagnostic tests, and interfaces with input/output (I/O) boards and networks.

o The Class 1E application-oriented library of re-usable software components

o The Class 1E software embedded in the NERVIA+ board

o The Class 1E software embedded in the ICTO Pulse Input board

o A non-Class 1E set of standard tools integrated in a Software Development Environment (SSDE) called CLARISSE, which configures the OSS and uses the application-oriented library to support development of the plant-specific application software. During design and implementation, the CLARISSE SSDE manages the interfaces between the OSS and application software and generates the executable code loaded on each UC25 N+ processor board


• The plant-specific application software, which is called by the OSS and is specific to each NPP safety I&C application. As described above, the application software is built using SCADE language operators (i.e., AND, OR, etc.) and SCADE library operators (i.e., Threshold, 2oo4 voting, etc.).

These elements of SPINLINE 3 software are described in this section.

4.4.2 SPINLINE 3 General Software Architecture

The general hardware and software architecture of a typical SPINLINE 3 processing unit is shown in Figure 4.4-1. A safety I&C system is comprised of a distributed network of many SPINLINE 3 processing units.

As shown in Figure 4.4-1, a processing unit software is composed of the following elements:

• Operational System Software (OSS), including:

o Core system software o Basic Functions (BF) o Local Display Unit driver (LDU CPU)

• Application Software

Basic Functions are used to access the hardware functions, including input and output modules, NERVIA network support, and self-diagnostics. The Local Display Unit driver (LDU CPU) manages the exchange of data with the Non-Class 1E LDU device. The core system software manages the environment in which the BF, LDU CPU, and the Application Software operate.

Core system software

ApplicationSoftware

OutputsNetworks

and Boards

Reset

BF

BF

Operational System Software

LDU CPU

InputsNetworks and

booards

Figure 4.4-1. Processing Unit: Hardware / Software Architecture


4.4.3 Operational System Software (OSS)

4.4.3.1 OSS Overview

The Operational System Software (OSS) is provided as a standard software component in each system SPINLINE3 processing units. The OSS installed in each unit supports all configurations of hardware.

In a plant-specific application, the OSS and the application software are installed as executable code on the EEPROMs on the UC25 N+ boards.

The OSS version and the software making up the OSS do not change for the purpose of a specific nuclear application. This means that the OSS will have support for input and output modules that are not installed in the system, for example, support for analog input in a processing unit where no analog sensors are needed. Despite the fact that these functions could be considered dead code, Rolls-Royce has concluded that the possible side effects of having the functions far outweighs the need for V&V of changed software in the OSS for each plant-specific application.

The OSS is ready for use in a plant-specific safety I&C application after a simple configuration process. Basic characteristics of the OSS are:

• For each UC25 N+ processor board, the OSS provides initialization, self-diagnostic tests, and interfaces

with I/O boards and networks • Low complexity of interface with the application software: the application software has one entry point

and one exit point. It is called as a subroutine within the OSS main execution loop. • Low complexity of operational system software control flow: one single main loop, no interrupts, no

dynamic memory allocation, no support for event-driven multitasking, no multiple execution threads. • The OSS is application-independent. Customization to application needs is performed during design

through static configuration parameters.

4.4.3.2 OSS Compliance with IEC 880

The SPINLINE 3 OSS originally was designed and validated based on the requirements provided in IEC 880 (Reference 4-2), which provides technical and process requirements for the development of software in the safety systems of nuclear power plants. These requirements include the following: • no interrupts • no dynamic memory allocation • no support for event driven multi-tasking • be simple and include only the functions and components necessary for I&C safety functions • be self-tested • include defense-in-depth safety programming • execution must be safety oriented (i.e., go to a safe position when a failure is detected) • internal independent V&V is required

OSS compliance with IEC 880-1986 (Reference 4-2) is summarized in Section 3.10, which also provides a comparison of IEC 880-1986 and NRC Branch Technical Position 7-14 (Reference 4-9). OSS compliance with IEC 880 requirements is discussed in further detail in Section 6.3, which also shows the alignment of the OSS life cycle processes to BTP 7-14 (Reference 4-9). The Design Analysis Report (DAR) examines how the OSS life cycle processes and the resulting OSS product compare to a product developed under BTP 7-14 software life cycle processes. The favorable DAR findings on this matter support the Rolls-Royce decision to dedicate the SPINLINE 3 platform software, which includes the OSS.

The SPINLINE 3 safety software (i.e., the OSS and application software) performs sequentially, deterministically and periodically the set of functions shown in Figure 4.4-2 which are explained further in the following sections.


Initialization

Cycle Time Management

Tests and Self Tests

Input boards and Nervia reception

Application

Output boards and Nervia emission

Local Display Unit

Cyclical Mode(Normal Operation)

Figure 4.4-2. SPINLINE 3 Software Cycle

After successful initialization, the processing unit enters the cyclical mode: • Tests and self-diagnostic tests detect failures in the hardware environment down to the level of boards.

• Cycle time management maintains a fixed cycle time and halts the CPU if the cycle time is exceeded,

• Acquisition and data management of all analog and discrete inputs in this processing unit, including

inputs from NERVIA networks,

• Execution of the application software, on a fixed time interval, which can be configured to be between 5 milliseconds and 264 seconds

• Providing output data to all analog and discrete outputs in this processing unit, including outputs to

NERVIA networks,

• Management of data exchange with the LDU.


The OSS is deterministic, meaning: • It runs in a cyclical mode, all treatments are executed at every cycle and they are independent from

inputs and external events. So there is no risk of processing overload.

• It has a fixed cycle time which is checked at each cycle.

The SPINLINE 3 OSS is adapted to the hardware configuration of the unit by mean of a set of parameters. Dedicated requirements for design and V&V have been issued and taken into account for this set of parameters for:

• Parameter structures, values, processing,

• Unit testing,

• Use of a reverse engineering tool for parameter verification.

The SPINLINE 3 OSS has undergone the following systematic formal tests:

• Unit tests on all software components,

• Integration tests,

• Validation tests performed on several target hardware configurations.

Additional V&V conducted on the plant-specific application software is described in Section 6.4.6.

4.4.3.3 Experience Feedback Related to the Operational System Software

This OSS is in operation on all the safety systems provided by Rolls-Royce since 1997. The SPINLINE 3 OSS reuses most software components, such as boards, drivers, and self-diagnostic test modules, which were developed for the EDF N4 project. The specific NPPs operating these systems are identified in Chapter 2.

Due to the high quality of the Rolls-Royce software development process, SPINLINE 3 systems have not experienced an unsafe condition in more than 85 reactor-years of operation as of December 2008.

4.4.3.4 Operational System Software Modes of Operation

The operating modes of the OSS and the allowable transitions between operating modes are shown in Figure 4.4-3.


[[

Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprie ]]

The transition from one OSS operating mode to another depends on the failures detected by the OSS functions, according to the principles of hardware failures management described in Section 4.4.3.6 and in Rolls-Royce document 1 207 108 J (Reference 4-23). The conditions for transitions between operating modes are summarized in Table 4.4-1.


[[


]]

4.4.3.5 Operational System Software Functions

The OSS performs the following five functions:

• Initialization;

• Tests and self-diagnostic tests;

• Cycle time management;

• Inputs/outputs management, which include: Acquisition and Transmission; and

• Data exchange management with the Local Display Unit (LDU).

These OSS functions are described in more detail in the following sections.

[[


Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text

Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text

]]


4.4.3.6 OSS Hardware Failure Management

Principles of hardware failure management are based on hardware failure detection. The OSS detects failures through the following three steps:

1. Checks of hardware status:

• To signal hardware status,

• To manage operation modes of the processing unit.

2. Internal indicators are generated from the results of hardware status checks. These indicators are used by functions of the OSS to invalidate data transmitted to application software and to manage data acquisitions/outputs. These indicators include:

• Operation status – indicates status of a board

• Address status – indicates access status of a board

• Specific status – this status is returned by specific checks on boards (e.g. loss of power of discrete input boards)

• Specific validity – specific validity of information set according to specific status.

3. External indicators are generated from hardware status checks. These external indicators are used

to signal hardware failures to Monitoring and Maintenance Unit (MMU) processing units, which are described in Section 4.6.10. These indicators include:

• Board status: indicate fault/no fault on a board,

• Network station (i.e. microcontroller) status: indicate fault/no fault on a station,

• Network status: indicate network status as seen by a network station,

• Communication status: indicate status of the communication between two SPINLINE 3 processing units over a NERVIA network.

[[


Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary ]]


4.4.4 System and Software Development Environment (SSDE)

4.4.4.1 CLARISSE SSDE

The CLARISSE System and Software Development Environment (SSDE) is the software development and automation environment that is used to build a plant-specific SPINLINE 3 application. CLARISSE includes SCADE, which evolved from SAGA, and all the tools to produce automatically generated executable code. These tools are not safety qualified. The output of the tools is subject to thorough V&V.

The CLARISSE environment serves the entire software development life cycle, from the functional specification phase to the code generation. It performs the following main functions:

• Description of the I&C architecture and hardware configuration. This description is used to generate automatically the OSS configuration, network configuration and network messages. The system components originally were proven and developed in compliance with IEC 880-1986 guidance (Reference 4-2) as implemented in I&C France procedures.

• Development of the application software using the SCADE tool. SCADE is based on a formal approach, which guarantees the completeness and the non-ambiguity of the design. These are essential characteristics for safety critical systems.

• Automatic generation of reliable and traceable code for the entire software set to be loaded on SPINLINE 3 processors.

CLARISSE generates the data structures used as interfaces between OSS and application software.

The following diagram shows the interfaces of the OSS and the application software in a processing unit. The blue boxes show permanent code and configuration data accessed in Read Only Memory (i.e. in write-protected RAM) and the Green boxes shows temporary Data such as acquisition values stored and accessed in Read/Write memory (read/write RAM).


CPU BOARD Hardware

ConfigurationTables

System Data

InterfaceTables

Application Data

OSS

Application Software

I/O &

Network

ROM Data RAM Data

Figure 4.4-3. Component Interfaces Managed by CLARISSE

The interfaces shown in Figure 4.4-3 are:

• Hardware Configuration Tables: Static description of units and networks used only by the OSS.

• System Data: Information used only by the OSS.

• Interface Tables: Information exchanged between OSS and application software. The contents of these tables are defined on an application-specific basis during the design phase, using the CLARISSE SSDE.

• Application Data: Information used only by the application software.

4.4.4.2 The SCADE Design Tool

The SCADE graphical editor offers the user-friendly features described below:

• The application is described by means of data flow block diagrams, as shown in Figure 4.4-4. These diagrams are very similar to traditional functional block diagrams. The use of this graphical notation allows for easier communication between system experts, subject matter experts, and software teams. The risk of introducing errors is reduced because the formalism is simple and comprehensible, and the number and types of possible human errors is greatly reduced when compared to traditional coding in a procedural language such as "C."

• The underlying language of SCADE is the synchronous data flow language LUSTRE. Based on simple mathematical principles, one of the salient features of LUSTRE is its ability to support formal design and formal verification. Semantic checks are performed, so that inconsistencies can be detected as early as possible (e.g. A real value is not a valid input of a Boolean operator, a first value must be specified at start up time).


Figure 4.4-4. SCADE Data-Flow Diagram Example

• Methodological checks can be performed to improve software reliability. SCADE includes a tool that checks proper application of design rules (e.g. variable names).

• Defensive programming can be easily set up by means of assertions.

• The SCADE specification is translated automatically into understandable C code. This C code is then compiled, assembled, and link-edited. The resulting binary code is either downloaded to the target CPU boards (development phases) or loaded into read-only memory components (for operation). For safety purposes, on-line downloading or modification of software is not possible on units during operation. The software is secured in write-protected memory with both physical and electronic identifiers. During operation, only user-defined parameters, which have been declared as modifiable, can be changed locally.

• Most of the documents are generated automatically.

• All manual inputs of CLARISSE are verified and validated during the software design phase using appropriate tools.

• CLARISSE provides an internal tool for configuration management.

A Class 1E application-oriented library of re-usable software components contains a set of standard safety SCADE operators (e.g., THRESHOLD, VOTE, etc.) that are available to application developers. These constructs are in the “SCADE” language. If functionalities dedicated to a particular safety system are not available in these libraries, they can be developed easily by use of additional functions coded in C language. These additional functions are also represented as SCADE operators and can be used directly in the “SCADE language.” Function interfaces are automatically generated in C language by CLARISSE. The body of these functions is then designed in C language according to a specific software life cycle process. Each SCADE operator in the application-oriented library has been subject to V&V.


4.4.4.3 Linking and Loading Processing Unit Software

[[Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text

Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Prop]]

4.4.5 Application Software

4.4.5.1 Application Software Overview

The plant-specific application software is dedicated to each processing unit and therefore is not a common software component, except within identical redundant divisions. The application software may be built from libraries of common operators, as described in Section 4.4.4.2, and user-defined modules.

This section describes the basic processes and tools for development of application software. Specific safety applications developed on the SPINLINE 3 digital safety I&C platform will be described in separate documentation from the NPP applicant.

Main features of the application software are the following:

• Data-flow organization: The program consists of a set of boxes connected by wires, flowing from the input data on the left to the outputs on the right. The wires convey data according to data types. The boxes transform data by means of Boolean operators, numeric operators, or by means of functions. All loops in the layout are controlled precisely by using the “previous” operator.

• Top/down design: The application program starts with an upper level view and proceeds through refinement steps for both the functions and the data. Relevant details are added at the appropriate level.

• Single task: The application program runs as a subroutine called within the OSS main program loop. It is executed periodically at each program cycle.At each execution, the application program computes its outputs from a fixed image of the sensors and network inputs provided by the OSS and from relevant results of its previous executions. The application program executes sequentially. No processing is done under hardware or software interrupts and no multitasking or multithreading is implemented. This prevents potential for deadlocks, resource sharing conflicts, and overload problems. This design helps to fulfill the deterministic response time requirements and keeps the software simple.

• Synchronous approach: The application program is designed to meet the synchronous hypothesis (i.e. the program reacts instantaneously to input events). The hypothesis is fulfilled when the processing is always performed within the cycle time allocated to the unit. The SPINLINE 3 CPU board offers enough computing power to fulfill the processing needs of typical I&C protection functions in the nuclear field. Moreover, the dataflow organization of the program makes the CPU load quite independent of the actual values of the inputs.


4.4.5.2 Application Software Compliance with Branch Technical Position 7-14

The software life cycle process for application software is governed by the software Plans described in Section 6.4. Compliance of these Plans with the NRC Branch Technical Position BTP 7-14 (Reference 4-9) is described in Section 6.4.

4.4.6 Generic Design Elements Against Software Common Cause Failure (CCF)

Protection against CCF is primarily provided at the overall I&C architecture level by implementing different lines of defense, including diversity as defined by NUREG/CR-6303 (Reference 4-14). Individual safety I&C systems are generally designed with identical equipment (same hardware and software) in separate divisions, therefore raising a CCF issue at that level.

As stated in IEC 60880-2006 (Reference 4-15), Section 13.2, “Design of software against Common Cause Failure (CCF)”:

“The basic and most important defense against common cause failure due to software is to produce software of the highest quality, i.e. as error-free as possible.”

As described below, this defensive measure is implemented in SPINLINE 3 software life cycle processes.

High quality of software development

SPINLINE 3 software development is based on software life cycle processes that guarantee achievement of a high level of quality (see Chapter 6). It aims at:

• Avoiding errors by means of:

• Adherence to a strict and phased development process, • Re-use of proven components, • Use of simple and proven design principles based on clearly defined rules, • Avoidance of unnecessary complexity • Use of proven tools for automated code generation as much as possible to reduce risk of human

errors. • Eliminating errors as soon as possible:

• Documents produced during a phase are formally verified and reviewed before starting the next phase,,

• V&V tasks are performed by an independent team, • Static verification is performed on all manual source code and parameters, • Unit tests, integration tests, processing unit validation tests, factory interconnected tests, site tests

are planned and performed. • Tolerating potential residual errors:

• Defensive programming, • Fail-safe features.

SPINLINE 3 application software is developed using the CLARISSE SSDE (see Section 4.4.4.1) and the SCADE design tool (see Section 4.4.4.2), which provides for automated generation of executable code, contributing to the high quality of the software.


Feedback from operational experience

Rolls-Royce has significant operational experience in designing and maintaining Class 1E software based systems performing protection functions such as reactor trip or ESFAS. These systems are generally designed with three or four identical independent equipment divisions implemented with the same hardware and the same software. In these systems, the software components are therefore a potential cause of CCF. As a consequence of the high quality software development, the feedback of experience gained from the P4, the N4 and the SPINLINE 3 safety I&C systems is that no failure with software as a root cause has been detected during operation in installed Class 1E systems up to now. This includes the four redundant P4 SPIN (20 units) and N4 SPIN (4 units) as well as the three redundant DUKOVANY RTS/ESFAS safety systems (4 units).

4.5 Communications

This section provides a generic description of how digital communications are implemented using the NERVIA digital communication network hardware and software to achieve intra-divisional and inter-divisional communications within a safety I&C system and to also achieve one-way communications between the safety I&C system and non-safety I&C systems. Communication hardware is described in Section 4.3.4.

In NUREG/CR-6082 (Reference 4-16), a set of 15 questions are posed to help reviewers focus attention on issues important to safety, reliability and performance. Answers from Rolls-Royce to those questions are presented in Section 3.6.

4.5.1 The Open Systems Interconnection (OSI) Model

The Open Systems Interconnection (OSI) model developed by the International Standards Organization (ISO) is designed to describe general routed messaging networks. The ISO model breaks down the various services required for communication into seven layers and standardizes these layers.

The NERVIA network implemented in SPINLINE 3 is built according to the Enhanced Performance Architecture (EPA) and implements the following three layers of the OSI model:

• The physical layer (OSI layer 1), which manages communications of bits through media;

• The data link layer (OSI layer 2), which manages the communication of message frames; and

• The application layer (OSI layer 7), which manages the communication of messages.

The NERVIA application layer is designed to ensure safe and efficient communication. The application layer includes only the services strictly needed by the other OSI layers:

• Network (OSI layer 3)

• Transport (OSI layer 4)

• Session (OSI layer 5)

• Presentation (OSI layer 6)


4.5.2 NERVIA Basic Concepts

NERVIA is a network dedicated to the exchange of information inside and among divisions of I&C safety systems. NERVIA allows a set of processing units to permanently exchange a pre-defined set of data within a bounded time frame, in order to ensure deterministic response time of safety actuations under all plant conditions.

The basic concept of the NERVIA network is to allow the exchange of data between processing units as if these data were wired and periodically updated by one unit and scanned by all others through digital I/O boards.

This exchange of data is such that the same information is sent again and again on the network and that the exchanged values evolve only when external conditions evolve, such as toggle of a discrete input or change in a sensor value. In order to implement this, the NERVIA network is “cyclic”, i.e. each station transmits its information periodically at its turn, and “broadcast” i.e. each transmitted message is received quasi simultaneously by all other stations on the network. No acknowledge mechanism or answering messages is implemented. Corrupted or missing messages are processed by receiving stations as invalid until reception of the next valid message.

Each processing unit can read the information produced by all other processing units on the same network and can issue its own information to these units, as if this information was permanently available, and without the need to know that it is exchanged through a digital network. The application software processes information coming from the network the same way as information acquired from or sent to I/O boards.

In order to provide this communication capability to the application software, the NERVIA network has the following characteristics:

The main features of NERVIA digital communications are:

• Deterministic communication (time-based token bus protocol, broadcast transmission, fixed cycle time);

• Broadcast network;

• No “master” station;

• Network initialization is independent of station initialization;

• Cyclical update of transmitted data;

• Station operation is asynchronous with Unit operation;

• Failure detection and recovery mechanism;

• Reliability (self-tested, fault tolerant).

These features are described in more detail in the following sections.


The following two definitions are used in the descriptions of the NERVIA network.

• Station: The Station provides the network service. A Station is one of the network connections

available on the electronic board equipped with a microprocessor running the NERVIA software (supported by NERVIA+ daughter board and associated I.NERVIA+ interface board or PCI NERVIA+ board as described in Section 4.3).

• Unit: The Unit makes use of the network service provided by the Stations. A Unit is composed of a CPU board, running the application software, and possibly I/O boards.

4.5.2.1 Deterministic Communication

The main property of the NERVIA network is to ensure deterministic communication The NERVIA network delivers the actual state of the data within a predefined maximum time. In order to achieve this property, the NERVIA network implements a dedicated communication protocol which is both “time-based” and “token-bus.”

Time-based protocol

“Time-based” means that each station knows when it can transmit and how long it is allowed to transmit its data, based on a synchronization signal. The time scheme is established from the configuration of the network, performed during design. It is composed:

• First, by the sequence of transmitting stations declared on the network,

• And then, by the amount of data transmitted by each station.

The time scheme defines the maximum network cycle time and the expected time for each station transmission, relative to the synchronization signal.

Token-bus protocol

“Token-bus” means that each station is allocated a sequence number, called the “token.”

This token is transmitted from one station to the other through the “next station sequence number” field included in all network messages.

“Bus” means that the physical topology of a NERVIA network is a bus, not a ring.

Broadcast transmission

Each message transmitted on the NERVIA media is received by all other stations within a minimum and maximum bounded propagation time. The maximum propagation time is taken into account when building the NERVIA network time scheme.

Message sent on the network are synchronization signal for all receiving stations, allowing the NERVIA network to meet its bounded response time requirement in case of failure of one or several stations. It allows stations to start transmission in case they de not receive the token from their previous station.


On reception of a message, a station compares the sequence number contained in the transmitted message with its own sequence number:

• [[

o

o

o

o

o

o •

o

o Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text

o ]]

Without reception of messages for more than one network cycle, i.e. all other stations are down, the station transmits its message periodically, based on its timer. This message will be the synchronization signal for the next station to join the network.

Transmission and reception are mutually exclusive operations.

Fixed cycle time definition

During configuration of the network, each transmitting station is allocated the amount of time needed for:

• Preparation of the message

• Transmission of the message on the network

• Reception and processing of the message by the receiving stations.

This amount of time is called the station “time window.” It is fixed for each transmitting station and differs from one transmitting station to another. The sum of all the time windows is the network cycle time.

Each Station transmits only once during a network cycle. Since all data are transferred at each cycle, the amount of data transmitted by each Station during a network cycle is fixed and a station failure has no impact on the network cycle time. The network cycle time is constant, and fixed by the network configuration.

[[


]]

Several typical communications errors, including loss and regeneration of the token, are explained in Sections 4.5.4 and 4.5.5.

4.5.2.2 Broadcast Network

The data transmitted by one station are received and stored by all other stations on the network. All Stations on the network are updated in parallel and have the same database. Units have read access to all data exchanged on the network. They have write access only to their own data in the form of Consistency blocks (see §5.5.4.3). Access to specific data is under control of the application program.


4.5.2.3 No “Master” Station

The NERVIA network management does not rely on a “Master” Station. No station has a specific role, either during network initialization or during operation. Active Stations can still work together, even in case of failure of one or several Stations on the network.

4.5.2.4 Network Initialization Independent of Station Initialization

The network is initialized as soon as a first Station is powered up.

When a Station is powered up, it first listens to the network traffic for a period of time greater than the Network cycle time.

• If no message is received during this period of time, the Station knows it is the first on the network and starts transmission.

• If the station receives a message, it knows where it is located within the time scheme and can start normal operation within the network.

When a station is down, the next station can proceed, based on its timer information.

When the station is up again, it reinserts in the traffic, following the initialization sequence.

4.5.2.5 Cyclical Update of Transmitted Data

NERVIA guarantees a constant cycle time with a tolerance of 5%. All network data are transmitted once at each cycle. All data are exchanged between Units according to a predefined configuration described in fixed tables.

4.5.2.6 Station Operation Not Synchronized with Unit Operation

Station and Units have independent cyclical processing. Exchanges between a Unit and an associated Station are not synchronized. Messages are exchanged through a dual ported-shared memory according to a dedicated protocol, using two buffers for which the access by the Unit or the Station is enabled through two data control flags (see § 4.5.4.3).

4.5.2.7 Reliability (self-tested, fault tolerant)

NERVIA is a Local Area Network (LAN) dedicated to communication within safety I&C systems. The NERVIA network is compliant with the NRC inter-divisional communications requirements for Class 1E I&C systems, as defined in the NRC Interim Staff Guide DI&C-ISG-04 (Reference 4-11). A compliance analysis is provided in Section 3.7.

The NERVIA network is designed to provide: • Reliable data exchange between Class 1E safety-related Units, • Appropriate isolation to support data transmission from Class 1E safety-related Units to non-1E

Units.


The following features ensure the reliability of the NERVIA based communications: • Static configuration of the network, defined during design and not modifiable in operation. • Application-to-application validity data associated to each frame transmitted on the network. • Monitoring of liveliness of upstream stations and units, allowing for safety-oriented action by

downstream units. • Self-test performed by NERVIA stations. • CRC32 included in NERVIA messages

4.5.3 NERVIA Hardware

The basic SPINLINE 3 communications hardware components are described in Section 4.3.4.8. Additional information on these components is provided in the component data sheets in Appendix B. This section describes how the communications hardware works in the context of a NERVIA communications network. Communications software is described in Section 4.5.4.

[[


]]


4.5.4 NERVIA Software

4.5.4.1 Main NERVIA Software Properties

The main properties of the NERVIA Network that allow it to be used in Class 1E I&C systems are:

• The only function of the NERVIA network is to transfer data from one Unit to others, without any modification. NERVIA guarantees the cyclical distribution of data, which is supplied to each Station by its Unit.

• Self-checking: ensures integrity of the transmitted data, whatever the default.

• High level of failure detection: all failures are detected.

• Availability is insured by the fault-tolerant protocol and guaranteed transmission time (deterministic, cyclic protocol).

4.5.4.2 Behavior in Case of Typical Failures

[[


Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Pro]]

4.5.4.3 Data Consistency and dual port memory protocol management

Within a given configuration, each Station transmits a fixed amount of data. Data are organized into blocks, known as consistency blocks (CB). Consistency is managed at three levels: the network level, the dual port memory level, and the Unit level.

[[


]]

4.5.5 Detailed Operation

4.5.5.1 Categories of Stations

NERVIA manages two categories of Stations, corresponding to different Station programs: the base stations and the stations associated with the test equipment.

A station category is defined during the network configuration. Within each category, it is important to distinguish between the transmitting stations and the receive-only stations. Most stations are transmitting stations, as described above. The stations associated with the test equipment are able to simulate one, several, or all the stations of the network in a given configuration. The stations associated with the test equipment therefore can transmit data several times during a network cycle. The receive-only stations are stations that, within a given configuration, do not transmit any data. Consequently, they do not use time during the network cycle and are not allocated any time on the network. They can only receive and store all the data carried on the network that is available to their equipment.

4.5.5.2 States of Stations

[[


]]


4.5.6 Communication Failures Detection

The purpose of this section is to present a general overview of the self-diagnostic tests for NERVIA. There are three categories of self-diagnostic tests for NERVIA:

[[

Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text ]]

4.5.7 Isolation and Independence Enforced on Data “Gateways” to Non-Class 1E Computer Systems

The PCI NERVIA+ board described in Section 4.3.4.8 establishes the physical interface between a non-Class 1E external computer and the SPINLINE 3 NERVIA+ communications network. This interface is shown in Figure 4.5-1.


[[

]]

Figure 4.5-1. Representative Gateway Configuration for Delivering Data from a SPINLINE 3 System to a Non-Class 1E System

Electrical, data and physical isolation is provided by the following features which ensure proper isolation and independence between the Class 1E SPINLINE 3 system and the non-Class 1E external computer on the other side of the “gateway”:

• Electrical isolation between the Class 1E system and the non-Class 1E system is provided by using fiber-optic communication links.

• Data isolation is implemented in the design of the NERVIA + network by means of a one-way data flow path from the Class 1E system to the non-Class 1E which prevents communication from the non-Class 1E systems/components to the Class 1E SPINLINE 3 systems. The non-Class 1E computer is a “non-transmitting” station like the one included in Figure 4.5-1.

• No fiber optic cable is provided for the return path from the non-Class 1E systems/components and the Class 1E systems.

• Physical isolation is implemented by means of proper physical separation between the Class 1E SPINLINE 3 system and the non-Class 1E external computer.

4.5.8 Compliance With NRC Communications Requirements

Compliance with NRC inter-divisional communications requirements for Class 1E I&C systems, as defined in the NRC Interim Staff Guide DI&C-ISG-04 (Reference 4-11), is documented in Section 3.7 and Table 3.7-1.


4.6 Testability

Safety equipment such as the Reactor Protection System or the Engineered Safety Features Actuation System does not produce any actuating signal when the plant is operating normally. In order to ensure that the equipment is capable of operating when needed, it is essential to set a strategy to verify the capacity of each part of the equipment to fulfill its functions. That is the purpose of testing the platform periodically.

Testability involves all the features implemented to detect all failures that can render the equipment incapable of performing its function. Features that provide testability include self-diagnostic tests, surveillance functions, and periodic tests. Several features have already been described in previous sections:

• See Section 4.4.3.5 for a description of the normal test and self-diagnostic test functions performed

by the OSS every cycle • See Section 4.4.3.6 for a description of how the OSS detects and manages hardware failures • See Sections 4.5.6 and 4.2.9 for descriptions of communications failure detection and the associated

alarming and signaling of communications failures

This section describes the principles and the methodology used to perform tests in order to verify the capability of safety systems to perform their functions in accordance with the design and safety requirements. This section gives an overview of the strategy used for testing. The different categories of tests are described.

The section is structured as follows:

• The overall strategy, • Detailed description of periodic tests of SPINLINE 3 equipment

4.6.1 Overall Strategy for Testing

The main objective of the testing strategy is to ensure, by means of failure detection, that the performance requirements defined in the design basis for automatic actuation and manual control are fulfilled.

The testing strategy includes the verification of the main parameters, which are accuracy, calibration, setpoint values, and response time.

The testing strategy is based on a combination of the following:

• Self-diagnostic tests that run as part of each cycle,

• Surveillance functions that are performed during refueling outages, and

• Periodic tests that are performed during plant operation.

A combination of tests is required to reduce the time when the unit is out of operation during the periodic tests. The strategy for testing arises from considerations associated with the safety objectives of:

• Optimizing failure detection, • Avoidance of spurious trips and/or actuations,


• Reducing maintenance costs and • Optimizing the testing period and duration.

4.6.2 Basic Concepts

Based on a typical ESF with the NERVIA architecture implemented, a single, complete test of one division may not be possible. In such case, a series of overlapping tests will be performed which will result in acceptable demonstration of the operation of the system. The periodic test is performed in one division at a time. The periodic tests are optimized in term of simplicity, safety, and equipment operability.

The testing strategy is based on the following considerations:

• Tests and surveillance functions are taken into account at the very beginning of the design, from the level of the module up to the level of the whole system.

• Self-diagnostic tests and self-supervision functions are implemented for early fault detection.

• The self-diagnostic tests and self-supervision functions are defined and refined after a safety analysis.

• When a fault is detected by self-diagnostic test, the output of the affected function is automatically set in a safe position.

• The results of self-diagnostic tests are permanently processed by a diagnostic system in order to help operators to identify the faulty module. The time to restore functional operation is thus minimized.

• The periodic tests require manual intervention on the equipment. It is desirable to limit the number of periodic tests and their duration.

• The self-diagnostic tests and self-supervision functions cover a wide range of potential failures. These tests support lengthening the interval between periodic tests.

• The periodic tests are dedicated to detect the possible residual faults not detected by self-diagnostic tests.

• The periods between tests are defined after a dependability analysis that takes into account the efficiency of self-diagnostic tests and surveillance functions. These periods may be different for each system.

• Prior to performance of the periodic tests on a unit, the unit shall be placed in a bypass mode by the maintenance operator, in order to avoid any spurious actuation during the periodic test. The bypassed status is signaled to the operator in Control Room.

• The bypassed status of a unit is taken into account by other units as appropriate (typically, the bypassed status of a trip logic unit in a division is taken into account by the voting logic in the other divisions as expressed in Section 4.2.5).

• The periodic tests are performed with Automated Testing Units (ATU), manually plugged on the system to be tested and manually started, as described in Section 4.6.9.

• The ATU produces a printed report.

• The ATU is equipped with signal generators, signal generating boards to simulate analog and discrete inputs, and network interfaces to simulate the data coming from the networks.

• After the periodic test, the correct operation of the tested unit is verified.

4.6.3 Design Principles for Testability

For a redundant architecture, periodic testing itself induces a risk for abnormal operation, due to the operation of the tested unit.


Some features are fundamental for periodic test purposes considering the design bases of the architecture:

• The architecture is based on redundancy with at three or four independent divisions.

• During the periodic test of a unit, the tested unit is bypassed and the bypassed status is reported as required by plant specific Technical Specifications.

• The periodic test of a unit is possible during operation of the plant.

• Only one unit is tested at a time, based on requirements in administrative procedures.

Hardware

For testability, the adequate interface devices are typically provided in the front of the cabinet: Plug-in sockets are provided for connecting the Automated Testing Unit (ATU) and in some case switches are also provided to set the unit into test position.

Alarming functions related to the testing of equipments are implemented directly on the chassis or on the cabinets. The opening of the cabinet doors is alarmed, to inform operators of possible changes in the safety systems status. The position of the test switches is alarmed, to inform operators of testing in progress on safety systems.

A connecting socket is available in front of each CPU board to give the operator the possibility to read or modify internal parameters by using the local display unit (LDU). This feature is mainly used during validation tests and not during periodic tests.

Correct operation of the safety system supposes a correct connection of all wiring to sensors, actuators, power supplies, manual controls, as well as network links. Some of these connections are directly self-tested, for instance when a signal is delivered (sensor or power supply). Verifying the signal itself is enough to test the connection. The network links are permanently self-tested through exchange of messages. Some connections to actuators are permanently verified, using a short pulse test. For example, the wiring to safety actuators can be tested up to the coil of the relay which controls the actuator. This is valid only if only one coil is connected. Connections which cannot be permanently tested are verified during periodic tests.

Software

Software contributes to testability through the following:

• Self-diagnostic tests with failure detection performed by the Operational System Software;

• The results of self-tests are processed by the MMU in order to help maintenance operators identify the faulty module; and

• Automated tests performed by the ATU during periodic tests.

4.6.4 Functional Verification Surveillance

The digital technology gives a considerable advantage for the surveillance of the correct system operation. One of the major features of digital systems is cyclic self-tests for functional verification. The reasoning is based on the following:

• The function of a unit is mainly performed by software stored in read only memories and supported by hardware.

• Hardware components can fail with a known probability. They must be tested using self-diagnostic test or external self-supervision functions.


• Software components are developed with a process aimed at producing “zero fault” software. Failures resulting from software faults are very unlikely. . however, achievement of “zero fault” software is difficult to demonstrate and the system is designed to withstand consequences of potential residual software faults.

• Random hardware failures are considered during software design for possible detection by self-test and for possible consequences on the software execution. For instance, failures of a read only memory can be detected by a memory self-test, and possible consequences of these failures can be minimized by the defensive programming implemented in the software.

• The verification of the function of the unit consists in checking the content of the ROM memories (program and parameters). If the content of the memories is not modified, the software has not changed and thus still conveys the same function. This verification is performed by the memory Self-diagnostic tests.

Most of the hardware faults are detected during operation by self-tests, and alarmed. The probability of having remaining latent, undetected faults is low. Periodic tests address detection of these remaining faults.

4.6.5 Self-diagnostic Tests

The function of self-diagnostic tests is to detect failures of hardware components early to prevent possible spurious operation of the safety system resulting from latent faults between two periodic test sessions. This concern requires permanent and automated surveillance functions performed by the equipment itself.

Two types of self-diagnostic tests are implemented, the hardware and software self-diagnostic tests.

• Hardware Self-diagnostic Tests: The hardware self-diagnostic tests are permanent monitoring functions, performed by the equipment itself, and based on analog or hardware techniques.

• Software Self-diagnostic Tests: The software self-diagnostic tests are used to verify the correct operation of hardware components, including memories and processors. The aim of self-diagnostic tests is to detect the maximum number of faults in order to increase the time between periodic tests. The software self-diagnostic tests are automatically performed at each cycle by each safety classified unit. These self-diagnostic tests evaluate the CPU board, microprocessor-based stations, and communication networks.

[[

]]


Generally, self-diagnostic tests are performed during each cyclic program execution. Some self-diagnostic tests, called slow self-diagnostic tests, are executed across several cycles. Then, the testing sequence needs a specific time to be completed. The main issue concerns the acceptable time during which a failure with safety consequences is not detected. The time required to detect such failures is used in the safety analysis.

4.6.6 Surveillance Functions

The surveillance functions provide the following indications to the operators:

• Some failures of safety equipment not detected by self-diagnostic tests,

• Discrepancies between functional parameters within and between divisions, which can result from a failure.

Alarm and signaling of such detected failure is performed as described in Section 4.2.9.

Maintenance operators can use the results from the Monitoring and Maintenance Unit (see section 4.6.10) for corrective and preventive maintenance.

4.6.7 Periodic Tests

The periodic tests are performed in steps, with overlapping between each step. The set of tests is a complete verification of all the hardware paths used by safety functions for actuation or signaling.

The periodic tests have two main objectives:

• To demonstrate that the equipment is capable of operating correctly when needed. Therefore, periodic tests ensure that inputs and outputs are active and that each assembly can produce the right actuation control when required. The time between periodic tests is validated by the dependability assessment.

• To detect hardware latent faults in safety classified units, which are not detectable by self-diagnostic tests and by the self-supervision functions provided by the MMU. Generally, inputs and outputs of these units are usually in the same state. During periodic tests, inputs are changed to cause expected changes in the output and thus to verify the capability of the system to operate.

The periodic tests are applied to each safety unit by using an Automated Testing Unit (ATU). They are initiated manually, and then performed automatically.

[[


]]

4.6.8 Description Self-diagnostic Testing Features of SPINLINE 3 Equipment

4.6.8.1 Software Self-diagnostic Tests Implemented on the CPU Board

A CPU board is equipped with the following typical hardware functions:

• The microprocessor

• The Random Access Memory (RAM)

• The flash memory

• The electrically erasable programmable read-only memory (EEPROM)

• The parallel bus

• The control logic

• The clock

• The network

The following paragraphs give the main characteristics of self-diagnostic tests on the main boards.

[[


]]

4.6.8.2 Tests of Peripheral Boards

4.6.8.2.1 Tests of Pulse Inputs (ICTO)

The acquisition of pulse inputs is performed through ITCO boards.

[[

]]


4.6.8.2.2 Tests of Analog Inputs (EANA)

The acquisition of analog inputs is performed through EANA boards.

[[

Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprie ]]

4.6.8.2.3 Tests of Discrete Inputs (ETOR)

The acquisition of discrete inputs is performed through discrete input boards (ETOR).

[[

Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary tex ]]


4.6.8.2.4 Tests of Actuation Interface (ACT)

The self-diagnostic tests of the Actuation interface board cover:

• Internal failures of the boards;

• Transmission failures to relays that control actuation; and

• A specific self-diagnostic test, called the short pulse test, is performed for actuator boards.

Periodic tests: According to the self-diagnostic test analysis, no periodic tests have to be performed for actuation interface boards.

4.6.8.3 Tests of Output Relays

Potential failures of output relays are failure of the coil or failure of a contact. [[Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Propriet ]]

4.6.8.4 Synthesis of Tests Overlapping on Electronic Boards

Table 4.6-1 gives the synthesis and the overlapping of tests performed on each main type of board of the safety systems.

[[


1. Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text

2. Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary te]]

4.6.9 Automated Testing Units (ATU)

The ATUs are non-Class 1E automatic devices to facilitate systematic testing. An ATU is manually plugged in the front of the tested cabinet for testing a unit. Once the maintenance staff starts the test, the tests are automatically processed. A written report is printed.

The ATUs are designed with these basic features:

• The ATUs produce signals equivalent to all types of input signals, coming from sensors (analog and discrete) or from networks.

• The ATUs receive the output signal from the tested unit by connection to the network.

4.6.9.1 Functions of ATUs

The ATUs are dedicated to periodic tests. The ATUs inject signals to inputs of the conditioning or processing units and detect hardware faults on all the protection signal paths.

[[

]]


4.6.9.2 Hardware and Software of ATUs

ATUs are non-Class 1E devices built with industrial computers for signal management and processing purposes. They are equipped with:

• Generators to produce signals equivalent to those issued from the neutron detectors as necessary.

• Analog and discrete output boards to apply analog and discrete test signals.

• A microprocessor-based interface board to simulate messages from other units and to read the response of the tested unit.

• The generators are verified periodically in order to achieve the metrological requirements.

• The computer and its interfaces are on a mobile cabinet.

• The software of the ATU is predefined and standardized. The programming consists of a description of the tested unit and a definition of the “input test vector” (sequence and value of injected values) and “output test vector” (output expected values).

4.6.10 Monitoring and Maintenance Unit (MMU)

The Monitoring and Maintenance Unit (MMU) is a non-Class 1E unit that is dedicated to process the result of self-diagnostic tests in order to help the maintenance operator to identify the location of the required corrective action in case of a failure:

• On a SPINLINE 3 module: By using the results of the self-diagnostic tests performed by each unit,

• On a SPINLINE 3 communication link: By using the results of the self-diagnostic tests performed by the NERVIA networks,

• On a sensor: By cross checking the values acquired by identical instrument channels in separate divisions.

MMUs are connected using a one-way NERVIA communication network to all the digital units and process the surveillance functions including the comparison between redundant measurements, in order to detect a wrong operation or a wrong parameterization of a unit. The comparison is adequate to detect, for example, a drifting sensor.

4.6.10.1 Functions of Monitoring and Maintenance Unit

The role of the MMU is to process the results of self-diagnostic tests received from all the units in order to indicate to the maintenance operator some pertinent information enabling the operator to locate the failed board. According to the data received from networks, the MMU produces a list of recommendations regarding the likely failure. The objective is to achieve a fast return to normal operation.

A more complete analysis can be done at the failed unit level. The functions of the Monitoring and Maintenance Unit are the following:

• Self-supervision functions, for example by comparison of similar information in redundant divisions

• Generation and display of messages concerning the status of the systems being monitored on the printer

• Display functional information about systems


• Diagnosis of failures of the monitored Class 1E equipment

4.6.10.2 Hardware and Software of Monitoring and Maintenance Unit

The MMU hardware is a non-Class 1E PC-type computer, equipped with microprocessor-based interfaces and screen and keyboard for man-machine interface.

The MMU software includes a large number of pre-existing functions, including receiving messages from the networks, comparison between redundant values, and interpretation of self-diagnostic test codes. To simplify the operator’s work and to reinforce safety conditions, all the screens are organized with the same frame, which includes:

• The top of the screen provides a permanent display of important data such as CPU identification, operating mode, status of the network, etc.,

• Display area dedicated to the running process,

• A specific area for the menu

4.7 Secure Development and Operational Environment

The generic SPINLINE 3 platform software and plant-specific application software for a SPINLINE 3 system are developed in-house by Rolls-Royce and a plant-specific system is integrated and factory tested in Rolls-Royce facilities. The software life cycle processes for the generic SPINLINE 3 platform software and plant-specific SPINLINE 3 application software are discussed in Chapter 6. Requirements for a secure development and operational environment for digital safety systems are defined in Draft Regulatory Guide 1249 (Proposed Revision 3 of Regulatory Guide 1.152, dated March 2010) (Reference 4-25), which describes a method that the NRC staff deems acceptable for complying with the Commission’s regulations for promoting high functional reliability and design quality for the use of digital computers in safety systems of nuclear power plants. Compliance with Regulatory Guide 1.152 is described in the separate Rolls-Royce document 3 013 962 (Reference 4-26)


4-1 “Equipment Qualification Plan”, Document No. 3 006 501D, I&C France, May 2010

4-2 IEC 880-1986, “Software for Computers in the Safety Systems of Nuclear Power Plants,” International Electrotechnical Commission

4-3 EPRI TR-107330, “Generic Requirements Specification for Qualifying a Commercially Available PLC for Safety-Related Applications in Nuclear Power Plants,” Electric Power Research Institute, December 1996

4-4 USNRC Letter dated July 30, 1998 to Mr. J. Naser (EPRI), “Safety Evaluation by the Office of Nuclear Reactor Regulation Electric Power Research Institute (EPRI) Topical Report, TR-107330, Final Report, “Generic Requirements Specification for Qualifying a Commercially Available PLC for Safety-Related Applications in Nuclear Power Plants.”


4-5 “SPINLINE 3 Design Analysis Report”, Document No. MPR-3337, MPR Associates, Inc., June 2009

4-6 Rolls-Royce Civil Nuclear SAS Quality Manual, Document No. 8 303 186 P, I&C France, June 2009

4-7 10 CFR 50 Appendix B, "Quality Assurances Requirements for Nuclear Power Plants and Fuel Reprocessing Plants”

4-8 IEEE Standard 7-4.3.2-2003, “Standard Criteria for Digital Computers in Safety Systems for Nuclear Power Generating Stations,” Institute of Electrical and Electronics Engineers

4-9 NRC Branch Technical Position 7-14, Rev, 5, “Guidance on Software Reviews for Digital Computer Based Instrumentation and Control Systems,” US Nuclear Regulatory Commission

4-10 IEEE Standard 379-2000, “Application of the Single-Failure Criterion to Nuclear Power Generating Station Safety Systems,” Institute of Electrical and Electronics Engineers

4-11 Interim Staff Guide DI&C-ISG-04, Revision 1, “Highly-Integrated Control Rooms – Digital Communication Systems,” US Nuclear Regulatory Commission, 6 March 2009

4-12 IEEE Standard 802.3i-1990, “IEEE Standard for Information Exchange Technology – Telecommunications and information exchange between systems – Local and metropolitan area networks – Specific requirements Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications,” Institute of Electrical and Electronics Engineers

4-13 Interim Staff Guide DI&C-ISG-02, “Diversity and Defense-in-Depth (D3),” US Nuclear Regulatory Commission, 26 September 2007

4-14 NUREG/CR-6303, “Method for Performing Diversity and Defense-in-Depth Analysis of Reactor Protection Systems”, Lawrence Livermore National Laboratory, December 1994

4-15 IEC 60880-2006, “Software for Computers in the Safety Systems of Nuclear Power Plants,” International Electrotechnical Commission

4-16 NUREG/CR-6082, “Data Communications,” Lawrence Livermore National Laboratory, August 1993

4-17 ASME NQA-1-1994, “Quality Assurance Program Requirements for Nuclear Facilities”, American Society of Mechanical Engineers

4-18 Master Configuration List, Document No. 3 010 612 D, I&C France, March 2010 4-19 10CFR21.21, “Notification of failure to comply or existence of a defect and its evaluation” 4-20 EPRI TR-106439, “Guideline on Evaluation and Acceptance of Commercial Grade Digital Equipment

for Nuclear Safety Applications”, Electric Power Research Institute, October 1996


4-21 USNRC Letter dated July 17, 1997 to Mr. Raymond C. Torok (EPRI), “Review of EPRI Topical

Report TR-106439, “Guideline on Evaluation and Acceptance of Commercial Grade Digital Equipment for Nuclear Safety Applications (TAC No. M94127)”

4-22 “Dedication Plan for the Generic SPINLINE 3 Digital Safety I&C Platform”, 3 010 794 A, I&C France,

December 2009 4-23 Software Requirements Specification – Operational System Software, 1 207 108 J, I&C France,

January 2010 4-24 IEEE 603-1991, "Criteria for Safety Systems for Nuclear Power Generating Stations," Institute of

Electrical and Electronics Engineers 4-25 Draft Regulatory Guide 1249 (Proposed Revision 3 of Regulatory Guide 1.152, dated March 2010),

June 2010, “Criteria for Use of Computers in Safety Systems of Nuclear Power Plants.” 4-26 SPINLINE 3 Secure Development and Operational Environment , Document No. 3 013 962 A, I&C

France


5 Equipment Qualification and Analysis

5.1 Equipment Qualification

Environmental qualification testing of the SPINLINE 3 Qualification Test Specimen (QTS) will be performed in accordance with the requirements of U.S. Nuclear Regulatory Commission (USNRC) Regulatory Guide (RG) 1.89, “Environmental Qualification of Certain Electric Equipment Important to Safety for Nuclear Power Plants,” (Reference 5-1) and requirements of Institute of Electrical and Electronics Engineers (IEEE) Standard 323-2003, “IEEE Standard for Qualifying Class 1E Equipment for Nuclear Power Stations” (Reference 5-2). This standard is subject to the enhancements and exceptions listed in Section C, “Regulatory Position” of USNRC Regulatory Guide 1.209, “Guidelines for Environmental Qualification of Safety Related Computer-Based Instrumentation and Control Systems in Nuclear Power Plants” (Reference 5-3).

The environmental qualification testing of the SPINLINE 3 QTS is also performed in accordance with the requirements for qualifying digital computers IEEE Standard 7-4.3.2-2003, “Standard Criteria for Digital Computers in Safety Systems of Nuclear Power Generating Stations” (Reference 5-4) and USNRC Regulatory Guide 1.152, Revision 2 (Reference 5-5).

Seismic qualification testing will be performed in accordance with Regulatory Guide 1.100, “Seismic Qualification of Electric and Mechanical Equipment for Nuclear Power Plants” (Reference 5-6), IEEE Standard 344-1987 (Reference 5-7) and the generic seismic spectra provided in Electric Power Research Institute (EPRI) Technical Report (TR)107330 (Reference 5-9).

EMC qualification testing will be performed in accordance with the guidance provided in Regulatory Guide 1.180, Revision 1, “Guidelines for Evaluating Electromagnetic and Radio-Frequency Interference in Safety Related Instrumentation and Control Systems” (Reference 5-8).

EPRI TR-107330, “Generic Requirements Specification for Qualifying a Commercially Available PLC for Safety-Related Applications in Nuclear Power Plants” (Reference 5-9), describes an approach for generically qualifying commercial Programmable Logic Controllers (PLCs) for safety-related applications. This approach was found acceptable by the USNRC as documented in USNRC Safety Evaluation Report (SER) Letter dated July 30, 1998 to Mr. J. Naser of the EPRI (Reference 5-10). The generic qualification approach for the SPINLINE 3 platform uses guidance from EPRI TR-107330 as applicable to meet the requirements of IEEE Standard 323-2003 and other USNRC guidance.


5.1.1 Equipment to be Tested

The equipment to be tested is the Rolls-Royce SPINLINE 3 QTS. In accordance with EPRI TR-107330 (Reference 5-9), a representative sampling of the SPINLINE 3 platform components are identified for evaluation and qualification testing. The assembled components of the SPINLINE 3 QTS include the following types of hardware modules and components:

• Chassis

• Power Supply Modules and Chassis

• Digital Processing Modules

• Communication Modules

• Signal Input Modules

• Signal Output Modules

• Signal Conditioning Modules

• Terminal Blocks

• Cable and Wire Sets

• Fan Cooling Hardware

• Power Distribution Hardware

The QTS will be exercised during qualification testing by a test system comprised of an industrial-grade data acquisition system (DAS) and a test specimen application program (TSAP). This test system is a non-qualified system whose purposes are to: (1) generate a series of known inputs to the QTS, and (2) monitor the corresponding outputs of the QTS. Correct correspondence between input and output before, during, and after qualification tests and lack of spurious behavior are the key results that will demonstrate the predictable behavior of SPINLINE 3 hardware during normal and abnormal plant operating conditions.

A detailed description of the SPINLINE 3 QTS and the test system is provided in the “System Specification for the Qualification Test Specimen and Data Acquisition System” (Reference 5-11). Test specimen and test system arrangement and wiring drawings will be prepared to provide additional hardware configuration information. A Master Configuration List (MCL), will be prepared to provide detailed SPINLINE 3 QTS configuration information such as component serial numbers and software version numbers.


5.1.2 Equipment Qualification (EQ) Testing

The Equipment Qualification (EQ) Plan (Reference 5-12) defines the scope of testing to be performed and provides a test plan for each of the individual qualification tests. The basic qualification test sequence is shown in Figure 5.1-1 and the individual tests are described briefly in this Section.

Test Specimen and Test SystemManufacture and Assembly

Pre-Qualification Testing SystemSetup and Checkout Testing

Pre-Qualification TestingPrudency Testing

Pre-Qualification TestingOperability Testing

Radiation Exposure WithstandTesting

Post-Radiation ExposurePrudency Testing

Post-Radiation ExposureTesting Operability Testing

Environmental Testing SystemSetup and Checkout Testing

MANUFACTURING

PRE-QUALIFICATION ACCEPTANCE TESTING

QUALIFICATION TESTING

Environmental Testing With Operability Testing at High Temp/RH, Low Temp/RH and Ambient Temp/RHWith Prudency Testing at High Temp/RH

Seismic Testing SystemSetup and Checkout Testing

Post SeismicPrudency Testing

Post SeismicOperability TestingSeismic Testing

EMI/RFI Testing SystemSetup and Checkout Testing

EMI/RFI SusceptibilityTestingEMI/RFI Emissions Testing

Electrical Fast Transient Testing Class 1E to Non-1E IsolationTestingSurge Withstand Testing

PERFORMANCE PROOF TESTING

Performance Proof Testing SystemSetup and Checkout Testing

Performance Proof TestingPrudency Testing

Performance Proof TestingOperability Testing

SPINLINE 3 QTS QUALIFICATION TESTING SEQUENCE

Test Specimen and Test System Factory Acceptance Testing

FACTORY ACCEPTANCE TESTING

Electrostatic DischargeTesting

Figure 5.1-1. SPINLINE 3 QTS Qualification Testing Sequence


5.1.2.1 Factory Acceptance Testing

Factory Acceptance Testing is performed at the end of the manufacturing and assembly phase to demonstrate compliance of the SPINLINE 3 QTS and Test System with the “System Specification of the Qualification Test Specimen and Data Acquisition System” (Reference 5-11).

During Factory Acceptance Testing, the SPINLINE 3 QTS will be powered with the input/outputs operating under control of the TSAP and the connected test system simulation devices. The input/output field circuits will be configured with loads representative of the types intended for connection to the corresponding input/output module points, and other devices required for monitoring of the circuit operations.

5.1.2.2 Pre-Qualification Acceptance Testing

The objective of Pre-Qualification Acceptance Testing is to demonstrate that the SPINLINE 3 QTS hardware and the Test Specimen Application Program (TSAP) operate as intended prior to start of qualification testing, and to provide baseline acceptance data for qualification testing implementation of the Operability and Prudency Tests. Section 5.2 of EPRI TR 107330 (Reference 5-9) provides guidance for implementation of pre-qualification acceptance testing.

5.1.2.3 Radiation Exposure Withstand Testing

The radiation exposure withstand testing demonstrates that the SPINLINE 3 QTS will not experience failures or unacceptable degradation due to expected radiation exposure from normal and abnormal service conditions as required by Regulatory Guide 1.89 (Reference 5-1) and IEEE Standard 323 (Reference 5-2). Section 4.3.6 of EPRI TR 107330 defines the normal and abnormal radiation exposure levels the test specimen must withstand (i.e., the test specimen must continue to meet the manufacturer specified performance levels).

As described in the EQ Plan, radiation exposure withstand test acceptance criteria are based on Section 4.3.6 of EPRI TR-107330.

5.1.2.4 Environmental Testing

The environmental testing demonstrates that the SPINLINE 3 QTS will not experience failures due to abnormal service conditions of temperature and humidity as required by Regulatory Guide 1.89 (Reference 5-1) and IEEE Standard 323 (Reference 5-2), subject to enhancements and exceptions listed in Section C of Regulatory Guide 1.209 (Reference 5-3). Section 4.3.6 of EPRI TR 107330 defines the recommended normal and abnormal temperature and humidity exposure levels the test specimen must withstand (i.e., the test specimen must continue to meet the manufacturer specified performance levels).

As shown in Figure 5.1-1, environmental testing is performed after completion of radiation exposure withstand testing, and includes performance of the post radiation exposure withstand testing Operability and Prudency Tests. The following describes the environmental testing sequence:

• Assemble the SPINLINE 3 QTS in the Environmental Test chamber.

• Perform the Pre-Environmental Testing System Setup and Checkout Test.

• Perform the Post Radiation Exposure Withstand Testing Operability and Prudency Testing.

• Expose the SPINLINE 3 QTS to varying temperature and humidity conditions according to the Environmental Testing procedures.

• Perform Environmental Testing Operability and Prudency Testing at the times identified in the Environmental Testing procedures.

• Remove the SPINLINE 3 QTS from the Environmental Test chamber.


As described in the EQ Plan, the Environmental Test acceptance criteria are based on Section 4.3.6 of EPRI TR-107330.

5.1.2.5 Seismic Testing

Seismic testing demonstrates the suitability of the SPINLINE 3 platform for qualification as a Category 1 seismic device based on seismic withstand testing performed on the SPINLINE 3 QTS in accordance with Regulatory Guide 1.100 (Reference 5-6) and IEEE Standard 344 (Reference 5-7). Section 4.3.9 of EPRI TR 107330 defines the seismic test levels to which the test specimen will be exposed, while the test specimen continues to meet the manufacturer specified performance levels.

As shown in Figure 5.1-1, seismic testing is performed after completion of environmental testing. The following describes the seismic testing sequence:

• Setup the SPINLINE 3 QTS on the Seismic Test table.

• Perform the Pre-Seismic Testing System Setup and Checkout Test.

• Perform Resonance Search testing on the SPINLINE 3 QTS components.

• Perform five seismic tests to the specified Operating Basis Earthquake (OBE) test levels.

• Perform one seismic test to the specified Safe Shutdown Earthquake (SSE) test level.

• Perform Post-Seismic Testing Operability and Prudency Testing.

• Remove the SPINLINE 3 QTS from the Seismic Test table.

As described in the EQ Plan, the seismic test acceptance criteria are based on Section 4.3.9 of EPRI TR-107330.

5.1.2.6 EMI/RFI Testing

The objective of EMI/RFI testing is to demonstrate the suitability of the SPINLINE 3 platform for qualification as a safety-related device with respect to EMI/RFI emissions and susceptibility levels. EMI/RFI testing of the SPINLINE 3 QTS will be performed in accordance with USNRC Regulatory Guide 1.180, Revision 1, using additional guidance from EPRI TR-107330 as applicable. The specific EMI/RFI tests to be performed include:

EMI/RFI Emissions Tests

• MIL-461E, CE101 (Reference 5-13): Conducted Emissions, Low Frequency, AC and DC Power Leads

• MIL-461E, CE102 (Reference 5-13): Conducted Emissions, High Frequency, AC and DC Power Leads

• MIL-461E, RE101 (Reference 5-13): Radiated Emissions, Magnetic Field, QTS Surfaces and Leads

• MIL-461E, RE102 (Reference 5-13): Radiated Emissions, Electric Field, Antenna Measurement

EMI/RFI Susceptibility Tests

• IEC 61000-4-6 (Reference 5-14): Conducted Susceptibility, Induced RF Fields, Power/Signal Leads


• IEC 61000-4-13 (Reference 5-15): Conducted Susceptibility, Harmonics/Interharmonics, Power Leads

• IEC 61000-4-16 (Reference 5-16): Conducted Susceptibility, Common Mode Disturbance, Power/Signal Leads

• IEC 61000-4-8 (Reference 5-17): Radiated Susceptibility, Magnetic Field, Helmholtz Coil Exposure

• IEC 61000-4-9 (Reference 5-18): Radiated Susceptibility, Magnetic Field, Pulsed

• IEC 61000-4-10 (Reference 5-19): Radiated Susceptibility, Magnetic Field, Damped Oscillatory

• IEC 61000-4-3 (Reference 5-20): Radiated Susceptibility, High Frequency, Antenna Exposure

As described in the EQ Plan, the EMI/RFI test acceptance criteria are based on Section 4.3.7 of EPRI TR-107330 and USNRC Regulatory Guide 1.180, Rev. 1.

As shown in Figure 5.1-1, EMI/RFI testing is performed after completion of seismic testing. The following describes the EMI/RFI testing sequence:

• Setup the SPINLINE 3 QTS in the EMI/RFI test chamber.

• Perform the Pre-EMI/RFI Testing System Setup and Checkout Test.

• Perform EMI/RFI Emissions Testing.

• Perform EMI/RFI Susceptibility Testing.

5.1.2.7 Electrical Fast Transient (EFT) Testing

The objective of EFT testing is to demonstrate the suitability of the SPINLINE 3 platform for qualification as a safety-related device with respect to EFT susceptibility levels. EFT testing of the SPINLINE 3 QTS will be performed in accordance with USNRC Regulatory Guide 1.180, Rev. 1 (Reference 5-8), using additional guidance from EPRI TR-107330 as applicable. The specific EFT test to be performed is IEC 61000-4-4, “Electromagnetic Compatibility (EMC), Part 4-4: Testing and Measurement Techniques, Electrical Fast Transient/Burst Immunity Test,” (Reference 5-21).

As described in the EQ Plan, the EFT acceptance criteria are based on Sections 4.6.2 and 4.3.7 of EPRI TR-107330 and USNRC Regulatory Guide 1.180, Rev. 1.

5.1.2.8 Surge Withstand Testing

The objective of surge withstand testing is to demonstrate the suitability of the SPINLINE 3 platform for qualification as a safety-related device with respect to surge withstand levels. Surge withstand testing of the SPINLINE 3 QTS will be performed in accordance with USNRC Regulatory Guide 1.180, Rev. 1, using additional guidance from EPRI TR-107330 as applicable. The specific surge withstand tests to be performed include:

• IEC 61000-4-5, “Electromagnetic Compatibility (EMC), Part 4-5: Testing and Measurement Techniques, Surge Immunity Test,” (Reference 5-22), and,

• IEC 61000-4-12, “Electromagnetic Compatibility (EMC), Part 4-12: Testing and Measurement Techniques, Oscillatory Waves Immunity Test,” (Reference 5-23).

As described in the EQ Plan, the surge withstand test acceptance criteria are based on Section 4.6.2 of EPRI TR-107330 and USNRC Regulatory Guide 1.180, Rev. 1.


5.1.2.9 Electrostatic Discharge (ESD) Testing

The objective of ESD testing is to demonstrate the suitability of the SPINLINE 3 platform for qualification as a safety-related device with respect to ESD withstand levels. EPRI TR-107330, Section 4.3.8, requires that the test specimen under qualification be tested for ESD withstand capability in accordance with the requirements of EPRI TR-102323-R1 (Reference 5-24). In accordance with EPRI TR-102323, the specific ESD Test to be performed is IEC 61000-4-2 “Electromagnetic Compatibility (EMC), Part 4-2: Testing and Measurement Techniques, Electrostatic Discharge Immunity Test,” (Reference 5-25). USNRC Regulatory Guide 1.180, Revision 1 (Reference 5-8) provides no guidance for ESD Testing.

As described in the EQ Plan, the ESD acceptance criteria are based on Sections 4.3.8 of EPRI TR 107330

5.1.2.10 Class 1E to Non-Class 1E Isolation Testing

The objective of Class 1E to non-Class 1E isolation testing is to demonstrate the suitability of the SPINLINE 3 platform for qualification as a safety-related device with respect to providing electrical isolation at non-Class 1E field connections, as required by IEEE Standard 384 (Reference 5-26). EPRI TR-107330, Section 6.3.6, requires that the test specimen under qualification be tested for Class 1E to non-Class 1E isolation capability in accordance with the requirements of EPRI TR-107330, Section 4.6.4.

As described in the EQ Plan, the Class 1E to non-Class 1E isolation testing acceptance criteria are based on Sections 4.6.4 of EPRI TR-107330.

5.1.2.11 Performance Proof Testing

The objective of performance proof testing is to demonstrate the continuing acceptable operation and performance of the SPINLINE 3 QTS following completion of all hardware qualification testing. EPRI TR-107330, Section 5.5 requires a final performance of the operability test procedure on completion of electrostatic discharge testing. As an alternative to this requirement, performance proof testing will include a final performance of both the Operability and Prudency test procedures following completion of all hardware qualification testing, and comparison of the test results to the results for all previous performances of the Operability and Prudency test procedures.

As shown in Figure 5.1-1, performance proof testing is performed after completion of Class 1E to non-Class 1E testing. The following describes the performance proof testing sequence:

• Remove the SPINLINE 3 QTS and test system from the EMI/RFI test chamber.

• Reassemble the SPINLINE 3 QTS and test system.

• Perform the Performance Proof Testing System Setup and Checkout Test.

• Perform Performance Proof Testing Operability Testing.

• Perform Performance Proof Testing Prudency Testing.

Acceptance criteria for performance monitoring of the SPINLINE 3 QTS during Performance Proof Testing will be as specified separately in the System Setup and Checkout, Operability and Prudency Test procedures. In addition, comparison of the Performance Proof Operability and Prudency Test data to all other Operability and Prudency test data shall not indicate an unacceptable change in performance of the SPINLINE 3 QTS hardware.


5.1.2.12 Operability Testing

The objective of operability testing is to demonstrate the continuing correct function and performance of the SPINLINE 3 QTS throughout qualification testing. Section 5.3 of EPRI TR-107330 describes the specific functional and performance tests to be performed as part of operability testing. These tests will be implemented in the SPINLINE 3 QTS operability test procedure as they are applicable to the SPINLINE 3 QTS design. Section 5.5 of EPRI TR-107330 identifies the points at which the operability tests should be performed during hardware qualification testing.

As shown in Figure 5.1-1, operability testing is performed at the following times during hardware qualification testing.

• With Pre-Qualification Acceptance Testing

• At the completion of Radiation Exposure Withstand Testing

• At the completion of the high temperature, high humidity phase of Environmental Testing

• At the completion of the low temperature phase of Environmental Testing

• At the completion of the low humidity phase of Environmental Testing

• At the completion of Environmental Testing

• At the completion of Seismic Testing

• With Performance Proof Testing

5.1.2.13 Prudency Testing

The objective of prudency testing is to demonstrate the continuing correct function and performance of the SPINLINE 3 QTS throughout qualification testing. Section 5.4 of EPRI TR-107330 describes the specific functional and performance tests to be performed as part of prudency testing. These tests will be implemented in the SPINLINE 3 QTS prudency test procedure as they are applicable to the SPINLINE 3 QTS design. Section 5.5 of EPRI TR-107330 identifies the points at which the prudency tests should be performed during hardware qualification testing.

As shown in Figure 5.1-1, prudency testing is performed at the following times during hardware qualification testing.

• With Pre-Qualification Acceptance Testing

• At the completion of Radiation Exposure Withstand Testing

• At the completion of the high temperature, high humidity phase of Environmental Testing

• At the completion of Seismic Testing

• With Performance Proof Testing

5.1.3 Generic Qualification Envelope

Successful execution of the Equipment Qualification (EQ) Plan (Reference 5-12) will qualify the generic SPINLINE 3 digital safety I&C platform for the qualification envelope summarized in Table 5.1-1.


Table 5.1-1. Generic Qualification Envelope for the SPINLINE 3 Digital Safety I&C Platform

Equipment Qualification

Category LTR

Section EQ Plan Section Regulatory Requirements Source of Qualification

Test Specification Qualification Envelope and

Test Levels Qualification Test Acceptance

Criteria

Radiation Exposure

5.1.2.3 Appendix C Regulatory Guide 1.89 (Ref. 5-1) and IEEE Standard 323-2003 (Ref. 5-2)

Section 4.3.6 of EPRI TR-107330

[[

Proprietary text Proprietary text Proprietary tex]]


Environmental (Temperature & Humidity)

5.1.2.4 Appendix D Regulatory Guide 1.89 (Ref. 5-1) and IEEE 323 (Ref. 5-2), subject to enhancements and exceptions listed in Section C of Regulatory Guide 1.209 (Ref. 5-3).

Section 4.3.6 of EPRI TR-107330, modified

[[Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text



[[Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Pro]]

[[Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary te Proprietary text Proprietary ]]

Seismic 5.1.2.5 Appendix E Regulatory Guide 1.100 (Ref. 5-6) and IEEE Standard 344 (Ref. 5-7)

Section 4.3.9 of EPRI TR-107330. The OBE and SSE tests shall follow the RRS curve given as Figure 4-5 in EPRI TR-107330 within the limits of the seismic test table, with the exception that the minimum ZPA requirements are met. [[Proprietary text Proprietary text

Proprietary text Proprietary text Proprietary text Propr]]

Section 4.3.9 of EPRI TR-107330.m\




Category

LTR Section

EQ Plan Section Regulatory Requirements Source of Qualification



Criteria

EMI/RFI Emissions Tests

MIL-461E, CE101 (Ref. 5-13): Conducted Emissions, Low Frequency, AC and DC Power Leads

[[ ]] Section 4.3.7 of EPRI TR-107330 and USNRC RG 1.180, Rev. 1

[[Proprietary text Proprietary text Proprietar]]

MIL-461E, CE102 (Ref. 5-13): Conducted Emissions, High Frequency, AC and DC Power Leads



MIL-461E, RE101 (Ref. 5-13): Radiated Emissions, Magnetic Field, QTS Surfaces and Leads



MIL-461E, RE102 (Ref. 5-13): Radiated Emissions, Electric Field, Antenna Measurement



EMI/RFI Susceptibility Tests

Section 4.3.7 of EPRI TR-107330 and USNRC RG 1.180, Rev. 1

[[Proprietary text Proprietary text Proprietary text P]]

EMI/RFI 5.1.2.6 Appendix F USNRC Regulatory Guide 1.180, Revision 1 (Ref. 5-8)

IEC 61000-4-6 (Ref. 5-14): Conducted Susceptibility, Induced RF Fields, Power/Signal Leads

[[ ]]






Category

LTR Section




Criteria

IEC 61000-4-13 (Ref. 5-15): Conducted Susceptibility, Harmonics/Interharmonics, Power Leads


[[Proprietary text Proprietary text Proprietary text ]]


[[Proprietary text Proprietary text Proprietary text Proprietary]]

IEC 61000-4-16 (Ref. 5-16): Conducted Susceptibility, Common Mode Disturbance, Power/Signal Leads

[[ ]]


[[Proprietary text Proprietary text Proprietary text Proprietary]]


[[Proprietary text Proprietary text Proprietary text Propr]]

IEC 61000-4-8 (Ref. 5-17): Radiated Susceptibility, Magnetic Field, Helmholtz Coil Exposure

[[ ]]



IEC 61000-4-9 (Ref. 5-18): Radiated Susceptibility, Magnetic Field, Pulsed


[[Proprietary text Proprietary text Pro]]

IEC 61000-4-10 (Ref. 5-19): Radiated Susceptibility, Magnetic Field, Damped Oscillatory


[[Proprietary text Proprietary text Pro]]




Category

LTR Section




Criteria

IEC 61000-4-3 (Ref. 5-20): Radiated Susceptibility, High Frequency, Antenna Exposure


[[Proprietary text Proprietary text]]

[[Proprietary text Proprietary text Proprietary text Propriet]]

Electrical Fast Transient (EFT)

5.1.2.7 Appendix G

USNRC Regulatory Guide 1.180, Rev. 1 (Ref. 5-8)

IEC 61000-4-4, “Electromagnetic Compatibility (EMC), Part 4-4: Testing and Measurement Techniques, Electrical Fast Transient/Burst Immunity Test,” (Ref. 5-21)

[[Proprietary text Proprietary text Proprietary text Propriet]]

Sections 4.6.2 and 4.3.7 of EPRI TR-107330 and USNRC Regulatory Guide 1.180, Rev. 1




Category

LTR Section




Criteria

Table 22 of USNRC RG 1.180, Rev. 1 defines the IEC 61000-4-12 Ring Wave and IEC 61000 4-5 Combination Wave surge withstand levels for power supplies installed in Category B locations with surge waveform Low Exposure levels

Table 15 of USNRC RG 1.180, Rev. 1 defines the IEC 61000-4-12 Ring Wave and IEC 61000 4-5 Combination Wave surge withstand levels for signal leads in Low Exposure locations with Level 2 surge waveforms.

[[.Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text ]]

IEC 61000-4-5, “Electromagnetic Compatibility (EMC), Part 4-5: Testing and Measurement Techniques, Surge Immunity Test,” (Ref. 5-22)

Surge Withstand

5.1.2.8 Appendix H USNRC Regulatory Guide 1.180, Rev. 1 (Ref. 5-8)

IEC 61000-4-12, “Electromagnetic Compatibility (EMC), Part 4-12: Testing and Measurement Techniques, Oscillatory Waves Immunity Test,” (Ref. 5-23).

[[ Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text ]]

Section 4.6.2 of EPRI TR-107330 and USNRC Regulatory Guide 1.180, Rev. 1.




Category

LTR Section




Criteria

Electrostatic Discharge (ESD)

5.1.2.9 Appendix I EPRI TR 107330, Section 4.3.8, requires that the test specimen under qualification be tested for ESD withstand capability in accordance with the requirements of EPRI TR-102323-R1. USNRC Regulatory Guide 1.180, Revision 1 (Ref. 5-8) provides no guidance or requirements for ESD Testing.

IEC 61000-4-2 “Electromagnetic Compatibility (EMC), Part 4-2: Testing and Measurement Techniques, Electrostatic Discharge Immunity Test.”

[[Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary te]]

Sections 4.3.8 of EPRI TR-107330

[[Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Propri]]

Class 1E to Non-Class 1E Isolation

5.1.2.10 Appendix J IEEE Standard 384 (Ref. 5-26). EPRI TR 107330, Section 6.3.6, requires that the test specimen under qualification be tested for Class 1E to non-Class 1E isolation capability in accordance with the requirements of EPRI TR-107330, Section 4.6.4


[[Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary]]



5.2 Equipment Analysis

This section describes the following generic analyses that have been performed to establish the foundations for future system-level analyses for plant-specific SPINLINE 3 systems:

• Board/device-level predictive reliability and safety analyses, which includes the following:

• Failure Modes and Effects Criticality Analysis (FMECA)

• Reliability analysis

• Setpoint analysis support

• Limited life parts analysis

5.2.1 Predictive reliability and safety analysis

5.2.1.1 Objective

The objectives of the board/device-level predictive reliability and safety analyses are to provide generic failure mode and effects criticality analysis (FMECA) and reliability data for the SPINLINE 3 hardware boards/devices identified in Section 4.3. These generic results are intended to be used as input data to support a system-level FMECA and reliability analysis for an NPP-specific SPINLINE 3 system.

This section includes a summary of the predicted reliability of SPINLINE 3 electronic boards and other components.

5.2.1.2 Approach for the FMECA

Generic board/device-level FMECAs have been prepared in accordance with the guidance in IEC 60812 (Reference 5-27). Unless otherwise noted, IEC 62380 (Reference 5-28) provides the distribution of failure modes and failure rates of the components that comprise the board/device being analyzed. These FMECAs are consistent the failure mode and effects analysis (FMEA) guidance of IEEE Standard 352-1987, Sections 4.1, 4.4, and 4.5 (Reference 5-29).

• Each board-level FMECA includes the following information on the device being analyzed:

• General description

• External functional analysis that identifies the device boundaries and the external systems that interact with the device

• Functional block diagram of the device

• Description of the function blocks

• The FMECA is used to identify the effects of the failure modes of each function block in the device and define the potential malfunctions of the device. For each board/device-level malfunction, the FMECA assesses the ability to detect the malfunction

• For each board/device, the FMECA results are presented in table format following the format and content guidance in IEC 60812


5.2.1.3 Results of the board/device-level FMECAs

The results of the board level FMECAs are documented in References 5-30 to 5-41.

5.2.1.4 Approach for the reliability analysis

The methods used to estimate the reliability of SPINLINE 3 boards/modules are based on the following:

• For all Rolls-Royce modules that are installed in a rack, the analyses have been recently updated and are based on IEC 62380, “Reliability Data Handbook, Universal Model for Reliability Prediction of Electronics Components, PCBs and Equipment,” (Reference 5-28) instead of MIL HDBK 217F, which is recommended in IEEE Standard 352 (Reference 5-27). IEC TR 62380 provides more current data for modern electronic hardware than MIL HDBK 217F

• For all Rolls-Royce modules that are installed in the cabinet but outside of the rack, the analyses are based on MIL HDBK 217F. These modules are MV16 and the output relay terminal block

• For modules from other manufacturers, the analyses are based on MIL HDBK 217F. These items are all installed in the cabinet but outside of the rack.

5.2.1.5 Results of the board/device-level reliability analyses

The results of the board level reliability analyses are documented in References 5-30 to 5-41. A summary of the predicted reliability for each board/device is presented in Table 5.2-1.

Table 5.2-1. Summary of the Predicted Reliability of SPINLINE 3 Electronic Boards and Other Components

Overall failure rate (h-1)

Rolls-Royce Predictive Safety and Reliability Analysis

Report

Source of Component-level Failure Data

Board Installed in the Chassis

RTD conditioning board: 8PT100 [[ ]]

I.8PT100 Interface board [[ ]]

5 100 436 882 B

(Reference 5-30) IEC 62380

Analog input board: 16E.ANA ISO [[ ]]

I.16EANA interface board [[ ]]

5 100 436 348 B


Digital isolated input board: 32ETOR TI SR [[ ]]

I.32ETOR TI interface board [[ ]]

5 100 435 707 C


Calibrated pulse acquisition board: ICTO [[ ]]

I.ICTO interface board [[ ]]

1 479 513 B


Actuator drive board: 32ACT [[ ]]

I.32ACT interface board [[ ]]

5 100 437 019 B






Report


Analog output board: 6SANA ISO [[ ]]

I.6SANA interface board [[ ]]

3 008 651 A


CPU board: UC25N+ [[ ]] 6 648 805 C


NERVIA+ daughter board

• Board equipped with 1 processor (management of up to 2 networks) [[ ]]

• Board equipped with 2 processors (management of up to 4 networks) [[ ]]

• Board equipped with 3 processor (management of up to 6 networks) [[ ]]

1 208 933 B


I.NERVIA+ interface board

• Management of up to 2 networks [[ ]]

• Management of up to 4 networks [[ ]]

• Management of up to 6 networks) [[ ]]

1 208 933 B

(Reference 5-37 IEC 62380

ALIM 48V/5V-24V power supply board [[ ]]

I.ALIM 48 interface board [[ ]]

3 000 180 B

(Reference 5-38 IEC 62380

Modules Installed Outside the Chassis

120VAC/48VDC power supply chassis [[ ]] None. Overall failure rate

obtained from manufacturer of the product.

MIL HDBK 217F

48VDC/48-24VDC power supply chassis [[ ]] None. Overall failure rate


MIL HDBK 217F

10MBps Ethernet Hub: 4TP [[ ]] None. Overall failure rate


MIL HDBK 217F

10MBps Ethernet Hub: 3TP/2FL [[ ]] None. Overall failure rate


MIL HDBK 217F

Twisted-pair to fiber optic (TP/FL) converter

• [[ ]] [[ ]] MIL HDBK 217F

• [[ ]] [[ ]]

None. Overall failure rate obtained from manufacturer of

the product.

Telcordia





Report


Actuation voting module: MV16 [[ ]] 5 100 436 936 A

(Reference 5-39) MIL HDBK 217F

Output relays terminal block: 8SRELAY1 and 8SRELAY2 [[ ]]

5 100 436 935 A

(Reference 5-40) MIL HDBK 217F

32ETOR input terminal block [[ ]] 3 008 991 B


8PT100 input terminal block

Failure rate not considered because this is a very simple

module (screw terminal block with a integrated circuit)

None

SPINLINE 3 interface terminal block

Failure rate not considered because this is a very simple

module (screw terminal block with a integrated circuit)

None

5.2.2 Setpoint Analysis Support

5.2.2.1 Objective

EPRI TR-107330, Section 4.2.4 (Reference 5-9) recommends that the qualifier provide information about the qualified hardware to support an application-specific setpoint analysis. USNRC Regulatory Guide 1.105, Rev 3 (Reference 5-42) endorses ISA S67.04-1994 (Reference 5-43), with qualifications, as the basis for performing an application-specific setpoint analysis.

The recommended setpoint analysis support information includes the following:

A. Calibrated accuracy, including hysteresis and non-linearity, of the analog inputs and outputs

B. Repeatability of the analog inputs and outputs

C. Temperature sensitivity of the analog inputs and outputs

D. Drift with time of the analog inputs and outputs

E. Power supply variation effects on the analog inputs and outputs

F. Error contribution of any arithmetic operations needed to implement a setpoint. The accuracy shall be based on using two additions and one multiplication on an input value plus a comparison. The error contributions shall be provided for both integer and floating point calculations.


In addition, EPRI recommends that the qualification process identify those components, if any, on analog I/O modules that are sensitive to the following.

G. Components where vibration could affect accuracy (e.g. potentiometers).

H. Components where radiation exposure could affect accuracy.

I. Components where relative humidity could affect accuracy.

The objective of the Setpoint Analysis Support Document (Reference 5-44) is to provide a single, concise listing of the accuracy, drift, and other relevant specifications of the SPINLINE 3 digital safety I&C platform. These specifications are intended to enable a licensee to calculate instrument measurement uncertainties and establish critical control setpoints for a plant-specific SPINLINE 3 system based on ISA RP67.04.02.

5.2.2.2 Approach

The Setpoint Analysis Support document provides the data recommended in EPRI TR-107330 for the following SPINLINE 3 components:

• 8PT100 Temperature conditioning board

• 16E.ANA ISO Analog signals acquisition and analog to digital conversion board

• 32ETOR TI SR ON-OFF isolated acquisition board (not redounded)

• ICTO Pulse Count Board

• 32ACT Actuator Drive Board

• 6SANA ISO Analog Outputs board

• MV16 Actuators voting module combining ON-OFF inputs

• 8SRELAY Type 1 Relay module based on Relay Type 1

• 8SRELAY Type 2 Relay module based on Relay Type 2

The accuracy specifications have been compiled from manufacturer’s documentation and the results of qualification testing of the SPINLINE 3 Qualification Test Specimen (QTS).

5.2.3 Limited Life Parts Analysis

EPRI TR-107330, Section 4.7.8.2 (Reference 5-9) requires the qualifier to perform a component aging analysis on the qualified hardware based on the normal and abnormal environmental conditions to which it is exposed. The purpose of this analysis is to provide a “qualified life” for components associated with the digital I&C platform under qualification.

Qualified life is a term not typically applied to digital I&C equipment intended for installation in a mild environment, because accelerated aging is not part of the equipment qualification program. In addition, IEEE Standard 323-2003 (Reference 5-2), Section 4.1 states that, “A qualified life is not required for equipment located in a mild environment and which has no significant aging mechanisms.” USNRC Regulatory Guide 1.209, Paragraph C.(1), (Reference 5-3) states that, “The NRC does not consider the age


conditioning (of IEEE Standard 323-2003) to be applicable because of the absence of significant aging mechanisms on microprocessor-based modules.”

The types of electronic components that typically have life limits are batteries and electrolytic capacitors. Any batteries in SPINLINE 3 hardware are identified in the Operations and Maintenance Manuals (OMMs) and regular replacement is performed throughout the operating lifetime of the system. There are no electrolytic capacitors or other components with known life limits in the generic SPINLINE 3 hardware described in Section 4.3.

Plant-specific SPINLINE 3 systems will be examined during the design phase to confirm if any life limited components are introduced in the hardware for a specific application. If any such components are identified, appropriate measures will be identified in the OMMs to manage the life-limited component.


5-1 U.S. Nuclear Regulatory Commission Regulatory Guide 1.89, Revision 1, “Environmental Qualification of Certain Electric Equipment Important to Safety for Nuclear Power Plants,” June 1984

5-2 IEEE 323-2003, “Standard for Qualifying Class 1E Equipment for Nuclear Power Generating Stations.”

5-3 U.S. Nuclear Regulatory Commission Regulatory Guide 1.209, Revision 0, “Guidelines for Environmental Qualification of Safety-Related Computer-Based Instrumentation and Control Systems in Nuclear Power Plants,” March 2007.

5-4 IEEE 7-4.3.2-2003, “Standard Criteria for Digital Computers in Safety Systems of Nuclear Power Generating Stations”

5-5 U.S. Nuclear Regulatory Commission Regulatory Guide 1.152, R2, Criteria for Use of Computers in Safety Systems of Nuclear Power Plants

5-6 U.S. Nuclear Regulatory Commission Regulatory Guide 1.100, Revision 2, “Seismic Qualification of Electric and Mechanical Equipment for Nuclear Power Plants,” June 1988

5-7 IEEE 344-1987, “Recommended Practice for Seismic Qualification of Class 1E Equipment for Nuclear Power Generating Stations.”

5-8 U.S. Nuclear Regulatory Commission Regulatory Guide 1.180, Revision 1, “Guidelines for Evaluating Electromagnetic and Radio-Frequency Interference in Safety-Related Instrumentation and Control System,” October 2003.

5-9 EPRI TR-107330, “Generic Requirements Specification for Qualifying a Commercially Available PLC for Safety-Related Applications in Nuclear Power Plants,” December 1996

5-10 USNRC Letter dated July 30, 1998 to Mr. J. Naser (EPRI), “Safety Evaluation by the Office of Nuclear Reactor Regulation Electric Power Research Institute (EPRI) Topical Report, TR-107330, Final Report, “Generic Requirements Specification for Qualifying a Commercially Available PLC for Safety-Related Applications in Nuclear Power Plants.”


5-11 “System Specification of the Qualification Test Specimen and Data Acquisition System,” Document No. 3 006 404 E , I&C France, April 2010

5-12 "Equipment Qualification (EQ) Plan", Document No. 3 006 501 D, I&C France, May 2010

5-13 Military Standard 461E, “Requirements for the Control of Electromagnetic Interference Characteristics of Subsystems and Equipment,” August 20, 1999

5-14 IEC 61000-4-6, “Testing and Measurement Techniques, Immunity to Conducted Disturbances Induced by Radio-Frequency Fields,” May 2006.

5-15 IEC 61000-4-13, “Testing and Measurement Techniques, Harmonics and Interharmonics Including Mains Signaling at A.C. Power Ports, Low Frequency Immunity Tests,” March 2002.

5-16 IEC 61000-4-16, “Testing and Measurement Techniques, Tests for Immunity to Conducted, Common Mode Disturbances in the Frequency Range 0 Hz to 150 kHz,” July 2002.

5-17 IEC 61000-4-8, “Testing and Measurement Techniques, Power Frequency Magnetic Field Immunity Test,” March 2001.

5-18 IEC 61000-4-9, “Testing and Measurement Techniques, Pulse Magnetic Field Immunity Test,” March 2001.

5-19 IEC 61000-4-10, “Testing and Measurement Techniques, Damped Oscillatory Magnetic Field Immunity Test,” March 2001.

5-20 IEC 61000-4-3, “Testing and Measurement Techniques, Radiated, Radio-Frequency, Electromagnetic Field Immunity Test,” February 2006.

5-21 IEC 61000-4-4, “Testing and Measurement Techniques, Section 4: Electrical Fast Transient/Burst Immunity Test,” July 2004.

5-22 IEC 61000-4-5, “Testing and Measurement Techniques, Section 5: Surge Immunity Test,” November 2005.

5-23 IEC 61000-4-12, “Testing and Measurement Techniques, Section 12: Oscillatory Waves Immunity Tests,” September 2006.

5-24 EPRI TR-102323-R1, “Guidelines for Electromagnetic Interference Testing in Power Plants,” January 1997.

5-25 IEC 61000-4-2, “Testing and Measurement Techniques, Section 2: Electrostatic Discharge Immunity Test,” April 2001.

5-26 IEEE 384-1981, “Standard Criteria for Independence of Class 1E Equipment and Circuits.”

5-27 IEC 60812 (2nd edition) 2006-01, "Analysis techniques for system reliability – Procedure for Failure Mode and Effects Analysis (FMEA)", International Electrotechnical Commission, 2006

5-28 IEC TR 62380 (1st edition) 2004-08, “Reliability Data Handbook, Universal Model for Reliability Prediction of Electronics Components, PCBs and Equipment,” International Electrotechnical Commission, 2004


5-29 IEEE 352-1987, “Guide for General Principles of Reliability Analysis of Nuclear Power Generating Station Safety Systems.”

5-30 “RTD conditioning board: 8PT100 and I.8PT100 Interface board”, Report 5 100 436 882 B, I&C France, 2009

5-31 “Analog input board: 16E.ANA ISO and I.16EANA interface board", Report 5 100 436 348 B, I&C France, 2009

5-32 Digital isolated input board: 32ETOR TI SR and I.32ETOR TI interface board”, Report 5 100 435 707 C, I&C France, 2009

5-33 “Calibrated pulse acquisition board: ICTO and I.ICTO interface board”, Report 1 479 513 B, I&C France, 2009

5-34 “Actuator drive board: 32ACT and I.32ACT interface board”, Report 5 100 437 019 B, I&C France, 2009

5-35 “Analog output board: 6SANA ISO and I.6SANA interface board”, Report 3 008 651 A, I&C France, 2009

5-36 “CPU board: UC25N+”, Report 6 648 805 C, I&C France, 2009

5-37 “NERVIA+ daughter board and “I.NERVIA+ interface board”, Report 1 208 933 B, I&C France, 2009

5-38 “ALIM 48V/5V-24V power supply board and I.ALIM 48 interface board”, Report 3 000 180 B, I&C France, 2009

5-39 “Actuation voting module: MV16”, Report 5 100 436 936 A, I&C France, 2009

5-40 “Output relays terminal block: 8SRELAY1 and 8SRELAY2”, Report 5 100 436 935 A, I&C France, 2009

5-41 “32ETOR input terminal block”, Report 3 008 991 B, I&C France, 2009

5-42 U.S. Nuclear Regulatory Commission Regulatory Guide 1.105, Rev. 3, "Setpoints for Safety-Related Instrumentation", December 1999

5-43 ISA RP 67.04.02-2000, “Methodologies for the Determination of Setpoints for Nuclear Safety-Related Instrumentation.”, Instrument Society of America

5-44 "Setpoint Analysis Support", Report 3 009 397A, I&C France, 2009


6 Software Development Process for SPINLINE 3 Platform Software and Application Software

6.1 SPINLINE 3 Platform Software Development History

Between 1993 and 1996, I&C France (at that time with Schneider Electric) modernized their existing digital safety I&C technology. This research and development (R&D) project was called MC3 (Modularité du Control Commande des Centrales). The objective was to start from the existing hardware and software technology used to implement the safety I&C systems on the EDF N4 1450 MW PWR in order to produce a modular digital platform, later called the SPINLINE 3 Platform, dedicated to the refurbishment and new construction requirements of the nuclear market for safety I&C systems worldwide.

The hardware for the SPINLINE 3 platform is derived from the N4 hardware with enhancements consisting mainly in a new design for the chassis to meet electromagnetic compatibility (EMC) requirements, and in the development of additional electronic boards to extend input/output (I/O) and processing capabilities, for instance, the new CPU board based on the MC68040 microprocessor.

The software for the SPINLINE 3 platform also builds on N4 software design and experience.

The following software was developed for the SPINLINE 3 platform:

• A Class 1E standardized Operational System Software (OSS), which creates the environment in which the SPINLINE 3 application software runs. The OSS is composed of the following three sub-tiers: Core System Software (CSS), Communication Driver with the Local Display Unit (CD_LDU), and a set of I/O board drivers and self-check subprograms called the Basic Functions (BF). The OSS development process is addressed in Section 6.2.1 to 6.2.6);

• A Class 1E application-oriented library of re-usable software components (addressed in Section 6.2.9);

• Class 1E software embedded in the communication board of the 10mbits/s version of the NERVIA network (addressed in Section 6.2.8.2) ; and

• A non-Class 1E set of tools integrated in a software development environment called CLARISSE, which is used for the configuration of the OSS and for the development of the application software for SPINLINE 3 systems (addressed in Section 6.2.7).

All software associated with the SPINLINE 3 platform was developed or procured according to a Quality Assurance program based on the International Atomic Energy Agency (IAEA) Standard 50-C-QA (Reference 6-1).

The SPINLINE 3 platform Class 1E software originally was developed under the life cycle process that was defined and used for the N4 project. This life cycle process explicitly addresses the development of software for safety-related systems in nuclear power plants (NPPs). This process originally was established based on the guidance of the International Electrotechnical Commission (IEC) Standard 880-1986 (Reference 6-2), with enhancements to take into account the advances in software engineering as reflected in a later revision of the standard.

The SPINLINE 3 platform software tools where either procured or developed. Rolls-Royce licensed the commercial off-the-shelf (COTS) SCADE tools from VERILOG (now Esterel Technologies) and the Motorola (now Freescale) MC68040 cross-development chain from Microtec Research, and developed the other software tools needed to configure the OSS and generate SPINLINE 3 application software and executable code.

Since 1996, safety related systems have been implemented with the SPINLINE 3 platform for several international projects. In order to meet specific requirements for these systems, Rolls-Royce has evolved the SPINLINE 3 software, mainly to implement new features such as those required for modernizing the safety I&C systems at the Dukovany NPP in the Czech Republic. These new features included increasing the speed of the NERVIA network to 10 megabits per second and developing or enhancing several I/O boards. These evolutions were performed under a strict modification process, consistent with the initial development process. They are tracked under the configuration management program.


The SPINLINE 3 software life cycle defined in this chapter was designed to comply with international engineering practice for software for nuclear safety applications.. As described in Section 1.1, the generic SPINLINE 3 platform now is managed under a quality assurance program that complies with 10CFR50 Appendix B (Reference 6-54) and is being commercially dedicated to demonstrate how the SPINLINE 3 software life cycle processes comply with U.S. nuclear safety requirements..

6.2 SPINLINE 3 Operational System Software (OSS) Development Process

6.2.1 OSS Software Life Cycle Process

The life cycle design and development process employed for the OSS, including the software library, was based on IEC 880-1986 (Reference 6-2). The IEC 880 standard provides process and technical requirements aimed at developing software suitable to implement safety I&C functions in NPPs. The life cycle processes used for the OSS development were based on those employed on the N4 project.

The OSS life cycle was divided into identified phases with defined input and output, design and validation and verification (V&V) activities and reviews, as documented in the MC3 Software Quality Plan (SQP), document 8 303 429 A (Reference 6-3).

This SPINLINE 3 OSS life cycle process depicted in the MC3 SQP is reproduced in Figure 6.2-1 below, with English translations for the various activities.


Requirements

Coding

Verification Review

Review

Review

Verification

Verification

Verification

Detailed Design

Preliminary Design

Unit Test

Integration

Validation

Figure 6.2-1. OSS Life Cycle Process

The life cycle process used to develop the OSS within the MC3 project is an implementation of the principles provided by IEC 880.

The main goal of this life cycle process is to produce “close to zero fault” software.

• The quality of the documents and code comes first from the activities of the design team and is then verified by a V&V team, independent from the design team, at each phase of the descending branch of the “V.”

• The quality of the software is checked through the testing performed during the phases of the ascending branch of the “V.”

The quality of the design and of the code is also supported by use of design and coding rules targeted at simplicity, deterministic behavior, understandable code, and structured programming, such as the recommendations provided by Appendix B of IEC 880. See Section 3.10.1 for more information on compliance with IEC 880 Appendix B.

The quality of the testing is obtained by applying systematic test strategies providing a comprehensive testing of the functions and of the code. Finding a low number of faults during the testing phases is a positive metric for the design and coding activities, which have a goal of achieving “close to zero fault” software during operation. This is the case for the OSS development as can be shown from the test reports referenced in this chapter.


6.2.2 SPINLINE 3 OSS Life Cycle Activities

The 1993 I&C France Quality Management System provided the framework and criteria for the initial development of the SPINLINE 3 platform design project.

The activities of the SPINLINE 3 development process were planned and organized according to the activities of a pre-defined life cycle for the system development with sub-cycles for hardware and software development.

Before starting the actual development, preliminary studies were performed and the Project Development Plan, document 6 615 351 (Reference 6-4), and contractual document TA 93061 (Reference 6-5) were established to address all the components to be developed for the implementation of the SPINLINE 3 systems and to secure funding and resources and set delivery dates. The requirements for software were provided in the Software General Requirement, document 1 207 101 (Reference 6-6), covering software to be developed for the project, mainly the Class 1E OSS and the CLARISSE SSDE. This document also provided the general strategy for the verification and validation of the OSS.

After review and approval of this initial set of documents, the development project started with a detailed planning phase and a breakdown into individual projects for the mechanical, the electronic and the software components.

Planning for the software project was documented in the MC3 Software Quality Plan 8 303 429 A, (Reference 6-3), which was established prior to development . This SQP applied to the Class 1E OSS (CSS, CD_LDU, BF) and to the non-Class 1E software such as the CLARISSE SSDE and the test bench developed for validation testing and periodic testing.

The SQP was the governing plan for the MC3 software development. The Software Development Plan, document 1 207 102 (Reference 6-7), which applied to the same software, also was established to describe the arrangements made for the management of the software project, including estimates for development and V&V effort and cost, initial schedules, technical resources needed, effort and cost tracking.

The MC3 SQP covered the following topics:

• Safety related software and non-safety related software addressed by the plan

• Organization and responsibilities for software development and V&V

• Life cycle process (see Figure 6.2-1), and task description, addressing independent V&V and human factors engineering (HFE)

• Documentation

• Configuration management

• Modification process

• Methods and tools

• Quality Assurance tasks, including end-of-phase reviews and audits

• Software manufacturing

• Security

• Software archiving


The MC3 SQP provided a list of referenced procedures and instructions to be used for the development.

.

The MC3 SQP was used for the initial development of the SPINLINE 3 software and for all evolutions up to the latest SPINLINE 3 evolution F performed in 2003. Since evolution E, it has been supplemented by the Software Modification Quality Plan, document 1 208 686 (Reference 6-8), which is dedicated to the SPINLINE 3 software modification process. It is supplemented by a separate SPINLINE 3 Software Configuration Management Plan, document 1 208 878 (Reference 6-9), which was introduced to describe the configuration management process under the Change DIMENSION, previously PCMS, configuration management tool.

The Software General Requirements, document 1 207 101 (Reference 6-6), was used as an input to the following documents:

• MC3 Software Requirement Specification, document 1 207 106 (Reference 6-21)

• MC3 Software Quality Plan, document 8 303 429 (Reference 6-3) and

• Software Validation Test Plan for the OSS, document 1 207 146 (Reference 6-15).

After the MC3 development, the Software General Requirements document has not been updated. Its content was incorporated as appropriate and is now maintained in the detailed requirement specification documents.

The evolution of the MC3 SQP and selected SPINLINE 3 software life cycle documents, from the initial MC3 version of the platform software through later development cycles, and culminating in the current software baseline, is summarized in Table 6.2-1.

Licensing Topical Report - SPINLINE 3 NRC Qualification 3 008 503 C - NP Imp rime n° 8303090 F

Table 6.2-1. Evolution of Selected SPINLINE 3 Software Life Cycle Documents

Evolution of Selected SPINLINE 3 Software Life Cycle Documents

Platform Software App SW

Type of Document Rolls-Royce Document Title Used in original

MC3 project platform software

project

Used in 2000 SPINLINE 3 platform SW

upgrade project


upgrade project

Applicable to a future SPINLINE 3

platform SW upgrade project

Applicable to future SPINLINE 3 plant-specific application

software

Comments

Rolls-Royce Civil Nuclear SAS Quality Manual (former SES department Quality Assurance Manual)

8 303 186 A/B/C/D/E/F 8 303 186 G 8 303 186 H 8 303 186 P 8 303 186 P

Software Quality Plan (SQP) - MC3 8 303 429 A/B/C/D/E 8 303 429 E 8 303 429 E Not applicable Not applicable

Software Modification Quality Plan Not applicable Not applicable 1 208 686 A 1 208 686 B Not applicable

Software Quality Plan - SCADE Operator Library Not applicable 1 208 356 A 1 208 356 A 1 208 356 C Not applicable

Software Quality Assurance Plan for Digital Hardware and Software

SPINLINE 3 Software Quality Assurance Plan - SQAP Not applicable Not applicable Not applicable Not applicable 8 307 208 B

Software Development Plan - MC3 1 207 102 A Not applicable Not applicable Not applicable Not applicable

Software Development Plan (SDP) - 2000 changes Not applicable 1 208 645 A Not applicable Not applicable Not applicable

Software Development Plan

Software Development Plan (SDP) - 2001 changes Not applicable Not applicable 1 208 908 A Not applicable Not applicable






project


upgrade project


upgrade project




software

Comments

Software Development Plan (SDP) - Future Not applicable Not applicable Not applicable Project-specific SDP Not applicable

SPINLINE 3 Software Development Plan - SDP Not applicable Not applicable Not applicable Not applicable 8 307 210 B

Software Quality Plan (SQP) - MC3 (This Plan + supporting instructions functioned as the SCMP)

8 303 429 A/B/C/D/E Not applicable Not applicable Not applicable Not applicable

Software Configuration Management Plan for SPINLINE 3 Software Sub-assemblies Managed by CM Tool

Not applicable 1 208 878 A 1 208 878 B 1 208 878 E Not applicable Software Configuration Management Plan

SPINLINE 3 Software Configuration Management Plan - SCMP Not applicable Not applicable Not applicable Not applicable 8 307 209 B

Software Requirements Specification

Software Requirement Specification - Operational System Software

1 207 108 A/B/C/D/E/F 1 207 108 G 1 207 108 H 1 207 108 J Not applicable

Software Preliminary Design - Core System Software

1 207 141 A/B/C/D/E 1 207 141 F 1 207 141 G 1 207 141 H Not applicable

Software Design Specification

Interface Specifications - Operational System Software and Application Software

1 207 110 A/B/C/D/E/F 1 207 110 G 1 207 110 H 1 207 110 J 1 207 110 J

Software Integration Plan, Test Plan

Software Integration Test Plan and Report (SITR) - SCC (Core System Software) 1 207 204 A/B/C 1 207 204 D 1 207 204 D 1 207 204 E Not applicable






project


upgrade project


upgrade project




software

Comments

Safety Analysis, Safety Plan

SPINLINE 3 Safety of Processing Unit Software

1 207 228 A/B/C/D/E 1 207 228 F 1 207 228 G 1 207 228 H Not applicable

Software Tool Verification Program

Requirements for Software Development Tools 1 206 747 A/B/C 1 206 747 C 1 206 747 C 1 206 747 E Not applicable

Software Quality Plan (SQP) - MC3 (This Plan + SVTP and supporting instructions functioned as the SVVP)

8 303 429 A/B/C/D/E 8 303 429 E Not applicable Not applicable Not applicable

Software Validation Test Plan (SVTP) - Operational System Software for Safety Class Units

1 207 146 A/B/C/D 1 207 146 E 1 207 146 F 1 207 146 G Not applicable

Software Modification Quality Plan (This Plan + SVTP and supporting instructions functioned as the SVVP)

Not applicable Not applicable 1 208 686 A 1 208 686 B Not applicable

Software Verification and Validation Plan

SPINLINE 3 Software Verification and Validation Plan - SVVP Not applicable Not applicable Not applicable Not applicable 8 307 210 B

V&V Reports Software Validation Test Report (SVTR) - Operational System Software for Safety Class Units

1 207 232 A/B/C 1 207 232 D 1 207 232 E 1 207 232 F Not applicable






project


upgrade project


upgrade project




software

Comments

General Processes for Software Development [IL_PROC_GEN] 1 208 079 A/B/C/D 1 208 079 E 1 208 079 E Not applicable Not applicable

Content of 1 208 079 was incorporated into and replaced by later revisions of 8 303 350.

Control of software design (safety systems) [PRO_Concept_log_C] Not applicable Not applicable Not applicable 8 303 350 L 8 303 350 L

Rules for Verification and Validation of Software Components 1 207 107 A/B/C 1 207 107 C 1 207 107 C 1 207 107 D Not applicable

Content of 1 207 107 incorporated into application software V&V template 8 307 210

Software Configuration Management Process [IL_Gest_Conf] 1 207 875 A 1 207 875 B 1 207 875 C 1 207 875 G 1 207 875 G

Software Management Implementing Procedures

Software Guideline: Software Document Evaluation Process [IL_Verif_Doc] 1 207 947 B/C 1 207 947 C 1 207 947 C 1 207 947 E 1 207 947 E


The activities performed in the SPINLINE 3 life cycle phases and associated documentation are discussed in the following sections. The application software life cycle processes are described in Section 6.4.

6.2.2.1 Requirements Specification (System and Software) Phase

For each software module to be developed, a detailed requirement specification was derived from the Software General Requirement, document 1 207 101 (Reference 6-6), established for the MC3 project. These software general requirements were issued after taking into account the experience gained on several major digital protection systems developed previously (e.g., the EDF N4 project for 1450MW NPPs). After the MC3 project, the Software General Requirement document was not updated. Its content was incorporated as appropriate and is now maintained in the detailed requirement specification documents.

For the Class 1E OSS, I&C France established the following:

• Software Requirement Specification, document 1 207 108 (Reference 6-10), provided detailed requirements for the OSS

• Software Requirement Specification, document 1 207 145 (Reference 6-11), provided detailed requirements for the CD_LDU

• Software Interface Specification, document 1 207 110 (Reference 6-12), provided detailed specification for interfaces between the OSS and the CLARISSE SSDE and between the OSS and the application software (e.g. the configuration tables).

• Requirements for SPINLINE 3 function blocks (FBs) either developed for the N4 project and adapted or newly developed for SPINLINE 3, and then documented in specification files (file “basic function” specification).

The OSS Software Requirement Specification (SRS) documents were verified by the I&C France V&V Group. This activity provided documents for assessment and approval performed during the requirement phase review, and prior to going to the next phase.

Records of verification reports and minutes of the specification review are available at I&C France.

The SRS documents are updated and maintained when necessary to support evolutionary changes of SPINLINE 3.

6.2.2.2 Preliminary Design Phase

The preliminary design activity produces the architecture for the software (i.e. the organization into layers of modules with definition of control flows, data flows and interfaces). The program structure was developed using a top-down approach that produced simple and easy to understand architecture and code. The software is designed so that the software units run cyclically, deterministically and sequentially.

The main architectural choices are always documented. The initial OSS design allowed support for a Class 1E and a non-Class 1E version of the OSS, sharing a common architecture and common modules. This design has been implemented in the first operational releases of the SPINLINE 3 platform. Since SPINLINE 3 evolution “E” performed in 2001, the Class 1E OSS and the non-Class 1E OSS are separate, distinct products. The architecture and the common modules of the Class 1E OSS were simplified by removing the code not needed for Class 1E applications. The resulting Class 1E OSS was subject to formal V&V. The non-Class 1E OSS is not addressed further in this LTR.


For the Class 1E OSS, I&C France prepared the following:

• Software Preliminary Design for the CSS, document 1 207 141 (Reference 6-13)

• Software Preliminary Design for the CD_LDU, document 1 207 163 (Reference 6-14)

The OSS preliminary design documents were verified by the I&C France V&V group. This activity provided documentation of the assessment that was discussed prior to going to the next phase.

Records of these verification reports are available at I&C France.

During the preliminary design phase, an analysis of the validation testing was started, aimed at establishing an early testing strategy to validate the requirements stated in the SRS.

This analysis is documented in the following:

• Software Validation Test Plan for the OSS, covering CSS, CD_LDU and BF, document 1 207 146 (Reference 6-15)

• Software Validation Test Plan dedicated for to the CD_LDU, document 1 207 175 (Reference 6-16)

The preliminary design documents are updated and maintained when necessary to support evolutionary changes of SPINLINE 3.

6.2.2.3 Detailed Design Phase

The detailed design phase produced the specification for the software modules and data structures to a level of detail allowing for coding in ”C” language. The detailed design provides the description of the functions, the algorithm being provided in the code itself.


• A set of Software Detailed Design (SDD) documents:

o Main part, document 1 207 151,

o Acquisition, document 1 207 153,

o Emission, document 1 207 154,

o Initialization, document 1 207 155,

o Pack/Unpack, document 1 207 156,

o Tests and Self-Tests, document 1 207 157, and

o Common Parts, document 1 207 159 (Reference 6-17)

• Software Detailed Design for the CD_LDU, document 1 207 174 (Reference 6-18)


The OSS detailed design documents were verified by the I&C France V&V group. This activity provided documented assessments with all findings discussed and documents approved during this phase review, prior to going to the next phase.

Records of verification reports and minutes of the design review are available at I&C France.

During the detailed design phase, an analysis of the integration testing was started, aimed at establishing early in the process the integration testing strategy to be used to validate the design architecture.

This analysis is documented in the:

• Software Integration Test Plan and Report for the OSS, covering CSS, CD_LDU and BF, document 1 207 204 (Reference 6-19)

• Software Integration Test Plan and Report , dedicated for the CD_LDU, document 1 207 239 (Reference 6-20)

The detailed design documents are updated and maintained when necessary to support evolutionary changes of SPINLINE 3.

6.2.2.4 Coding Phase

Software coding activities are the responsibility of the I&C France design team. This team was highly qualified in writing software. The software to be written is defined in the specifications contained in the detailed design documentation developed in the previous activities. The coding was performed mainly using the ANSI C high level programming language, according to the guidance provided in the I&C France “C” Programming Rule, document 1 207 106 (Reference 6-21) established for the MC3 project. In addition, six Basic Functions written in assembly language were needed for the initialization of the MC 68040, for self-tests of the MC 68040 instruction set, and for management of access to the dual-ported shared memory.


• Coding source files for the CSS

• Coding source files for the CD_LDU

• Coding source files for the BF

The coding source files were identified and managed under the Configuration Management Program.

The OSS coding source files were verified by the I&C France V&V group. This activity provided documents for assessment, prior to going to the next phase.

Records of verification reports are available at I&C France.


The coding source files are updated and maintained when necessary to support evolutionary changes of SPINLINE 3..

6.2.2.5 Unit Testing Phase

Almost 90% of the software modules developed for the OSS were tested by running unit tests at the module level. The other modules were covered by the tests run during integration or validation, based on their simplicity. The testing strategy for each module is documented in the SPINLINE 3 OSS Safety of Processing Unit Software, document 1 207 228 (Reference 6-22).

The unit testing strategy consisted in designing test cases derived from the module specification provided in the Software Detailed Design (SDD) documents using a black box functional testing approach. When 100% instruction coverage (C and assembly) is not achieved by these tests, additional test cases are designed, using a white-box approach to enhance structural coverage.

When unit testing of a module is completed, the object code used for unit testing is the one used to generate the final software.

For the Class 1E OSS, I&C France tested the following:

• The CSS and the CD_LDU modules, under a simulated MC68040 processor run time environment on a UNIX based Workstation.

• The BF modules, on the target SPINLINE 3 hardware equipped with appropriates I/O and CPU boards.

Units tests are documented in files managed under the Configuration Management Program. Each independently unit tested module has an associated set of files which include:

• A test analysis (file “module.”avl)

• A test program which includes the detailed test cases (file “module.”tvl.c)

• A test results file (file “module.”rvl)

If the OSS is modified, then the Unit Testing files are updated, used and maintained as necessary to support regression testing.

6.2.2.6 Integration Phase

The integration process combined software modules into programs capable of performing specified functions in accordance with the strategy defined in the integration plans. The goal of the testing performed during integration was to check for correct communication between modules, including having the basic functions interfaced with the hardware and to measure the execution time of the OSS modules. The programs developed for integration purposes were designed and built to run on specific hardware configurations, typically composed of one CPU board and one input or output board. The inter-module and performance testing was performed by the design group to check proper operation of individual functions of the OSS in these defined hardware environments.


The integration programs were built from sets of verified OSS software modules. Stubs were added when appropriate. Integration testing was performed in an environment which includes software debugging tools in order to access software variables or software control flow when necessary.

Integration tests were run as sessions until all planned tests were run without errors. Inside a session, as many of the tests are run as practicable, depending on the defects found during the testing. Defects were reported through formal anomaly reports and then processed for correction before start of the next integration test session. During a new session, tests successfully run during a former session on modules shown to be not affected by the correction were not run again. The session was completed when all planned tests had been run without errors. As an example, the OSS integration testing performed for the initial version of the OSS was found to be 100% correct after the third session.

For the OSS, the integration strategy, tests cases and results are documented in the:

• Software Integration Test Plan and Report, for the OSS, covering CSS, CD_LDU and BF, document 1 207 204 (Reference 6-19)

• Software Integration Test Plan and Report, for the CD_LDU, document 1 207 239 (Reference 6-20)

If the OSS is modified then the Integration Test Plan and Report documents are updated and maintained where necessary. based on new testing requirements and results of testing.

6.2.2.7 Validation Phase

The validation phase consisted in building the final software and exercising it in a hardware configuration representative of actual operational use. The validation testing was performed according to the strategy and detailed test cases defined in the validation plans. The results of the validation testing are documented in the validation reports.

The goal of the validation testing was to check the correct performance of the functions specified in the Software Requirements Specification, under conditions as close to operational conditions as practical. Inputs were simulated using both static and dynamic means. A matrix has been written to demonstrate a 100% coverage of the functions by the tests. Hardware configurations were established in order to achieve this coverage and tests harnesses were specified. A set of regression tests was established. These were run at each evolution of the OSS in order to check that the functions not impacted by the changes still function properly. Appropriate tests were added to the regression suite to ensure the changes were also covered.

The validated software was built from an identified baseline of verified software modules and was burned into flash memories.

Validation tests also were run as sessions until all planned tests were run without errors. For a session, as many of the tests were run as practicable, depending on the defects found during the testing. Defects were reported through formal anomaly reports and then processed for correction before the start of the next validation test session. During a new session, tests successfully run during a former session on modules shown to be not affected by the correction were not run again. The test was completed when all planned tests had been run without errors. In general, two validation sessions were adequate. Generally during the first session, a few anomalies are usually discovered and in the second session, no additional anomalies are discovered leading to software that is as close to 100% correct as can be achieved based on the reviews and testing performed. The validation testing records for each session and the anomalies found are always documented in the Software Validation Test Report.


For Class 1E software such as the OSS, the validation testing was planned, analyzed and performed by an independent V&V team.

For the OSS, the validation planning strategy, tests cases and results including all anomalies discovered were documented in the:

• Software Validation Test Plan, at OSS level, for validation strategy, document 1 207 146 (Reference 6-15)

• Software Validation Test Report , at OSS level, for detailed test cases and results, document 1 207 232 (Reference 6-23)

• Software Validation Test Plan, dedicated for the CD_LDU, for validation strategy, document 1 207 175 (Reference 6-16)

• Software Validation Test report, dedicated for the CD_LDU, for detailed test cases and results, document 1 207 292 (Reference 6-24)

The SPINLINE 3 OSS cannot perform any function without being linked to an application program which will receive inputs, perform processing and transmit outputs.

It was determined that three different chassis configurations were necessary to encompass the SPINLINE 3 range of I/O boards for the validation testing. For each chassis configuration, the data corresponding to its I/O boards were generated using the CLARISSE configuration tool Then a test application software exercising these I/Os was implemented, and the Processing Unit software linking the OSS, the test application software and the configuration data were generated using the CLARISSE SSDE.

The Processing Unit software for each of the three chassis configurations was exercised and tested according to the test cases defined in the validation test plans in order to cover all of the OSS functionality.

The Software Validation Test Plans (References 6-15 and 6-16) were reviewed before entering the validation implementation in order to check that the planned testing strategy is appropriate to validate the software with regard to requirements stated in the Software Requirements Specification.

The Software Validation Test Reports (References 6-23 and 6-24) are reviewed after validation to verify that the documented values resulting from execution of the test cases are compliant with the expected values stated in the test cases.

If the OSS is modified, then the Software Validation Test Plan and Software Validation Test Report documents are updated and maintained where necessary.

6.2.2.8 Maintenance & Modification

The I&C France Maintenance and Modification process is part of the I&C France Quality Management Program. This includes a process to record anomalies and requests for modification, such as enhancements of the SPINLINE 3 functionalities. It also includes a process to control implementation of subsequent changes implemented to the SPINLINE 3 components.


As introduced in Section 6.2.2, the SPINLINE 3 platform has undergone several evolutions since it was first developed during the years 1993-1996. The first evolutions were limited in scope and were implemented according to the I&C France maintenance and modification process, as required by the MC3 software quality plan.

A formal Software Modification Quality Plan, document 1 208 686 (Reference 6-8), was established to supplement the MC3 software quality plan. This plan was established to better manage broad scope evolutions such as the support of new input or output boards which caused related changes to a significant number of the SPINLINE 3 OSS modules, This plan formalizes a process to select a set of change requests as the requirements input for the change, to make associated impact analyses and then to manage the implementation of these requirements. This process is implemented either in the existing SPINLINE 3 components or in the additional new components. This plan requires a thorough management of the implementation and the V&V of the changes.

All software modifications at each evolution are tracked in a dedicated software configuration management report. For the Class 1E OSS, I&C France established and maintains the following documents:

• Software Configuration Management Report at OSS level, document 3 000 824 (Reference 6-25)

• Software Configuration Management Report for the CSS, document 1 207 257 (Reference 6-26)

• Software Configuration Management Report for the CD_LDU, document 1 207 283 (Reference 6-27)

• Software Configuration Management Report for the BF, document 1 207 277 (Reference 6-28)

[[

Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprie]]

The requirements, design and source code documents and files reflect the state of the latest release of the software.

For testing files, a chapter related to the modification is added. This chapter contains the changes to the analysis (when necessary), the new and modified test cases, the regression testing to be performed, possibly including new tests based on the context of the modifications performed, and the results of the test performed to integrate and validate the modification.


6.2.2.9 Process Implementation Activities

The SPINLINE 3 OSS life cycle is supported by the following process implementation activities:

• A Quality Assurance Program is in place throughout the OSS design and development process for the entire life cycle. The process for Quality Assurance Program implementation and documentation is discussed in Section 6.2.3

• A Software Project Management Program is in place continuously throughout the life cycle. This activity is discussed in Section 6.2.4

• An independent Verification and Validation program is implemented at various stages of the OSS life cycle as depicted in Figure 6.2-1. This activity is discussed in Section 6.2.5

• A Configuration Management Program is in place throughout the OSS life cycle. This activity is discussed in Sections 6.2.6

• A process for procurement or development of software tools needed for the OSS development has been implemented. This activity is discussed in Section 6.2.7.

The I&C France management structure is designed with the outcome of the highest quality and reliability software as a goal. There is no one report that discusses I&C France management but general information regarding management can be found throughout the SPINLINE 3 OSS life cycle documents.

6.2.3 SPINLINE 3 OSS Quality Assurance Plan

The main goal of the Quality Assurance Plan is to develop highly reliable OSS software, i.e. to have “close to zero faults.” In order to achieve this, IEC 880 (Reference 6-2) was chosen as the governing standard for the OSS development and as a foundation of the OSS Software Quality Plan (SQP). Section 5.3.1 of IEEE Standard 7-4.3.2-2003 (Reference 6-29) recognizes the IEC Standard as providing acceptable quality assurance guidance along with IEEE Standard 730 (Reference 6-30).

High reliability of the OSS is first governed by the quality of its development process. The well established model used for the OSS development process is the “V” life cycle discussed in Section 6.2.1. The reliability of the software is built-in during the descending branch of the “V” (i.e. during the specification, design and coding phases). Quality assurance during these phases consists in ensuring establishment of formal specification and design documents as well as source code, verified by independent V&V personnel within the same phases, and reviewed during the phase reviews.

Second, high reliability is based on the quality built into the design and the code by the experienced staff, following the guidance of the I&C France processes and coding standards. The V&V staff understands the SPINLINE 3 system, the controlling documents, and good coding practices. This aids in providing high quality reviews and testing for the software.

Third, high reliability of the software is confirmed once the coding has been performed. The testing activity, performed during the ascending branch of the “V”, confirms that the expected reliability has been actually achieved by checking systematically that the software behaves according to its requirements and specifications. The testing activity provides evidence of achievement of high reliability by being comprehensive and finding only a low number of faults through the different phases. Quality assurance for the testing activity consists in ensuring that adequate documented planning and test analyses are performed during the descending branch of the “V”. The QAP also ensures that tests are consistently carried out during the ascending branch of the “V” and that all faults revealed by the testing are reported and corrected.


Fourth, high reliability of the OSS is governed by the technical features of the design and implementation. As described in more detail in Section 4.4, the SPINLINE 3 OSS has been designed to meet IEC 880 technical requirements, which contribute to reliability. These requirements enforce the achievement of rigor, simplicity and deterministic behavior.

For the OSS, these technical requirements resulted in the following features:

• no interrupts are used for management of OSS functions,

• no dynamic memory allocation is used (using allocation and de-allocation routines in a memory pool),

• no support for real time multitasking (no inter-task communication and synchronization primitives, no priority management and therefore, no risk of priority inversion, no primitives to share resources through semaphores or locks and therefore no risk of deadlocks),

• no support for time and date management and therefore no risk of peak loads depending on the time or date,

• only the necessary functions and components for implementation of I&C safety functions are supported,

• self-supervision and defense-in-depth safety programming are implemented

• The OSS execution is safety oriented (i.e., go to a fail-safe position when a failure is detected)

In order to assess the Hardware Configuration Tables and the Configuration Data, Failure Mode and Effects Analyses were performed on these data. The Configuration Data are used in accessing and modifying parameters through the LDU, which is generated by the CLARISSE configuration tool. As a consequence, requirements for defensive programming were input into the OSS as well as in CLARISSE. For data where unsafe consequences of faults could not be covered by defensive programming at the OSS level, Verification and Validation actions to be performed on these configuration data were specified. These actions are performed each time a new configuration is produced by CLARISSE.

The Failure Mode and Effect Analyses performed are documented in the:

• Analysis of Consequences of Errors (in Hardware Configuration Tables), document 1 207 184 (Reference 6-31)

• Functional FMEA documented in Software Requirement document of LDU, document 1 207 142 (Reference 6-32)

The quality assurance tasks for the OSS are described in the Software Quality Plan established for the MC3 project and in its Software Modification Quality Plan supplement (see section 6.2.2).

These tasks are performed by personnel independent from the development and the V&V personnel. The QA personnel report to the QA Manager of I&C France. The records of the QA activity are kept in the I&C France QA files for the project.

6.2.4 SPINLINE 3 OSS Project Management

The initial OSS development project was planned and tracked according to a Software Development Plan (SDP) 1 207 102 (Reference 6-7) established prior to the OSS development (see Section 6.2).


The SDP documents the management arrangements made for the development of the OSS, in particular, detailed organizational arrangements made within the software project to perform the scheduling and cost tracking of the project development and V&V tasks. This plan includes periodic project meetings and reporting forms.

The plan also documents the staffing and the Man/Hour resources allocated to the OSS development and V&V teams. It provides the schedules and estimates for the workstations, software tools and SPINLINE 3 hardware resources needed for integration and validation activity for the OSS.

Each evolution of the SPINLINE 3 platform is planned and tracked according to a dedicated Software Development Plan. This plan is established using the latest guidance available in the I&C France Quality Management Program.

6.2.5 SPINLINE 3 OSS Verification and Validation Program

The OSS verification and validation (V&V) program was performed using procedures that were derived from the V&V requirements of IEC 880 (Reference 6-2). Planning of Verification and Validation activities was not described in a separate V&V Plan, as it was not required at the time of the MC3 project, but instead was documented in the following MC3 project documents:

• Software Quality Plan, document 8 303 429 (Reference 6-3), which provided organization and life cycle V&V activity

• Software General Requirements, document 1 207 101 (Reference 6-6), which provided the general strategy for the Verification and Validation of the OSS software, now incorporated in the SPINLINE 3 SQAP and in the Software Validation Test Plans

• Project Technical Instruction on V&V of Software Module 1 207 107 (Reference 6-33), which provides the V&V general strategy for modules developed for the OSS

• SPINLINE 3 safety of processing unit software document, which provides detailed testing strategy for each modules

The Verification activities are performed following most of the life cycle development activities such as software requirements, software preliminary and detailed design, software coding and integration (see Figure 6.2-1). Verification reports for this effort are established and are managed under the Configuration Management (CM) program for the OSS (see Section 6.2.6).

The Validation activities are started early during the Preliminary Design Phase and completed during the Validation phase (see Sections 6.2.2.2 and 6.2.2.7).

The OSS verification and validation reports are listed below:

• Document and coding verification forms

• Review reports

• Results of module unit testing (files “module”.rvl) for CSS and BF modules

• Software Integration Test Plan and Report for the OSS, covering CSS, CD_LDU and BF, document 1 207 204 (Reference 6-19)


• Software Integration Test Plan and Report for the CD_LDU, document 1 207 239 (Reference 6-20)

• Software Validation Tests Report, for the OSS, covering CSS, CD_LDU and BF, document 1 207 232 (Reference 6-23)

• Software Validation Tests Report dedicated for the CD_LDU, document 1 207 292 (Reference 6-24)

[[

]]

6.2.6 SPINLINE 3 OSS Configuration Management Program

At start of the MC3 project, planning of Configuration Management activities was not described in a separate CM plan, which was not required at the time of the MC3 project. However, it has been documented in the following MC3 project documents:

• Software Quality Plan, document 8 303 429 (Reference 6-3), which includes a chapter on Configuration Management


• Project Technical Instruction on Development Environment Organization, document 1 207 105 (Reference 6-34), which provides the organization of the directories and files under the UNIX and PC development environments, with separate storage for files under development and files under CM control.

The V&V team is in charge of transferring the files into the CM controlled Environment.

Since SPINLINE 3 evolution “E”, the Configuration Management activities for SPINLINE 3 are defined in a separate Software Configuration Management Plan, document 1 208 878 (Reference 6-9, see section 6.2.2).

The planning of the software configuration activities followed the guidance originally provided in IEC 880-1986 (Reference 6-2) and has evolved to take into account the advances in software engineering as reflected in a later revision of the standard.

Configuration management activities were consistently performed during the development of the OSS and its evolutions. The main goal of these activities is to maintain controlled baselines of software modules for each developed software sub-tiers (CSS, CD_LDU, and BF) with associated design documentation, test and validation files, and software tools used for the development.

The OSS consists of the following three sub-tiers: core system software (CSS), Communication driver with the local display unit (CD_LDU) and the basic functions (BF). There is one top tier SCM Report and one Software Configuration Management Report for each of the three sub-tiers as follows:

• Software Configuration Management Report at OSS level, document 3 000 824 (Reference 6-25)

• Software Configuration Management Report for the CSS, document 1 207 257 (Reference 6-26)

• Software Configuration Management Report for the CD_LDU, document 1 207 283 (Reference 6-27)

• Software Configuration Management Report for the BF, document 1 207 277 (Reference 6-28)

Software Configuration Management Reports contain a chapter for each software delivery which provides references of the change requests and the status of all software modules, affected or not by the changes.

This set of OSS configuration management reports contains the following information, resulting from the CM activity:

• Identification and control of the change requests

• Identification and control of the OSS software design documents and code affected by the change

• Control of all software design changes

• Control of software documentation (user, operating, and maintenance documentation)

• Control and retrieval of validation information associated with software designs and code

• Control of archive sets

The OSS and any changes to it are part of the configured baseline and are archived in accordance with the SCMP with clear organizational responsibilities for each action.


6.2.7 SPINLINE 3 Platform Software Tools Procurement, Development and Validation Processes

A description of the SPINLINE 3 Software Tools is provided in Section 4.4.4, which includes the CLARISSE SSDE and SCADE. The Software Tools development process was originated using the guidance of IEC 880-1986 (Reference 6-2) Section 5.2 and Appendix D and resulted in the software tools meeting the software tool requirements of the IEC standard. In addition, these tools were thoroughly tested before their implementation in the SPINLINE 3 platform design and have a successful operating history over many years as shown in Chapter 2. The SPINLINE 3 Software tools used to support the OSS development processes are controlled under the I&C France Configuration Management Program.

The SPINLINE software tools were either procured from tools vendors according to guidance of instruction “Requirements for tools used to develop software” 1 206 747 (Reference 6-35) or developed “in-house” according to the life cycle process and Quality Assurance Program applicable to non-Class 1E software.

The MICROTEC Research suite of cross development tools for the MC680x0 processors include a C compiler, an assembler and a linker. This suite was selected based on technical features of the C compiler such as its ability to compile large programs issued from the SCADE generation and also desired features aimed at mastering the verification of the compiler outputs such as production of understandable assembly code easily traceable to the C code. Another requirement was the availability of the compiler libraries as source code. The Feedback of use of Microtec tools by others and results of a technical and quality audit led at MICROTEC Research were also used to validate this choice.

The SCADE tools, now developed and maintained by the Esterel Technologies supports the graphical and textual description of the application software and the associated code generation. (See section 4.4.4.2.). Because of their planned used in nuclear and aviation, the SCADE tools were developed under technical and quality assurance requirements put in place by I&C France and AEROSPATIAL.

The CLARISSE SSDE embeds the above MICROTEC and SCADE tools and a set of tools developed internally to configure the SPINLINE 3 hardware and the NERVIA networks. These tools have associated design, test and maintenance documentation, established in accordance with the I&C France processes for non class 1E software.

Validated versions of tools are used as long as there is no mandatory reason for change such as the tool cannot be run any longer because of obsolescence of the host computer or its operating system. A newer version of the tool or a replacement tool would then be evaluated and a migration path to the new version is established.

The SPINLINE 3 software tools have been procured or developed to meet high quality and long term support requirements. Their feedback of experience for developing Class 1E software has been very positive to date. However, I&C France does not claim these tools to be safety related or fault free. Faults in executable code that could result from the malfunction of tools will be detected by independent V&V testing activities performed on tool results. A large amount of software tool operating experience has been incurred by I&C France and other companies to provide additional confidence in the suitability of the SPINLINE 3 software tools, particularly when evaluating the potential for undetected defects. Considering the above and including existing documentation resulting from the software tool development process and the software tools being placed under the Configuration Management Program; the SPINLINE 3 software tools, CLARISSE, SSDE and SCADE, meet the guidance provided in IEEE 7-4.3.2 paragraph 5.3.2, “Software Tools” and the tools requirements in IEC 880.

6.2.8 SPINLINE 3 Platform Software Embedded in I/O and Communication Boards

This section applies only to the ICTO pulse counter module and to the NERVIA+ module. The Class 1E software embedded in I/O and communication boards was developed according to the life cycle process and Quality Assurance Program applicable to Class 1E software that was used for the development of the OSS and is discussed in sections 6.2.1 to 6.2.7.


Since the N4 project, the I&C France Quality Assurance Program applicable to development of software based systems has not changed in its principles which are those expressed in IEC 880-1986. Changes were introduced to take into account evolution in the tools available in software engineering that may impact some of the phase activities.

For each software development, the I&C France Quality Assurance Program requires establishment of a Project or Software Quality Plan that specifies the organization and activities specific to the development in the framework of the Quality Assurance Program procedures.

6.2.8.1 Software Embedded in the ICTO Pulse Input Board

The development and the maintenance of the Class 1E software embedded in the ICTO pulse board was performed according to the N4 Software Quality Plan (SQP), document 8 301 017 (Reference 6-36), which describes specific requirements for Design, V&V, Documentation, Configuration Management and Modification, in accordance with the life cycle process and Quality Assurance Program that was in place when the N4 project was developed.

Comprehensive design and V&V documentation is organized according to the software life cycle phases defined in the N4 Software Quality Plan.

The design and V&V documentation, the source files, the tools used for development and validation are identified and managed according to the Configuration Management section of the N4 SQA.

Because this software was developed in the late 1980’s, the documents and procedures have some minor differences with the OSS software design process and its standards. For instance, the documents were established using word processing software run on the Digital Equipment Corporation VAX/VMS development machine.

6.2.8.2 Software Embedded in the NERVIA Communication Board

The Class 1E software embedded in the NERVIA communication board was developed according to the life cycle process and Quality Assurance Program in place for revision E of the SPINLINE 3 platform, in the context of the NERVIA+ project, launched for the development of the hardware and associated software needed to implement the new NERVIA network.

This major effort was performed to implement the SPINLINE 3 platform into the safety I&C systems at the DUKOVANY (Czech Republic) and IGNALINA (Lithuania) NPPs.

The planning of the Class 1E software development is provided in the following plans:

• Project Quality Plan, document 1 208 708 (Reference 6-37)

• Project Development Plan, document 1 208 568 (Reference 6-38)

The requirements for the software were derived from the requirement of the original NERVIA software developed for the N4 project during the late 80’s, and included simplifications to the NERVIA protocol. This was made possible by the use of a faster transmission rate on the medium.


Comprehensive Design and V&V documentation is organized according to the software life cycle phases defined in the NERVIA+ Project Quality Plan.

The design and V&V documentation, the source files, the tools used for development and validation are identified and managed according to the Configuration Management section of the NERVIA+ PQP.

6.2.9 SPINLINE 3 Platform Application-Oriented Library of Re-usable Software Components

The generic Class 1E application-oriented library of re-usable software components is a collection of logic or numeric functions that can be used by developers when designing application software using the SCADE tool.

The generic application-oriented library components were developed according to the same I&C France software life cycle process and Quality Assurance Program applicable to Class 1E software that was used for the development of the OSS and is discussed in Sections 6.2.1 to 6.2.7.

The development and the maintenance of the library components is performed according to a dedicated SCADE Operator Library Software Quality Plan, document 1 208 356 (Reference 6-39), which describes specific requirements for design, V&V, documentation, configuration management and modification. This plan was developed in accordance with the I&C France life cycle process and Quality Assurance Program applicable to Class 1E software that was used for the development of the OSS and discussed in sections 6.2.1 to 6.2.7.

Comprehensive design and V&V documentation for each component in the library is organized according to the life cycle phases defined in the SCADE Operator Library Software Quality Plan. This design and V&V documentation and the source files are identified and managed according to the configuration management section of the SCADE Operator Library Software Quality Plan.

A user’s guide for each component provides name, function description, input and output parameters with their type, checks performed by the function on the input parameters, and when relevant, reference to other components with similar function to reduce risk of misuse. The user guide is intended for application software developers.

Additional re-usable components may be developed in connection with a plant-specific application. These components are not part of the generic SPINLINE 3 platform software and will be maintained in a separate plant-specific library that can be addressed by SCADE in addition to the generic library described above.

6.2.10 SPINLINE 3 Platform PLD and FPGA embedded in electronic boards

The Class 1E SPINLINE 3 electronic boards have been developed and qualified according to the I&C France Quality Assurance Program applicable to Class 1E hardware, as introduced in Section 2.1.


On electronic boards, functions were first designed using discrete components such as transistors and dedicated integrated circuits, providing basic logic functions such as gates or multiplexers. Programmable Logic Devices (PLD), Complex Programmable Logic Devices (CPLD), and Field Programmable Gate Arrays (FPGA) have progressively been used for their ability to implement a dedicated logic functions into single standardized components, thus eliminating discrete components, solders joints, and wiring on the printed circuits and thereby improving hardware reliability.

However, due to the programmable capability of these components and to their ability to embed potentially complex functions, the I&C France Electronic Design Department established a development process when these components started to be used, with associated design and validation guidelines to be used for their development.

[[

Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary tex]]

6.3 SPINLINE 3 Platform Software Design and Development Analyses – IEC 880 and BTP 7-14

As stated earlier, the SPINLINE 3 Class 1E platform software (OSS, application-oriented library of re-usable software components, and software embedded in I/O and communication boards) was designed and developed based on the guidance of IEC 880-1986 (Reference 6-2), which was the significant IEC software standard for development of software for safety systems in NPPs at that time, with enhancements to take into account the advances in software engineering as reflected in a later revision of the standard. As described in Section 1.1, the generic SPINLINE 3 platform now is managed under a quality assurance program that complies with 10CFR50 Appendix B (Reference 6-54) and is being commercially dedicated to demonstrate how the SPINLINE 3 software life cycle processes comply with U.S. nuclear safety requirements

To draw a comparison between IEC 880-1986 and BTP 7-14 (Reference 6-40), a matrix comparing the requirements of the IEC Standard with those of BTP 7-14 is provided in Section 3.10.1, Table 3.10-2. This comparison highlights the key differences between the two guidance documents and illustrates that the BTP 7-14 software life cycle is similar to that of IEC 880, although there are differences in the number of phases and the total documents produced between the respective software life cycle processes. By using the comparison, the evaluations, analyses, and reviews between the original SPINLINE 3 platform software design and development process and the IEC 880 and BTP 7-14 life cycle process can be made. The conclusions reached are that the SPINLINE 3 platform software life cycle process and, as a result, the evaluations, reviews and analyses and ensuing documentation achieve equivalent results to those that would be attained using the guidance in BTP 7-14. However, all of the design phases and associated documentation described in BTP 7-14 are not provided as a result of the SPINLINE 3 platform software life cycle process being based on IEC 880. However, the missing design phases and associated documentation are accounted for through the process of combining certain life cycle phases, including the associated documentation.


For example, reports were generated that represented multiple phases rather than reports for each phase. A more detailed review of this process was initiated to demonstrate the resulting equality between the BTP 7-14 software design and development process results and the quality and reliability results for the SPINLINE 3 platform software design and development process results.

The alignment of the SPINLINE 3 platform software life cycle documentation to the software plans described in BTP 7-14 is shown in Figure 6.3-1. Although there is not a one-to-one match with the BTP 7-14 Plans, the required planning information is provided by the SPINLINE platform software life cycle documents shown in Figure 6.3-1. The “missing” plans (installation, training and operation) are needed only for plant-specific application of SPINLINE 3. These plans are addressed in Section 6.4.



Software Quality Assurance Plan

Software V&V Plan

Software Management Plan

Software Safety Plan

Software Integration Plan

Software Test Plan

Software Installation Plan

Software Training Plan

Software Operation Plan

Software Maintenance Plan

Software Configuration ManagementPlan

BTP 7-14 Software PlansSPINLINE 3 Platform SoftwareDocuments

Software Quality AssuranceMC3 Software Quality Plan (SQP), 8 303 429 A (Ref 6-3)Quality Plan, 1 208 356 (Ref 6-39) for development &maintenance of the library components(N4) Software Quality Plan (SQP), 8 301 017 C (Ref 6-36) for embedded sw on ICTO board

Software DevelopmentSoftware Development Plan (SDP), 1 207 102 (Ref 6-7)

Software V&VSoftware Validation Test Plan 1 207 146 (Ref 6-15) atOSS level, for validation strategySoftware Validation Test Report 1 207 232 (Ref 6-23) atOSS level, for detailed test cases and resultsSoftware Validation Test Plan 1 207 175 (Ref 6-16) forthe CD_LDU, for validation strategySoftware Validation Test Report 1 207 292 (Ref 6-24),which is dedicated for the CD_LDU, for detailed testcases and resultsProject Technical Instruction on V&V of SoftwareModule 1 207 107 (Ref 6-33), which provides the V&Vgeneral strategy for modules developed for the OSS

System Integration & TestSoftware Integration Test Plan and Report, 1 207 204(Ref 6-19) for the OSS, covering CSS, CD_LDU and BFSoftware Integration Test Plan and Report, 1 207 239(Ref 6-20) for the CD_LDU

Software Configuration Management

Software Configuration Management Plan, 1 208 878(Ref 6-9)Software Configuration Management Report 3 000 824(Ref 6-25) at OSS levelSoftware Configuration Management Report 1 207 257(Ref 6-26) for the CSSSoftware Configuration Management Report 1 207 283(Ref 6-27) for the CD_LDUSoftware Configuration Management Report 1 207 277(Ref 6-28) for the BF

Software SafetySPINLINE 3 Safety of Processing Unit SoftwareDocument 1 207 228 G (Ref 6-22)Analysis of Consequences of Errors (in HardwareConfiguration Tables) 1 207 184 (Ref 6-31)Functional FMEA documented in Software Requirementdocument of LDU 1 207 142 (Ref 6-32)

Software MaintenanceSoftware Modification Quality Plan, 1 208 686 (Ref 6-8)

Figure 6.3-1. Alignment of BTP 7-14 Plans and SPINLINE 3 Platform Software Documentation


To achieve this, I&C France chose to supplement the information on the SPINLINE 3 platform software life cycle process provided in this LTR with a Design Analyses Report (DAR, Reference 6-41), which documents the results of a Critical Design Review (CDR). The purpose of the DAR was to evaluate the platform software life cycle processes and determine if the resulting software quality and reliability meet the applicable U.S. nuclear safety requirements and guidelines provided in the Standard Review Plan (e.g., BTP 7-14) and the relevant software IEEE Standards such as IEEE 7-4.3.2.

The DAR follows a nine-step process defined in EPRI Handbook 1011710 (Reference 6-42). As the review progresses, the later steps are actually intermixed to facilitate the review. The nine steps included in the DAR are as follows:

1. Identification of Critical Attributes

2. Functional Review

3. System Orientation

4. Process Orientation.

5. Thread Analysis

6. Risk Analysis

7. Staff Capabilities and Attitude

8. Operating History Review

9. Identification and Resolution of Issues

The DAR analyzes the SPINLINE 3 platform software quality process and focuses on existing documentation, the software code and postulated unforeseen and/or undesired events. The SPINLINE 3 platform software life cycle phases, activities and resulting output documentation are compared to the same features represented in BTP 7-14 with a matrix developed using BTP 7-14, Figure 7.A-1. This matrix identifies where concepts and documentation are the same and where documentation for certain activities is combined with other activities.

The DAR team examined the actual SPINLINE 3 platform software code as well as documentation resulting from the original design effort. The actual code examination was performed by using thread audits.

A key objective of the DAR was to determine the potential of the digital platform under investigation to produce unforeseen events and unacceptable behaviors. To this end, it examined a number of essential properties:

• Identification: Is the SPINLINE 3 system and its main components precisely and uniquely identified?

• Functional Characterization: Are the characteristics of the SPINLINE 3 system clearly, thoroughly and unambiguously described?

• Functional Adequacy and availability: Are these characteristics appropriate for the real needs and operational conditions of the system? Should faults or failures occur, will nominal service be interrupted, and for how long?

• Digital reliability: In these operational conditions, will the SPINLINE 3 system conform to its stated characteristics?

• Robustness and safety: Will abnormal situations, which may be due to causes external or internal to SPINLINE 3, result in acceptable system behavior?

• Testability: Can the defaults introduced in the system during manufacturing or operation be revealed with good chance of success and with reasonable effort?

• Maintainability: Can the above properties be maintained throughout SPINLINE 3 operational lifetime, in particular when the system is modified?


A key result of the DAR was that the SPINLINE 3 platform software was suitable for being dedicated. As described in Chapter 1, the SPINLINE 3 platform software was dedicated under the 10CFR50 Appendix B-compliant I&C France QA program.

6.4 SPINLINE 3 Application Software Development Process

This section describes the life cycle processes that are used to develop, verify, validate and deploy the application software for a plant-specific SPINLINE 3 system. The software life cycle process for the application software is depicted in Figure 6.4-1. The evaluations, analyses, reviews and documents produced in each phase are listed in Figure 6.4-1. This life cycle process is consistent with the BTP 7-14 life cycle process (Reference 6-40). In addition, the SPINLINE 3 application software life cycle processes follow the guidance in Regulatory Guide 1.173, "Developing Software Life Cycle Processes for Digital Computer Software Used in Safety Systems of Nuclear Power Plants," (Reference 6-43), which endorses IEEE 1074-1995, "Standard for Developing Life Cycle Processes" (Reference 6-44).

The alignment of the SPINLINE 3 application software life cycle plans to the software plans described in BTP 7-14 is shown in Figure 6.4-2. Although there is not a one-to-one match with the BTP 7-14 Plans, all of the required planning information is provided by the SPINLINE 3 application software life cycle and system plans shown in Figure 6.4-2.

[[


]]

Figure 6.4-1. Application Software Life Cycle Overview



Software Quality Assurance Plan

Software V&V Plan

Software Management Plan

Software Safety Plan

Software Integration Plan

Software Test Plan

Software Installation Plan

Software Training Plan

Software Operation Plan

Software Maintenance Plan

Software Configuration ManagementPlan

BTP 7-14 Software PlansSPINLINE 3 Platform SoftwareDocuments

Software Quality AssuranceMC3 Software Quality Plan (SQP), 8 303 429 A (Ref 6-3)Quality Plan, 1 208 356 (Ref 6-39) for development &maintenance of the library components(N4) Software Quality Plan (SQP), 8 301 017 C (Ref 6-36) for embedded sw on ICTO board

Software DevelopmentSoftware Development Plan (SDP), 1 207 102 (Ref 6-7)

Software V&VSoftware Validation Test Plan 1 207 146 (Ref 6-15) atOSS level, for validation strategySoftware Validation Test Report 1 207 232 (Ref 6-23) atOSS level, for detailed test cases and resultsSoftware Validation Test Plan 1 207 175 (Ref 6-16) forthe CD_LDU, for validation strategySoftware Validation Test Report 1 207 292 (Ref 6-24),which is dedicated for the CD_LDU, for detailed testcases and resultsProject Technical Instruction on V&V of SoftwareModule 1 207 107 (Ref 6-33), which provides the V&Vgeneral strategy for modules developed for the OSS

System Integration & TestSoftware Integration Test Plan and Report, 1 207 204(Ref 6-19) for the OSS, covering CSS, CD_LDU and BFSoftware Integration Test Plan and Report, 1 207 239(Ref 6-20) for the CD_LDU

Software Configuration Management

Software Configuration Management Plan, 1 208 878(Ref 6-9)Software Configuration Management Report 3 000 824(Ref 6-25) at OSS levelSoftware Configuration Management Report 1 207 257(Ref 6-26) for the CSSSoftware Configuration Management Report 1 207 283(Ref 6-27) for the CD_LDUSoftware Configuration Management Report 1 207 277(Ref 6-28) for the BF

Software SafetySPINLINE 3 Safety of Processing Unit SoftwareDocument 1 207 228 G (Ref 6-22)Analysis of Consequences of Errors (in HardwareConfiguration Tables) 1 207 184 (Ref 6-31)Functional FMEA documented in Software Requirementdocument of LDU 1 207 142 (Ref 6-32)

Software MaintenanceSoftware Modification Quality Plan, 1 208 686 (Ref 6-8)

Figure 6.4-2. Alignment of BTP 7-14 Plans and SPINLINE 3 Application Software and System Plans


The following Plans shown in Figure 6.4-2 are strictly application software plans:

• Software Quality Assurance Plan (Reference 6-45)

• Software Development Plan (Reference 6-46)

• Software Configuration Management Plan (Reference 6-47)

• Software V&V Plan (Reference 6-48)

The following Plans shown in Figure 6.4-2 are system plans that address both application software and hardware elements of the plant-specific SPINLINE 3 system:

• System Integration and Factory Test Plan (Reference 6-49)

• System Installation and Site Test Plan (Reference 6-50)

• System Training Plan (Reference 6-51)

• System Operation and Maintenance Plan (Reference 6-52)

As shown in Figure 6.4-2 and described below, the following BTP 7-14 Plans have been consolidated:

• There is no separate Software Management Plan (SMP). The SMP functions described in IEEE 1058-1987 (Reference 6-53) have been incorporated in the software management planning descriptions in the Software Quality Assurance Plan (Reference 6-45) and the Software Development Plan (Reference 6-46).

• There is no separate Software Test Plan. Unit and module testing is addressed in the Software V&V Plan (Reference 6-48). System integration and factory testing are addressed in the System Integration and Factory Test Plan (Reference 6-49). Final system-level site acceptance testing is addressed in the System Installation and Site Test Plan (Reference 6-50).

• There is no separate Software Safety Plan. Software safety is addressed primarily in the Software V&V Plan. (Reference 6-48) and also in the Software Quality Assurance Plan (Reference 6-45)

• There are no separate Software Operations Plan and Software Maintenance Plan. These matters are addressed together in the System Operations and Maintenance Plan (Reference 6-52).

An overview of the individual SPINLINE 3 application software and system plans is provided in the following sections. All of these plans are prepared using templates that are completed for a plant-specific application. The use of these standard Plan templates is intended to improve the systematic application of the software life cycle processes in each plant-specific SPINLINE 3 application.

6.4.1 Software Quality Assurance Plan

The process defined in the Software Quality Assurance Plan (SQAP, Reference 6-45) is somewhat separated from the I&C France Nuclear Quality Assurance process, which is also required for developing nuclear safety related software. The SQA process evaluates the design, verification and validation, software safety analysis, configuration management, and change control processes to ensure compliance with the overall software process. The quality of the software results mainly from the activities of the members of the Software Development team and of the independent V&V teams at each stage of the development process. The Software Quality Assurance Manager (SQAM) assists the Software Project Manager in ensuring that the customer's requirements are taken into account and that the I&C France quality policy is respected.

Starting from the customer quality requirements and from the I&C France quality system, the SQAM is responsible for issuing the SQA Plan (SQAP) for the project. This plan describes the software project organization with roles and responsibilities, the life cycle phases, the phase input and output documents and products, the SQA tasks, the project documentation with associated responsibilities for establishment,


verification and approval, the guidance to follow, the scheduled reviews and audits. This plan ensures the criteria selected to achieve the required quality is met during software development.

The SQAP is the plan corresponding to SQAP and SMP as defined in BTP 7-14. The SQAP covers the entire software life cycle and includes traceability requirements (see section 6.4.10). Performing the software development according to the SQAP ensures that the required quality will be built-in the software and that any deviations from the planned process will be discovered in time to allow the software team to take corrective action.

In addition, the SQAP incorporates a description of software management and software safety analysis planning information. This ensures that I&C France identify, implement, review, and test all the safety-critical requirements. This also ensures that decisions made while refining the design through the Requirements, Detailed Design, and Coding phases do not introduce unacceptable faults, failures, or vulnerabilities in the design.

The SQAP provides software QA guidance consistent with the following references:

Branch Technical Position 7-14, Revision 5 (Reference 6-40)

“Guidance on Software Reviews for Digital Computer-based Instrumentation and Control Systems”, Section B.3.1.3, Software Quality Assurance Plan (SQAP)”

10 CFR Part 50, Appendix B (Reference 6-54)

‘Quality Assurances Requirements for Nuclear Power Plants and Fuel Reprocessing Plants”

Regulatory Guide 1.28, Revision 3

(Reference 6-55)

“Quality Assurance Program Requirements (Design and Construction)”


(Reference 6-56)

“Criteria for Use of computers in Safety Systems of Nuclear Power Plants”.

IEEE Standard 7-4.3.2-2003

(Reference 6-29)

“IEEE Standard Criteria for Digital Computers in Safety Systems of Nuclear Power Generating Stations,” Clause 5.3.1 “Software Development”

ANSI/ASME NQA-1-1994 (Reference 6-57)

“Quality Assurance Program Requirements for Nuclear Facilities”

NUREG/CR-6101 (Reference 6-58)

“Software Reliability and Safety in Nuclear Power Plant Protection Systems”, Sections 3.1.2 and 4.1.2, “Software Quality Assurance Plan,”


The SQAP provides software management guidance consistent with the following references:

Branch Technical Position 7-14 (Reference 6-40)

“Guidance on Software Reviews for Digital Computer-based Instrumentation and Control Systems”, Section B.3.1.1, “Acceptance Criteria for Software Management Plan”

Regulatory Guide 1.173 (Reference 6-43)

“Developing Software Life Cycle Processes for Digital Computer Software Used in Safety Systems of Nuclear Power Plants,” which endorses IEEE 1074-1995

IEEE Standard 1074-1995 (Reference 6-44)

“IEEE Standard for Developing Software Life Cycle Processes,” Clause A.1 .2.7, “Plan Project Management”


“Software Reliability and Safety in Nuclear Power Plant Protection Systems”, Sections 3.1.1 and 4.1.1, “Software Project Management Plan,”

6.4.2 Software Development Plan

The purpose of the Software Development Plan (SDP, Reference 6-46) is to ensure that its use will define a process that delivers high quality and reliable software suitable for SPINLINE 3 safety applications. This includes a provision for effective oversight, where the strategy for managing the technical development is specified. The SDP describes the arrangements made for the management of the software project, including estimates for development and V&V effort and cost, initial schedules, technical resources needed, effort and cost tracking. The SDP clearly states the tasks to be performed in the framework of the application software life cycle. It states the project deliverables (documents, software products), the staffing with associated planned training, the hardware and the software resources needed. The SDP is primarily intended for internal control of the software development and in addition, it allows the customer to adequately monitor the software development process.

Following the SDP ensures that the project development is under control for quality and reliability, with assurance that the design and the V&V tasks have allocation of budget, resources, and schedule consistent with the safety objective of the development effort.

The SDP is written and maintained by the Software Development Manager (SDM) as the primary author and the Software V&V Manager (SVVM) as the secondary author. The SDM inputs the information associated with the development activities and incorporates the information related to the V&V activities, as provided by the SVVM

The SDP provides software development guidance consistent with the following references:


“Guidance on Software Reviews for Digital Computer-based Instrumentation and Control Systems”, Section B.3.1.2, “Software Development Plan (SDP)”




“IEEE Standard for Developing Software Life Cycle Processes”


“Software Reliability and Safety in Nuclear Power Plant Protection Systems”, Sections 3.1.6, “Software Development Plan”, and Section 4.1.6, “Software Project Management Plan”


6.4.3 Software Configuration Management Plan

The purpose of the Software Configuration Management Plan (SCMP, Reference 6-47) is to maintain the current and historical status of all design documents, including requirements documents, detailed design documents, coding, peer review reports, test plans, test procedures, test cases, test reports, software change requests, user manuals, operation and maintenance manuals, and other work products. The Change Control activities are designed to ensure that management retains control of the process and that changes are considered and dispositioned appropriately into the processes.

The objectives of configuration management activities are:

• To identify and manage software products, software components and documents,

• To provide the information needed to perform impact analyses related to Change Requests.

• To specify the change control procedure.

The components placed under configuration management are:

• Software documents,

• System software source code and application software source code,

• Applicable software rules and guidelines,

• Tools used for software development,

• Tools used for verification and testing.

The SCMP provides CM guidance consistent with the following references:


“Guidance on Software Reviews for Digital Computer-based Instrumentation and Control Systems”, Section B.3.1.11, “Software Configuration Management Plan”

Regulatory Guide 1.152, Revision 2 (Reference 6-56)

“Criteria for Use of Computers in Safety Systems of Nuclear Power Plants” which endorses IEEE 7-4.3.2-2003


“Configuration Management Plans for Digital Computer Software Used in Safety Systems of Nuclear Power Plants”, which endorses IEEE 828-1990




“IEEE Standard for Configuration Management Plans”


“IEEE Standard for Software Verification and Validation”


"Standard for Developing Life Cycle Processes”, Clause A.1 .2.4, “Plan Configuration Management”

IEEE Standard 7-4.3.2-2003 (Reference 6-29)

”IEEE Standard Criteria for Digital Computers in Safety Systems on Nuclear Power Generating Stations”, Clause 5.3.5, “Software configuration management” and Clause 5.4.2.1.3, “Establish configuration management controls”


“Software Reliability and Safety in Nuclear Power Plant Protection Systems”, Sections 3.1.3 and 4.1.3, “Software Configuration Management Plan”


6.4.4 Software Verification and Validation Plan

The Software Verification and Validation Plan (SVVP, Reference 6-48) for the SPINLINE 3 application software defines the following:

• Verification activities, which are formal reviews and analyses performed on all documents and code produced by the software project. They are performed during the relevant phases of the software life cycle, by the software V&V team.

• Validation activities, which consist of preparing and running software tests. They are performed in two steps: first, generation of the Software Test Plan and then execution of the software tests as shown in the software life cycle overview. The Software Test Plan is created by the V&V team during the design phase. The tests are executed during the components test, the validation test for each processing unit and the factory acceptance test (FAT) performed on the integrated processing units into the final I&C system. Component tests are established in reference to the detailed design description. Validation tests are established in reference to the requirements for the system and application software given in the SRS. They are run on the target hardware.

• Software safety activities: The purpose of the software safety activities is to implement procedures and practices in all life cycle phases of the SPINLINE 3 application software that will eliminate or minimize the risk of a safety software defect from causing a problem that impacts the health and safety of the public. The application software safety activities are intended to produce “close to 0 software defects”.

The SVVP defines the tasks to be performed by the SVVM, the SDM and the SQAM related to the V&V activities. In addition, the SVVP contains the guidance for Software Safety activities and for Software Testing activities.

When developing Class 1E software, the design, implementation and V&V activities are safety activities because of their potential to introduce defects in the software, and then, of their potential to not detect defects so they can be removed. In addition, design of Class 1E software includes implementation of safety oriented features such as defensive programming and self supervision in order to tolerate consequences of potential residual software defects.

Defect prevention is enforced by having skilled and trained staff with adequate resources and guidance to perform their tasks. Defect prevention is implemented by the development team when they establish the software design and the coding and, by the V&V team when they establish the validation test plans and procedures.

Defect removal is enforced by carrying out verifications on all documents and manually input source codes that may impact the safety of the implemented function and then by carrying out testing providing objective evidence that the software performs according to its requirements without failures.

Correct performance of design, implementation and V&V safety activities according to plans is checked all along the life cycle through phase reviews and audits under control of the Quality Assurance staff.

In addition, safety activities include safety analyses performed along the development during verification of specification and design documents and source codes. The safety analyses ensure that:

• Safety system requirements are correctly addressed

• No new hazards are introduced

• Software elements that can affect safety are identified

• There is evidence that other software elements do not affect safety.


Safety problems and resolutions identified in these analyses are documented and tracked to completion.

The organizational responsibility for the safety analyses effort rests with the independent V&V team. The V&V team confirms that the correct documents define the safety critical software functions and the related hazards that can prevent the functions from performing their safety roles and the measures necessary to block these hazards. The V&V team verifies that these measures are properly implemented throughout the life cycle process up to and including the design and implementation phase. The requirements are analyzed along with the design and code for the application software. Application Software validation testing, subsystem, interface, stress, regression and unit testing are used to confirm that these measures result in a “close to zero defects” software appropriate for implementation of a Class 1E function. The safety analyses provide adequate documentation that identifies the safety functions, the hazards, mitigating design features and all special tests.

The Software testing activities are planned and documented in the SVVP, which include unit testing and validation testing of processing unit software. Validation testing of the integrated I&C system is planned in the Project Qualification Plan. The software testing activities are performed during the applicable phases of the software development cycle shown in Figure 6.4-1.

The SVVP provides V&V guidance consistent with the following references:


“Guidance on Software Reviews for Digital Computer-based Instrumentation and Control Systems”, Section B.3.1.10, “Software Verification and Validation Plan (SVVP)”


"Criteria for Use of Computers in Safety Systems of Nuclear Power Plants", Section C.2.2.1, “System Features”


“Verification, Validation, Reviews and Audits for Digital Computer Software Used in Safety Systems of Nuclear Power Plants”,, Section C.7.3, “Security Assessment”. This RG also endorses IEEE 1012-1998 and IEEE 1028-1997

NRC RG 1.170, Rev. 0 (Reference 6-63)

“Software Test Documentation for Digital Computer Software Used in Safety Systems of Nuclear Power Plants”


“Software Unit Testing for Digital Computer Software Used in Safety Systems of Nuclear Power Plants”


“Developing Software Life Cycle Processes for Digital Computer Software Used in Safety Systems of Nuclear Power Plants”

IEEE Standard 7-4.3.2-2003 (Reference 6-29)

“IEEE Standard Criteria for Digital Computers in Safety Systems of Nuclear Power Generating Stations”


“IEEE Standard for Software Test Documentation”


“IEEE Standard for Software Unit Testing”


“IEEE Standard for Software Verification and Validation”


“IEEE Standard for Software Reviews and Audits”


“Software Reliability and Safety in Nuclear Power Plant Protection Systems”, Sections 3.1.4 and 4.1.4, “Software Verification and Validation Plan”


The SVVP provides software safety guidance consistent with in the following references:


“Guidance on Software Reviews for Digital Computer-based Instrumentation and Control Systems”, Section B.3.1.9, “Software Safety Plan (SSP)”


“Developing Software Life Cycle Processes for Digital Computer Software Used in Safety Systems of Nuclear Power Plants”, Section C.3, “Software Safety Analyses”


“Software Reliability and Safety in Nuclear Power Plant Protection Systems”, which contains safety analyses criteria for each life cycle phase

6.4.5 System Integration and Factory Test Plan

The plant-specific System Integration and Factory Test Plan (Reference 6-49) for a SPINLINE 3 digital safety I&C system describes the processes for system integration at the factory and factory testing of a SPINLINE 3 system. These factory tests consist of the tests listed in Table 6.4-1.

[[

]]

Software integration and testing are governed by the Software Verification and Validation Plan (SVVP, Reference 6-48). Software V&V testing is performed before the start of system integration and factory testing, as provided in the SVVP.


The plant-specific System Integration and Factory Test Plan will comply with the factory test requirements and recommendations of the following documents


“Guidance on Software Reviews for Digital Computer-based Instrumentation and Control Systems”, Section B.3.1.12, “Software Test Plan (STP)”


(Reference 6-56)

"Criteria for Use of Computers in Safety Systems of Nuclear Power Plants"


“Software Test Documentation for Digital Computer Software Used in Safety Systems of Nuclear Power Plants”, which endorses IEEE 829-1983



IEEE Std 7-4.3.2-2003 (Reference 6-29)

”IEEE Standard Criteria for Digital Computers in Safety Systems on Nuclear Power Generating Stations”, Clause 5.4.1, “Computer System Testing"

6.4.6 System Installation and Site Test Plan

The System Installation and Site Test Plan (Reference 6-50) for a plant-specific SPINLINE 3 digital safety I&C system describes the process for installation and final site acceptance testing of a plant-specific SPINLINE 3 system at the licensee’s site.

This Plan will identify all of the applicable installation procedures, which will be issued as separate documents. These installation procedures will include sign-off blocks for an installer and verifier to confirm completion of the steps in the procedure. The signed-off procedure becomes part of the permanent record of installation

Many of the system-level tests will be the same as the tests run during the factory acceptance test (FAT). The goal of re-running these tests is to demonstrate the same correct performance at the NPP as was demonstrated during FAT. The licensee and Rolls-Royce will agree additional end-to-end tests that can only be performed after installation has been completed. These new final acceptance test procedures will be identified in the System Installation and Site Test Plan.

The plant-specific System Installation and Site Test Plan will comply with the installation requirements and recommendations of the following documents:


“Guidance on Software Reviews for Digital Computer-based Instrumentation and Control Systems”, Section B.3.1.5, “Software Installation Plan (SInstP)”


“IEEE Standard for Developing Software Life Cycle Processes”, Clause A.1.2.4, “Plan Installation”


“Software Reliability and Safety in Nuclear Power Plant Protection Systems”, Sections 3.1.8 and 4.1.8, “Software Installation Plan”

The plant-specific System Installation and Site Test Plan will comply with the site testing requirements and recommendations of the following documents:



“Guidance on Software Reviews for Digital Computer-based Instrumentation and Control Systems”, Section B.3.1.12, “Software Test Plan (STP)”


(Reference 6-56)

"Criteria for Use of Computers in Safety Systems of Nuclear Power Plants"


“Software Test Documentation for Digital Computer Software Used in Safety Systems of Nuclear Power Plants”, which endorses IEEE 829-1983



IEEE Std 7-4.3.2-2003 (Reference 6-29)

”IEEE Standard Criteria for Digital Computers in Safety Systems on Nuclear Power Generating Stations”,Clause 5.4.1, “Computer System Testing"

6.4.7 System Training Plan

The plant-specific System Training Plan (Reference 6-51) for a SPINLINE 3 digital safety I&C system, including the application software and the associated hardware system, will describe the process for qualification of utility personnel to operate and maintain a plant-specific SPINLINE 3 system after successful installation and commissioning of that system. This plan defines training programs for the following:

• licensee’s instructors

• control room operators,

• I&C maintenance operators,

• selected managers

This Plan defines the course content and duration for the target audiences listed above.

The plant-specific System Training Plan will comply with the requirements and recommendations of the following documents:


“Guidance on Software Reviews for Digital Computer-based Instrumentation and Control Systems”, Section B.3.1.7, “Software Training Plan (STrngP)”


“IEEE Standard for Developing Software Life Cycle Processes”, Clause A.1.2.6, “Plan Training”

Regulatory Guide 1.152, Rev 2 (Reference 6-56)

"Criteria for Digital Computers in Safety Systems of Nuclear Power Plants"

Regulatory Guide 1.173, Rev 0 (Reference 6-43)

“Developing Software Life Cycle Processes for Digital Computer Software Used in Safety Systems of Nuclear Power Plants”


“Software Reliability and Safety in Nuclear Power Plant Protection Systems”, Section 3.1.10, “Software Training Plan”


6.4.8 System Operation and Maintenance Plan

The plant-specific System Operations and Maintenance Plan (SO&MP, Reference 6-52) for a SPINLINE 3 digital safety I&C system, including the application software and the associated hardware system, will describe the operating and maintenance principles and specific operating and maintenance activities that apply to the operating phase of the system life cycle after successful installation and commissioning.

The software operations portion of this Plan includes the general description of software operations for the installed system, its functions, the methods, techniques, and tools as well as the means to carry out these functions. A description of the facility to carry out the operation along with software and hardware necessary to operate the system are provided as part of the SO&MP and the associated subordinate documents identified in this Plan.

The Operations and Maintenance Manuals (OMMs) are the key subordinate documents identified in this Plan. The OMMs are a comprehensive set of documents that defines operating and maintenance activities associated with the equipment in a plant-specific SPINLINE 3 system.

Operational security provisions defined in the licensee’s Cyber Security Plan are implemented in the SO&MP and the associated OMMs. Provisions for measuring and analyzing software operational aspects will be part of the SO&MP. All procedures for initiation, operating and halting the software operation will be provided to the utility. The operators will be provided error message resolution along with backup procedures for data gathering and reloading of the software code if necessary.

The plant-specific System Operations and Maintenance Plan will comply with the requirements and recommendations of the following documents:


“Guidance on Software Reviews for Digital Computer-based Instrumentation and Control Systems”, Section B.3.1.8, “Software Operations Plan (SOP)” and Section B.3.1.6, “Software Maintenance Plan (SMaintP)”


“Vendor Assessments and Software Plans”, Sections 3.1.9 and 4.1.9, “Software Maintenance Plan”

6.4.9 SPINLINE 3 Application Software Life Cycle Process Implementation Reports

Rolls-Royce will apply the previously described software life cycle plans in the development of plant-specific SPINLINE 3 systems. The results of the software system implementation activities will provide reports for all life cycle activities for the following areas:

• Safety Analyses Reports (SAR): A safety analysis will be performed during the software life cycle after identifying the software requirements, design elements, and code that can affect safety. This identification also includes the safety software features and the varied means to achieve safety objectives. The system safety requirements are addressed for each life cycle activity group. During the Safety Analysis, it will be verified that no hazards have been introduced into the software and that all other software requirements, design, and code elements will not adversely affect safety. A SAR will be issued that describes the results of this effort.


• Verification Report: This report documents the results of review and audit activities performed during the entire software development process. This report will also include the results of the safety evaluation activities and results of the software testing activities.

• Software Validation Test Report (SVTR): The SVTR specifies the detailed test procedures. It documents the results of the tests performed on each release of the software and reports the anomalies detected and the corrective actions. All required functionality for all operating modes, including error recovery are placed under the test program with each requirement being tested and test reports documented. This report will also include results of the software testing activities.

• Software Configuration Management Report (SCMR): The SCMR is the software change and version management file. It lists changes that are made from one version to another. Changes as well as impact analyses are stored in this file. This document identifies the software baselines.

• Configuration Management Final Report (CMFR): The CMFR describes the main results of the configuration management activities for the life cycle.

• Software Manufacturing File (SMF): The SMF provides the information needed to deliver a release of the software, such as content of memories for SPINLINE 3 equipment or content of CD-ROM for PC based equipment. The SMF describes the procedures allowing to build the executable code from its software sources , to load and identify the media hosting the software, and to install the software into the equipment. The identifier of the SMF is the identifier of the release of the software. This identifier is referenced in the manufacturing files used to build the equipment, under the equipment configuration management system.

6.4.10 SPINLINE 3 Application Software Design Outputs

The design and development process produces the primary deliverables for the system, including the design documentation, code, and operational software which are generally not available until plant-specific implementation. Rolls-Royce commits to follow the life cycle design output process described in BTP 7-14. The results of the software system design will provide output reports for the following areas:

• Management Reviews: The objective of the management reviews is to track technical progress, schedule, risks, and issues against the Software Development Plan. These reviews are performed periodically. The participants are the Software Development Team, Software V&V Team, and Software Quality Assurance Manager. The review lead is the Software Development Manager

• End of Phase Reviews: The objectives of the end of phase reviews are to assess the execution of all the activities identified in the SQAP and the conformity with the SQAP dispositions, standards and guidelines, to approve the phase results, to get ready for the next phase. These reviews are conducted at selected project milestones, including the end of; “start of software project”, requirements, integration, validation, and the software project.

Software Requirement Documents: These provide the software requirements resulting from the system requirements and leads to the Software Requirements Traceability Matrix (RTM). This matrix is used during the Software Test Analysis to trace Software Requirements with Software Validation Tests.

The following information will be made available in the output documentation:

• Functional Design (Requirements) and Software Design Specifications


• Hardware and Software Architecture

• Code files-The actual programmed software code

• Installation Configuration Tables

• System Build Documents

• Operations and Maintenance Manuals (OMMs)

6.5 Secure Development and Operational Environment

Requirements for a secure development and operational environment for digital safety I&C systems are defined in Regulatory Guide 1.152 (Reference 6-68), which describes a method that the NRC staff deems acceptable for complying with the Commission’s regulations for promoting high functional reliability and design quality for the use of digital computers in safety systems of nuclear power plants.

Refer to the separate document 3 013 962 A (Reference 6-69), which describes how the generic SPINLINE 3 platform design and the associated software life cycle processes comply with the NRC guidance in Regulatory Guide 1.152 for establishing and maintaining a secure development environment at the Rolls-Royce factory. Document 3 013 962 A also identifies generic SPINLINE 3 design and software life cycle process features that will support a licensee in establishing a secure operational environment in a plant-specific system installed and operating at a nuclear power plant.


6-1 IAEA Safety Series 50-C-QA, Rev. 1., “Code on the Safety of Nuclear Power Plants: Quality Assurance,” International Atomic Energy Agency (IAEA), 1988

6-2 IEC 880-1986, “Software for Computers in the Safety Systems of Nuclear Power Stations,” International Electrotechnical Commission

6-3 MC3 Software Quality Plan (SQP), 8 303 429 A, I&C France

6-4 Project Development Plan, 6 615 351 C, I&C France

6-5 Contractual documents, TA 93061, I&C France

6-6 Software General Requirement Document, 1 207 101 A, I&C France

6-7 Software Development Plan, 1 207 102 A, I&C France

6-8 Software Modification Quality Plan, 1 208 686 B, I&C France

6-9 SPINLINE 3 Software Configuration Management Plan, 1 208 878 E, I&C France


6-10 (OSS) Software Requirement Specification, 1 207 108 J, I&C France

6-11 (CD_LDU) Software Requirement Specification, 1 207 145 B, I&C France

6-12 Software Interface Specification, 1 207 110 J, I&C France

6-13 (CSS) Software Preliminary Design Document, 1 207 141 H, I&C France

6-14 (CD_LDU) Software Preliminary Design Document, 1 207 163 B, I&C France

6-15 (OSS) Software Validation Test Plan, 1 207 146 G, I&C France

6-16 (CD_LDU) Software Validation Test Plan, 1 207 175 E, I&C France

6-17 Software Detailed Design documents for the CSS composed of the following seven reports: Main part, 1 207 151 G; Acquisition, 1 207 153 G; Emission, 1 207 154 F; Initialization, 1 207 155 G; Pack/Unpack, 1 207 156 D; Tests and Self-Tests, 1 207 157 H; and Common Parts, 1 207 159 G, I&C France

6-18 (CD_LDU) Software Detailed Design Document, 1 207 174 D, I&C France

6-19 (OSS) Software Integration Test Plan and Report, 1 207 204 E, I&C France

6-20 (CD_LDU) Software Integration Test Plan and Report, 1 207 239 A, I&C France

6-21 “C” Programming Rule, 1 207 106 C, I&C France

6-22 SPINLINE 3 Safety of Processing Unit Software Document, 1 207 228 H, I&C France

6-23 (OSS) Software Validation Test Report 1 207 232 F, I&C France

6-24 (CD_LDU) Software Validation Test Report, 1 207 292 D, I&C France

6-25 (OSS) Software Configuration Management Report, 3 000 824 A, I&C France

6-26 (CSS) Software Configuration Management Report, 1 207 257 F, I&C France

6-27 (CD_LDU) Software Configuration Management Report, 1 207 283 D, I&C France

6-28 (BF) Software Configuration Management Report, 1 207 277 E, I&C France


6-29 IEEE 7-4.3.2-2003, “Standard Criteria for Digital Computers in Safety Systems of Nuclear Power Generating Stations,” Institute of Electrical and Electronics Engineers

6-30 IEEE 730-1998, “IEEE Standard for Software Quality Assurance Plans”, Institute of Electrical and Electronics Engineers

6-31 Analysis of Consequences of Errors (in Hardware Configuration Tables), 1 207 184 F, I&C France

6-32 Functional FMEA documented in Software Requirement document of LDU, 1 207 142 F, I&C France

6-33 Project Technical Instruction on V&V of Software Module, 1 207 107 D, I&C France

6-34 Project Technical Instruction on Development Environment Organization, 1 207 105 D, I&C France

6-35 Instruction: “Requirements for tools used to develop software,” 1 206 747 E, I&C France

6-36 (N4) Software Quality Plan (SQP), 8 301 017 C, I&C France

6-37 Project Quality Plan, 1 208 708 A, I&C France

6-38 Project Development Plan, 1 208 568 B, I&C France

6-39 (App Oriented Library) Software Quality Plan, 1 208 356 C, I&C France

6-40 NRC Branch Technical Position 7-14, Rev, 5, “Guidance on Software Reviews for Digital Computer Based Instrumentation and Control Systems”, US Nuclear Regulatory Commission

6-41 SPINLINE 3 Design Analysis Report, MPR-3337 Rev. 1, MPR Associates, Inc., June 2009

6-42 EPRI Handbook 1011710, “Handbook for Evaluating Critical Digital Equipment and Systems”, Electric Power Research Institute, November 2005

6-43 Regulatory Guide 1.173, Rev. 0, "Developing Software Life Cycle Processes for Digital Computer Software Used in Safety Systems of Nuclear Power Plants"

6-44 IEEE 1074-1995, "Standard for Developing Life Cycle Processes," Institute of Electrical and Electronics Engineers

6-45 (Application) Software Quality Assurance Plan (SQAP), 8 307 208 B, I&C France

6-46 (Application) Software Development Plan (SDP), 8 307 211 B, I&C France


6-47 (Application) Software Configuration Management Plan (SCMP), 8 307 209 B, I&C France

6-48 (Application) Software Verification and Validation Plan (SVVP), 8 307 210 B, I&C France

6-49 System Integration and Factory Test Plan, 8 307 245 A, I&C France

6-50 System Installation and Site Test Plan, 8 307 243 A, I&C France

6-51 System Training Plan, 8 307 242 A, I&C France

6-52 System Operations and Maintenance Plan, 8 307 244 A, I&C France, June 2009

6-53 IEEE 1058-1998, “IEEE Standard for Software Project Management Plans”, Institute of Electrical and Electronics Engineers

6-54 10CFR50 Appendix B, “Quality Assurances Requirements for Nuclear Power Plants and Fuel Reprocessing Plants”

6-55 Regulatory Guide 1.28, Rev. 3, “Quality Assurance Program Requirements (Design and Construction).”

6-56 Regulatory Guide 1.152, Rev. 2, “Criteria for Use of Computers in Safety Systems of Nuclear Power Plants.”

6-57 ANSI/ASME NQA-1-1994, “Quality Assurance Program Requirements for Nuclear Facilities

6-58 NUREG/CR-6101, “Software Reliability and Safety in Nuclear Reactor Protection Systems”, Lawrence Livermore National Laboratory, November 1993

6-59 Regulatory Guide 1.169, Rev. 0, “Configuration Management Plans for Digital Computer Software Used in Safety Systems of Nuclear Power Plants”

6-60 IEEE 828-1990, “IEEE Standard for Configuration Management Plans,” Institute of Electrical and Electronics Engineers

6-61 IEEE 1012-1998, “IEEE Standard for Software Versification and Validation,” Institute of Electrical and Electronics Engineers

6-62 Regulatory Guide 1.168, Rev.1, “IEEE Standard for Software Versification and Validation”


6-63 Regulatory Guide 1.170, Rev. 0, “Software Test Documentation for Digital Computer Software Used in Safety Systems of Nuclear Power Plants”

6-64 Regulatory Guide 1.171, Rev. 0, “Software Unit Testing for Digital Computer Software Used in Safety Systems of Nuclear Power Plants”

6-65 IEEE 829-1983, “IEEE Standard for Software Test Documentation”, Institute of Electrical and Electronics Engineers

6-66 IEEE 1008-1987, “IEEE Standard for Software Unit Testing,” Institute of Electrical and Electronics Engineers

6-67 IEEE 1028-1997, “IEEE Standard for Software Reviews and Audits,” Institute of Electrical and Electronics Engineers

6-68 Draft Regulatory Guide 1249 (Proposed Revision 3 of Regulatory Guide 1.152, dated March 2010), June 2010, “Criteria for Use of Computers in Safety Systems of Nuclear Power Plants.”

6-69 SPINLINE 3 Secure Development and Operational Environment, 3 013 962 A, I&C France


Appendix A : Compliance Matrices

This Appendix contains the following compliance matrices that are referenced in Chapter 3 of this LTR:

Table 3.1-1 Standard Review Plan Table 7-1 Compliance Summary

Table 3.2-1 10 CFR 50 Appendix B and ASME NQA-1-1994 Map to the Corresponding I&C France QA Plans & Procedures

Table 3.2-2. 10 CFR 50 Appendix B and ASME NQA-1-1994 Map to the Corresponding I&C US QA Plans & Procedures

Table 3.6-1 Responses to NUREG/CR-6082 Communications System Questions

Table 3.7-1 Interim Staff Guide DI&C-ISG-04 Rev. 1 Compliance Matrix

Table 3.8-1 IEEE Standard 7-4.3.2-2003 Compliance Matrix

Table 3.8-2 IEEE Standard 603-1991 Compliance Matrix

Table 3.8-3 Mapping SPINLINE 3 SQP MC3 and Other Content to IEEE 730-1998 SQAP Content Guidance

Table 3.8-4 Mapping SPINLINE 3 SMQP and Other Content to IEEE 730-1998 SQAP Content Guidance

Table 3.8-5 Mapping SPINLINE 3 Application SQAP and Other Content to IEEE 730-1998 SQAP Content Guidance

Table 3.8-6 Mapping SPINLINE 3 SQP MC3 and Other Content to IEEE 828-1998 SCMP Content Guidance

Table 3.8-7 Mapping SPINLINE 3 Platform Software SCMP and Other Content to IEEE 828-1998 SCMP Content Guidance

Table 3.8-8 Mapping SPINLINE 3 Application SCMP and Other Content to IEEE 828-1998 SCMP Content Guidance

Table 3.8-9 Mapping SPINLINE 3 SQP MC3 and Other Content to IEEE 1012-1998 SVVP Content Guidance

Table 3.8-10 Mapping SPINLINE 3 SMQP and Other Content to IEEE 1012-1998 SVVP Content Guidance

Table 3.8-11 Mapping SPINLINE 3 Application SVVP and Other Content to IEEE 1012-1998 SVVP Content Guidance

Table 3.8-12 Alignment of IEEE 1074-1995 Activities, ISG-06 Tier 3 Document Guidance, and SPINLINE 3 Documents

Table 3.10-1 IEC 880-1986 Compliance Matrix

Table 3.10-2 Comparison of IEC 880-1986 & NRC Branch Technical Position 7-14 Requirements


Table 3.1-1. Standard Review Plan Table 7-1 Compliance Summary Regulatory Requirements (R), and SRP Acceptance Criteria (A) for

Instrumentation and Control Systems Important to Safety

Criteria Rev #

Title or Subject

Address compliance in generic

SPINLINE 3 LTR?

Location of compliance statement

in LTR

Endorsed standards

1. 10 CFR Parts 50 and 52

a 50.55a(a)(1) Quality Standards for Systems Important to Safety

Yes 3.2.1.2

IEEE 603-1991

Criteria for Safety Systems for Nuclear Power Generating Stations

b 50.55a(h)(2) Protection Systems (IEEE Std 603-1991 or IEEE Std 279-1971)

Yes 3.2.1.3

IEEE 279-1971

Criteria for Protection Systems for Nuclear Power Generating Stations

c 50.55a(h)(3) Safety Systems (IEEE Std 603-1991) Yes 3.2.1.4 IEEE 603-1991


d 50.34(f)(2)(v) [I.D.3]

Bypass and Inoperable Status Indication Yes 3.2.1.1

e 50.34(f)(2)(xi) [II.D.3]

Direct Indication of Relief and Safety Valve Position

No

f 50.34(f)(2)(xii) [II.E.1.2]

Auxiliary Feedwater System Automatic Initiation and Flow Indication

No

g 50.34(f)(2)(xvii) [II.F.1]

Accident Monitoring Instrumentation No

h 50.34(f)(2)(xviii) [II.F.2]

Instrumentation for the Detection of Inadequate Core Cooling

No




Criteria Rev #

Title or Subject


SPINLINE 3 LTR?


in LTR

Endorsed standards

i 50.34(f)(2)(xiv) [II.E.4.2]

Containment Isolation Systems No

j 50.34(f)(2)(xix) [II.F.3]

Instruments for Monitoring Plant Conditions Following Core Damage

No

k 50.34(f)(2)(xx) [II.G.1]

Power for Pressurizer Level Indication and Controls for Pressurizer Relief and Block Valves

No

l 50.34(f)(2)(xxii) [II.K.2.9]

Failure Mode and Effect Analysis of Integrated Control System

No

m 50.34(f)(2) (xxiii)[II.K.2.10]

Anticipatory Trip on Loss of Main Feedwater or Turbine Trip

No

n 50.34(f)(2)(xxiv) [II.K.3.23]

Central Reactor Vessel Water Level Recording

No

o 50.62 Requirements for Reduction of Risk from Anticipated Transients without Scram

No

p 52.47(b)(1) ITAAC for Standard Design Certification No

q 52.80(a) ITAAC for Combined Licensee Applications

No

r 50.49 Environmental qualification of electric equipment important to safety for nuclear power plants

Yes 3.2.1.5

s 73.54 Protection of Digital Computer and Communication Systems and Networks

Yes 3.2.4




Criteria Rev #

Title or Subject


SPINLINE 3 LTR?


in LTR

Endorsed standards

2. 10 CFR Part 50, Appendix A General Design Criteria (GDC)

a GDC 1 Quality Standards and Records Yes 3.2.2.1

b GDC 2 Design Bases for Protection Against Natural Phenomena

Yes 3.2.2.2

c GDC 4 Environmental and Dynamic Effects Design Bases

Yes 3.2.2.3

d GDC 10 Reactor Design No

e GDC 13 Instrumentation and Control Yes 3.2.2.4

f GDC 15 Reactor Coolant System Design No

g GDC 16 Containment Design No

h GDC 19 Control Room No

i GDC 20 Protection System Functions Yes 3.2.2.5

j GDC 21 Protection Systems Reliability and Testability

Yes 3.2.2.6

k GDC 22 Protection System Independence Yes 3.2.2.7

l GDC 23 Protection System Failure Modes Yes 3.2.2.8

m GDC 24 Separation of Protection and Control Systems

Yes 3.2.2.9

n GDC 25 Protection System Requirements for Reactivity Control Malfunctions

Yes 3.2.2.10

o GDC 28 Reactivity Limits No




Criteria Rev #

Title or Subject


SPINLINE 3 LTR?


in LTR

Endorsed standards

p GDC 29 Protection Against Anticipated Operational Occurrences

Yes 3.2.2.11

p GDC 33 Reactor Coolant Makeup No

q GDC 34 Residual Heat Removal No

r GDC 35 Emergency Core Cooling No

s GDC 38 Containment Heat Removal No

t GDC 41 Containment Atmosphere Cleanup No

u GDC 44 Cooling Water No

3. 10 CFR Part 50, Appendix B

a 10 CFR Part 50, Appendix B

Quality Assurances Requirements for Nuclear Power Plants and Fuel Reprocessing Plants

Yes 3.2.3

4. Staff Requirements Memoranda

a SRM to SECY 93-087, II.Q

Defense Against Common-Mode Failures in Digital Instrumentation and Control Systems

Yes 3.5.1

b SRM to SECY 93-087, II.T

Control Room Annunciator (Alarm) Reliability

No

5. Regulatory Guides

a Regulatory Guide 1.22

R0 Periodic Testing of Protection System Actuation Functions

Yes 3.3.1




Criteria Rev #

Title or Subject


SPINLINE 3 LTR?


in LTR

Endorsed standards

b Regulatory Guide 1.47

R0 Bypassed and Inoperable Status Indication for Nuclear Power Plant Safety System

Yes 3.3.2 IEEE 279-1971


c Regulatory Guide 1.53

R2 Application of the Single-Failure Criterion to Safety Systems

Yes 3.3.3 IEEE 379-2000

Application of the Single-Failure Criterion to Nuclear Power Generating Station Safety Systems

d Regulatory Guide 1.62

R0 Manual Initiation of Protection Actions Yes 3.3.4 IEEE 279-1971


e Regulatory Guide 1.75

R3 Independence of Electrical Safety Systems Yes 3.3.5 IEEE 384-1992

Standard Criteria for Independence

of Class 1E Equipment and Circuits

f

Regulatory Guide 1.89

R1 Environmental Qualification of Certain Electrical Equipment Important to Safety for Nuclear Power Plants

Yes 3.3.6 IEEE 323-1974

IEEE Standard for Qualifying Class IE Equipment for Nuclear Power generating Stations

g Regulatory Guide 1.97

R3 Instrumentation for Light Water Cooled Nuclear Power Plants to Assess Plant Conditions During and Following an Accident and Criteria for Accident Monitoring Instrumentation for Nuclear Power Plants

No ANS 4.5-1980

Criteria for Accident Monitoring Functions in Light-Water-Cooled Reactors




Criteria Rev #

Title or Subject


SPINLINE 3 LTR?


in LTR

Endorsed standards

R4 Instrumentation for Light Water Cooled Nuclear Power Plants to Assess Plant Conditions During and Following an Accident and Criteria for Accident Monitoring Instrumentation for Nuclear Power Plants

No IEEE 497-2002

IEEE Standard Criteria for Accident

Monitoring Instrumentation for Nuclear Power Generating Stations

h Regulatory Guide 1.100

R2 Seismic Qualification of Electric and Mechanical Equipment for Nuclear Power Plants

Yes 3.3.7 IEEE 344-1987

IEEE Standard for Qualifying Class 1E Equipment for Nuclear Power Generating Stations

i Regulatory Guide 1.105

R3 Setpoints for Safety-Related Instrumentation

Yes 3.3.8 ISA S67.04-1994

Setpoints for Nuclear Safety-Related Instrumentation Used in Nuclear Power Points

j Regulatory Guide 1.118

R3 Periodic Testing of Electric Power and Protection Systems

Yes 3.3.9 IEEE 338-1987

Criteria for the Periodic Surveillance Testing of Nuclear Power Generating Station Safety Systems

ISA S67.02-1980

Nuclear-Safety-Related Instrument Sensing Line Piping and Tubing Standards for Use in Nuclear Power Plants

k Regulatory Guide 1.151

R0 Instrument Sensing Lines No

ASME B&PV Code, Section III

Rules for Construction of Nuclear Power Plant Components




Criteria Rev #

Title or Subject


SPINLINE 3 LTR?


in LTR

Endorsed standards

l Regulatory Guide 1.152

R2 Criteria for Use of Computers in Safety Systems of Nuclear Power Plants

Yes 3.3.10 IEEE 7-4.3.2-2003

Standard Criteria for Digital Computers in Safety Systems of Nuclear Power Generating Stations

m Regulatory Guide 1.153

R1 Criteria for Safety Systems Yes 3.3.11 IEEE 603-1991


IEEE 1012-1998

IEEE Standard for Software Verification and Validation Plans

n Regulatory Guide 1.168

R1 Verification, Validation, Reviews and Audits for Digital Computer Software Used in Safety Systems of Nuclear Power Plants

Yes 3.3.12

IEEE 1028-1997

IEEE Standard for Software Reviews and Audits

IEEE 828-1990

IEEE Standard for Software Configuration Management Plans

o Regulatory Guide 1.169

R0 Configuration Management Plans for Digital Computer Software Used in Safety Systems of Nuclear Power Plants

Yes 3.3.13

IEEE 1042-1987

IEEE Guide to Software Configuration Management

p Regulatory Guide 1.170

R0 Software Test Documentation for Digital Computer Software Used in Safety Systems of Nuclear Power Plants

Yes 3.3.14 IEEE 829-1983

IEEE Standard for Software Test Documentation

q Regulatory Guide 1.171

R0 Software Unit Testing for Digital Computer Software Used in Safety Systems of Nuclear Power Plants

Yes 3.3.15 IEEE 1008-1987

IEEE Standard for Software Unit Testing




Criteria Rev #

Title or Subject


SPINLINE 3 LTR?


in LTR

Endorsed standards

r Regulatory Guide 1.172

R0 Software Requirements Specifications for Digital Computer Software Used in Safety Systems of Nuclear Power Plants

Yes 3.3.16 IEEE 830-1993

IEEE Recommended Practice for Software Requirements Specifications

s Regulatory Guide 1.173

R0 Developing Software Life Cycle Processes for Digital Computer Software Used in Safety Systems of Nuclear Power Plants

Yes 3.3.17 IEEE 1074-1995

IEEE Standard for Developing Software Life Cycle Processes

t Regulatory Guide 1.174

R1 An Approach for Using Probabilistic Risk Assessment in Risk-Informed Decisions on Plant-Specific Changes to the Licensing Basis

No

u Regulatory Guide 1.177

R0 An Approach for Plant-Specific Risk-Informed Decision Making: Technical Specifications

No

IEEE 1050-1996

Guide for Instrumentation and Control Equipment Grounding in Generating Stations

MIL-STD-461E

DOD Interface Standard Requirements for the Control of Electromagnetic

Interference Characteristics of Subsystems and Equipment

IEC 61000-3

Electromagnetic Compatibility (EMC) - Part 3

v Regulatory Guide 1.180

R1 Guidelines for Evaluating Electromagnetic and Radio- Frequency Interference in Safety-Related Instrumentation and Control Systems Instrumentation and Control Systems

Yes 3.3.18

IEC 61000-4





Criteria Rev #

Title or Subject


SPINLINE 3 LTR?


in LTR

Endorsed standards

IEC 61000-5


IEEE C62.41-1991

Recommended Practice on Surge Voltages in Low-Voltage AC Power Circuits

IEEE C62.45-1992

Guide on Surge Testing for Equipment Connected to Low-Voltage AC Power Circuits

w Regulatory Guide 1.189

R1 Fire Protection for Operating Nuclear Power Plants

No

x Regulatory Guide 1.200

R1 An Approach for Determining the Technical Adequacy of Probabilistic Risk Assessment Results for Risk-Informed Activities

No

IEEE 665-1995

IEEE Guide for Generating Station Grounding

IEEE 666-1991

IEEE Design Guide for Electrical Power Service Systems for Generating Stations

y Regulatory Guide 1.204

R0 Guidelines for Lightning Protection of Nuclear Power Plants

No

IEEE 1050-1996

IEEE Guide for Instrumentation and Control Equipment Grounding in Generating

Stations




Criteria Rev #

Title or Subject


SPINLINE 3 LTR?


in LTR

Endorsed standards

IEEE C62.23-1995

IEEE Application Guide for Surge Protection

of Electric Generating Plants

z Regulatory Guide 1.209

R0 Guidelines for Environmental Qualification of Safety-Related Computer-Based Instrumentation and Control Systems in Nuclear Power Plants

Yes 3.3.19 IEEE 323-2003

IEEE Standard for Qualifying Class 1E Equipment for Nuclear Power Generating Stations

aa

Regulatory Guide 5.71

R0 Cyber Security Programs for Nuclear Facilities Yes 3.3.20

6. Branch Technical Positions (BTP)

a BTP 7-1 R5 Guidance on Isolation of Low-Pressure Systems from the High-Pressure Reactor Coolant System

No

b BTP 7-2 R5 Guidance on Requirements on Motor-Operated Valves in the Emergency Core Cooling System Accumulator Lines

No

c BTP 7-3 R5 Guidance on Protection System Trip Point Changes for Operation with Reactor Coolant Pumps Out of Service

No

d BTP 7-4 R5 Guidance on Design Criteria for Auxiliary Feedwater Systems

No




Criteria Rev #

Title or Subject


SPINLINE 3 LTR?


in LTR

Endorsed standards

e BTP 7-5 R5 Guidance on Spurious Withdrawals of Single Control Rods in Pressurized Water Reactors

No

f BTP 7-6 R5 Guidance on Design of Instrumentation and Controls Provided to Accomplish Changeover from Injection to Recirculation Mode

No

g BTP 7-7 Not used N/A

h BTP 7-8 R5 Guidance on Application of Regulatory Guide 1.22

Yes 3.4.1

i BTP 7-9 R5 Guidance on Requirements for Reactor Protection System Anticipatory Trips

No

j BTP 7-10 R5 Guidance on Application of Regulatory Guide 1.97

No

k BTP 7-11 R5 Guidance on Application and Qualification of Isolation Devices

Yes 3.4.2

l BTP 7-12 R5 Guidance on Establishing and Maintaining Instrument Setpoints

Yes 3.4.3

m BTP 7-13 R5 Guidance on Cross-Calibration of Protection System Resistance Temperature Detectors

No

n BTP 7-14 R5 Guidance on Software Reviews for Digital Computer-Based Instrumentation and Control Systems

Yes 3.4.4




Criteria Rev #

Title or Subject


SPINLINE 3 LTR?


in LTR

Endorsed standards

o BTP 7-15 Not used N/A

p BTP 7-16 Not used N/A

q BTP 7-17 R5 Guidance on Self-Test and Surveillance Test Provisions

Yes 3.4.5

r BTP 7-18 R5 Guidance on Use of Programmable Logic

Controllers in Digital Computer-Based

Instrumentation and Control Systems

Yes 3.4.6

s BTP 7-19 R5 Guidance on Evaluation of Diversity and Defense-in-

Depth in Digital Computer-Based


Yes 3.4.7

t BTP 7-20 Not used N/A

u BTP 7-21 R5 Guidance on Digital Computer Real-Time Performance

Yes 3.4.8

7. Interim Staff Guidance (ISG)

a DI&C-ISG-01 R0 Cyber Security Yes 3.7.1 RG 1.152, R2

Criteria for Use of Computers in Safety Systems of Nuclear Power Plants

b DI&C-ISG-02 R1 Diversity and Defense-in-Depth (D3) Yes 3.7.2 NUREG/CR-6303

Method for Performing Diversity and Defense-in-Depth Analyses of Reactor Protection Systems




Criteria Rev #

Title or Subject


SPINLINE 3 LTR?


in LTR

Endorsed standards

BTP 7-19 Guidance on Evaluation of Diversity and Defense-in-

Depth in Digital Computer-Based


c DI&C-ISG-03 R0 Risk-Informed Digital Instrumentation and Controls

No

IEEE 603-1991


d DI&C-ISG-04 R1 Highly Integrated Control Rooms – Digital Communication Systems

Yes 3.7.3

IEEE 7-4.3.2-2003

Standard Criteria for Digital Computers in Safety Systems of Nuclear Power Generating Stations

NUREG-0700 Rev 2

Human-System Interface Design Review Guidelines

e DI&C-ISG-05 R0 Highly Integrated Control Rooms – Human Factors

No

NUREG-0711

Human Factors Engineering Program Review Model

f DI&C-ISG-06 Draft Licensing Process Yes 3.7.4


Table 3.2-1. 10 CFR 50 Appendix B and ASME NQA-1-1994 Map to the Corresponding I&C France QA Plans & Procedures

10 CFR 50 App B Requirement

ASME NQA-1-1994 Requirement Corresponding I&C France Quality Plans and Procedures

Introduction 1. Purpose

2. Applicability

3. Responsibility

4. Terms and Definitions

Basic Requirement 1: Organization 8 303 701 Organization I - Organization

Organization Supplemental Requirements

200 Structure and Responsibility

201 General

202 Delegation of Work

203 Interface Control

8 303 701 Organization

Basic Requirement 2: Quality Assurance Program 8 303 186 Quality Management Plan, N II - Quality Assurance Program Quality Assurance Program Supplemental Requirements

200 Indoctrination and Training 201 Indoctrination 202 Training 300 Qualification Requirements 301 Nondestructive Examination (NDE) 302 Inspection and Test 303 Lead Auditor 304 Auditors 400 Certification of Qualification 500 Records

8 303 186 Quality Management Plan, N

3 006 499 Project Quality Plan, A

8 303 242 Quality Management System

8 303 243 QP establishment rules

8 303 695 Continuous Improvement Process

8 303 696 Resources Management Process

8 307 053 Human Resources Process

8 303 321 Training of Personnel





Basic Requirement 3: Design Control


8 303 693 Product development process

III - Design Control

Design Control Supplement Requirements

200 Design Input

300 Design Process

400 Design Analysis

401 Use of Computer Programs

402 Document of Design Analysis

500 Design Verification

501 Methods

600 Change Control

601 Configuration Mgmt of Operating Facilities


800 Software Design Control

801 Software Design Process

802 Software Configuration Management

900 Documentation and Records

8 303 693 Product development process

8 307 032 Principles for control of design

(Safety Related systems only)

8 303 314 Project development process

8 303 334 System Design

(Safety Related systems only)

8 303 350 Control of Software Design

8 303 603 Equipment Design process

8 303 349 Electronics Design process

8 303 197 Change Management process

(technical changes)





Basic Requirement 4: Procurement Document Control

8 303 186 Quality Management Plan, N IV - Procurement Document Control

Procurement Document Control Supplemental Requirements

200 Content of the Procurement Documents

201 Scope of Work

202 Technical Requirements

203 Quality Assurance Program Requirements

204 Right of Access

205 Documentation Requirements

206 Nonconformances

207 Spare and Replacement Parts

300 Procurement Document Review

400 Procurement Document Changes

8 303 698 Purchasing process

8 303 398 Purchasing Order processing procedure

8 303 194 Commercial Grade Item

8 307 139 Subcontracting quality prescription

8 307 003 Vendor Evaluation

V - Instructions, Procedures and Drawings

Basic Requirement 5: Instructions, Procedures and Drawings


8 303 719 Control of Documents

8 303 198 Establishment of Technical documents





Basic Requirement 6: Document Control 8 303 186 Quality Management Plan, N


VI - Document Control

Document Control Supplemental Requirements

200 Document Control

300 Document Changes

301 Major Changes

302 Minor Changes


8 303 197 Change Management process

(technical changes)

8 303 198 Establishment of Technical documents

8 303 243 QP establishment rules

8 303 217 Establishment of manufacturing and

test documents

Basic Requirement 7: Control of Purchased Items and Services


8 303 194 Commercial Grade Items

VII - Control of Purchased Materials, Equipment and Services Control of Purchased Items and Services Supplemental

Requirements

200 Supplier Evaluation

300 Bid Evaluation

400 Control of Supplier-Generated Documents

500 Acceptance of Item or Service

501 General

502 Methods of Acceptance

503 Certificate of Conformance


8 303 404 Procurement Quantity Inspection

8 303 405 Procurement Quality Inspection

8 303 715 Monitoring of subassemblies suppliers

8 303 320 Control of Records





504 Source Verification

505 Receiving Inspection

506 Post installation Testing

507 Acceptance of Services Only

600 Control of Supplier Nonconformances

700 Commercial Grade Items and Services

701 General

702 Utilization

703 Critical Characteristics

704 Dedication

705 Supplier Deficiency Correction

800 Records

Basic Requirement 8: Identification and Control of Items 8 303 186 Quality Management Plan, N

8 303 221 Product Identification and Traceability

VIII - Identification and Control of Materials, Parts and Components Identification and Control of Items Supplemental

Requirements

200 Identification Methods

201 Item Identification

202 Physical Identification

300 Specific Requirements

301 Identification and Traceability of Items

8 303 221 Product Identification and Traceability





302 Limited Life Items

303 Maintaining Identification of Stored Items

Basic Requirement 9: Control of Processes 8 303 222 Control of manufacturing processes


IX - Control of Special Processes

Control of Processes Supplemental Requirements

200 Process Control

201 Special Processes

202 Acceptance Criteria

203 Special Requirements

300 Responsibility

400 Records

8 303 222 Control of manufacturing processes

8 303 233 Special Process Documentation



Basic Requirement 10: Inspection 8 303 223 In Process Inspections and Tests

X - Inspection

Inspection Supplemental Requirements

200 Inspection Requirements

300 Inspection Hold Points

400 Inspection Planning

401 Planning

402 Sampling

500 In-Process Inspection

8 303 223 In Process Inspections and Tests

8 303 404 Procurement Quantity Inspection

8 303 405 Procurement Quality Inspection

8 303 662 Inspection and tests for product repair






600 Final Inspections

601 Resolution of Nonconformances


603 Modifications, Repairs, or Replacements

700 Records

Basic Requirement 11: Test Control 8 303 186 Quality Management Plan, N XI - Test Control

Test Control Supplemental Requirements

200 Test Requirements

300 Test Procedures (other than for computer programs)

400 Computer Program Test Procedures

500 Test Results

600 Test Records

8 303 223 In Process Inspections and Tests

8 303 662 Inspection and tests for product repair

Basic Requirement 12: Control of Measuring and Test Equipment


8 303 224 Control of Test and Measurement Devices

XII - Control of Measuring and Test Equipment

Control of Measuring and Test Equipment Supplemental Requirements

200 Selection

300 Calibration and Control

301 Calibration

302 Reference Standards

8 303 224 Control of Test and Measurement Devices





303 Control

304 Commercial Devices

400 Records

401 General

402 Reports and Certificates

Basic Requirement 13: Handling, Storage and Shipping 8 303 186 Quality Management Plan, N

8 303 226 Handling, Packing and Storage

8 303 326 Shipping

XIII - Handling, Storage and Shipping

Handling, Storage and Shipping Supplemental Requirements


300 Procedures

400 Tools and Equipment

500 Operators

600 Marking or Labeling

8 303 226 Handling, Packing and Storage

8 303 326 Shipping

XIV - Inspections, Test and Operating Status

Basic Requirement 14: Inspections, Test and Operating Status

8 303 228 Establishment of Test & Factory Reports

8 303 661 Establishment of product repair reports





Basic Requirement 15: Control of Nonconforming Items 8 303 186 Quality Management Plan, N

8 303 202 Nonconformity

XV - Nonconforming Materials, Parts of Components

Control of Nonconforming Items Supplemental Requirements

200 Identification

300 Segregation

400 Disposition

401 Control

402 Responsibility and Authority

403 Personnel

404 Disposition

405 Reexamination

8 303 202 Nonconformity

8 307 152 Classified Nonconformities

XVI - Corrective Action

Basic Requirement 16: Corrective Action 8 303 186 Quality Management Plan, N

8 303 238 Corrective and Preventative Actions

Basic Requirement 17: Quality Assurance Records 8 303 320 Control of Records XVII - Quality Assurance Records Quality Assurance Records Supplemental Requirements

200 Generation of Records

300 Authentication of Records

400 Classification

401 Lifetime Records

402 Nonpermanent Records





500 Receipt Control of Records

600 Storage

700 Retention

800 Maintenance of Records

Basic Requirement 18: Audits 8 303 186 Quality Management Plan, N

8 303 239 Audits

XVIII - Audits

Audits Supplemental Requirements

200 Scheduling

300 Preparation

301 Audit Plan

302 Personnel

303 Selection of Audit Team

400 Performance

500 Reporting

600 Response

700 Follow-up Action

800 Records

8 303 239 Audits





Subpart 2.7 Basic Requirements: Quality Assurance Requirements for Computer Software for Nuclear Facility Applications

8 307 032 Principles for control of design, safety systems

8 303 050 Control of software design

Quality Assurance Requirements for Computer Software for Nuclear Facility Applications Supplemental Requirements

200 General Requirements

201 Documentation

202 Review


204 Problem Reporting and Corrective Action

300 Software Acquisition

301 Procured Software and Software Services

302 Otherwise Acquired Software

400 Software Engineering Method

401 Software Design Requirements

402 Software Design

403 Implementation

404 Acceptance Testing

405 Operation

406 Maintenance

407 Retirement

8 303 050 Control of software design 8 307 034 Software impact analyses management 8 303 671 Checking upon receipt of external software 1 207 875 Software configuration management 1 208 055 Software project management 1 206 747 Requirements for software Tools used for software development 1 208 210 V&V training plan 8 303 634 Software quality control process 1 207 947 checking process for software document





500 Standards, Conventions, and other Work Practices

600 Support Software

601 Software Tools

602 System Software




ASME NQA-1-1994 Requirement Corresponding I&C US QA Plans and Procedures

Introduction 1. Purpose

2. Applicability

3. Responsibility

4. Terms and Definitions

I&C US Quality Manual, ICQ-005-C

Basic Requirement 1: Organization

QPP 01-1 Organization

WF 01-1 Organization Chart

ICQ-005 I&C US Quality Manual, Rev B

ICQ-006 Quality Oversight Board

I - Organization

Organization Supplemental Requirements

200 Structure and Responsibility

201 General

202 Delegation of Work


QPP 01-2 Roles, Responsibilities and Authorities

II - Quality Assurance Program

Basic Requirement 2: Quality Assurance Program

I&C US Quality Manual, ICQ-005-C

QPP 02-1 Quality Assurance Program

QPP 02-2 Program – Management Review

QPP 02-3 Documents and Vocabulary

QPP 02-5 Identification Tag Authority

QPP 02-6 Customer Satisfaction & WF 02-6 CSA




ASME NQA-1-1994 Requirement Corresponding I&C US QA Plans and Procedures Process

QPP 05-4 I&C US Share Point


ICQ-006 Quality Oversight Board Quality Assurance Program Supplemental Requirements 200 Indoctrination and Training 201 Indoctrination 202 Training 300 Qualification Requirements 301 Nondestructive Examination (NDE) 302 Inspection and Test 303 Lead Auditor 304 Auditors 400 Certification of Qualification 500 Records


QPP 10-1 Certification - Inspectors

QPP 10-3 Certification – QA Insp. Officials

QPP 11-1 Certification – System Testers

QPP 14-1 Certification – In-Line Inspectors

QPP 18-1 Certification – Lead Nuclear Auditors

QPP 18-4 Auditor Approval

WF 18-4 Approving Auditors

Basic Requirement 3: Design Control

QPP 03-1 Process - Lifecycle

QPP 03-5 Control – Project Data Mgmt



III - Design Control

Design Control Supplement Requirements

200 Design Input

300 Design Process

400 Design Analysis

401 Use of Computer Programs

QPP 03-2 Control – Design

WI 03-2.1 Configuration Control Board

WI 03-2.2 Software Configuration Management

QPP 03-3 Control – Development

WI 03-3.1 Software Review





402 Document of Design Analysis

500 Design Verification

501 Methods

600 Change Control

601 Configuration Mgmt of Operating Facilities


800 Software Design Control

801 Software Design Process


900 Documentation and Records

WI 03-3.2 PMS Product Test Procedures Review & Update

WI 03-3.3 Non-Product Test Procedure Review & Update

WI 03-3.4 Code Review

QPP 03-4 Control - Acceptance

QPP 03-5 Control – Project Data Mgmt

WI 03-5.1 Software Development Folders

WI 03-5.2 Project Closeout

WF 03-5 Backups

WI 03-6.2 Software Baseline Control

WI 03-6.3 Third Party Software Certification

QPP 03-7 Process – Maintenance & Support

Basic Requirement 4: Procurement Document Control

QPP 04-3 Procurement - Vendor Administration

QPP 04-4 Procurement – Annual Vendor Evaluation

IV - Procurement Document Control

Procurement Document Control Supplemental Requirements

200 Content of the Procurement Documents

201 Scope of Work

202 Technical Requirements

203 Quality Assurance Program Requirements

QPP 04-1 Procurement – Class 1E & Special Provision Purchases

QPP 04-2 Procurement – IWO for Class 1E Purchases







204 Right of Access

205 Documentation Requirements

206 Nonconformances

207 Spare and Replacement Parts

300 Procurement Document Review

400 Procurement Document Changes

V - Instructions, Procedures and Drawings

Basic Requirement 5: Instructions, Procedures and Drawings

QPP 05-1 Document Control - Quality

QPP 05-2 Document Control – Drawings

WI 05-2.1 Engineering Change Report

QPP 05-3 Drawing Numbers


QPP 05-5 Policy and WI Development

Basic Requirement 6: Document Control QPP 06-1 Document Control - Technical

QPP 06-2 Document Numbering

VI - Document Control

Document Control Supplemental Requirements

200 Document Control

300 Document Changes

301 Major Changes

302 Minor Changes

QPP 05-1 Document Control - Quality

QPP 05-2 Document Control – Drawings

QPP 06-1 Document Control - Technical

QPP 06-2 Document Numbering

QPP 06-3 Document Changes

WI 06-3.1 Document Change Order

WI 06-3.2 Document Review





Basic Requirement 7: Control of Purchased Items and Services

QPP 07-1 Document Control - Vendors

QPP 07-2 Control - Customer Supplied Items

VII - Control of Purchased Materials, Equipment and Services Control of Purchased Items and Services Supplemental

Requirements

200 Supplier Evaluation

300 Bid Evaluation

400 Control of Supplier-Generated Documents

500 Acceptance of Item or Service

501 General

502 Methods of Acceptance

503 Certificate of Conformance

504 Source Verification

505 Receiving Inspection

506 Post installation Testing

507 Acceptance of Services Only

600 Control of Supplier Nonconformances

700 Commercial Grade Items and Services

701 General

702 Utilization

703 Critical Characteristics

704 Dedication

QPP 04-1 Procurement – Class 1E & Special Provision Purchases

QPP 04-2 Procurement – IWO for Class 1E Purchases



QPP 07-1 Document Control - Vendors

QPP 07-2 Control - Customer Supplied Items

QPP 09-2 Control – Commercial Dedication

QPP 10-2 Inspections – Goods Receipt





705 Supplier Deficiency Correction

800 Records

Basic Requirement 8: Identification and Control of Items QPP 02-5 Identification Tag Authority

QPP 08-1 Control - Materials, Parts and Components


VIII - Identification and Control of Materials, Parts and Components

Identification and Control of Items Supplemental Requirements

200 Identification Methods

201 Item Identification

202 Physical Identification

300 Specific Requirements

301 Identification and Traceability of Items

302 Limited Life Items

303 Maintaining Identification of Stored Items


QPP 08-1 Control - Materials, Parts and Components

QPP 08-2 Control – Customer Returned Materials


Basic Requirement 9: Control of Processes QPP 09-1 Control - Special Processes

QPP 09-2 Control - Commercial Dedication

IX - Control of Special Processes

Control of Processes Supplemental Requirements

200 Process Control

201 Special Processes

202 Acceptance Criteria

QPP 09-1 Control - Special Processes

QPP 09-2 Control - Commercial Dedication






300 Responsibility

400 Records

Basic Requirement 10: Inspection QPP 02-5 Identification Tag Authority

QPP 10-1 Certification - Goods Receipt Inspectors

WF 10-1 Inspector Certification

QPP 10-2 Inspections - Goods Receipt

QPP 10-3 Certification – QA Inspection Officials


QPP 14-2 Inspections – In-Line and Status

X - Inspection

Inspection Supplemental Requirements


300 Inspection Hold Points

400 Inspection Planning

401 Planning

402 Sampling

500 In-Process Inspection

600 Final Inspections

601 Resolution of Nonconformances


603 Modifications, Repairs, or Replacements


WI 10-2.1 Goods Receiving

WI 10-2.2 Discrepancy Report



QPP 14-2 Inspections – In-Line and Status





700 Records

Basic Requirement 11: Test Control QPP 11-1 Certification - System Testers

QPP 11-2 Testing – Systems in Development

QPP 11-3 Testing – Integrated Systems

XI - Test Control

Test Control Supplemental Requirements

200 Test Requirements

300 Test Procedures (other than for computer programs)

400 Computer Program Test Procedures

500 Test Results

600 Test Records

QPP 11-2 Testing – Systems in Development

QPP 11-3 Testing – Integrated Systems

QPP 11-4 Testing – Problem Reporting

WI 11-4.1 Hardware Problems

WI 11-4.2 Software Problems

Basic Requirement 12: Control of Measuring and Test Equipment


QPP 12-1 Calibration

XII - Control of Measuring and Test Equipment

Control of Measuring and Test Equipment Supplemental Requirements

200 Selection

300 Calibration and Control

301 Calibration

302 Reference Standards

303 Control

304 Commercial Devices

400 Records


QPP 12-1 Calibration





401 General

402 Reports and Certificates

Basic Requirement 13: Handling, Storage and Shipping QPP 02-5 Identification Tag Authority

QPP 13-1 Control – Storage

XIII - Handling, Storage and Shipping

Handling, Storage and Shipping Supplemental Requirements


300 Procedures

400 Tools and Equipment

500 Operators

600 Marking or Labeling


QPP 13-1 Control – Storage

QPP 13-1 Control – Pack & Ship

XIV - Inspections, Test and Operating Status

Basic Requirement 14: Inspections, Test and Operating Status



QPP 14-1 Certification - In-Line Inspectors

WF 14-1 In-Line Inspector Certification

QPP 14-2 Inspections - In-Line and Status

XV - Nonconforming Materials, Parts of Components

Basic Requirement 15: Control of Nonconforming Items QPP 02-5 Identification Tag Authority


QPP 11-4 Testing – Problem Reporting


WI 14-2.1 Inspection Planning





WI 14-2.2 In-line Inspection Report

QPP 15-1 Nonconformances

QPP 15-2 Nonconformance Evaluation

ICQ-002 10CFR21 Reporting Safety-Related Problems

ICQ-004 10CFR21 Posting Notice Review


Control of Nonconforming Items Supplemental Requirements

200 Identification

300 Segregation

400 Disposition

401 Control

402 Responsibility and Authority

403 Personnel

404 Disposition

405 Reexamination




QPP 15-1 Nonconformances

WI 15-1.1 Material Review Board

QPP 15-2 Nonconformance Evaluation

WI 15-2.1 Nonconformance Report

ICQ-002 10CFR21 Reporting Safety-Related Problems

ICQ-003 Class 1E Record Annual Review


XVI - Corrective Action

Basic Requirement 16: Corrective Action QPP 16-1 Process Improvement - Corrective Action

QPP 16-2 Process Improvement - Preventative Action





QPP 16-3 Process Improvement – Business Process Improvement

QPP 16-4 Root Cause Analysis

Basic Requirement 17: Quality Assurance Records QPP 17-1 Records XVII - Quality Assurance Records Quality Assurance Records Supplemental Requirements

200 Generation of Records

300 Authentication of Records

400 Classification

401 Lifetime Records

402 Nonpermanent Records

500 Receipt Control of Records

600 Storage

700 Retention

800 Maintenance of Records

QPP 17-1 Records

WI 17-1.1 Dual Storage

ICQ-003 Class 1E Record Annual Review

Basic Requirement 18: Audits QPP 18-1 Certification - Auditors

QPP 18-4 Auditor Approval

WF 18-4 Approving Auditors

XVIII - Audits

Audits Supplemental Requirements

200 Scheduling

300 Preparation

301 Audit Plan

QPP 18-2 Program – Audits

QPP 18-3 Audit Report





302 Personnel

303 Selection of Audit Team

400 Performance

500 Reporting

600 Response

700 Follow-up Action

800 Records

Subpart 2.7 Basic Requirements: Quality Assurance Requirements for Computer Software for Nuclear Facility Applications



Quality Assurance Requirements for Computer Software for Nuclear Facility Applications Supplemental Requirements

200 General Requirements

201 Documentation

202 Review


204 Problem Reporting and Corrective Action

300 Software Acquisition

301 Procured Software and Software Services

302 Otherwise Acquired Software

400 Software Engineering Method



WI 03-2.1 Configuration Control Board

WI 03-2.2 Software Configuration Management

WI 03-3.1 Software Review

WI 03-3.2 PMS Product Test Procedures Review & Update

WI 03-3.3 Non-Product Test Procedure Review & Update

WI 03-3.4 Code Review

QPP 03-4 Control - Acceptance





401 Software Design Requirements

402 Software Design

403 Implementation

404 Acceptance Testing

405 Operation

406 Maintenance

407 Retirement

500 Standards, Conventions, and other Work Practices

600 Support Software

601 Software Tools

602 System Software

QPP 03-6 Control – Product Releases

WI 03-6.1 Error Notification

WI 03-6.2 Software Baseline Control

WI 03-6.3 Third Party Software Certification

QPP 03-8 Improvement – Product Delivery



NUREG/CR-6082 Question SPINLINE 3 2.1.1. Is it an event-based or state based system?

NERVIA is based on a cyclic and deterministic protocol. The communication between the NERVIA stations and units is asynchronous. NERVIA is a state-based system.

2.1.2. Is there an accurate picture of the layout? The detailed architectures with the connection of each unit on the networks are shown in each individual system description.

2.1.3. Are the data rates known between all nodes of the architecture? Are they known for upset and error conditions?

The data rates between all nodes of the architecture are based on the network cycle time. This cycle time is constant even in case of failure of a Station.

The cycle time is fixed and defined from the definition of the data sent on the network during the design phase.

The consistency of data transmission is verified (see Section 4.5.4.3).

2.1.4. Is the message mix known? Is it known for upset and error conditions?

The messages mix is well-characterized and the data are carried in Ethernet frames (see Section 4.5.4.3)

2.1.5. Are the timing and delay requirements known?

Timing and delay requirements are expressed in detailed system requirements. The response time of a system is defined by a theoretical model and verified on the equipment during factory tests.

2.1.6. Is the system “deterministic” and the effects of error recovery accounted for?

The protocol is deterministic. Even in case of errors, the cycle time is constant. (see Section 4.5.2.1)

If there is any error, the operational system software of the receiver invalidates the data as long as the error remains. The application software processes invalid data. (see Section 4.5.6)



NUREG/CR-6082 Question SPINLINE 3 2.1.7. Is the actual link capacity including interface, operating system and protocol performance effects being quoted, or is the vendor basing calculations on raw media bandwidth?

The cycle time includes the timing of reception and transmission processing, and is used to determine the actual link capacity. (see Section 4.5.2.1)

2.1.8. What are the media requirements? The media (cable and fiber optic) are defined in Section 4.3.4.8.

2.1.9. Does the design meet independence requirements?

The architecture and the use of fiber optic allow the requirements of electrical and physical independence to be met.

2.1.10. What are the communications error performance requirements?

[[Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Propri]]

2.1.11. What are the protocol requirements? What services should the protocol provide?

This is described in Sections 4.5.

2.1.12. Is the medium proprietary? Are the protocols proprietary?

The medium is an off-the-shelf product.

The protocol is a time-based token bus protocol.

The software is proprietary software developed by Rolls-Royce.

2.1.13. Is there theoretical support for performance and reliability?

For performance, the cycle time of each network is fixed and monitored. Refer to Section 4.5.



NUREG/CR-6082 Question SPINLINE 3 2.1.15. Is there experimental support for performance and reliability?

Detection of failed components is supported by system self-tests. Then repair is limited to replacement of electronic cards and the cabling is facilitated by use of connectors. Restoration of NERVIA networks after identification of any failure of an electronic component is simple and not time consuming.

2.1.16. Is there an installed base? If proprietary, how many suppliers support the medium and the protocol software?

The NERVIA network is already installed in French N4 NPPs (4 units), Fessenheim and Bugey NPPs (6 units), Kozloduy NPPs, Ignalina NPPs, and Dukovany NPPs. The lower levels of the protocol are provided by the Freescale MPC860 Communication Processor. The upper level of the protocol is provided by Rolls-Royce proprietary software.

2.1.17. Is there a good match between nodes processors, networks controllers, and operating system and protocol stack?

The NERVIA network is already installed in safety systems of NPPs. This long-term installation and operation allows us to claim that there is a good match between all elements of the SPINLINE 3 system.



Section #

ISG-04 Requirements Compliance of the SPINLINE 3 generic platform

SPINLINE 3 interface criteria for NPP-specific digital safety I&C applications

1 INTERDIVISIONAL COMMUNICATIONS

1 A safety channel should not be dependent upon any information or resource originating or residing outside its own safety division to accomplish its safety function. This is a fundamental consequence of the independence requirements of IEEE603. It is recognized that division voting logic must receive inputs from multiple safety divisions

• The SPINLINE 3 Safety channel introduced in Section 4.2.4.1 does not depend upon information coming from outside its safety division, except for trip requests coming from the other divisions and input to the voting logic.

• Signal acquisition, conditioning and trip logic do not depend on the other safety divisions.

Confirm generic compliance statement applies to plant specific architecture

2 The safety function of each safety channel should be protected from adverse influence from outside the division of which that channel is a member. Information and signals originating outside the division must not be able to inhibit or delay the safety function. This protection must be implemented within the affected division (rather than in the sources outside the division), and must not itself be affected by any condition or information from outside the affected division. This protection must be sustained despite any operation, malfunction, design error, communication error, or software error or corruption existing or originating outside the division.

• The only communication between Safety channels is via one-way NERVIA networks which provide the data required by the voting logic.

• A Safety channel transmits its data to the other safety channels on one network and reads data from the other networks (there is one network per Safety channel).

• Communication among Safety channels is one-way and asynchronous (i.e. the transmitting Safety channel sends messages periodically on its network to the other Safety channels, in broadcast mode). The receiving Safety channels do not need to wait or synchronize with these messages to issue their own safety actuations.

• [[Proprietary text Proprietary text




Section #



Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text

• Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Pr ]]

• In case of 2oo4 voting logic, the safe action can result in a modification of the voting logic (for instance going from 2oo4 to 2oo3).

• Communication failures are detected immediately, allowing the system to be repaired.



Section #



3 A safety channel should 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. Safety systems should be as simple as possible. 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.

• The only input coming from outside a Safety channel division is the input needed for the division voting logic (i.e. request for actuation coming from the other divisions).

• The safety system is kept as simple as possible and does not include functions not related to the safety functions.




Section #



For example, comparison of readings from sensors in different divisions may provide useful information concerning the behavior of the sensors (for example, On-Line 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, should be justified. It should be demonstrated that 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 does not significantly increase the likelihood of software specification or coding errors, including errors that would affect more than one division. The applicant should justify the definition of “significantly” used in the demonstration.

• Comparison of readings from sensors in different divisions is performed outside the safety system on a permanently installed, non-Class 1E Monitoring and Maintenance Unit (MMU).

• Communication from the Safety channels to the MMU is achieved through a dedicated one way NERVIA network, ensuring Class 1E / non-Class 1E isolation.

4 The communication process itself should be carried out by a communications processor separate from the processor that executes the safety function, so that communications errors and malfunctions will not interfere with the execution of the safety function.

• The microprocessor that executes the safety function is a Freescale MC68040, located on the processing unit board (UC25 N+).

• The communication process is carried out on a separate microprocessor. It is a Freescale MPC860, located on the NERVIA daughter board.

Generic. No change.



Section #



The communication and function processors should operate asynchronously, sharing information only by means of dual-ported memory or some other shared memory resource that is dedicated exclusively to this exchange of information.

• [[Proprietary textProprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Prop]]

Generic. No change.

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 must be designed, qualified, fabricated, etc., in accordance with 10 C.F.R. Part 50, Appendix A and B.

• Hardware (UC25 N+, NERVIA daughter and interface boards, hubs and associated cables) as well as NERVIA software are safety related items, and have been designed, qualified and fabricated according to Class 1E requirements.

Generic. No change.

Access to the shared memory should 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.

• [[Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary

• Proprietary text Proprietary text Proprietary text

•

o

o Proprietary text Proprietary text Proprietary text

Proprietary text Proprietary text Proprietary text

Generic. No change.



Section #



Proprietary text Proprietary text Proprietary text Proprietary text P]]

For example, if the communication processor is accessing the shared memory at a time when the function processor needs to access it, the function processor should gain access within a timeframe that does not impact the loop cycle time assumed in the plant safety analyses. If the shared memory cannot support unrestricted simultaneous access by both processors, then the access controls should be configured such that the function processor always has precedence. The safety function circuits and program logic should ensure that the safety function will be performed within the timeframe established in the safety analysis, and will be completed successfully without data from the shared memory in the event that the function processor is unable to gain access to the shared memory.

See above See above



Section #



5 The cycle time for the safety function processor should be determined in consideration of the longest possible completion time for each access to the shared memory. This longest-possible completion time should include the response time of the memory itself and of the circuits associated with it, and should 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 should be detected and alarmed.

• The time to access (to get or to write data to) the shared memory is constant by design. It depends only on the size of the communication areas.

• [[Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary te]]

• The cycle time of the processing unit is pre-defined during the design. Exceeded processing unit cycle time is detected and alarmed. (See Section 4.4.3.5.3 for further information on processing unit cycle time management).

• Network cycle time is constant (see Section 4.5 for further information on network cycle time).

Generic. No change.

6 The safety function processor should perform no communication handshaking and should not accept interrupts from outside its own safety division.

• The safety function processor does not perform communication handshaking.

• Software units do not make use of interrupt-driven tasks or algorithms based on dynamic memory allocation.

Generic. No change.



Section #



7 Only predefined data sets should be used by the receiving system. Unrecognized messages and data should be identified and dispositioned by the receiving system in accordance with the pre-specified design requirements. Data from unrecognized messages must not be used within the safety logic executed by the safety function processor.

• All data is exchanged through predefined messages according to a configuration established during design and described in fixed tables

• [[Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text

• Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary te ]]

Generic. No change.

Message format and protocol should be pre-determined. Every message should have the same message field structure and sequence, including message identification, status information, data bits, etc. in the same locations in every message.

• [[Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text

• Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text


Generic. No change.



Section #




Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Propriet ]].

Every datum should be included in every transmit cycle, whether it has changed since the previous transmission or not, to ensure deterministic system behavior.

All network data are transmitted at each cycle (whether it has changed or not).

Generic. No change.



Section #



8 Data exchanged between redundant safety divisions or between safety and nonsafety divisions should be processed in a manner that does not adversely affect the safety function of the sending divisions, the receiving divisions, or any other independent divisions.

• NERVIA communication is managed by a dedicated microprocessor separated from the microprocessor which performs the safety function.

• [[

Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text ]]

Generic. No change.



Section #



9 Incoming message data should be stored in fixed predetermined locations in the shared memory and in the memory associated with the function processor. These memory locations should not be used for any other purpose. The memory locations should be allocated such that input data and output data are segregated from each other in separate memory devices or in separate pre-specified physical areas within a memory device.

• [[Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text

• Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Pro ]]

Generic. No change.

10 Safety division software should be protected from alteration while the safety division is in operation. On-line changes to safety system software should be prevented by hardwired interlocks or by physical disconnection of maintenance and monitoring equipment. A workstation (e.g. engineer or programmer station) may alter addressable constants, setpoints, parameters, and other settings associated with a safety function only by way of the dual-processor / shared-memory scheme described in this guidance, or when the associated channel is inoperable. Such a workstation should 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 either physically opens the data transmission circuit or interrupts the connection by means of hardwired logic. “Hardwired logic” as used here refers to circuitry that physically interrupts the flow of information, such as an electronic AND gate circuit (that does not use software or firmware) with one input controlled by the hardware switch and the

• The safety division software is installed in read-only flash memories. There is no provision to erase or reprogram the flash memories while installed on the CPU board. At startup, the software is loaded into dedicated RAM memory, which is then write locked while the software is running.

• [[Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text

•

Generic. No change.



Section #



other connected to the information source: the information appears at the output of the gate only when the switch is in a position that applies a “TRUE” or “1” at the input to which it is connected. Provisions that rely on software to effect the disconnection are not acceptable. It is noted that software may be used in the safety system or in the workstation to accommodate the effects of the open circuit or for status logging or other purposes.

Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text]]

11 Provisions for interdivisional communication should explicitly preclude the ability to send software instructions to a safety function processor unless all safety functions associated with that processor are either bypassed or otherwise not in service. The progress of a safety function processor through its instruction sequence should not be affected by any message from outside its division.

• The SPINLINE 3 technology precludes the ability to send software instructions to a safety function processor.

• The application program associated with the operational system software runs as a single continuous program loop. One loop execution is called a scan. During each scan, outputs are computed from a fixed image of the inputs and from relevant results of the previous scans.

• Data received through NERVIA messages have the same behavior as data received through digital or analog input boards. Received data is not used to control the execution of this safety division application program.

Generic. No change.



Section #



For example, a received message should not be able to direct the processor to execute a subroutine or branch to a new instruction sequence.

See above See above

12 Communication faults should not adversely affect the performance of required safety functions in any way. Faults, including communication faults, originating in nonsafety equipment, do not constitute “single failures” as described in the single failure criterion of 10 CFR Part 50, Appendix A.

Data exchange cannot adversely affect safety functions. Communication fault detection and communications behavior in the presence of typical faults are addressed in Section 4.5.4

(see also 8)

Generic. No change.

Examples of credible communication faults include, but are not limited to, the following:

1. Messages may be corrupted due to errors in communications processors, errors introduced in buffer interfaces, errors introduced in the transmission media, or from interference or electrical noise.

2. Messages may be repeated at an incorrect point in time.

3. Messages may be sent in the incorrect sequence.

4. Messages may be lost, which includes both failures to receive an uncorrupted message or to acknowledge receipt of a message.

5. Messages may be delayed beyond their permitted arrival time window for several reasons, including errors in the transmission medium, congested transmission lines, interference, or by delay in sending buffered messages.

6. Messages may be inserted into the communication

• Communication failures are detected and appropriate safety actions are taken. See Section 4.5.6 "Communication failures detection"

[[

Generic. No change.



Section #



medium from unexpected or unknown sources.

7. Messages may be sent to the wrong destination, which could treat the message as a valid message.

8. Messages may be longer than the receiving buffer, resulting in buffer overflow and memory corruption.

9. Messages may contain data that is outside the expected range.

10. Messages may appear valid, but data may be placed in incorrect locations within the message.

11. Messages may occur at a high rate that degrades or causes the system to fail (i.e., broadcast storm).

12. Message headers or addresses may be corrupted.



Section #



]]

13 Vitaliii communications, such as the sharing of channel trip decisions for the purpose of voting, should 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, should be shown to always reconstruct the original message exactly or to designate the message as unrecoverable. None of this activity should affect the operation of the safety-function processor.

• Communication failures are detected and appropriate safety actions are taken. See Section 4.5.6 "Communication failures detection";

• [[Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text

• Proprietary textProprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text P ]]

Generic. No change.



Section #



14 Vitaliii communications should be point-to-point by means of a dedicated medium (copper or optical cable). In this context, “point-to-point” means that the message is passed directly from the sending node to the receiving node without the involvement of equipment outside the division of the sending or receiving node. Implementation of other communication strategies should provide the same reliability and should be justified.

• The SPINLINE 3 safety channel is compliant with this requirement. . The passive hubs establish simple star point-to-point network configurations

Generic. No change.

15 Communication for safety functions should communicate a fixed set of data (called the "state") at regular intervals, whether data in the set has changed or not.

• Data communication layouts are predefined, using the CLARISSE System and Software Development Environment (SSDE) during the design phase. All network data are transmitted once at each cycle, whether it has changed or not. (see also 7, item 3)

Generic. No change.

16 Network connectivity, liveness, and real-time properties essential to the safety application should be verified in the protocol. Liveness, in particular, is taken to mean that no connection to any network outside the division can cause an RPS/ESFAS communication protocol to stall, either deadlock or livelock. (Note: This is also required by the independence criteria of: (1) 10 CFR. Part 50, Appendix A, General Design Criteria (“GDC”) 24, which states, “interconnection of the protection and control systems shall be limited so as to assure that safety is not significantly impaired.”; and (2) IEEE 603-1991 IEEE Standard Criteria for Safety Systems for Nuclear Power Generating Stations.) (Source: NUREG/CR-6082, 3.4.3)

• The NERVIA protocol is deterministic. • Even in case of errors, the cycle time is

constant. In case of error, the operational system software of the receiver invalidates the data as long as the error remains. The application software processes invalid data in a safety oriented way.

Generic. No change.



Section #



17 Pursuant to 10 CFR. § 50.49, the medium used in a vitaliii communications channel should be qualified for the anticipated normal and post-accident environments.

The SPINLINE 3 digital I&C platform includes selected medium and equipment used for NERVIA network: optical fibers, twisted-shielded pair cables, hubs, TP/FL converters. (See EQ Plan and QTS System Specification).

• Confirm that the plant-specific environment is consistent with the generic SPINLINE 3 qualification envelope.

• Also confirm the qualification of any third-party communications media used in the plant-specific system.

For example, some optical fibers and components may be subject to gradual degradation as a result of prolonged exposure to radiation or to heat. In addition, new digital systems may need susceptibility testing for EMI/RFI and power surges, if the environments are significant to the equipment being qualified.

See above See above

18 Provisions for communications should be analyzed for hazards and performance deficits posed by unneeded functionality and complication.

• As described in Section 4.5, there are no unneeded functionalities or complexities in NERVIA

• NERVIA protocol is fit for this purpose and dedicated to safety I&C systems

A plant-specific communications analysis is recommended if the plant-specific safety I&C system includes third-party safety I&C components (i.e., safety display processors or commend prioritization)



Section #



19 If data rates exceed the capacity of a communications link or the ability of nodes to handle traffic, the system will suffer congestion. All links and nodes should have sufficient capacity to support all functions. The applicant should identify the true data rate, including overhead, to ensure that communication bandwidth is sufficient to ensure proper performance of all safety functions. Communications throughput thresholds and safety system sensitivity to communications throughput issues should be confirmed by testing.

• A SPINLINE 3 system cannot suffer congestion during operation:

[[

Proprietary text Proprietary text Proprietary text Proprietary text Propri]]

Compliance is based on the generic deterministic characteristics of the SPINLINE 3 digital communications networks. No change.



Section #



20 The safety system response time calculations should assume a data error rate that is greater than or equal to the design basis error rate and is supported by the error rate observed in design and qualification testing.

• The SPINLINE 3 digital I&C platform has a deterministic behavior. It is a key feature to meet response time requirements and to avoid overload situations. The maximum response time for a system is established using the maximum response time of each unit and network. SPINLINE 3 determinism guarantees that I&C outputs will always be delivered within the computed maximum response time limit. Data errors in communications do not impact the safety system maximum response time. See Section 4.2.6 (SPINLINE 3 main features - Deterministic behavior) for further detail.

Compliance is based on the generic deterministic characteristics of the SPINLINE 3 digital communications networks. No change.

2 COMMAND PRIORITIZATION

The generic SPINLINE 3 safety I&C platform does not include a priority logic module. Therefore, this section of ISG-04 does not apply.

Include details of any command prioritization features in the plant-specific documentation. Also expand this table to address each of the ISG-06 items related to command prioritization



Section #



3 MULTIDIVISIONAL CONTROL AND DISPLAY STATIONS

3.1 Independence and Isolation

The following provisions are applicable to multidivisional control and display stations. These guidance provisions do not apply to conventional hardwired control and indicating devices (hand switches, indicating lamps, analog indicators, etc.).

The generic SPINLINE 3 safety I&C platform does not include multidivisional control and display stations. Therefore, the requirements for multi-division controls in this section of ISG-04 does not apply.

Include details of any multidivisional control and display stations in the plant-specific documentation.

1 Nonsafety stations receiving information from one or more safety divisions:

All communications with safety-related equipment should conform to the guidelines for interdivisional communications.

Comply. As described in Section 4.5.7, isolation and independence is enforced on data “gateways” to non-Class 1E computer systems.


2 Safety-related stations receiving information from other divisions (safety or nonsafety):

All communications with equipment outside the station’s own safety division, whether that equipment is safety-related or not, should conform to the guidelines for interdivisional communications. Note that the guidelines for interdivisional communications refer to provisions relating to the nature and limitations concerning such communications, as well as guidelines relating to the communications process itself

Comply. SPINLINE 3 systems require interdivisional communications to support voting logics. In addition, SPINLINE 3 system enable one-way (broadcast only) communications from divisional processors to divisional display processors that can aggregate data and perform calculations that are not done within a single division (i.e., average, maximum, minimum of all divisions)


3 Nonsafety stations controlling the operation of safety-related equipment:

Nonsafety stations may control (see note above) the operation of safety-related equipment, provided the

The generic SPINLINE 3 safety I&C platform does not provide this control capability.

Include details of any such control capabilities in the plant-specific documentation.



Section #



following restrictions are enforced:

• The nonsafety station should access safety-related plant equipment only by way of a priority module associated with that equipment. Priority modules should be designed and applied as described in the guidance on priority modules.

• A nonsafety station should not affect the operation of safety-related equipment when the safety-related equipment is performing its safety function. This provision should be implemented within the safety-related system, and must be unaffected by any operation, malfunction, design error, software error, or communication error in the nonsafety equipment. In addition:

• The nonsafety station should be able to bypass a safety function only when the affected division has itself determined that such action would be acceptable.

• The nonsafety station should not be able to suppress any safety function. (If the safety system itself determines that termination of a safety command is warranted as a result of the safety function having been achieved, and if the applicant demonstrates that the safety system has all information and logic needed to make such a determination, 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



Section #



safety division is not acceptable because there would be no protection from inappropriate or accidental reset.)

• The nonsafety station should 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.

4 Safety-related stations controlling the operation of equipment in other safety-related divisions:

Safety-related stations controlling (see note above) the operation of equipment in other divisions are subject to constraints similar to those described above for nonsafety stations that control the operation of safety-related equipment.

• A control station should access safety-related plant equipment outside its own division only by way of a priority module associated with that equipment. Priority modules should be designed and applied as described in the guidance on priority modules.

• A station must not influence the operation of safety-related equipment outside its own division when that equipment is performing its safety function. This provision should be implemented within the affected (target) safety-related system, and should be unaffected by any operation, malfunction, design error, software error, or communication error outside the division of which those controls are a member. In addition:

The generic SPINLINE 3 safety I&C platform does not provide this control capability.

Include details of any such control capabilities in the plant-specific documentation.



Section #



• The extra-divisional (that is, “outside the division”) control station should be able to bypass a safety function only when the affected division itself determined that such action would be acceptable.

• The extra-divisional station should not be able to suppress any safety function. (If the safety system itself determines that termination of a safety command is warranted as a result of the safety function having been achieved, and if the applicant demonstrates that the safety system has all information and logic needed to make such a determination, 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.)

• The extra-divisional station should 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.



Section #



5 Malfunctions and Spurious Actuations:

The result of malfunctions of control system resources (e.g., workstations, application servers, protection/control processors) shared between systems must be consistent with the assumptions made in the safety analysis of the plant. Design and review criteria for complying with these requirements, as set forth in 10 C.F.R. § 50.34 and 50.59, include but are not limited to the following:

• Control processors that are assumed to malfunction independently in the safety analysis should not be affected by failure of a multidivisional control and display station.

• Control functions that are assumed to malfunction independently in the safety analysis should not be affected by failure of a single control processor.

• Safety and control processors should be configured and functionally distributed so that a single processor malfunction or software error will not result in spurious actuations that are not enveloped in the plant design bases, accident analyses, 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 must be addressed.

• No single control action (for example, mouse click

The generic SPINLINE 3 safety I&C platform does not provide this control capability, therefore these requirements do not apply.

If such control capabilities exist in the plant-specific system, then provide the supporting analysis in plant-specific documentation.



Section #



or screen touch) should generate commands to plant equipment. Two positive operator actions should be required to generate a command. For example: When the operator requests any safety function or other important function, the system should respond “do you want to proceed?” The operator should then be required to respond “Yes” or “No” to cause the system to execute the function. Other question-and-confirm strategies may be used in place of the one described in the example. The second operation as described here is to provide protection from spurious actuations, not protection from operator error. Protection from operator error may involve similar but more restrictive provisions, as addressed in guidance related to Human Factors.

• Each control processor or its associated communication processor should detect and block commands that do not pass the communication error checks.

• Multidivisional control and display stations should be qualified to withstand the effects of adverse environments, seismic conditions, EMI/RFI, power surges, and all other design basis conditions applicable to safety-related equipment at the same plant location. This qualification need not demonstrate complete functionality during or after the application of the design basis condition unless the station is safety-related. Stations which are not safety-related should be shown to produce no spurious actuations and to have no adverse effect



Section #



upon any safety-related equipment or device as a result of a design basis condition, both during the condition and afterwards. If spurious or abnormal actuations or stoppages are possible as a result of a design basis condition, then the plant safety analyses must envelope those spurious and abnormal actuations and stoppages. Qualification should be supported by testing rather than by analysis alone. D3 considerations may warrant the inclusion of additional qualification criteria or measures in addition to those described herein.

• Loss of power, power surges, power interruption, and any other credible event to any operator workstation or controller should 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.

• The design should have provision for an “operator workstation disable” switch to be activated upon abandonment of the main control room, to preclude spurious actuations 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 operator 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.

• Failure or malfunction of any operator workstation



Section #



must not result in a plant condition (including simultaneous conditions) that is not enveloped in the plant design bases, accident analyses, and anticipated transients without scram (ATWS) provisions, or in other unanticipated abnormal plant conditions

3.2 Human Factors Considerations This will be determined on a plant-specific basis.

Include details of human factors in the plant-specific documentation. Also expand this table to address each of the ISG-06 items related to human factors.

3.3 Diversity and Defense-in-Depth (D3) Considerations

This will be determined on a plant-specific basis.

Include details of D3 in the plant-specific documentation. Also expand this table to address each of the ISG-06 items related to D3.



Section #



ISG-04 Notes

i IEEE 603-1991 (cited in 10CFR50.55a(h)) provides the following definitions: 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.” 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.” For the purposes of this guidance document, the terms channel and division are further described below. Note that the following is for illustrative purposes, and is not intended to impose requirements or new interpretations: A safety channel as used herein is a set of safety-related instruments and equipment, along with the associated software, that together generate a protective actuation or trip signal to initiate a single protective function. While an analog/hardwired system would have each functional circuit clearly assigned to only one channel, the processor and other components in a digital system may be assigned to multiple channels within a single division. A safety division is the collection of all safety channels that are powered by a single power division. Different channels perform different functions. Different divisions perform the same set of functions, and are redundant to one another. Licensing typically credits redundancy among divisions. The voting logic that generates the final actuation signal to an item of plant equipment typically resides in one division and receives input from redundant channels in all divisions. For the purposes of this guidance, it is to be assumed that each of the actuation signals entering the voting logic that establishes the final actuation signal to an item of plant equipment is in a different division, regardless of the particular usage of the term “division” for a particular nuclear power plant. ii “Processor” may be a CPU or other processing technology such as simple discrete logic, logic within an FPGA, an ASIC, etc. iii “Vital” communications as used herein are communications that are needed to support a safety function. Failure of vital communications could inhibit the performance of the safety function. The most common implementation of vital communications is the distribution of channel trip information to other divisions for the purpose of voting.


Table 3.8-1. IEEE Standard 7-4.3.2-2003 Compliance Matrix Section

# Section Title Relationship of


requirements to IEEE Standard 603-1991 requirements

Compliance of the SPINLINE 3 generic digital safety I&C platform

SPINLINE 3 interface criteria for NPP-specific digital safety

I&C applications

4 Safety system design basis

No requirements beyond IEEE Standard 603

5 Safety system criteria

See specific subsections, below

5.1 Single-failure criterion


5.2 Completion of protective action


5.3 Quality Section 5.3 requirements addresses software quality. These are in addition to IEEE Standard 603, which addresses hardware quality.

Software life cycle processes dedicated for SPINLINE 3 platform software are discussed in Chapter 6. BTP 7-14-compliant software life cycle processes for application software are described in Chapter 6.








I&C applications

5.3.1 Software development

Software resident on the processing unit are: • the plant-specific application, • the OSS, • software embedded in I/O and

communication boards. Application software will be developed, modified or accepted according to an approved Software Quality Assurance Plan. See Section 6.4.3.

SPINLINE 3 OSS Quality Assurance Plan was developed under IEC 880, which provides acceptable quality assurance guidance. See Section 6.2.3.

Class 1E software embedded in I/O and communication boards is developed according to the I&C France life cycle process and Quality Assurance Program applicable to Class 1E software (see section 6.2.8)

5.3.1.1 Software quality metrics

Software quality metrics are used as defined in the Software Quality Assurance Plan.

5.3.2 Software tools SPINLINE 3 software tools are configuration managed items. For details, see Chapter 6, the Software Configuration Management Plan, and the Design Analysis Report (DAR).








I&C applications

5.3.3 Verification and validation

Verification and validation is implemented for the application software as prescribed in the SVVP.

Verification and validation is implemented for the OSS (see section 6.2.5)

Verification and validation is implemented for software embedded in I/O and communication boards (see section 6.2.8)

5.3.4 Independent V&V (IV&V) requirements

Independent verification and validation is implemented for the application software as prescribed in the SVVP.

Independent verification and validation is implemented for the OSS (see section 6.2.5)

Independent verification and validation is implemented for software embedded in I/O and communication boards (see section 6.2.8)

5.3.5 Software configuration management

Software configuration management is implemented for the application software as prescribed in the SCMP.

Software configuration management is implemented for the OSS (see section 6.2.6)

Software configuration management is implemented for software embedded in I/O and communication boards (see section 6.2.8)








I&C applications

5.3.6 Software project risk management

Not applicable, to be dealt with at system level

5.4 Equipment qualification

Section 5.4 requirements are necessary to qualify digital computers for use in safety systems and are in addition to the equipment qualification criteria in IEEE Standard 603.

The Equipment Qualification (EQ) Plan provides the environmental, seismic, radiation, and EMC test levels and criteria.

5.4.1 Computer system testing

The equipment qualification tests will exercise all portions of the SPINLINE 3 digital I&C platform necessary to accomplish a safety functions.

5.4.2 Qualification of existing commercial computers

The SPINLINE 3 digital safety I&C platform is not COTS. However, the generic SPINLINE 3 platform was not originally designed under a 10 CFR 50 Appendix B quality program. Therefore, the generic SPINLINE 3 platform is being dedicated under the I&C France 10 CFR 50 Appendix B quality program in accordance with I&C France document 3 010 794 A, “Dedication Plan for the Generic SPINLINE 3 Digital Safety I&C Platform.

The Local Display Unit (LDU) described in LTR Section 4.4.3.5.5 and the Monitoring and








I&C applications

Maintenance Unit (MMU) described in LTR Section 4.6.10 are commercial quality and are not used for, or qualified for, Class 1E functions.

5.4.2.1 Preliminary phase of the COTS dedication process

See comment to section 5.4.2

5.4.2.2 Detailed phase of the COTS dedication process

See comment to section 5.4.2

5.4.2.3 Maintenance of commercial dedication

Commercial dedication is maintained in accordance with I&C France document 3 010 794 A, “Dedication Plan for the Generic SPINLINE 3 Digital Safety I&C Platform”

5.5 System integrity Section 5.5 requirements are necessary to achieve system integrity in digital equipment for use in safety systems and are in addition to the system integrity criteria in IEEE Standard 603.








I&C applications

5.5.1 Design for computer integrity

Generic qualification of the SPINLINE 3 I&C digital platform demonstrates its ability to perform its safety function when subjected to environmental or electrical disturbances. It also includes power supply voltage and frequency variations, all initialization states, communication failures and dynamic process conditions including burst of events.

5.5.2 Design for test and calibration

No calibration on SPINLINE 3 boards is performed once they are installed in the equipment. Section 4.6 has additional details on periodic testing and calibration.

Modification of a setpoint may be required on a plant-specific application.

- This is performed with the Local Display Unit. Only parameters that have been declared as modifiable during the development can be modified within the corresponding declared range.

- The management of the modified parameters is not a generic platform issue and shall be addressed at system level.

5.5.3 Fault detection and self-diagnostics

SPINLINE 3 I&C digital platform includes fault detection and self-diagnostics. Refer to Sections 4.4 to 4.6








I&C applications

5.6 Independence In addition to the requirements of IEEE Standard 603, this section addresses independence of data communication between safety channels or between safety and non-safety systems.

As required in RG1.152, if a safety software shall perform non-safety functions, the latter will be classified as safety-related.

ISG4 specifically addresses issues related to interactions among safety divisions and between safety-related equipment and equipment that is not safety-related. Refer to Section 3.7 for compliance to ISG4 requirements.

5.7 Capability for test and calibration


5.8 Information displays


5.9 Control of access No requirements beyond IEEE Standard 603

5.10 Repair No requirements beyond IEEE Standard 603








I&C applications

5.11 Identification Section 5.11 supplements IEEE Standard 603 with additional requirements to ensure that the computer system hardware and software are installed in the appropriate system configuration

Assurance that proper hardware and software configuration is installed is based on configuration management of hardware and software.

[[


5.12 Auxiliary features No requirements beyond IEEE Standard 603

5.13 Multi-unit stations No requirements beyond IEEE Standard 603








I&C applications

5.14 Human factor considerations


5.15 Reliability In addition to the requirements of IEEE Standard 603, when reliability goals are identified, the proof of meeting the goals shall include the software

Software reliability results from:

- software design oriented toward simplicity and high quality

- rigorous development process (including verification of intermediate products (requirements specification, design, coding) by independent V&V team)

6 Sense and command features—functional and design requirements


7 Execute features—functional and design requirements


8 Power source requirements



Table 3.8-2. IEEE Standard 603-1991 Compliance Matrix Section # Section Title

Are there supplementary requirements in

IEEE Standard 7-4.3.2-2003?

IEEE Standard 603 compliance of the SPINLINE 3 generic digital safety I&C

platform


I&C applications

4 Safety system design basis

Item 4.7 - generic qualification of the platform will provide the basis for conditions in which the system can perform

Item 4.8 - generic qualification will demonstrate Class 1E/non-Class 1E isolation

Item 4.9 - FMEA and reliability data of modules will provide input for systems analysis

The safety system design basis for a SPINLINE 3 application is defined on a plant-specific basis

5 Safety system criteria See specific subsections, below

5.1 Single-failure criterion

The SPINLINE 3 digital platform includes features which minimize the possibility of a postulated single-failure precluding the actuation of a safety action when requested: • the digital platform is qualified both to

Appendix B requirements and to mild-environment (including seismic and EMC) criteria which eliminates these causal common-cause failures

• The self-diagnostic testing and periodic surveillance testing identify all credible failures within the platform.

The single failure criterion is implemented in the design of plant-specific Class 1E systems, which will have redundant, independent divisions.






platform


I&C applications


This requirement shall be addressed at system level within the execute features of the protection system.

5.3 Quality Yes. IEEE Standard 7-4.3.2 Section 5.3 provides additional requirements for software quality.

I&C France quality assurance program (compliant with 10 CFR 50 Appendix B) governs the life cycle of safety system modules. The platform meets both 10 CFR 50 Appendix B and ANSI/ASME NQA-1 quality requirements.

5.4 Equipment qualification

Yes. IEEE Standard 7-4.3.2 Section 5.4 provides additional requirements to qualify digital computers for use in safety systems.

The generic qualification of the SPINLINE 3 digital platform is performed in accordance with NRC requirements.

Plant specific environmental envelopes at the locations where SPINLINE 3 equipment is installed should be compared to the generic qualification envelope and, if exceeded, additional qualification testing may be required for a plant-specific application of SPINLINE 3.






platform


I&C applications

5.5 System integrity Yes. IEEE Standard 7-4.3.2 Section 5.5 provides additional requirements to achieve system integrity in digital equipment for use in safety systems.

The SPINLINE3 platform is tested under a wide range of applicable operating conditions to demonstrate the system will perform its protective actions upon demand. Details of the qualification program are in the Equipment Qualification Plan. In addition, the platform software was developed under a high quality process that minimizes latent errors. The application software will be developed under a high quality process that minimizes latent errors.

5.6 Independence Yes. IEEE Standard 7-4.3.2 Section 5.6 provides additional requirements for independence of data communications

Independence is dealt with at the system level. Redundant portions of a system are independent and separated such that all regulations are met. The communication network meets independence requirements for physical, electrical and communications.

The specific redundant and independent features of a safety I&C system are defined at the system level, on a plant-specific basis.

5.6.1 Between redundant portions of a safety system

NERVIA features contribute to independence between redundant portions of a safety systems (fault tolerance, one-way data transfer between divisions, self-checking, data validation, safe default actions, electrical independence with use of fiber optic cable for isolation)






platform


I&C applications

5.6.2 Between safety systems and effects of design basis event

The SPINLINE 3 platform hardware is qualified for mild environment conditions.

Plant specific environmental envelopes at the locations where SPINLINE 3 equipment is installed should be compared to the generic qualification envelope and, if exceeded, additional qualification testing may be required for a plant-specific application of SPINLINE 3.

5.6.3 Between safety systems and other systems

Interaction between safety systems and non-safety systems is performed either by a NERVIA network or with contacts of output relays.

NERVIA features contribute to independence between safety systems and other systems (fault tolerance, one-way data transfer to non-safety systems, self-checking, data validation, safe default actions, electrical independence with use of fiber optic cable for isolation)

Class 1E/non-Class 1E isolation qualification contributes to independence between safety systems and other systems.






platform


I&C applications

5.6.4 Detailed criteria Yes. This section of IEEE Standard 603 refers to IEEE Standard 7-4.3.2 and IEEE Standard 384.

The SPINLINE 3 safety system meets the independence criteria specified in IEEE Standard 603-1991, clause 5.6, and IEEE Standard 384-1981.

5.7 Capability for test and calibration

The SPINLINE 3 system is designed to meet the guidance of RG 1.22, RG 1.118, and IEEE Standard 338-1987.

Refer to Section 4.6 "Testability "

Capability based on inhibition and redundancy features.

During periodic tests, the response of the tested unit and its capability to perform its safety functions are verified.

5.8 Information displays

5.8.1 Displays for manually controlled actions

Operator displays are not in the scope of the generic SPINLINE 3 digital safety I&C platform.

Operator displays will be addressed on a plant-specific basis






platform


I&C applications

5.8.2 System status indication

As described on Section 4.5, SPINLINE 3 is capable of communicating status data to Class 1E and non-Class 1E display or indication systems.

System status indication is available via the Automated Testing Unit (ATU) described in Sections 4.6.9 and the Monitoring and Maintenance Unit (MMU) described in Section 4.6.10. Other status indication is not in the scope of the generic SPINLINE 3 digital safety I&C platform.

Other system status indication will be addressed on a plant-specific basis






platform


I&C applications

5.8.3 Indication of bypasses

If a channel is placed in the bypass mode during periodic testing, that system status is available via the Automated Testing Unit (ATU) described in Sections 4.6.9 and the Monitoring and Maintenance Unit (MMU) described in Section 4.6.10. Other indication of bypass status is not in the scope of the generic SPINLINE 3 digital safety I&C platform.

Other bypass status indication will be addressed on a plant-specific basis

5.8.4 Location Conformance will be addressed on an NPP-specific basis

5.9 Control of access [[Proprietary textProprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Propri]]

The NPP will implement administrative access controls to limit access to the panels.






platform


I&C applications

5.10 Repair The SPINLINE 3 platform is designed with many ease of repair features that are aided by the reliability of the digital platform which has been demonstrated through many years of operation and by using Appendix B qualified hardware and software. In addition rapid failure detection is possible through the multiple testing features inherent in the SPINLINE 3 platform design discussed in chapter 4. The SPINLINE 3components are readily accessible which aids in their ease of removal, replacement and/or repair.

In a plant-specific application, the cabinet and chassis wiring are visually identifiable and easily tested for faults.

5.11 Identification Yes. IEEE 7-4.3.2 Section 5.11 provides additional requirements to ensure that the computer system hardware and software are installed in the appropriate system configuration

The digital platform hardware and software will be individually identified to enable the correct configuration and installation in a plant application.

The cabinets will be marked using the plant's identification scheme.






platform


I&C applications

5.12 Auxiliary features Plant specific requirement. However, plant supporting functions will be verified to be consistent with the SPINLINE 3 digital platform interface requirements.

5.13 Multi-unit stations NA

5.14 Human factor considerations

There are non-safety interfaces between a human and the platform via the Automated Testing Unit (ATU) described in Section 4.6.9. and the Monitoring and Maintenance Unit (MMU) described in Section 4.6.10.

In plant-specific implementations, the design of the interactive displays associated with the MT panel will be subject to a human factors review to ensure the interface displays facilitate ease of use and do not result in ambiguous information to plant personnel

5.15 Reliability Yes. IEEE 7-4.3.2 Section 5.15 provides additional requirements on reliability analysis

Generic FMEA and hardware reliability information for SPINLINE 3 modules/components will be provided as described in Sections 5.2.1 and 5.2.2.

System-level analyses must be performed on a plant-specific basis.

6 Sense and command features—functional and design requirements







platform


I&C applications

6.1 Automatic control The generic platform provides the capability for implementing automatic control of outputs based on inputs status.

Specific automatic controls are determined on a plant-specific basis.

6.2 Manual control However, the generic platform provides the capability to implement manual controls to actuate protective functions or ESF components.

Specific manual controls are determined on a plant-specific basis.

6.3 Interaction between the sense and command features and other systems

Conformance will be addressed on an NPP-specific basis.

6.4 Derivation of system inputs

Conformance will be addressed on an NPP-specific basis

6.5 Capability for testing and calibration


6.5.1 Checking the operational availability

Operational availability is confirmed via the self-diagnostic and periodic testing measured described in Section 4.6

6.5.2 Means of assuring the operational availability

Operational availability is confirmed via the self-diagnostic and periodic testing measured described in Section 4.6






platform


I&C applications

6.6 Operating bypasses The SPINLINE 3 platform has the capability to implement operating bypasses. [[

]]

The specific operating bypasses implemented in a SPINLINE 3 system are defined on a plant-specific basis.

6.7 Maintenance bypass The system architecture using the SPINLINE 3 platform will ensure that the safety function will be retained regardless of a maintenance bypass condition with the exception noted in clause 6.7.

The plant-specific system architecture will ensure that the safety function will be retained when a maintenance bypass is implemented. Plant-specific Technical Specifications govern the use of the maintenance bypass feature.

6.8 Setpoints Accuracy of modules included in the generic platform is defined in the "Setpoint Analysis Support Document." See Section 5.2

Actual setpoints will be established on a plant-specific basis.






platform


I&C applications

7 Execute features—functional and design requirements

No execute features in the generic platform

7.1 Automatic control NA

7.2 Manual control NA


NA

7.4 Operating bypass NA

7.5 Maintenance bypass NA

8 Power source requirements

8.1 Electrical power sources

Class 1E power is a required interface requirement for a SPINLINE 3 digital safety I&C system. The power interface requirements are provided in chapter 4.

The actual Class 1E power sources for a SPINLINE 3 digital safety I&C system will be specified in an NPP-specific application.

8.2 Non-electrical power sources

The SPINLINE 3 generic safety I&C platform does not require any non-electrical power sources.

8.3 Maintenance bypass NA


Table 3.8-3. Mapping SPINLINE 3 SQP MC3 and Other Content to IEEE 730-1998 SQAP Content Guidance

IEEE 730-1998 Guidance Where found in SPINLINE 3 generic platform software life cycle documentation

IEEE 730 Section

SQAP Section # Content Guidance Document Doc # Section # Document or Section Title Notes

SQP MC3 8 303 429 E 1 Purpose, Scope and Responsibilities

The MC3 SQP + the following software instructions also perform the functions of the SCMP and SVVP: (1) 1 207 875 A, "Software Configuration Management Process" [IL_Gest_Conf], and (2) 1 207 107 A/B/C, "Rules for Verification and Validation of Software Components." Later revisions of these instructions are applicable to current CM and V&V processes.

1 Project Overview This SDP supports the SQP MC3 with additional guidance for the MC3 project (for the original creation of SPINLINE 3). Some of the topics addressed in this SDP align with the SQAP content guidance in IEEE 730-1998.

4.1 1 Purpose: This section shall delineate the specific purpose and scope of the particular SQAP. It shall list the name(s) of the software items covered by the SQAP and the intended use of the software. It shall state the portion of the software life cycle covered by the SQAP for each software item specified.

SDP MC3 1 207 102 A

2 Description of the Project

2 Reference Documents and Applicable Documents

4.2 2 Referenced documents: This section shall provide a complete list of documents referenced elsewhere in the text of the SQAP

SQP MC3 8 303 429 E

9.3 Rules

4.3 3 Management: This section shall describe organization, tasks, and responsibilities

See 3.1 - 3.3 below


Table 3.8-3. Mapping SPINLINE 3 SQP MC3 and Other Content to IEEE 730-1998 SQAP Content Guidance IEEE 730-1998 Guidance Where found in SPINLINE 3 generic platform software life cycle documentation

IEEE 730 Section


4.3.1 3.1 Organization: This paragraph shall depict the organizational structure that influences and controls the quality of the software. This shall include a description of each major element of the organization together with the delegated responsibilities. Organizational dependence or independence of the elements responsible for SQA from those responsible for software development and use shall be clearly described or depicted

SQP MC3 8 303 429 E 4 Specific Organizational Structure Associated With Software Project

Refer to organization chart

5 Quality Control in the Design and Production of Software

SQP MC3 8 303 429 E

9.1 Methods Applied

4.3.2 3.2 Tasks: This paragraph shall describea) That portion of the software life cycle covered by the SQAP;b) The tasks to be performed with special emphasis on software quality assurance activities; andc) The relationships between these tasks and the planned major checkpoints.The sequence of the tasks shall be indicated.

SDP MC3 1 207 102 A 2 Description of the Project

4.3 Duties of Members of the Software Team

4.3.3 3.3 Responsibilities: This paragraph shall identify the specific organizational elements responsible for each task.

SQP MC3 8 303 429 E

7.4 & 8 Procedures for identification and entry into configuration; Management of changes to software and associated documentation

Software Project Manager is responsible for CM



IEEE 730 Section


SQP MC3 8 303 429 E 6 Project Documentation

Guide to writing documentation 1 207 139 Referenced in SQP MC3 §6

4.4 4 Documentation

Document and data control procedure Included in 8 303 186

Referenced in SQP MC3 §6.3

6.1 Project Management Documents Refer to table of document responsibilities (writing, checking, approval)

SQP MC3 8 303 429 E

6.2 Documents specific to each software item embedded on a unit

Refer to table of document responsibilities (writing, checking, approval)

4.4.1 4.1 Purpose: This section shall perform the following functions: a) Identify the documentation governing the development, verification and validation, use, and maintenance of the software. b) State how the documents are to be checked for adequacy. This shall include the criteria and the identification of the review or audit by which the adequacy of each document shall be confirmed, with reference to Section 6 of the SQAP.

Document drafting rules 1 207 103 Referenced in SQP MC3 §9.3

4.4.2 4.2 Minimum documentation requirements: To ensure that the implementation of the software satisfies requirements, the documentation in 4.4.2.1 through 4.4.2.6 is required as a minimum

SQP MC3 8 303 429 E 6.1 Project Management Documents



IEEE 730 Section


6.2 Software Specifications (SRS) 4.4.2.1 4.2.1 Software Requirements Specification (SRS): The SRS shall clearly and precisely describe each of the essential requirements (functions, performances, design constraints, and attributes) of the software and the external interfaces. Each requirement shall be defined such that its achievement is capable of being objectively verified and validated by a prescribed method (e.g., inspection, analysis, demonstration, or test)

SQP MC3 8 303 429 E

9.1.1 Specifications

6.2 Preliminary Software Design (PSD), Detailed Software Design (DSD), Preliminary & Detailed Software Design (PDSD), Software component description file (BF or SAF), Software Production File (SPF), Software Validation Test Analysis (SVTP), Software Validation Test Reports (SVTR)

SQP MC3 8 303 429 E

9.1.2 Preliminary Design and Detailed Design

4.4.2.2 4.2.2 Software Design Description (SDD): The SDD shall depict how the software will be structured to satisfy the requirements in the SRS. The SDD shall describe the components and subcomponents of the software design, including databases and internal interfaces. The SDD shall be prepared first as the Preliminary SDD (also referred to as the top-level SDD) and shall be subsequently expanded to produce the Detailed SDD

Interface Specifications - Operational System Software and Application

Software

1 207 110 J Not referenced in SQP MC3, but applicable.



IEEE 730 Section



SQP MC3 8 303 429 E

9.1.6 Software Validation

There is no separate SVVP. The SQP MC3, SVTP and subordinate V&V guidance documents perform the function of the SVVP.

SVTP 1 207 146 G Software Validation Test Plan (SVTP) - Operational System Software for Safety Class Units

SVTP is referenced in SQP MC3 §5.3, 6.2, 9.1 & 10.2.2.4

4.4.2.3 4.2.3 Software Verification and Validation Plan (SVVP): The SVVP shall identify and describe the methods (e.g., inspection, analysis, demonstration, or test) to be used toa1) Verify that the requirements in the SRS have been approved by an appropriate authority;a2) Verify that the requirements in the SRS are implemented in the design expressed in the SDD; anda3) Verify that the design expressed in the SDD is implemented in the code.b) Validate that the code, when executed, complies with the requirements expressed in the SRS

Rules for Verification/Validation of Software Components

1 207 107 A/B/C


4.4.2.4 4.2.4 Software Verification and Validation Report (SVVR): The SVVR shall describe the results of the execution of the SVVP.

SVTR 1 207 232 F Software Validation Test Report (SVTR) - Operational System Software for Safety Class Units

SVTR is referenced in SQP MC3 §5.3, 6.2, 9.1 & 10.2.2.4



IEEE 730 Section


4.4.2.5 4.2.5 User documentation: User documentation (e.g., manual, guide) shall specify and describe the required data and control inputs, input sequences, options, program limitations, and other activities or items necessary for successful execution of the software. All error messages shall be identified and corrective actions shall be described. A method of describing user identified errors or problems to the developer or the owner of the software shall be described. (Embedded software that has no direct user interaction has no need for user documentation and is therefore exempted from this requirement.)

SQP MC3 8 303 429 E 6.2 Software User Manual (SUM)

7 Configuration Management SQP MC3 8 303 429 E

8 Management of Changes to Software and Associated Documentation

CM is addressed in the MC3 SQP and supporting documents. There is no separate SCMP

Software Configuration Management Process [IL_Gest_Conf]

1 207 875 A Not referenced in MC3 SQP, but applicable

Upgrade management 8 303 197 Referenced in SQP MC3 §8

4.4.2.6 4.2.6 Software Configuration Management Plan (SCMP): The SCMP shall document methods to be used for identifying software items, controlling and implementing changes, and recording and reporting change implementation status

Software maintenance and changes 1 206 624 Referenced in SQP MC3 §8



IEEE 730 Section


SDP MC3 8 303 429 E

Design control 8 303 334 Referenced in SQP MC3 §9.3

General process for Software Development [IL_PROC_GEN]

1 208 079 A/B/C/D

Not referenced in MC3 SQP, but applicable

Development of safety class software 1 206 076 Referenced in SQP MC3 §9.3

Development of standard software 1 206 077 Referenced in SQP MC3 §9.3

4.4.3 4.3 Other: Other documentation may include the following: a) Software Development Plan; b) Standards and Procedures Manual; c) Software Project Management Plan; d) Software Maintenance Manual

Software Quality Assurance Handbook 8 303 670 Referenced in SQP MC3 §9.3


4.5 5 Standards, practices, conventions, and metrics

SQP MC3 8 303 429 E

9 Methods, Tools and Rules

2.1 Reference Documents

5.1 Procedure used for software development

Refer to the diagram for the software development life cycle

5.2 Development process for software incorporating HMIs

Refer to diagram showing the development cycle for software with HMI

4.5.1 5.1 Purpose: This section shalla) Identify the standards, practices, conventions, and metrics to be applied;b) State how compliance with these items is to be monitored and assured.

SQP MC3 8 303 429 E

9.3 Rules



IEEE 730 Section


5.3 Description of phases 1) Specification phase 2) Preliminary Design Phase 3) Detailed design phase 4) Production phase (coding and unit tests) 5) Integration phase 6) Validation phase 7) System tests

For each phase, identifies phase inputs, phase outputs and conditions for moving to the next phase

4.5.2 5.2 Content: The subjects covered shall include the basic technical, design, and programming activities involved, such as documentation, variable and module naming, programming, inspection, and testing

SQP MC3 8 303 429 E

10.3 Quality Monitoring Documentation

4.6 6 Reviews and audits SQP MC3 8 303 429 E 10 Quality Assurance Measures

SES Department Quality Assurance Manual

8 303 186 8.2.2 Internal audits Referenced in SQP MC3 §2.1 & 6.3. Now known as I&C France Quality Manual [PQM]

4.6.1 6.1 Purpose: This section shall a) Define the technical and managerial reviews and audits to be conducted; b) State how the reviews and audits are to be accomplished; c) State what further actions are required and how they are to be implemented and verified.

SQP MC3 8 303 429 E 10.1 Principles



IEEE 730 Section


10.2 Quality Actions Quality Actions, including:a) End of phase reviewsb) Document design reviews, including:- Software specification design review- Software preliminary design document review- Software detailed design document review- Software validation test documentation design reviewc) Document peer reviewd) Audits

4.6.2 6.2 Minimum requirements:a) Software Requirements Review (SRR)b) Preliminary Design Review (PDR)c) Critical Design Review (CDR)d) Software Verification and Validation Plan Review (SVVPR)e) Functional auditf) Physical auditg) In-process auditsh Managerial reviewsi) Software Configuration Management Plan Review (SCMPR)j) Post-mortem review

SQP MC3 8 303 429 E


4.6.3 6.3 Other: Other reviews and audits may include the user documentation review (UDR). This review is held to evaluate the adequacy (e.g., completeness, clarity, correctness, and usability) of user documentation.

SQP MC3 8 303 429 E 10.2.3 Documentation Peer Review

9.1.4 Unit tests on software components 4.7 7 Test: This section shall identify all the tests not included in the SVVP for the software covered by the SQAP and shall state the methods to be used

SQP MC3 8 303 429 E

9.1.5 Software integration tests



IEEE 730 Section



8 303 186 8.3 Control of nonconforming product Referenced in SQP MC3 §2.1 & 6.3. Now known as I&C France Quality Manual [PQM]

SQP MC3 8 303 429 E 1.2.5 Procedure in the event of failure to apply the SQP

4.8 8 Problem reporting and corrective action: This section shall a) Describe the practices and procedures to be followed for reporting, tracking, and resolving problems identified in both software items and the software development and maintenance process; b) State the specific organizational responsibilities concerned with their implementation.

Software maintenance and changes 1 206 624 Referenced in SQP MC3 §8

SQP MC3 8 303 429 E 9 Methods, Tools and Rules 4.9 9 Tools, techniques, and methodologies: This section shall identify the special software tools, techniques, and methodologies that support SQA, state their purposes, and describe their use

List of tools and libraries used by software

1 207 286 Referenced in SQP MC3 §9.2.2

SQP MC3 8 303 429 E 9.1.3 Coding

Software Instructions Handbook 8 303 670 Referenced in SQP MC3 §2.1

Rules for programming in C 1 207 106 Referenced in SQP MC3 §9.3

Defensive programming application rules

1 207 185 Referenced in SQP MC3 §9.3

Development environment organization


4.10 10 Code control: This section shall define the methods and facilities used to maintain, store, secure, and document controlled versions of the identified software during all phases of the software life cycle. This may be implemented in conjunction with a computer program library. This may be provided as a part of the SCMP. If so, an appropriate reference shall be made thereto

Basic and system access function management




IEEE 730 Section


4.11 11 Media control: This section shall state the methods and facilities to be used to a) Identify the media for each computer product and the documentation required to store the media, including the copy and restore process; and b) Protect computer program physical media from unauthorized access or inadvertent damage or degradation during all phases of the software life cycle. This may be provided as a part of the SCMP. If so, an appropriate reference shall be made thereto.

SQP MC3 8 303 429 E 11 Reproduction, Protection, Delivery



IEEE 730 Section


4.12 12 Supplier control: This section shall state the provisions for assuring that software provided by suppliers meets established requirements. In addition, this section shall state the methods that will be used to assure that the software supplier receives adequate and complete requirements. For previously developed software, this section shall state the methods to be used to assure the suitability of the product for use with the software items covered by the SQAP. For software that is to be developed, the supplier shall be required to prepare and implement an SQAP in accordance with this standard. This section shall also state the methods to be employed to assure that the developers comply with the requirements of this standard.


8 303 186 7.4 Purchasing Referenced in SQP MC3 §2.1 & 6.3. Now known as I&C France Quality Manual [PQM]


8 303 186 4.2 QMS Documents Referenced in SQP MC3 §2.1 & 6.3. Now known as I&C France Quality Manual [PQM]

1.2.4 Revision of the SQP

4.13 13 Records collection, maintenance, and retention: This section shall identify the SQA documentation to be retained; shall state the methods and facilities to be used to assemble, safeguard, and maintain this documentation; and shall designate the retention period.

SQP MC3 8 303 429 E




IEEE 730 Section



8 303 186 6.6.2 Competence, awareness and training

Referenced in SQP MC3 §2.1 & 6.3. Now known as I&C France Quality Manual [PQM]

4.14 14 Training: This section shall identify the training activities necessary to meet the needs of the SQAP

Training New Team Members 1 207 104 Referenced in SQP MC3 §9.3


8 303 186 4.2.4, 5.3, 7.0, 7.4.1,

7.5.5, 8.5.3,

Embedded in quality management system processes. No separate section on risk management.


4.15 15 Risk management: This section shall specify the methods and procedures employed to identify, assess, monitor, and control areas of risk arising during the portion of the software life cycle covered by the SQAP

SDP MC3 1 207 102 A 8 Risk Assessment

3 Terminology, Abbreviations and Acronyms

No counterpart in IEEE 730 SQP MC3 8 303 429 E

5.1, 5.2, 5.3.6, 9.1.6

Definition of V&V activities embedded in SQP processes


Table 3.8-4. Mapping SPINLINE 3 SMQP and Other Content to IEEE 730-1998 SQAP Content Guidance


IEEE 730 Section


SMQP 1 208 686 B 1.1 & 1.2 Purpose of Document; Scope of Application

This SMQP, document 1 208 686 B, is the standard SQAP that is used in connection with modifications to the generic SPINLINE 3 platform software. Modifications may be made on occasion to improve this platform software. This SQMP applies only to the modification phase of the software life cycle. When a modification is needed, a project-specific SDP provides the project-specific guidance for that modification effort. Modification of the platform software typically is not required for plant-specific SPINLINE 3 systems.

1.1 Origin and objectives of the project


Modification-specific SDPs for 2000 & 2001

modification projects

1 208 645 A and

1 208 908 A 1.2 Contract Clauses

Use of a separate SDP for each modification project is explained in SMQP §1.2.1

SMQP 1 208 686 B 2 Applicable Documents and Reference Documents




1 208 645 A and

1 208 908 A

1.3 Technical reference documents

Use of a separate SDP for each modification project is explained in SQMP §1.2.1

SMQP 1 208 686 B 5 Management of SPINLINE 3 Software Modification

4.3 3 Management: This section shall describe organization, tasks, and responsibilities

[IL_Gest_Proj] 1 208 055 E Software Project Management Process Instruction

Referenced in SQMP §5.1


Table 3.8-4. Mapping SPINLINE 3 SMQP and Other Content to IEEE 730-1998 SQAP Content Guidance IEEE 730-1998 Guidance Where found in SPINLINE 3 generic platform software life cycle documentation

IEEE 730 Section


SMQP 1 208 686 B 4 Organization


1 207 105 Referenced in SMQP §8.4




1 208 645 A and

1 208 908 A

5 Organization Use of a separate SDP for each modification project is explained in SQMP §1.2.1

1.2 Scope of Application SMQP 1 208 686 B

5.2 SPINLINE 3 Software Modification Process

Process flow charts provide an integrated view of the software modification process.

7 Standard development cycle for safety class software

Control of software design (safety systems)

[PRO_Concept_log_C]

8 303 350 L

8 Development of SPINLINE 3 type safety class software

Referenced in SMQP §5.2.1 & 8.1

[PRO_Concept_log_NC] 8 307 214 B Non safety software design process

Referenced in SQMP §5.2


2.1 Technical tree

2.2 Software development cycle retained

4.3.2 3.2 Tasks: This paragraph shall describea) That portion of the software life cycle covered by the SQAP;b) The tasks to be performed with special emphasis on software quality assurance activities; andc) The relationships between these tasks and the planned major checkpoints.The sequence of the tasks shall be indicated.



1 208 645 A and

1 208 908 A

2.3 Flowchart of tasks




IEEE 730 Section


1.3 Responsibilities and changes to Quality Plan

SMQP 1 208 686 B

4 Organization




1 208 645 A and

1 208 908 A

3.4 Management Activities Use of a separate SDP for each modification project is explained in SQMP §1.2.1

SMQP 1 208 686 B 6 Documentation

[Pro_Etab_Doc] 8 303 198 P Procedure: Establishment and application of engineering documents

Referenced in SMQP §6

4.4 4 Documentation

[Gest_Doc_Col_Ref] 8 303 638 B Documents and reference files management

Referenced in SMQP §6 & 10

SMQP 1 208 686 B 11.1.2 Document Control 4.4.1 4.1 Purpose: This section shall perform the following functions:a) Identify the documentation governing the development, verification and validation, use, and maintenance of the software.b) State how the documents are to be checked for adequacy. This shall include the criteria and the identification of the review or audit by which the adequacy of each document shall be confirmed, with reference to Section 6 of the SQAP.



1 208 645 A and

1 208 908 A

3.3.1 Document control Use of a separate SDP for each modification project is explained in SQMP §1.2.1



IEEE 730 Section



See 4.2.1 - 4.2.6 below. This SMQP applies to modification to the generic platform software and associated documentation.

SRS 1 207 108 J Software Requirement Specification - Operational

System Software

SRS may be updated in connection with the software modification. See SMQP §5.2.

4.4.2.1 4.2.1 Software Requirements Specification (SRS): The SRS shall clearly and precisely describe each of the essential requirements (functions, performances, design constraints, and attributes) of the software and the external interfaces. Each requirement shall be defined such that its achievement is capable of being objectively verified and validated by a prescribed method (e.g., inspection, analysis, demonstration, or test)

Interface Specifications - Operational System

Software and Application Software

1 207 110 J Not referenced in SMQP, but applicable.


SDD 1 207 141 H Software Preliminary Design - Core System Software

SDD or similar documents may be updated in connection with the software modification. See SMQP §5.2.



IEEE 730 Section


8.2.4 Unit tests of software components (includes Static Code Analysis & Functional Validation)


SMQP 1 208 686 B

11.1.1 Phase reviews

There is no separate SVVP. This SMQP, SVTP and subordinate V&V guidance documents perform the function of the SVVP.


SVTP is referenced in SMQP §8.2.6. SVTP may be updated in connection with the software modification.


[PRO_Concept_log_C]

8 303 350 L 6.4 Verification & validation process


Rules for Verification & Validation of software

components

1 207 107 D Referenced in SMQP §8.4

4.4.2.3 4.2.3 Software Verification and Validation Plan (SVVP): The SVVP shall identify and describe the methods (e.g., inspection, analysis, demonstration, or test) to be used to a1) Verify that the requirements in the SRS have been approved by an appropriate authority; a2) Verify that the requirements in the SRS are implemented in the design expressed in the SDD; and a3) Verify that the design expressed in the SDD is implemented in the code. b) Validate that the code, when executed, complies with the requirements expressed in the SRS

[PGCL_SPINLINE 3] 1 208 878 E SPINLINE 3 Software Configuration Management Plan

Referenced in SMQP §7. This SCMP may be updated in connection with the software modification. See SMQP §5.2.


SVTR 1 207 232 F Software Validation Test Report (SVTR) - Operational System Software for Safety Class Units

SVTR is referenced in SMQP §8.2.6. SVTR may be updated in connection with the software modification.



IEEE 730 Section



Software User Manual (SUM) already exists

User documents may be updated in connection with the software modification. See SMQP §5.2.

SMQP 1 208 686 B 7 Configuration Management Invokes CM process in [IL_Gest_Conf] and [PGCL_SPINLINE 3]




[PRO_Concept_log_C]

8 303 350 L 6.9 Configuration management process


Configuration Management Process [IL_Gest_Conf].

1 207 875 G Referenced in SMQP §7




1 208 645 A and

1 208 908 A

3.5 Configuration management activities and changes




IEEE 730 Section





1 208 645 A and

1 208 908 A


4.5 5 Standards, practices, conventions, and metrics

SMQP 1 208 686 B 8 Methods, Tools and Rules Also see Tools, techniques, and methodologies

4.5.1 5.1 Purpose: This section shall a) Identify the standards, practices, conventions, and metrics to be applied; b) State how compliance with these items is to be monitored and assured.

See 5.2 below


[PRO_Concept_log_C]

8 303 350 L Safety software design process

Referenced in SMQP §5.2 & 8.1



[LOBUL_SL3] 1 207 286 List of Tools and Libraries used for the Software - SPINLINE 3


7.2 Identify configuration Configuration Management Process [IL_Gest_Conf].

1 207 875 G

Appendix 1 Identification rules


4.5.2 5.2 Content: The subjects covered shall include the basic technical, design, and programming activities involved, such as documentation, variable and module naming, programming, inspection, and testing


components

1 207 107 D Referenced in SMQP §8



IEEE 730 Section




Basic functions and system access functions

management


3 Rules, Methods and Tools

3.1 Development activities

3.2 Test Activities



1 208 645 A and

1 208 908 A

3.3 Control Activities


4.6 6 Reviews and audits See 4.6.1 - 4.6.3 below

I&C France Quality Manual [PQM]

8 303 186 P 8.2.2 Internal audits Not referenced in SMQP, but applicable.

4.6.1 6.1 Purpose: This section shall a) Define the technical and managerial reviews and audits to be conducted; b) State how the reviews and audits are to be accomplished; c) State what further actions are required and how they are to be implemented and verified.

SMQP 1 208 686 B 11 Monitoring Application of the Quality Plan



IEEE 730 Section


SMQP 1 208 686 B 11.1 Quality Actions: Typical Quality Assurance actions are:− Phase reviews,− Document control� document reviews,� peer reviews,− Regular monitoring of the Quality File.

4.6.2 6.2 Minimum requirements:a) Software Requirements Review (SRR)b) Preliminary Design Review (PDR)c) Critical Design Review (CDR)d) Software Verification and Validation Plan Review (SVVPR)e) Functional auditf) Physical auditg) In-process auditsh Managerial reviewsi) Software Configuration Management Plan Review (SCMPR)j) Post-mortem review



1 208 645 A and

1 208 908 A

3.3.2 Audits Use of a separate SDP for each modification project is explained in SQMP §1.2.1




8.2.4 Unit tests on software components

SMQP 1 208 686 B

8.2.5 Software integration tests



1 208 645 A and

1 208 908 A

3.2 Test Activities Use of a separate SDP for each modification project is explained in SQMP §1.2.1


components

1 207 107 D Referenced in SMQP §8

4.7 7 Test: This section shall identify all the tests not included in the SVVP for the software covered by the SQAP and shall state the methods to be used

SITR 1 207 204 E Software Integration Test Plan and Report (SITR) - SCC (Core System Software)

SIT is described in SMQP §6.2.5



IEEE 730 Section



8 303 186 P 8.3 Control of nonconforming product

Not referenced in SMQP, but applicable.


1 207 875 G 7.3.1 Record (Non-conformity report)


4.8 8 Problem reporting and corrective action: This section shall a) Describe the practices and procedures to be followed for reporting, tracking, and resolving problems identified in both software items and the software development and maintenance process; b) State the specific organizational responsibilities concerned with their implementation.


components

1 207 107 D 11 Change report Referenced in SMQP §8

4.9 9 Tools, techniques, and methodologies: This section shall identify the special software tools, techniques, and methodologies that support SQA, state their purposes, and describe their use

SMQP 1 208 686 B 8 Methods, Tools and Rules See details above, mapped to "Standards, practices, conventions, and metrics"

5.2.1 Upgrade campaign control process

5.2.2 Process for upgrading and technical management of a SPINLINE 3 software component

8.2.3 Coding

SMQP 1 208 686 B

8.4 Rules



[PRO_Concept_log_C]

8 303 350 L








IEEE 730 Section


[LOBUL_SL3] 1 207 286 List of Tools and Libraries used for the Software - SPINLINE 3


Basic functions and system access functions

management


SMQP 1 208 686 B 10 Reproduction, Protection, Delivery

This section of the SMQP also addresses document control.

4.11 11 Media control: This section shall state the methods and facilities to be used to a) Identify the media for each computer product and the documentation required to store the media, including the copy and restore process; and b) Protect computer program physical media from unauthorized access or inadvertent damage or degradation during all phases of the software life cycle. This may be provided as a part of the SCMP. If so, an appropriate reference shall be made thereto.

[Reg_SLI] 1 204 971 G Information Technology Support functioning rules




IEEE 730 Section



8 303 186 P 7.4 Purchasing Not referenced in SMQP, but applicable.

SMQP 1 208 686 B 9 Monitoring Suppliers There are no subcontractors

[IL_Outils] 1 206 747 E Software Instruction: Requirements on software development tools

Referenced in SMQP §9.2

4.12 12 Supplier control: This section shall state the provisions for assuring that software provided by suppliers meets established requirements. In addition, this section shall state the methods that will be used to assure that the software supplier receives adequate and complete requirements. For previously developed software, this section shall state the methods to be used to assure the suitability of the product for use with the software items covered by the SQAP. For software that is to be developed, the supplier shall be required to prepare and implement an SQAP in accordance with this standard. This section shall also state the methods to be employed to assure that the developers comply with the requirements of this standard.

[IL_Ctrl_log_Ext] 8 303 671 B Software Instruction: External software reception control



8 303 186 P 4.2 QMS Documents Not referenced in SMQP, but applicable.

10 Reproduction, Protection, Delivery

SMQP 1 208 686 B

11.3 Quality-related records


Referenced in SMQP §6 & 10

[Reg_SLI] 1 204 971 Referenced in SMQP §2


[Mait_Enr] 8 303 320 L Procedure: Control of records Referenced in SMQP §10



IEEE 730 Section



8 303 186 P 6.6.2 Competence, awareness and training


[IL_Plan_Form_VV] 1 208 210 C Software Guideline: Software V&V Team Training Plan


5 Reference documents (references 1 208 210, "Software instruction – Software V&V Team Training Plan"

6.7 Sub-contract management process


[PRO_Concept_log_C]

8 303 350 L

7.2.3 Software development plan (references SDP as the location of training requirements)






8 303 186 P 4.2.4, 5.3, 7.0, 7.4.1,

7.5.5, 8.5.3,






1 208 645 A and

1 208 908 A

8 Risk Analysis Use of a separate SDP for each modification project is explained in SQMP §1.2.1



IEEE 730 Section


3 Terminology and Abbreviations

5.1 Budget and schedule control Invokes process in [IL_Gest_Proj]

SMQP 1 208 686 B

11.2 Scheduling Quality Assurance actions

4 Means (Resources)

4.1 Material means

4.2 Software means

4.3 Human means

9.1 Planning

No counterpart in IEEE 730



1 208 645 A and

1 208 908 A

9.2 Table of costs



Table 3.8-5. Mapping SPINLINE 3 Application SQAP and Other Content to IEEE 730-1998 SQAP Content Guidance


IEEE 730 Section



SQAP 8 307 208 B 1.1 & 1.2 Purpose Note that SQAP, document 8 307 208 B, is a generic template that establishes the framework for completing the SQAP for plant-specific application software that will interface with the SPINLINE 3 generic platform software.


SQAP 8 307 208 B 2 Reference Documents

SQAP 8 307 208 B 3 Management 4.3 3 Management: This section shall describe organization, tasks, and responsibilities

[IL_Gest_Proj] 1 208 055 E Software Project Management Process Instruction



SQAP 8 307 208 B 3.1 Organization


Table 3.8-5. Mapping SPINLINE 3 Application SQAP and Other Content to IEEE 730-1998 SQAP Content Guidance IEEE 730-1998 Guidance Where found in SPINLINE 3 generic platform software life cycle documentation

IEEE 730 Section


3.2 Tasks

3.2.1 Software life Cycle Overview Figure provides an integrated view of software activities in each life cycle phase

3.2.1.1 Document Relationship in the Software Life Cycle

Figure provides an integrated view input and output documents in each life cycle phase

3.2.2 Software Management Activities

3.2.3 Software Development Activities

3.2.4 Software Safety and Security Activities

3.2.5 Software Verification and Validation Activities

3.2.6 Software Configuration Management Activities

4.3.2 3.2 Tasks: This paragraph shall describe a) That portion of the software life cycle covered by the SQAP; b) The tasks to be performed with special emphasis on software quality assurance activities; and c) The relationships between these tasks and the planned major checkpoints. The sequence of the tasks shall be indicated.

SQAP 8 307 208 B

3.2.7 Software Quality Assurance Activities

1.4 Creation and Update of the SQAP

3.1, 3.3 Organization; Responsibilities


SQAP 8 307 208 B

4.8 Summary of Engineering Documents and Associated Responsibilities



IEEE 730 Section


4 Documentation 4.4 4 Documentation SQAP 8 307 208 B


4.1 Introduction 4.4.1 4.1 Purpose: This section shall perform the following functions: a) Identify the documentation governing the development, verification and validation, use, and maintenance of the software. b) State how the documents are to be checked for adequacy. This shall include the criteria and the identification of the review or audit by which the adequacy of each document shall be confirmed, with reference to Section 6 of the SQAP.

SQAP 8 307 208 B



SQAP 8 307 208 B 4.2 to 4.8

SQAP 8 307 208 B 4.3 Software Requirements Specification (SRS)

4.4.2.1 4.2.1 Software Requirements Specification (SRS): The SRS shall clearly and precisely describe each of the essential requirements (functions, performances, design constraints, and attributes) of the software and the external interfaces. Each requirement shall be defined such that its achievement is capable of being objectively verified and validated by a prescribed method (e.g., inspection, analysis, demonstration, or test)

[IL_GD_CCL] 1 207 854 B Software Guideline: SRS Documentation Guideline

Referenced in SQAP §2



IEEE 730 Section



SQAP 8 307 208 B 4.3 Software Design Description (SDD)

4.4, 4.5 Software Verification and Validation Plan (SVVP)

Software Validation Test Plan (SVTP)

Software Validation Test Plan and Report (SVTPR)

4.4.2.3 4.2.3 Software Verification and Validation Plan (SVVP): The SVVP shall identify and describe the methods (e.g., inspection, analysis, demonstration, or test) to be used toa1) Verify that the requirements in the SRS have been approved by an appropriate authority;a2) Verify that the requirements in the SRS are implemented in the design expressed in the SDD; anda3) Verify that the design expressed in the SDD is implemented in the code.b) Validate that the code, when executed, complies with the requirements expressed in the SRS

SQAP 8 307 208 B

4.5

Software Integration Test Plan and Report (SITPR)

Verification and Validation Documents, listed below:

Verification Report

Software Validation Test Report (SVTR)

Software Validation Test Plan and Report (SVTPR)


SQAP 8 307 208 B 4.5

Software Integration Test Plan and Report (SITPR)



IEEE 730 Section


Software Component Test Description and Report

V&V Final Report (VVFR)


SQAP 8 307 208 B 4.3 Software User Documentation

Configuration Management Documents, listed below:

Software Configuration Management Plan (SCMP)

List of Software Documents (LSD)

Software Manufacturing File (SMF)

Software Configuration Management Report (SCMR)


SQAP 8 307 208 B 4.6

Configuration Management Final Report (CMFR)



IEEE 730 Section


Software Development Plan (SDP)

4.2

Software Project Tracking File (SPTF)

Network Design Description (NDD)

Software Component Specification

4.3

Source Code


SQAP 8 307 208 B

4.7 Quality Assurance Documents

4.5 5 Standards, practices, conventions, and metrics SQAP 8 307 208 B 5 Standards, practices, conventions, and metrics

5.1 Purpose: This section shalla) Identify the standards, practices, conventions, and metrics to be applied;b) State how compliance with these items is to be monitored and assured.

See 5.2 below


[PRO_Concept_log_C]

8 303 350 L Various Referenced in SQAP §6

[PRO_Concept_Log_NC] 8 307 214 B Non Safety Software Design Process


Configuration Management Process

[IL_Gest_Conf].

1 207 875 G Various Referenced in SQAP §2 & 5

4.5.1

5.2 Content: The subjects covered shall include the basic technical, design, and programming activities involved, such as documentation, variable and module naming, programming, inspection, and testing

[SDP] 8 307 211 B SPINLINE 3 Software Development Plan - SDP

Referenced in SQAP §2, 4.2 & 5



IEEE 730 Section


[IL_Spec_IHM] 1 208 592 B Software Guideline: Human-Machine Interface specification process

Referenced in SQAP §2 & 5

[IL_SCADE] 1 208 250 E Software Guideline: SCADE Design Rules


[IL_Prog_C] 1 208 954 C Software Guideline: C programming rules: synthesis


[IL_Prog_Def] 1 208 605 C Defensive programming application rules

Not referenced but applicable

[SVVP] 8 307 210 B SPINLINE 3 Software Verification and Validation Plan - SVVP


[SCMP] 8 307 209 B SPINLINE 3 Software Configuration Management Plan - SCMP

Referenced in SQAP §2, 9 & 10

[IL_GD_Intro] 1 207 853 E Software Guideline : Documentation Guidelines


[IL_Vérif_Doc] 1 207 947 E Software Guideline: Software Document Evaluation Process


[IL_Proc_Qual] 8 303 634 D Software Guideline: Software Quality Assurance Process


[IL_Ctrl_Log-Ext] 8 303 671 B Software Guideline: Requirements for commercial software


[IL_Outils] 1 206 747 E Software Guideline: Requirements on tools used for software development


4.6 6 Reviews and audits SQAP 8 307 208 B 6 Reviews and audits



IEEE 730 Section


I&C France Quality Manual [PMQ]

8 303 186 P 8.2.2 Internal audits Referenced in SQAP §2. 4.6.1 6.1 Purpose: This section shall a) Define the technical and managerial reviews and audits to be conducted; b) State how the reviews and audits are to be accomplished; c) State what further actions are required and how they are to be implemented and verified.

SQAP 8 307 208 B 6 Reviews and audits

Management reviews

End of phase reviews Document reviews Audits

SQAP 8 307 208 B 6

External audits Control of software design

(safety systems) [PRO_Concept_log_C]

8 303 350 L Various Referenced in SQAP §6

[PRO_Concept_Log_NC] 8 307 214 B Non Safety Software Design Process


4.6.2 6.2 Minimum requirements: a) Software Requirements Review (SRR) b) Preliminary Design Review (PDR) c) Critical Design Review (CDR) d) Software Verification and Validation Plan Review (SVVPR) e) Functional audit f) Physical audit g) In-process audits h Managerial reviews i) Software Configuration Management Plan Review (SCMPR) j) Post-mortem review

[IL_Proc_Qual] 8 303 634 D Software Guideline: Software Quality Assurance Process



Software Guideline: Software Document Evaluation Process

[IL_Verif_Doc]

1 207 947 E Referenced in SQAP §6



IEEE 730 Section


SQAP 8 307 208 B 7 Testing Activities

SVVP 8 307 210 B SPINLINE 3 Software Verification and Validation Plan - SVVP


4.7 7 Test: This section shall identify all the tests not included in the SVVP for the software covered by the SQAP and shall state the methods to be used

[IL_Plan_Test] 1 208 304 A Software Guideline: Software Test Plan




Referenced in SQAP §2.

SQAP 8 307 208 B 8 Problem reporting and corrective action

SCMP 8 307 209 B 5.3 SPINLINE 3 Software Configuration Management Plan - SCMP

Referenced in SQAP §2, 8, 9 & 10

4.8 8 Problem reporting and corrective action: This section shalla) Describe the practices and procedures to be followed for reporting, tracking, and resolving problems identified in both software items and the software development and maintenance process;b) State the specific organizational responsibilities concerned with their implementation.

SVVP 8 307 210 B 5.1, 6.1 SPINLINE 3 Software Verification and Validation Plan - SVVP


4.9 9 Tools, techniques, and methodologies: This section shall identify the special software tools, techniques, and methodologies that support SQA, state their purposes, and describe their use

SQAP 8 307 208 B 9 Tools, techniques, and methodologies


SCMP 8 307 210 B 4.5 SPINLINE 3 Software Verification and Validation Plan - SVVP




IEEE 730 Section


SQAP 8 307 208 B 10 Media control 4.11 11 Media control: This section shall state the methods and facilities to be used to a) Identify the media for each computer product and the documentation required to store the media, including the copy and restore process; and b) Protect computer program physical media from unauthorized access or inadvertent damage or degradation during all phases of the software life cycle. This may be provided as a part of the SCMP. If so, an appropriate reference shall be made thereto.

SCMP 8 307 209 B SPINLINE 3 Software Configuration Management Plan - SCMP



8 303 186 P 7.4 Purchasing Referenced in SQAP §2. 4.12 12 Supplier control: This section shall state the provisions for assuring that software provided by suppliers meets established requirements. In addition, this section shall state the methods that will be used to assure that the software supplier receives adequate and complete requirements. For previously developed software, this section shall state the methods to be used to assure the suitability of the product for use with the software items covered by the SQAP. For software that is to be developed, the supplier shall be required to prepare and implement an SQAP in accordance with this standard. This section shall also state the methods to be employed to assure that the developers comply with the requirements of this standard.

SQAP 8 307 208 B 11 Supplier control


8 303 186 P 4.2 QMS Documents Referenced in SQAP §2.

1.4 Creation and Update of the SQAP

SQAP 8 307 208 B

12 Records collection, maintenance, and retention


SCMP 8 307 209 B 6.5 Archiving Referenced in SQAP §12.



IEEE 730 Section



8 303 186 P 6.2.2 Competence, awareness and training


SQAP 8 307 208 B 13 Training





8 303 186 P 4.2.4, 5.3, 7.0, 7.4.1,

7.5.5, 8.5.3



SQAP 8 307 208 B 14 Risk Management


[IL_Gest_Proj] 1 208 055 E Software Guideline: Software Management Process


1.2 Relationship of this SQAP to the Plans Defined in BTP 7-14

No counterpart in IEEE 730 SQAP 8 307 208 B

1.3 Definitions and Abbreviations



IEEE 828-1998 Guidance Where found in SPINLINE 3 software life cycle documentation

IEEE 828 Section

SCMP Section # Content Guidance Document Doc # Section # Document or Section Title Notes

SQP MC3 8 303 429 E 1 Purpose, Scope and Responsibilities

There is no separate SCMP. The SQP MC3, supplemented by software instruction 1 207 875 A, "Software Configuration Management Process" [IL_Gest_Conf], performs the function of the SCMP. A later revision of this instruction is applicable to current CM processes.

1 Project Overview SDP MC3 1 207 102 A


4.1 1 Introduction: Describes the Plan's purpose, scope of application, key terms, and references

List of tools and libraries used by software

1 207 286 Referenced in SQP MC3 §9.2.2

SQP MC3 8 303 429 E 7.1 Purpose of Configuration Management (see SCM responsibilities below)

4.2 2 SCM management: (Who?) Identifies the responsibilities and authorities for accomplishing the planned activities

Software Configuration Management Process

[IL_Gest_Conf]


4.2.1 2.1 Organization: The organizational context, both technical and managerial, within which the planned SCM activities are to be implemented shall be described.

SQP MC3 8 303 429 E 4 Specific organizational structure associated with the software project




IEEE 828 Section


4.3 Duties of Members of the Software Team

4.2.2 2.2 SCM responsibilities: The allocation of SCM activities to organizational units shall be specified.

SQP MC3 8 303 429 E

7.4 & 8 Procedures for identification and entry into configuration; Management of changes to software and associated documentation

Software Project Manager is responsible for CM

SQP MC3 8 303 429 E 2 Reference Documents and Applicable Documents

Guide to writing documentation

1 207 139 No Referenced in SQP MC3 §6

4.2.3 2.3 Applicable policies, directives, and procedures: Any external constraints placed on the Plan by other policies, directives, and procedures shall be identified. For each, its impact and effect on the Plan shall be stated.

Document drafting rules 1 207 103 No Referenced in SQP MC3 §9.3

7 Configuration management SQP MC3 8 303 429 E

8 Management of changes to software and associated documentation

4.3 3 SCM activities: (What?) Identifies all activities to be performed in applying to the project


[IL_Gest_Conf]


7.2 Configuration Elements

7.3 Identification of Elements

4.3.1 3.1 Configuration identification: The Plan shall identify the project configuration items (CI) and their structures at each project control point. The Plan shall state how each CI and its versions are to be uniquely named and describe the activities performed to define, track, store, and retrieve CIs.

SQP MC3 8 303 429 E

7.4 Procedure for Identification and Entry Into Configuration




IEEE 828 Section


List of documents for the CSS

1 207 269

List of documents for the CD_LDU

1 207 282

List of documents for the BF 1 207 148

Software Configuration Management Report for the

CSS

1 207 257


BF

1 207 277


CD_LDU

1 207 283

These documents contain the results of configuration identification for the elements of the OSS.

SQP MC3 8 303 429 E 8 Management of changes to software and associated documentation

Document and data control 8 303 186 No Referenced in SQP MC3 §6.3

Upgrade management 8 303 197 No Referenced in SQP MC3 §8

4.3.2 3.2 Configuration control: Activities include request, evaluate, approve or disapprove, and implement changes to baselined CIs. Changes encompass both error correction and enhancement

Software maintenance and changes

1 206 624 No Referenced in SQP MC3 §8




IEEE 828 Section


4.3.3 3.3 Configuration status accounting: Configuration status accounting activities record and report the status of project CIs

SQP MC3 8 303 429 E 10.3 Quality Monitoring Documentation

10 Quality assurance measures

10.2.1 End-of-phase reviews

10.2.2 Document design reviews

10.2.3 Document peer reviews

4.3.4 3.4 Configuration audits and reviews: Configuration audits determine to what extent the actual CI reflects the required physical and functional characteristics. Configuration reviews are management tools for establishing a baseline.

SQP MC3 8 303 429 E

10.2.4 Audits



1 207 110 J Not referenced in SQP, but applicable.

4.3.5 3.5 Interface control: Interface control activities coordinate changes to the project CIs with changes to interfacing items outside the scope of the Plan. Hardware, system software and support software, as well as other projects and deliverables, should be examined for potential interfacing effects on the project. SQP MC3 8 303 429 E 4.3 Duties of members of the software

team Project Manager was responsible for coordination of work performed by the project partners

4.3.6 3.6 Subcontractor/vendor control: Subcontractor/vendor control activities incorporate items developed outside the project environment into the project CIs. Included are software developed by contract and software acquired in its finished form.


8 303 186 7.4 Purchasing Referenced in SQP MC3 §2.1 & 6.3. Now known as I&C France Quality Manual [PQM]

3.4 Cost and schedule management SDP MC3 1 207 102 A

6 Planning

It is Rolls-Royce practice to put schedule details in the SDP for each project.

4.4 4 SCM schedules: (When?) Identifies the required coordination of SCM activities with the other activities in the project


[IL_Gest_Conf]





IEEE 828 Section


4.5 5 SCM resources: (How?) Identifies tools and physical and human resources required for execution of the Plan

SDP MC3 1 207 102 A 4 Resources to be deployed It is Rolls-Royce practice to put resource details in the SDP for each project.

4.6 6 SCM plan maintenance: Identifies how the Plan will be kept current while in effect


8 303 186 Document and Data Control Referenced in SQP MC3 §2.1 & 6.3. Now known as I&C France Quality Manual [PQM]

No counterpart in IEEE 828 None




IEEE 828 Section



SCMP [PGCL_SPINLINE 3]

1 208 878 E 1 Introduction This SCMP, document 1 208 878 E, is used in connection with modifications to the generic SPINLINE 3 platform software. Modifications may be made on occasion to improve this platform software. This SCMP applies only to the modification phase of the software life cycle. When a modification is needed, this SCMP provides the project-specific guidance for that modification effort. Modification of the platform software typically is not required for plant-specific SPINLINE 3 systems.


1 208 878 E 2.1 Duties and responsibilities 4.2 2 SCM management: (Who?) Identifies the responsibilities and authorities for accomplishing the planned activities


[IL_Gest_Conf].

1 207 875 G 6 Duties and responsibilities Referenced in SCMP §2.1 & 2.9





Modification-specific SDPs for 2000 & 2001 modification projects

1 208 645 A and 1 208 908 A





IEEE 828 Section


1.3 Responsibilities and changes to Quality Plan

SMQP 1 208 686 B

4 Organization


1 208 645 A and 1 208 908 A




1 208 878 E 2.1 Duties and responsibilities



[IL_Gest_Conf].

1 207 875 G 6 Duties and responsibilities Referenced in SCMP §2.1 & 2.9

1.4 Reference documents

3 Tools, Techniques, and Methodology


1 208 878 E

3.1 Principle applied to the organization of development spaces

Invokes process in [IT_SL3_Env_Dev]


[IT_SL3_Env_Dev] 1 207 105 D SPINLINE 3 technical instruction: Description of development environments

Referenced in SCMP §3.1

2.4 Elements managed SCMP [PGCL_SPINLINE 3]

1 208 878 E

3.2 Configuration administration

4.3 3 SCM activities: (What?) Identifies all activities to be performed in applying to the project


1 208 645 A and 1 208 908 A






IEEE 828 Section


2.3 Configuration breakdown Refer to tree diagram of configuration breakdown

2.6 Reference configuration


1 208 878 E

3.1 Principle applied to the organization of development spaces


[IL_Gest_Conf].

1 207 875 G 7.2 Identify Configuration Referenced in SCMP §2.1 & 2.9

List of documents for the CSS

1 207 269

List of documents for the CD_LDU

1 207 282

List of documents for the BF

1 207 148

Software Configuration Management report for

the CSS

1 207 257


the BF

1 207 277



the CD_LDU

1 207 283

These documents contain the results of configuration identification for the elements of the OSS.




IEEE 828 Section


SMQP 1 208 686 B 7 Configuration Management

2.4 Elements managed

2.5 Control levels

2.8 Managing modifications

2.10 Configuration control Invokes process in [IL_Gest_Conf]

3.3 Procedure for changing a FICHIER_1E type file


1 208 878 E

3.4 Work spaces under Unix for verification and unit tests



[IL_Gest_Conf].

1 207 875 G 7.3 Control Changes Referenced in SCMP §2.1 & 2.9



1 208 878 E 2.9 Monitoring the configuration


SMQP 1 208 686 B 11.1 Quality Actions: Typical Quality Assurance actions are: − Phase reviews, − Document control � document reviews, � peer reviews, − Regular monitoring of the Quality File.




IEEE 828 Section



1 208 878 E 2.4 Elements managed

4.3.5 3.5 Interface control: Interface control activities coordinate changes to the project CIs with changes to interfacing items outside the scope of the Plan. Hardware, system software and support software, as well as other projects and deliverables, should be examined for potential interfacing effects on the project.



1 207 110 J Not referenced in SCMP, but applicable.

SMQP 1 208 686 B 9 Monitoring Suppliers 4.3.6 3.6 Subcontractor/vendor control: Subcontractor/vendor control activities incorporate items developed outside the project environment into the project CIs. Included are software developed by contract and software acquired in its finished form.

[IL_Ctrl_log_Ext] 8 303 671 B Software Instruction: External software reception control

Not referenced in SCMP, but applicable. Referenced in SMQP §9.2

4.4 4 SCM schedules: (When?) Identifies the required coordination of SCM activities with the other activities in the project


1 208 645 A and 1 208 908 A

6 Schedule It is Rolls-Royce practice to put schedule details in the SDP for each project. Use of a separate SDP for each modification project is explained in SQMP §1.2.1


1 208 645 A and 1 208 908 A

4 Means It is Rolls-Royce practice to put resource details in the SDP for each project. Use of a separate SDP for each modification project is explained in SQMP §1.2.1


[For_Gcf] Configuration management tool training document

Referenced in SCMP §2.5, 2.6




IEEE 828 Section



[Gest_Doc_Col_Ref] 8 303 638 B No Documents and reference files management

Not referenced in SCMP, but applicable. Referenced in SMQP §6 & 10

No counterpart in IEEE 828 SCMP 1 208 878 E 2.7 Archives




IEEE 828 Section


1.1 Purpose SCMP 8 307 209 B

2 Reference documents

Note that SCMP, document 8 307 209 B, is a generic template that establishes the framework for completing the SCMP for plant-specific application software that will interface with the SPINLINE 3 generic platform software.

2 Scope



1 207 875 G

4 Introduction

Referenced in SCMP §3.3, 4.1, 5 & 6.

3 Management Activities 4.2 2 SCM management: (Who?) Identifies the responsibilities and authorities for accomplishing the planned activities

SCMP 8 307 209 B

5.1 Management of SCM activity Figure provides an integrated view of configuration management activities in each life cycle phase


SCMP 8 307 209 B 3.1 Organization

1.4 Creation and Update of the SCMP

3.2 Responsibilities

SCMP 8 307 209 B

5.1 Management of SCM activity Figure provides an integrated view of configuration management activities in each life cycle phase



1 207 875 G 6 Duties and responsibilities Referenced in SCMP §3.3, 4.1, 5 & 6.




IEEE 828 Section


2 Reference documents

3.3 Applicable policies, directives, and procedures:

SCMP 8 307 209 B

6.4 Principles of development organization


1 207 875 G 3 Reference documents Referenced in SCMP §3.3, 4.1, 5 & 6.


[PRO_Concept_log_C]

8 303 350 L Referenced in SCMP §3.3

[PRO_Concept_log_NC] 8 307 214 B Non Safety Software Design Process


[DSS_PEV] 8 303 197 K Definition of the Change Management Process

Referenced in SCMP §3.3 & 5.3


[Reg_SLI] 1 204 971 G Operating Rules of the Computer Center


SCMP 8 307 209 B 4 SCM activities 4.3 3 SCM activities: (What?) Identifies all activities to be performed in applying to the project


1 207 875 G 5 Process characteristics Referenced in SCMP §3.3, 4.1, 5 & 6.




IEEE 828 Section


4.1 Configuration identification SCMP 8 307 209 B

5.2 Configuration identification

7.2 Identify configuration Configuration Management Process [IL_Gest_Conf].

1 207 875 G

Appendix 1 Identification rules

Referenced in SCMP §3.3, 4.1, 5 & 6. Configuration Items are managed according to the three levels of control

[Help_DIMENSIONS] CD-DIMDOC-012

ChangeMan DIMENSIONS user guide

Referenced in SCMP §2, 4.1, 4.3, 6.5


[CLARISSE_SUD] 8 002 800 C CLARISSE SSDE user guide Referenced in SCMP §4.1 & 6.

4.2 Configuration control

5.3 Configuration control

SCMP 8 307 209 B

6.3 Change management


1 207 875 G 7.3 Control changes Referenced in SCMP §3.3, 4.1, 5 & 6.

[DSS_PEV] 8 303 197 K Definition of the Change Management Process

Referenced in SCMP §3.3 & 5.3








IEEE 828 Section


4.3 Configuration status accounting

5.4 Configuration status accounting

SCMP 8 307 209 B

6.3.4 Configuration Tracking

7.4 Track the configuration Configuration Management Process [IL_Gest_Conf].

1 207 875 G

7.6 Performm configuration administration tasks






4.4 Configuration audits and reviews

5.1.2 Management Review of SCM

5.1.3 Configuration Audit Support

SCMP 8 307 209 B

5.1.4 Configuration Review Support



1 207 875 G 7.5 Check the configuration Referenced in SCMP §3.3, 4.1, 5 & 6.

4.5 Interface control SCMP 8 307 209 B

5.5 Interface control

4.3.5 3.5 Interface control: Interface control activities coordinate changes to the project CIs with changes to interfacing items outside the scope of the Plan. Hardware, system software and support software, as well as other projects and deliverables, should be examined for potential interfacing effects on the project.

Interface Specifications 1 207 110 J Interface Specifications - Operational System Software and Application Software

Not referenced in SCMP




IEEE 828 Section



8 303 186 P 7.4 Purchasing Referenced in SCMP §2.

4.5.2 Interface Between Rolls-Royce and External Companies: Company_X

4.6 Subcontractor/Vendor Control

5.5.2 Interface Between Rolls-Royce and External Companies: Company_X

SCMP 8 307 209 B

5.6 Subcontractor/Vendor Control

4.3.6 3.6 Subcontractor/vendor control: Subcontractor/vendor control activities incorporate items developed outside the project environment into the project CIs. Included are software developed by contract and software acquired in its finished form.

[X_RRCN_INT] Referenced in SCMP §4.5.2 & 5.5.2. Defined specifically for each subcontractor and project

SCMP 8 307 209 B 5 SCM schedules 4.4 4 SCM schedules: (When?) Identifies the required coordination of SCM activities with the other activities in the project SDP 8 307 211 B 6 Schedule It is Rolls-Royce practice to put

schedule details in the SDP for each project. SDP is referenced in §2 of the SCMP.

SDP 8 307 211 B 9 Resource requirements It is Rolls-Royce practice to put resource details in the SDP for each project. SDP is referenced in §2 of the SCMP.

SCMP 8 307 209 B 6.1 SCM Tools





[CLARISSE_SUD] 8 002 800 C CLARISSE SSDE user guide Referenced in SCMP §4.1 & 6.




IEEE 828 Section


1.4 Creation and Update of the SCMP


SCMP 8 307 209 B

7 SCM plan maintenance

1.2 Relationship of this SCMP to the Plans Defined in BTP 7-14

1.3 Definitions and Abbreviations

No counterpart in IEEE 828 SCMP 8 307 209 B

6.5 Archiving


Table 3.8-9 Mapping SPINLINE 3 SQP MC3 and Other Content to IEEE 1012-1998 SVVP Content Guidance


IEEE 1012 Section

SVVP Section # Content Guidance Document Doc # Section # Document or Section

Title Notes

SQP MC3 8 303 429 E 1 Purpose, scope and responsibilities

There is no separate SVVP. The SQP MC3, the SVTP, and software instruction 1 207 107 A, "Rules for Verification and Validation of Software Components," provided the needed V&V process guidance for the MC3 project. A later revision of this instruction is applicable to current platform software V&V processes.

1 Project Overview SDP MC3 1 207 102 A



1 207 107 A/B/C


7.1 1 Purpose: The SVVP shall describe the purpose, goals, and scope of the software V&V effort, including waivers from this standard. The software project for which the Plan is being written and the specific software processes and products covered by the software V&V effort shall be identified.

SVTP 1 207 146 G 1.1 Purpose

SQP MC3 8 303 429 E 2 Reference documents and applicable documents


1 207 107 A/B/C


7.2 2 Referenced documents: The SVVP shall identify the compliance documents, documents referenced by the SVVP, and any supporting documents supplementing or implementing the SVVP.

SVTP 1 207 146 G 1.2 Reference documents and bibliography



Table 3.8-9 Mapping SPINLINE 3 SQP MC3 and Other Content to IEEE 1012-1998 SVVP Content Guidance IEEE 1012-1998 Guidance Where found in SPINLINE 3 generic platform software life cycle documentation

IEEE 1012 Section


Title Notes

SQP MC3 8 303 429 E 3 Terminology, abbreviations and acronyms


1 207 107 A/B/C


7.3 3 Definitions: The SVVP shall define or reference all terms used in the SVVP, including the criteria for classifying an anomaly as a critical anomaly. All abbreviations and notations used in the SVVP shall be described.



SQP MC3 8 303 429 E 5.1 Procedure used for software development

7.4 4 V&V overview: The SVVP shall describe the organization, schedule, software integrity level scheme, resources, responsibilities, tools, techniques, and methods necessary to perform the software V&V.


1 207 107 A/B/C


SQP MC3 8 303 429 E 4 Specific organizational structure associated with the software project (project to create SPINLINE 3)

SDP MC3 1 207 102 A 5 Organization

7.4.1 4.1 Organization: The SVVP shall describe the organization of the V&V effort, including the degree of independence required (See Annex C of this standard). The SVVP shall describe the relationship of the V&V processes to other processes such as development, project management, quality assurance, and configuration management. The SVVP shall describe the lines of communication within the V&V effort, the authority for resolving issues raised by V&V tasks, and the authority for approving V&V products. Annex F provides an example organizational relationship chart.


1 207 107 A/B/C




IEEE 1012 Section


Title Notes

3.4 Cost and schedule management

7.4.2 4.2 Master Schedule: The SVVP shall describe the project life cycle and milestones. It shall summarize the schedule of V&V tasks and task results as feedback to the development, organizational, and supporting processes (e.g., quality assurance and configuration management). V&V tasks shall be scheduled to be re-performed according to the task iteration policy. If the life cycle used in the SVVP differs from the life cycle model in this standard, this section shall describe how all requirements of the standard are satisfied (e.g., by cross-referencing to this standard).

SDP MC3 1 207 102 A

6 Planning

7.4.3 4.3 Software integrity level scheme: The SVVP shall describe the agreed upon software integrity level scheme established for the system and the mapping of the selected scheme to the model used in this standard. The SVVP shall document the assignment of software integrity levels to individual components (e.g., requirements, detailed functions, software modules, subsystems, or other software partitions), where there are differing software integrity levels assigned within the program. For each SVVP update, the assignment of software integrity levels shall be reassessed to reflect changes that may occur in the integrity levels as a result of architecture selection, detailed design choices, code construction usage, or other development activities.

SQP MC3 8 303 429 E 5.1 Procedures used for software development

The software to be produced belongs to one of three categories:- "standard" software- "safety class" software- HMI software

SDP MC3 1 207 102 A 4 Resources to be deployed It is Rolls-Royce practice to put resource information in the SDP

7.4.4 4.4 Resources summary: The SVVP shall summarize the V&V resources, including staffing, facilities, tools, finances, and special procedural requirements (e.g., security, access rights, and documentation control)

SVTP 1 207 146 G 3 Test resources SVTP is referenced in SQP MC3 §5.3, 6.2, 9.1 & 10.2.2.4



IEEE 1012 Section


Title Notes

SQP MC3 8 303 429 E 4 Specific Organizational Structure Associated With Software Project

7.4.5 4.5 Responsibilities: The SVVP shall identify an overview of the organizational element(s) and responsibilities for V&V tasks.


SQP MC3 8 303 429 E 9 Methods, Tools and Rules


1 207 107 A/B/C


Software Guideline: Software V&V Team

Training Plan [IL_Plan_Form_VV]

1 208 210 B

3 Rules, Methods, Tools Refers to SQP MC3

7.4.6 4.6 Tools, techniques, and methods: The SVVP shall describe documents, hardware and software V&V tools, techniques, methods, and operating and test environment to be used in the V&V process. Acquisition, training, support, and qualification information for each tool, technology, and method shall be included. Tools that insert code into the software shall be verified and validated to the same rigor as the highest software integrity level of the software. Tools that do not insert code shall be verified and validated to assure that they meet their operational requirements. If partitioning of tool functionscan be demonstrated, only those functions that are used in the V&V processes shall be verified to demonstrate that they perform correctly for their intended use. The SVVP shall document the metrics to be used by V&V, and shall describe how these metrics support the V&V objectives.

SVTP 1 207 146 G 6 Regression tests


5.2 Development process for software incorporating HMIs

SQP MC3 8 303 429 E

5.3 Description of phases Identifies V&V tasks integrated into each phase

7.5 5 V&V processes: The SVVP shall identify V&V activities and tasks to be performed for each of the V&V processes described in Clause 5 of this standard, and shall document those V&V activities and tasks. The SVVP shall contain an overview of the V&V activities and tasks for all software life cycle processes.


1 207 107 A/B/C




IEEE 1012 Section


Title Notes

2 Analysis of functions

4 Analysis of tests

5 Coverage of tests

SVTP 1 207 146 G

7 to 10 Analysis of Tests on Upgrade


Software life cycle: The SVVP shall include sections 5.1 through 5.6 for V&V activities and tasks in each life cycle phase

SQP MC3 8 303 429 E 5.3 Description of software life cycle phases 1) Specification phase 2) Preliminary Design Phase 3) Detailed design phase 4) Production phase (coding and unit tests) 5) Integration phase 6) Validation phase 7) System tests

SVTP 1 207 146 G 2.4 Verification / validation sub-project


1) V&V Tasks


1 207 107 A/B/C


SQP MC3 8 303 429 E 9 Methods, tools and rules


1 207 107 A/B/C


3 Rules, Methods, Tools Refers to SQP MC3

7.5.1 5.1 - 5.6

2) Methods and Procedures

SVTP 1 207 146 G

6 Regression tests



IEEE 1012 Section


Title Notes

SQP MC3 8 303 429 E 5.3.1.1; 5.3.2.1; 5.3.3.1; 5.3.4.1; 5.3.5.1; 5.3.6.1

Phase inputs 3) Inputs


1 207 107 A/B/C


5.3.1.2; 5.3.2.2; 5.3.3.2; 5.3.4.2; 5.3.5.2; 5.3.6.2

Phase outputs SQP MC3 8 303 429 E

5.3.1.3; 5.3.2.3; 5.3.3.3; 5.3.4.3; 5.3.5.3; 5.3.6.3

Conditions for completing phase

4) Outputs


1 207 107 A/B/C


3.4 Cost and schedule management

5) Schedule SDP MC3 1 207 102 A

6 Planning

It is Rolls-Royce practice to put schedule details in the SDP for each project.

SDP MC3 1 207 102 A 4 Resources to be deployed It is Rolls-Royce practice to put resource details in the SDP for each project.

6) Resources

SVTP 1 207 146 G 3 Test resources SVTP is referenced in SQP MC3 §5.3, 6.2, 9.1 & 10.2.2.4



IEEE 1012 Section


Title Notes

7) Risks and Assumptions SDP MC3 1 207 102 A 8 Risk assessment

SQP MC3 8 303 429 E 4.3 Duties of members of the software team

8) Roles and Responsibilities


6.2 Documents specific to each software item embedded on a unit

Required V&V reports are (1) Software Validation Test Analysis (SVTP) and (2) Software Validation Test Reports (SVTR). See below for anomaly resolution and reporting.

SQP MC3 8 303 429 E

9.1.6 Software validation


1 207 107 A/B/C


SVTP 1 207 146 G

7.6 6 V&V reporting requirements: V&V reporting shall consist of Task Reports, V&V Activity Summary Reports, Anomaly Reports, and the V&V Final Report.

SVTR 1 207 232 F Software Validation Test Report (SVTR) - Operational System Software for Safety Class Units. This constitutes the V&V Final Report

SVTR is referenced in SQP §8.2.6. SVTR may be updated in connection with the software modification.



IEEE 1012 Section


Title Notes


1 207 107 A/B/C

Referenced in SQP MC3 §9.3 7.7 7 V&V administrative requirements: Administrative V&V requirements shall describe anomaly resolution and reporting, task iteration policy, deviation policy, control procedures, and standards, practices, and conventions

Also see additional references in 7.1 - 7.5 below


8 303 186 8.3 Control of nonconforming product


7.7.1 7.1 Anomaly resolution and reporting: The SVVP shall describe the method of reporting and resolving anomalies, including the criteria for reporting an anomaly, the anomaly report distribution list, and the authority and time lines for resolving anomalies. The section shall define the anomaly criticality levels. Classification for software anomalies may be found in IEEE Std 1044-1993. SQP MC3 8 303 429 E 8 Management of changes to

software and associated documentation

7.7.2 7.2 Task iteration policy: The SVVP shall describe the criteria used to determine the extent to which a V&V task shall be repeated when its input is changed or task procedure is changed. These criteria may include assessments of change, software integrity level, and effects on budget, schedule, and quality

SVTP 1 207 146 G 6 Regression tests

7.7.3 7.3 Deviation policy: The SVVP shall describe the procedures and criteria used to deviate from the Plan. The information required for deviations shall include task identification, rationale, and effect on software quality. The SVVP shall identify the authorities responsible for approving deviations

SQP MC3 8 303 429 E 1.2.5 Procedure in the event of failure to apply the SQP



IEEE 1012 Section


Title Notes


8 303 186 4.2 QMS Documents Referenced in SQP MC3 §2.1 & 6.3. Now known as I&C France Quality Manual [PQM]

7 Configuration Management

8 Management of Changes to Software and Associated Documentation


7.7.4 7.4 Control procedures: The SVVP shall identify control procedures applied to the V&V effort. These procedures shall describe how software products and V&V results shall be configured, protected, and stored. These procedures may describe quality assurance, configuration management, data management, or other activities if they are not addressed by other efforts. The SVVP shall describe how the V&V effort shall comply with existing security provisions and how the validity of V&V results shall be protected from unauthorized alterations.

SQP MC3 8 303 429 E



SQP MC3 8 303 429 E

9 Methods, tools and rules

7.7.5 7.5 Standards, practices, and conventions: The SVVP shall identify the standards, practices, and conventions that govern the performance of V&V tasks including internal organizational standards, practices, and policies.

General process for Software Development

[IL_PROC_GEN]

1 208 079 A/B/C/D

Not referenced in MC3 SQP, but applicable



IEEE 1012 Section


Title Notes

6.2 Documents specific to each software item embedded on a unit. Required V&V reports are (1) Software Validation Test Analysis (SVTP) and (2) Software Validation Test Reports (SVTR)

SQP MC3 8 303 429 E

9.1.6 Software validation


1 207 107 A/B/C


SVTP 1 207 146 G SVTP is referenced in SQP MC3 §5.3, 6.2, 9.1 & 10.2.2.4 .

SVTR 1 207 232 F SVTR is referenced in SQP MC3 §5.3, 6.2, 9.1 & 10.2.2.4

7.8 8 V&V documentation requirements: The SVVP shall define the purpose, format, and content of the test documents. A description of the format for these test documents may be found in IEEE Std 829-1983]. If the V&V effort uses test documentation or test types (e.g., component, integration, system, acceptance) different from those in this standard, the software V&V effort shall show a mapping of the proposed test documentation and execution to the test items defined in this standard. Test planning tasks defined in Table 1 shall be implemented in the test plan, test design(s), test case(s), and test procedure(s) documentation. The SVVP shall describe the purpose, format, and content for the V&V test documents:All V&V results and findings shall be documented in the V&V Final Report

V&V forms for the software components in configuration

management.

These are V&V records produced in accordance with the Plans.



Table 3.8-10 Mapping SPINLINE 3 SMQP and Other Content to IEEE 1012-1998 SVVP Content Guidance


IEEE 1012 Section

SVVP Section # Content Guidance Document Doc # Section # Section Title or Reference

Location Notes

SMQP 1 208 686 B 1.1 & 1.2 Purpose of Document; Scope of Application

There is no separate SVVP. The SMQP, SVTP and subordinate V&V guidance documents perform the function of the SVVP.


[PRO_Concept_log_C]

8 303 350 L 1 & 2 Objective & Scope Referenced in SMQP §5.2 & 8


1 207 107 D 1 & 2 Subject & Scope Referenced in SMQP §8

SVTP 1 207 146 G 1.1 Purpose SVTP is referenced in SMQP §8.2.6. SVTP may be updated in connection with the software modification.

1.1 Origin and objectives of the project


Modification-specific SDPs for 2000 & 2001 modification

projects

1 208 645 A and

1 208 908 A 1.2 Contract Clauses


SMQP 1 208 686 B 2 Applicable Documents and Reference Documents


[PRO_Concept_log_C]

8 303 350 L 5 Reference documents Referenced in SMQP §5.2 & 8



1 207 107 D 3 Reference documents Referenced in SMQP §8


Table 3.8-10 Mapping SPINLINE 3 SMQP and Other Content to IEEE 1012-1998 SVVP Content Guidance IEEE 1012-1998 Guidance Where found in SPINLINE 3 generic platform software life cycle documentation

IEEE 1012 Section


Location Notes




projects

1 208 645 A and

1 208 908 A

1.3 Technical reference documents


SMQP 1 208 686 B 3 Terminology and Abbreviations


[PRO_Concept_log_C]

8 303 350 L 4 Abbreviations Referenced in SMQP §5.2 & 8


1 207 107 D 4 Glossary and terminology Referenced in SMQP §8






7.4 4 V&V overview: The SVVP shall describe the organization, schedule, software integrity level scheme, resources, responsibilities, tools, techniques, and methods necessary to perform the software V&V.

SMQP 1 208 686 B




IEEE 1012 Section


Location Notes


[PRO_Concept_log_C]

8 303 350 L 6.4 Verification & Validation process

Referenced in SMQP §5.2 & 8


1 207 107 D 7 Approach Referenced in SMQP §8



[PRO_Concept_log_C]

8 303 350 L 6.2 Parties involved and duties Referenced in SMQP §5.2 & 8





projects

1 208 645 A and

1 208 908 A




IEEE 1012 Section


Location Notes

7 Standard Development Cycle for Safety Class Software


[PRO_Concept_log_C]

8 303 350 L

8 Development of SPINLINE 3 type Safety Class Software

Referenced in SMQP §5.2 & 8

6 Schedule

7.4.2 4.2 Master Schedule: The SVVP shall describe the project life cycle and milestones. It shall summarize the schedule of V&V tasks and task results as feedback to the development, organizational, and supporting processes (e.g., quality assurance and configuration management). V&V tasks shall be scheduled to be re-performed according to the task iteration policy. If the life cycle used in the SVVP differs from the life cycle model in this standard, this section shall describe how all requirements of the standard are satisfied (e.g., by cross-referencing to this standard).


projects

1 208 645 A and

1 208 908 A

9.1 Planning

It is Rolls-Royce practice to put schedule details in the SDP for each project. Use of a separate SDP for each modification project is explained in SQMP §1.2.1

SMQP 1 208 686 B 1.2.2 Software covered by the plan

2 Scope Identifies various international safety software classifications.

3 Introduction Defines special case: Class B or C2 software

7 Standard Development Cycle for Safety Class Software

Identifies the generic life cycle for safety software



[PRO_Concept_log_C]

8 303 350 L

8 Development of SPINLINE 3 type Safety Class Software

Identifies the life cycle for SPINLINE 3 safety software



IEEE 1012 Section


Location Notes


projects

1 208 645 A and

1 208 908 A

4 Means It is Rolls-Royce practice to put resource details in the SDP for each project. Use of a separate SDP for each modification project is explained in SQMP §1.2.1


SVTP 1 207 146 G 3 Test resources SVTP is referenced in SMQP §8.2.6. SVTP may be updated in connection with the software modification.

SMQP 8 303 429 E 4 Organization


[PRO_Concept_log_C]

8 303 350 L 6.2 Parties involved and duties Referenced in SMQP §5.2 & 8


projects

1 208 645 A and

1 208 908 A







IEEE 1012 Section


Location Notes

8 Methods, Tools and Rules

8.2 Methods applied 8.3 Tools

SMQP 1 208 686 B

8.4 Rules 8 to 13 Documentation for each V&V

activity is identified in the corresponding section and report templates are provided in the appendices (Section 13)

Aligns with IEEE 1012 SVVP Section 4.6 content recommendation: "Documents"

10.1 Tool used for code verification

12.3 Tool used for code validation

Aligns with IEEE 1012 SVVP Section 4.6 content recommendation: "Hardware & software V&V tools"

8 Specification verification 9 Design verification

10 Static verification of source code

11 Change report 12 Unit Test Validation

Aligns with IEEE 1012 SVVP Section 4.6 content recommendation: "Techniques, Methods"


12.1 Test analysis methods 12.2 Devising the test program

and conducting the tests

Aligns with IEEE 1012 SVVP Section 4.6 content recommendation: "Operating and test environment"


1 207 107 D

10.2 Verification reports

7.4.6 4.6 Tools, techniques, and methods: The SVVP shall describe documents, hardware and software V&V tools, techniques, methods, and operating and test environment to be used in the V&V process. Acquisition, training, support, and qualification information for each tool, technology, and method shall be included. Tools that insert code into the software shall be verified and validated to the same rigor as the highest software integrity level of the software. Tools that do not insert code shall be verified and validated to assure that they meet their operational requirements. If partitioning of tool functions can be demonstrated, only those functions that are used in the V&V processes shall be verified to demonstrate that they perform correctly for their intended use. The SVVP shall document the metrics to be used by V&V, and shall describe how these metrics support the V&V objectives.


[PRO_Concept_log_C]

8 303 350 L 9 Indicators of the Effectiveness of the Safety Class Software Design Process

Aligns with IEEE 1012 SVVP Section 4.6 content recommendation: "Metrics to be used by V&V"



IEEE 1012 Section


Location Notes

Software Guideline: Software V&V Team

Training Plan [IL_Plan_Form_VV]

1 208 210 C

3 Rules, Methods, Tools (refers to SQP MC3)

SVTP 1 207 146 G

6 Regression tests


5.2 SPINLINE 3 Software Modification Process



SMQP 1 208 686 B




2 Analysis of functions

4 Analysis of tests

5 Coverage of tests


SVTP 1 207 146 G

7 to 10 Analysis of Tests on Upgrade




IEEE 1012 Section


Location Notes

Software life cycle: The SVVP shall include sections 5.1 through 5.6 for V&V activities and tasks in each life cycle phase

SMQP 1 208 686 B 5.2 SPINLINE 3 Software Modification Process

Note: The focus of the SMQP is on the maintenance phase of the SPINLINE 3 software life cycle, which is addressed in §5.6 of IEEE 1012. Topics 1, 2, 3, 4 & 8 are already addressed elsewhere in this table. Refer to the SDP for Topics 5, 6 & 7.

8 Specification verification

9 Design verification


11 Change report


1 207 107 D

12 Unit Test Validation

Referenced in SMQP §8 1) V&V Tasks


8 Specification verification

9 Design verification


11 Change report


1 207 107 D

12 Unit Test Validation


3 Rules, Methods, Tools

7.5.1 5.1 - 5.6

2) Methods and Procedures

SVTP 1 207 146 G

6 Regression tests



IEEE 1012 Section


Location Notes

3) Inputs Rules for Verification/Validation of Software Components

1 207 107 D 12.1.1 Defining the inputs and outputs of the component to be tested


4) Outputs Rules for Verification/Validation of Software Components

1 207 107 D 12.1.1 Defining the inputs and outputs of the component to be tested


5) Schedule

6) Resources

7) Risks and Assumptions

It is Rolls-Royce practice to put schedule, resource, and

risk details in the SDP for each project.

8) Roles and Responsibilities See 4.5, above



SMQP 1 208 686 B


10.2 Verification reports

11 Change report

12.4 Drawing up a validation report

Appendix 1 Specification validation sheet

Appendix 2 Design verification report



1 207 107 D

Appendix 3 Code verification sheet




IEEE 1012 Section


Location Notes

Appendix 4 Validation report sheet

Appendix 5 Description of tests





7.7 7 V&V administrative requirements: Administrative V&V requirements shall describe anomaly resolution and reporting, task iteration policy, deviation policy, control procedures, and standards, practices, and conventions

See below





1 207 107 D 11 Change report Referenced in SMQP §8

7.7.1 7.1 Anomaly resolution and reporting: The SVVP shall describe the method of reporting and resolving anomalies, including the criteria for reporting an anomaly, the anomaly report distribution list, and the authority and time lines for resolving anomalies. The section shall define the anomaly criticality levels. Classification for software anomalies may be found in IEEE Std 1044-1993.


1 207 875 G 7.3.1 Record (Non-conformity report)




IEEE 1012 Section


Location Notes


SVTP 1 207 146 G 6 Regression tests SVTP is referenced in SMQP §8.2.6. SVTP may be updated in connection with the software modification.

7.7.3 I&C France Quality Manual [PQM]

8 303 186 P 5.6 Management Review Not referenced in SMQP, but applicable.

7.3 Deviation policy: The SVVP shall describe the procedures and criteria used to deviate from the Plan. The information required for deviations shall include task identification, rationale, and effect on software quality. The SVVP shall identify the authorities responsible for approving deviations


[PRO_Concept_log_C]

8 303 350 L 6.2 and 6.4 Referenced in SMQP §5.2 & 8


8 303 186 P 4.2 QMS Documents Not referenced in SMQP, but applicable.

7 Configuration Management


SMQP 1 208 686 B

11.3 Quality-related records

[IL_Ctrl_log_Ext] 8 303 671 B No Software Instruction: External software reception control





1 207 875 G 7.3 Control Changes Referenced in SMQP §7



projects

1 208 645 A and

1 208 908 A





IEEE 1012 Section


Location Notes


[PRO_Concept_log_C]

8 303 350 L See 5.1 - 5.6, above

Referenced in SMQP §5.2 & 8 7.7.5 7.5 Standards, practices, and conventions: The SVVP shall identify the standards, practices, and conventions that govern the performance of V&V tasks including internal organizational standards, practices, and policies.


1 207 107 D See 5.1 - 5.6, above




SMQP 1 208 686 B



1 207 107 D Appendices (Section

13)

Templates for verification and validation report sheets




7.8 8 V&V documentation requirements: The SVVP shall define the purpose, format, and content of the test documents. A description of the format for these test documents may be found in IEEE Std 829-1983]. If the V&V effort uses test documentation or test types (e.g., component, integration, system, acceptance) different from those in this standard, the software V&V effort shall show a mapping of the proposed test documentation and execution to the test items defined in this standard. Test planning tasks defined in Table 1 shall be implemented in the test plan, test design(s), test case(s), and test procedure(s) documentation. The SVVP shall describe the purpose, format, and content for the V&V test documents:All V&V results and findings shall be documented in the V&V Final Report





IEEE 1012 Section


Location Notes


1 208 878 E SPINLINE 3 Software Configuration Management Plan




Table 3.8-11 Mapping SPINLINE 3 Application SVVP and Other Content to IEEE 1012-1998 SVVP Content Guidance


IEEE 1012 Section

SVVP Section # Content Guidance Document Doc # Section # Document or Section Title Notes


SVVP 8 307 210 B 1.1 Purpose Note that SVVP, document 8 307 210 B, is a generic template that establishes the framework for completing the SVVP for plant-specific application software that will interface with the SPINLINE 3 generic platform software.


SVVP 8 307 210 B 2 Reference Documents


SVVP 8 307 210 B 1.3 Definitions and Abbreviations

3 V&V Overview 7.4 4 V&V overview: The SVVP shall describe the organization, schedule, software integrity level scheme, resources, responsibilities, tools, techniques, and methods necessary to perform the software V&V.

SVVP 8 307 210 B

Figures 3.2-1 & 3.2-1

V&V Activities in the Software Life Cycle for Safety Software; Software Life Cycle Process for Nonsafety Software


Table 3.8-11 Mapping SPINLINE 3 Application SVVP and Other Content to IEEE 1012-1998 SVVP Content Guidance IEEE 1012-1998 Guidance Where found in SPINLINE 3 generic platform software life cycle documentation

IEEE 1012 Section



SVVP 8 307 210 B 3.1 Organization

SVVP 8 307 210 B 3.2 Master Schedule 7.4.2 4.2 Master Schedule: The SVVP shall describe the project life cycle and milestones. It shall summarize the schedule of V&V tasks and task results as feedback to the development, organizational, and supporting processes (e.g., quality assurance and configuration management). V&V tasks shall be scheduled to be re-performed according to the task iteration policy. If the life cycle used in the SVVP differs from the life cycle model in this standard, this section shall describe how all requirements of the standard are satisfied (e.g., by cross-referencing to this standard). SDP 8 307 211 B 6 Schedule It is Rolls-Royce practice to put

schedule details in the SDP for each project. SDP is referenced in §2 of the SVVP.



IEEE 1012 Section



SVVP 8 307 210 B 3.3 Software Integrity Level Scheme

SVVP 8 307 210 B 3.4 Resources Summary

SDP 8 307 211 B 9 Resource requirements It is Rolls-Royce practice to put resource details in the SDP for each project. SDP is referenced in §2 of the SVVP.



Referenced in SVVP §3.4 & 4.2.2

1.4 Creation and Update of the SVVP


SVVP 8 307 210 B

3.5 Responsibilities



IEEE 1012 Section


SVVP 8 307 210 B 3.6 Tools, techniques, and methods


[IL_Verif_Doc]

1 207 947 E Referenced in SVVP §3.6, 4.3, 4.4 & 4.7


Referenced in SVVP §3.6, 4.3, 4.4, 4.5, 4.6 & 4.7

[IL_GD_ATVL] 1 207 858 G Software Guideline : Guide for writing a SVTP

Referenced in SVVP §3.6 & 4.3

[IL_SCADE] 1 208 250 C Software Guideline: SCADE Design Rules


[VERIF_CMU] 3 002 593 A User Manual for VERIF_CMU tool


[VERIF_ASA] 3 002 594 A User Manual for VERIF_ASA tool


[VERIF_COMP] 3 003 769 A User Manual for VERIF_COMP tool


SCADE design evaluation checklists

8 307 250 B Checklist for scade verification activities




7.4.6 4.6 Tools, techniques, and methods: The SVVP shall describe documents, hardware and software V&V tools, techniques, methods, and operating and test environment to be used in the V&V process. Acquisition, training, support, and qualification information for each tool, technology, and method shall be included. Tools that insert code into the software shall be verified and validated to the same rigor as the highest software integrity level of the software. Tools that do not insert code shall be verified and validated to assure that they meet their operational requirements. If partitioning of tool functions can be demonstrated, only those functions that are used in the V&V processes shall be verified to demonstrate that they perform correctly for their intended use. The SVVP shall document the metrics to be used by V&V, and shall describe how these metrics support the V&V objectives.

[IL_QAC] 8 307 104 A Guideline : Source code static analysis process using QA-C

Referenced in SVVP §3.6.



IEEE 1012 Section


[IL_GD_RTVL] 1 207 859 A Software Guideline : Guide for writing a SVTR


[SP3_TST_BENCH] 3 002 494 C User Manual for SPINLINE 3 Test bench tool

Referenced in SVVP §3.6.

[IL_GD_TVL] 1 208 535 A Software Guideline : Guide for writing a SVTPR


3.1.1 V&V Tasks According to Equipment Technology

3.1.2 V&V Tasks According to Software Category

Figures 3.2-1

& 3.2-3


4 Life Cycle Verification and Validation Activity

SVVP 8 307 210 B

4.1 Management of V&V Activity


[PRO_Concept_log_C]

8 303 350 L 6.4 Verification & validation process

Referenced in SVVP §4.1.4.


[Pro_Concept_Log_NC] 8 307 214 B Non Safety Software Design Process

Referenced in SVVP §4.1.4.



IEEE 1012 Section


Figures 3.2-1 & 3.2-3


SVVP 8 307 210 B

4.2 to 4.11 • “Start of Software Project” Phase • Requirements Phase • Design Phase • Coding Phase • Test and Integration Phase• Validation Phase • “End of Software Project” Phase • Installation Phase • Operation Phase • Maintenance Phase

It is Rolls-Royce practice to put schedule, resource and risk analysis details in the SDP for each project.




[IL_Verif_Doc]

1 207 947 E Referenced in SVVP §3.6, 4.3, 4.4 & 4.7


Referenced in SVVP §3.6, 4.3, 4.4, 4.5, 4.6 & 4.7

[IL_GD_TVL] 1 208 535 A Software Guideline : Guide for writing a SVTPR


7.5.1 5.1 - 5.6 Software life cycle: The SVVP shall include sections 5.1 through 5.6 for V&V activities and tasks in each life cycle phase:1) V&V Tasks2) Methods and Procedures3) Inputs4) Outputs5) Schedule6) Resources7) Risks and Assumptions8) Roles and Responsibilities

[IL_GD_ATVL] 1 207 858 G Software Guideline : Guide for writing a SVTP




IEEE 1012 Section


[IL_SCADE] 1 208 250 C Software Guideline: SCADE Design Rules


SCADE design evaluation checklists

8 307 250 B Checklist for scade verification activities


[VERIF_CMU] 3 002 593 A User Manual for VERIF_CMU tool


[VERIF_ASA] 3 002 594 A User Manual for VERIF_ASA tool


[VERIF_COMP] 3 003 769 A User Manual for VERIF_COMP tool




[IL_GD_RTVL] 1 207 859 A Software Guideline : Guide for writing a SVTR


[PRO_Concept_log_NC] 8 307 214 B Non Safety Software Design Process




[PRO_Concept_log_C]

8 303 350 L




8 303 186 P I&C France Quality Manual Referenced in SVVP §2 & 4.9

SCMP 8 307 209 B Software Verification and Validation Plan

Referenced in SVVP §4.11



IEEE 1012 Section


5 V&V Reporting

5.1 Anomaly Reports

5.2 V&V Tasks Reports

5.3 V&V Phase Summary Reports


SVVP 8 307 210 B

5.4 V&V Final Report

7.7 7 V&V administrative requirements: Administrative V&V requirements shall describe anomaly resolution and reporting, task iteration policy, deviation policy, control procedures, and standards, practices, and conventions

SVVP 8 307 210 B 6 V&V Administrative Procedures



Referenced in SVVP §2 & 4.9

5.1 Anomaly Reports

7.7.1 7.1 Anomaly resolution and reporting: The SVVP shall describe the method of reporting and resolving anomalies, including the criteria for reporting an anomaly, the anomaly report distribution list, and the authority and time lines for resolving anomalies. The section shall define the anomaly criticality levels. Classification for software anomalies may be found in IEEE Std 1044-1993.

SVVP 8 307 210 B

6.1 Anomaly Reporting and Resolution


SVVP 8 307 210 B 6.2 Task Iteration Policy



IEEE 1012 Section


7.7.3 7.3 Deviation policy: The SVVP shall describe the procedures and criteria used to deviate from the Plan. The information required for deviations shall include task identification, rationale, and effect on software quality. The SVVP shall identify the authorities responsible for approving deviations

SVVP 8 307 210 B 6.3 Deviation Policy


8 303 186 P 4.2 QMS Documents Referenced in SVVP §2 & 4.9

SVVP 8 307 210 B 6.4 Configuration Control Procedures


SCMP 8 307 209 B SPINLINE 3 Software Configuration Management Plan - SCMP

Referenced in SVVP §6.4

7.7.5 7.5 Standards, practices, and conventions: The SVVP shall identify the standards, practices, and conventions that govern the performance of V&V tasks including internal organizational standards, practices, and policies.

SVVP 8 307 210 B 6.5 Standards, Practices, and Conventions

See SVVP §2



IEEE 1012 Section


7 Documentation

7.1 Transverse V&V Documents • Software V&V Plan (SVVP) • Network Detailed Design (NDD) V&V report • V&V Final Report (VVFR)

7.2 Software Product V&V Documents for Safety Software

• Software Validation Test Plan (SVTP) • Software Validation Test Report (SVTR) • Verification reports • Anomaly reports

7.8 8 V&V documentation requirements: The SVVP shall define the purpose, format, and content of the test documents. A description of the format for these test documents may be found in IEEE Std 829-1983]. If the V&V effort uses test documentation or test types (e.g., component, integration, system, acceptance) different from those in this standard, the software V&V effort shall show a mapping of the proposed test documentation and execution to the test items defined in this standard. Test planning tasks defined in Table 1 shall be implemented in the test plan, test design(s), test case(s), and test procedure(s) documentation. The SVVP shall describe the purpose, format, and content for the V&V test documents: All V&V results and findings shall be documented in the V&V Final Report

SVVP 8 307 210 B

7.3 Software Product V&V Documents for Nonsafety Software

• Software Integration Test Plan and Report (SITPR) • Software Validation Test Plan and Report (SVTPR) • Verification reports • Anomaly reports

1.2 Relationship of this SVVP to the Plans Defined in BTP 7-14

No counterpart in IEEE 1012 SVVP 8 307 210 B

3.7 Risk Management


Table 3.8-12. Alignment of IEEE 1074-1995 Activities, ISG-06 Tier 3 Document Guidance, and SPINLINE 3 Documents

SPINLINE 3 Life Cycle Phases

Alignment to ISG-06 Documents Alignment to Rolls-Royce Documents


IEEE 1074-1995 Software Life

Cycle Activities

Spec

ifica

tion

Prel

imin

ary

Des

ign

Det

aile

d D

esig

n

Cod

ing

Uni

t Tes

t

Inte

grat

ion

Valid

atio

n

UA

, Lat

er o

r Aud

it *

Doc

Nr.

ISG-06 Document Title

Rolls-Royce Document Title

Used in original MC3

project platform software project


upgrade project


upgrade project

Applicable to a future

SPINLINE 3 platform SW

upgrade project

Applicable to future

SPINLINE 3 plant-specific application software

Comments

Software Life Cycle Process

I&C France Quality Manual (former SES department Quality Assurance Manual)

8 303 186 A/B/C/D 8 303 186 G 8 303 186 H 8 303 186 P 8 303 186 P

Software Quality Plan (SQP) - MC3

8 303 429 A/B/C/D/E 8 303 429 E 8 303 429 E Not

applicable Not

applicable

Software Modification Quality Plan

Not applicable

Not applicable 1 208 686 A 1 208 686 B Not

applicable

Software Quality Plan - SCADE Operator Library

Not applicable 1 208 356 A 1 208 356 A 1 208 356 C Not

applicable

UA 12

Quality Assurance Plan for Digital Hardware and Software

SPINLINE 3 Software Quality Assurance Plan - SQAP

Not applicable

Not applicable

Not applicable

Not applicable 8 307 208 B

Identify Candidate SW Life Cycle Models

X

UA Several Licensing Topical Report

Not applicable

Not applicable

Not applicable

3 008 503B, § 6.1 &

Figure 6.2-1

3 008 503B, Figure 6.4-1

The software life cycle model selected by Rolls-Royce is integrated with SPINLINE 3 industrial processes.







Cycle Activities

Spec

ifica

tion

Prel

imin

ary

Des

ign

Det

aile

d D

esig

n

Cod

ing

Uni

t Tes

t

Inte

grat

ion

Valid

atio

n

UA

, Lat

er o

r Aud

it *

Doc

Nr.






upgrade project


upgrade project



upgrade project



Comments

Software Development Plan - MC3 1 207 102 A Not

applicable Not

applicable Not

applicable Not

applicable

Software Development Plan (SDP) - 2000 changes

Not applicable 1 208 645 A Not

applicable Not

applicable Not

applicable

Software Development Plan (SDP) - 2001 changes

Not applicable

Not applicable 1 208 908 A Not

applicable Not

applicable

Software Development Plan (SDP) - Future

Not applicable

Not applicable

Not applicable

Project-specific SDP

Not applicable

Select Project Model X UA 17c Software

Development Plan

SPINLINE 3 Software Development Plan - SDP

Not applicable

Not applicable

Not applicable


The project model developed by Rolls-Royce is integrated with SPINLINE 3 industrial processes.







Cycle Activities

Spec

ifica

tion

Prel

imin

ary

Des

ign

Det

aile

d D

esig

n

Cod

ing

Uni

t Tes

t

Inte

grat

ion

Valid

atio

n

UA

, Lat

er o

r Aud

it *

Doc

Nr.






upgrade project


upgrade project



upgrade project



Comments

Project Management Processes

Project Initiation Process

8 303 429 E UA 12


Included in the applicable SQAP

8 303 429 A/B/C/D/E 8 303 429 E

1 208 686 A

1 208 686 B 8 307 208 B

UA 17c Software Development Plan

Included in the applicable SDP 1 207 102 A 1 208 645 A 1 208 908 A Project-

specific SDP 8 307 211 B

UA Several Licensing Topical Report

Not applicable

Not applicable

Not applicable

3 008 503B, § 6.1 &

Figure 6.2-1

3 008 503B, Figure 6.4-1

The alignment of software activities to the software life cycle model is discussed in the SPINLINE 3 LTR §6

Map Activities to SLC Model X

Later 18a


General Processes for Software Development [IL_PROC_GEN]

1 208 079 A/B/C/D 1 208 079 E 1 208 079 E Not

applicable Not

applicable








Cycle Activities

Spec

ifica

tion

Prel

imin

ary

Des

ign

Det

aile

d D

esig

n

Cod

ing

Uni

t Tes

t

Inte

grat

ion

Valid

atio

n

UA

, Lat

er o

r Aud

it *

Doc

Nr.






upgrade project


upgrade project



upgrade project



Comments

Safety Software Design Process [PRO_Concept_log_C]

Not applicable

Not applicable

Not applicable 8 303 350 L 8 303 350 L




Allocate Project Resources X X X X X X X

Later 14

Quality Assurance Procedures for Digital Hardware and Software

Resources management process

Not applicable

Not applicable 8 303 696 A 8 303 696 E 8 303 696 E




Establish Project Environment X X

Later 14


SPINLINE 3 technical instruction: Description of development environments [IT_SL3_Env_Dev]

1 207 105 A/B/C 1 207 105 D 1 207 105 D 1 207 105 D Not

applicable







Cycle Activities

Spec

ifica

tion

Prel

imin

ary

Des

ign

Det

aile

d D

esig

n

Cod

ing

Uni

t Tes

t

Inte

grat

ion

Valid

atio

n

UA

, Lat

er o

r Aud

it *

Doc

Nr.






upgrade project


upgrade project



upgrade project



Comments





1 208 079 A/B/C/D 1 208 079 E 1 208 079 E Not

applicable Not

applicable



Not applicable

Not applicable


Non Safety Software Design Process [PRO_Concept_log_NC]

Not applicable

Not applicable

Not applicable 8 307 214 A 8 307 214 A

Plan Project Management X X

Later 18a


Software Guideline: Software Management Process [IL_Gest_Proj]

Not applicable 1 208 055 B 1 208 055 B 1 208 055 E 1 208 055 E







Cycle Activities

Spec

ifica

tion

Prel

imin

ary

Des

ign

Det

aile

d D

esig

n

Cod

ing

Uni

t Tes

t

Inte

grat

ion

Valid

atio

n

UA

, Lat

er o

r Aud

it *

Doc

Nr.






upgrade project


upgrade project



upgrade project



Comments

Project Monitoring and Control Process


8 303 186 A/B/C/D 8 303 186 G 8 303 186 H 8 303 186 P,

5.3, 7.0, 8.5.38 303 186 P, 5.3, 7.0, 8.5.3

Analyze Risks X X X X X X X UA 17gSoftware Project Risk Management Plan

Risk analysis is included in applicable Software Development Plan

1 207 102 A, § 8

1 208 645 A, § 8

1 208 908 A, § 8

Project-specific SDP

8 307 211 B, § 7

and more in the other

application SW Plans

Perform Contingency Planning

X X X X X X X UA 17c Software Development Plan

Contingency planning is part of risk management

See risk analysis above





There is no separate Risk Management Plan. Risk management (analysis and mitigation planning) is integrated with basic quality management system processes

UA 12


Manage the Project X X X X X X X


Apply the processes defined in the applicable SQAP, SDP and supporting procedures

See SQAP and SDP

listed above

See SQAP and SDP

listed above

See SQAP and SDP

listed above

See SQAP and SDP

listed above

See SQAP and SDP

listed above







Cycle Activities

Spec

ifica

tion

Prel

imin

ary

Des

ign

Det

aile

d D

esig

n

Cod

ing

Uni

t Tes

t

Inte

grat

ion

Valid

atio

n

UA

, Lat

er o

r Aud

it *

Doc

Nr.






upgrade project


upgrade project



upgrade project



Comments


1 208 079 A/B/C/D 1 208 079 E 1 208 079 E Not

applicable Not

applicable



Not applicable

Not applicable


Later 18a



Not applicable

Not applicable

Not applicable 8 307 214 A 8 307 214 A

Retain Records X X X X X X X UA 12


Apply the process defined in the applicable SQAP above

8 303 429 A/B/C/D/E

8 303 429 E, § 1.2.4 &

10.3 1 208 686 A 1 208 686 B,

§ 10 & 11.3 8 307 208 B, § 1.4 and 12

UA 12



8 303 186 A/B/C/D 8 303 186 G 8 303 186 H 8 303 186 P,

§ 8.3 8 303 186 P,

§ 8.3

Non conformity 8 303 202 E 8 303 202 F 8 303 202 G 8 303 202 M 8 303 202 M

Implement Problem Reporting System

X X X X X X X

Later 14


Classified nonconformities

Not applicable

Not applicable

Not applicable 8 307 152 B 8 307 152 B







Cycle Activities

Spec

ifica

tion

Prel

imin

ary

Des

ign

Det

aile

d D

esig

n

Cod

ing

Uni

t Tes

t

Inte

grat

ion

Valid

atio

n

UA

, Lat

er o

r Aud

it *

Doc

Nr.






upgrade project


upgrade project



upgrade project



Comments

Software Quality Management Process


8 303 186 A/B/C/D 8 303 186 G 8 303 186 H 8 303 186 P 8 303 186 P

Software Quality Plan (SQP) - MC3

8 303 429 A/B/C/D/E 8 303 429 E 8 303 429 E Not

applicable Not

applicable

Software Modification Quality Plan

Not applicable


applicable

Software Quality Plan - SCADE Operator Library

Not applicable 1 208 356 A 1 208 356 A 1 208 356 C Not

applicable

Plan Software Quality Management

X X UA 12


SPINLINE 3 Software Quality Assurance Plan - SQAP

Not applicable

Not applicable

Not applicable


This document is a plan template that will be completed for each plant-specific system.







Cycle Activities

Spec

ifica

tion

Prel

imin

ary

Des

ign

Det

aile

d D

esig

n

Cod

ing

Uni

t Tes

t

Inte

grat

ion

Valid

atio

n

UA

, Lat

er o

r Aud

it *

Doc

Nr.






upgrade project


upgrade project



upgrade project



Comments

UA 12



8 303 186 A/B/C/D 8 303 186 G 8 303 186 H 8 303 186 P,

§ 8.2 8 303 186 P,

§ 8.2

Define Metrics X X X

Later 18a



Not applicable

Not applicable


Manage Software Quality X X X X X X X Later 14


Software Quality Control Process 8 303 634 A 8 303 634 A 8 303 634 A 8 303 634 E 8 303 634 E

X X X X X X X UA 12



8 303 186 A/B/C/D 8 303 186 G 8 303 186 H 8 303 186 P,

§ 8.5 8 303 186 P,

§ 8.5

Identify Quality Improvement Needs

X X X X X X X Later 14


Continuous improvement process

Not applicable

Not applicable 8 303 695 A 8 303 695 E 8 303 695 E







Cycle Activities

Spec

ifica

tion

Prel

imin

ary

Des

ign

Det

aile

d D

esig

n

Cod

ing

Uni

t Tes

t

Inte

grat

ion

Valid

atio

n

UA

, Lat

er o

r Aud

it *

Doc

Nr.






upgrade project


upgrade project



upgrade project



Comments

Pre-Development Processes

Concept Exploration Process

Identify Ideas or Needs X

Formulate Potential Approaches

X X

Conduct Feasibility Studies X X


1 208 079 A/B/C/D 1 208 079 E 1 208 079 E Not

applicable Not

applicable

Plan System Transition (if applicable)

X X Safety Software Design Process [PRO_Concept_log_C]

Not applicable

Not applicable


Refine and Finalize the Idea or Need

X

Later 18a



Not applicable

Not applicable


The concept exploration process may be performed by the licensee in connection with their development of the bid specification for a new or replacement digital safety I&C system. If requested, Rolls-Royce can assist the licensee in this process.

System Allocation Process

Analyze Functions X X Later 18a

Software Management Implementing


1 208 079 A/B/C/D 1 208 079 E 1 208 079 E Not

applicable Not

applicable

These activities primarily apply to a plant-specific







Cycle Activities

Spec

ifica

tion

Prel

imin

ary

Des

ign

Det

aile

d D

esig

n

Cod

ing

Uni

t Tes

t

Inte

grat

ion

Valid

atio

n

UA

, Lat

er o

r Aud

it *

Doc

Nr.






upgrade project


upgrade project



upgrade project



Comments

Develop System Architecture X X

Safety software design process [PRO_Concept_log_C] (formerly Software Design Control)

Not applicable

Not applicable


Procedures

Non safety software design process [PRO_Concept_log_NC]

Not applicable

Not applicable


Decompose System Requirements

X X

UA 18 Requirements Traceability Matrix

Licensing Topical Report

Not applicable

Not applicable

Not applicable

3 008 503B, § 3

Plant-specific RTM

system

Development Processes

Requirements Process

UA 17b Software Design Specification

Software Preliminary Design - Core System Software

1 207 141 A/B/C/D/E 1 207 141 F 1 207 141 G 1 207 141 H Not

applicable

Define and Develop Software Requirements

X X X

UA 17hPlatform Software Requirements Specification

Software Requirement Specification - Operational System Software

1 207 108 A/B/ C/D/E/F/ 1 207 108 G 1 207 108 H 1 207 108 J Not

applicable

Preliminary software requirements typically are established by the licensee.







Cycle Activities

Spec

ifica

tion

Prel

imin

ary

Des

ign

Det

aile

d D

esig

n

Cod

ing

Uni

t Tes

t

Inte

grat

ion

Valid

atio

n

UA

, Lat

er o

r Aud

it *

Doc

Nr.






upgrade project


upgrade project



upgrade project



Comments

UA 17i

Application Software Requirements Specification

None. This is a plant-specific document for an application to be built on the generic SPINLINE 3 platform.

Not applicable

Not applicable

Not applicable

Not applicable

Plant-specific specification

Define Interface Requirements X X X UA 17b Software Design

Specification

Interface Specifications - Operational System Software and Application Software

1 207 110 A/B/C/D/E/F 1 207 110 G 1 207 110 H 1 207 110 J 1 207 110 J

Software Integration Test Plan and Report (SITR) - SCC (Core System Software)

1 207 204 A/BC 1 207 204 D 1 207 204 D 1 207 204 E Not

applicable Prioritize and Integrate Software Requirements

X X X UA 17e Software Integration Plan

SPINLINE 3 Software Verification and Validation Plan - SVVP

Not applicable

Not applicable

Not applicable

Not applicable 8 307 210B

Design Process

Perform Architectural Design

X X

Design Data Base (if applicable) X X

Later 18aSoftware management Implementing Procedures


1 208 079 A/B/C/D 1 208 079 E 1 208 079 E Not

applicable Not

applicable

A standard process guides the design effort for a modification to the generic platform software or for a







Cycle Activities

Spec

ifica

tion

Prel

imin

ary

Des

ign

Det

aile

d D

esig

n

Cod

ing

Uni

t Tes

t

Inte

grat

ion

Valid

atio

n

UA

, Lat

er o

r Aud

it *

Doc

Nr.






upgrade project


upgrade project



upgrade project



Comments

Design Interfaces X X

Select or Develop Algorithms X X


Not applicable

Not applicable


Perform Detailed Design X


Not applicable

Not applicable


plant-specific system.

Implementation Process

Create Test Data X X None Test data requirements are established in the respective Test Plans

See Test Plans, below





Create Source X X X Audit 8 Software Code Listings

SPINLINE 3 Technical Instruction: Description of Development Environments [IT_SL3_Env_Dev]

1 207 105 A/B/C/D 1 207 105 D 1 207 105 D 1 207 105 D 1 207 105 D







Cycle Activities

Spec

ifica

tion

Prel

imin

ary

Des

ign

Det

aile

d D

esig

n

Cod

ing

Uni

t Tes

t

Inte

grat

ion

Valid

atio

n

UA

, Lat

er o

r Aud

it *

Doc

Nr.






upgrade project


upgrade project



upgrade project



Comments

Generate Object Code X X X Audit 8 Software Code

Listings

Software Manufacturing File – Programming Instruction document

1 207 287 A 1 207 287 A 1 207 287 B 1 207 287 C Not applicable

Create Operating Documentation X X X None System Operations and

Maintenance Plan Not

applicable Not

applicable Not

applicable Not

applicable 8 307 244 A



1 207 204 A/B/C 1 207 204 D 1 207 204 D 1 207 204 E Not

applicable

Plan Integration X X UA 17e Software Integration Plan

System Integration and Factory Test Plan

Not applicable

Not applicable

Not applicable

Not applicable 8 307 245 A








Cycle Activities

Spec

ifica

tion

Prel

imin

ary

Des

ign

Det

aile

d D

esig

n

Cod

ing

Uni

t Tes

t

Inte

grat

ion

Valid

atio

n

UA

, Lat

er o

r Aud

it *

Doc

Nr.






upgrade project


upgrade project



upgrade project



Comments

Perform Integration X UA 16 System Test Plan

Apply the process defined in the Software Integration Test Plan above. Produce the "Report" part of the SITR.

See SITR above

See SITR above

See SITR above

See SITR above

Not applicable

Post-Development Processes

Installation Process

System Integration and Factory Test Plan (Generic)

Not applicable

Not applicable

Not applicable


UA 17d Software Installation Plan System Installation and

Site Test Plan (Generic)

Not applicable

Not applicable

Not applicable

Not applicable 8 307 243 A Plan Installation X X

Later 12 Installation Test Plans and Procedures

System Installation and Site Test Plan (Generic)

Not applicable

Not applicable

Not applicable


These documents are plan templates that will be completed for each plant-specific system.

Distribute Software X X X Later 18a


Software Manufacturing File – Programming Instruction document (one document per software)

1 207 287 A 1 207 287 A 1 207 287 B 1 207 287 C Not applicable

Software manufacturing process distributes executable code to EEPROMS that are installed on the UC25+ CPU boards







Cycle Activities

Spec

ifica

tion

Prel

imin

ary

Des

ign

Det

aile

d D

esig

n

Cod

ing

Uni

t Tes

t

Inte

grat

ion

Valid

atio

n

UA

, Lat

er o

r Aud

it *

Doc

Nr.






upgrade project


upgrade project



upgrade project



Comments

Install Software X X X Later 12 Installation Test Plans and Procedures

Accept Software in Operational Environment

→ Later 12 Installation Test Plans and Procedures

System Installation and Site Test Plan

Not applicable

Not applicable

Not applicable


Licensee makes the decision to accept the system following successful completion of site acceptance test or other criteria established in the contract for the system.

Operation and Support Process

Operate the System → None System Operations and

Maintenance Plan Not

applicable Not

applicable Not

applicable Not

applicable 8 307 244 A

This document is a plan template that will be completed for each plant-specific system. The licensee operates the system







Cycle Activities

Spec

ifica

tion

Prel

imin

ary

Des

ign

Det

aile

d D

esig

n

Cod

ing

Uni

t Tes

t

Inte

grat

ion

Valid

atio

n

UA

, Lat

er o

r Aud

it *

Doc

Nr.






upgrade project


upgrade project



upgrade project



Comments

On-site activities process

Not applicable

Not applicable

Not applicable

Not applicable 8 303 659 E

Presentation and organization of On-site activities group

Not applicable

Not applicable

Not applicable

Not applicable 8 303 373 N Provide Tech.

Asst. & Consult → Later 14


On site Maintenance, Preparation, Follow-up

Not applicable

Not applicable

Not applicable

Not applicable 8 303 382 K

The licensee may contract Rolls-Royce for technical assistance and/or consulting

Establishment of on-site activities reports

Not applicable

Not applicable

Not applicable

Not applicable 8 303 384 L

Maintain Support Request Log → Later 14

Quality Assurance Procedures for Digital Hardware and Software On site non

conformities Not

applicable Not

applicable Not

applicable Not

applicable 8 303 647 G

Rolls-Royce maintains a log of customer support activities.

Maintenance Process

Reapply Software Life Cycle → None Software Modification

Quality Plan Not

applicable Not

applicable 1 208 686 A 1 208 686 B Not applicable







Cycle Activities

Spec

ifica

tion

Prel

imin

ary

Des

ign

Det

aile

d D

esig

n

Cod

ing

Uni

t Tes

t

Inte

grat

ion

Valid

atio

n

UA

, Lat

er o

r Aud

it *

Doc

Nr.






upgrade project


upgrade project



upgrade project



Comments

Retirement Process

Notify User → None

The licensee will make the decision to initiate replacement and retirement of a system.

Conduct Parallel Operations (if applicable)

→ None

Rolls-Royce has structured projects with parallel operation of the original system and the new digital system. This is captured in the SDP.

Retire System → None The licensee will make the decision to retire a system.







Cycle Activities

Spec

ifica

tion

Prel

imin

ary

Des

ign

Det

aile

d D

esig

n

Cod

ing

Uni

t Tes

t

Inte

grat

ion

Valid

atio

n

UA

, Lat

er o

r Aud

it *

Doc

Nr.






upgrade project


upgrade project



upgrade project



Comments

Integral Processes

Verification and Validation Process

Software Quality Plan (SQP) - MC3 (This Plan + SITR, SVTP and supporting instructions functioned as the SVVP)

8 303 429 A/B/C/D/E

8 303 429 E, § 5 & 9.1.6

8 303 429 E, § 5 & 9.1.6

Not applicable

Not applicable

The MC3 SQP, 8 303 429 E, served the function of the SVVP where indicated.

Software Modification Quality Plan (This Plan + SITR, SVTP and supporting instructions functioned as the SVVP)

Not applicable


applicable

The SMQP, 1 208 686 A, served the function of the SVVP where indicated.

Plan Verification and Validation X X

UA 17m

Software V&V Plan and Procedures

SPINLINE 3 Software Verification and Validation Plan - SVVP

Not applicable

Not applicable

Not applicable









Cycle Activities

Spec

ifica

tion

Prel

imin

ary

Des

ign

Det

aile

d D

esig

n

Cod

ing

Uni

t Tes

t

Inte

grat

ion

Valid

atio

n

UA

, Lat

er o

r Aud

it *

Doc

Nr.






upgrade project


upgrade project



upgrade project



Comments

Later 18a


Rules for Verification & Validation of software components

1 207 107 A/B/C 1 207 107 C 1 207 107 C 1 207 107 D Not

applicable

Execute V&V Tasks X X X X X X X Later 18a


Apply processes defined in the applicable V&V Plan and procedures

See SVVP above

See SVVP above

See SVVP above

See SVVP above

See SVVP above

Collect and Analyze Metric Data

X X X X Later 18a


Apply processes defined in the applicable V&V Plan and procedures

See SVVP above

See SVVP above

See SVVP above

See SVVP above

See SVVP above

UA 17e

, 17k

Software Integration Plan, Software Test Plan


1 207 204 A/B/C 1 207 204 D 1 207 204 D 1 207 204 E Not

applicable

Plan Testing X X X

UA 17e

, 17k

Software Integration Plan, Software Test Plan

Software Validation Test Plan (SVTP) - Operational System Software for Safety Class Units

1 207 146 A/B/C 1 207 146 E 1 207 146 F 1 207 146 G Not

applicable

Develop Test Requirements X X X Audit 6

Test requirements included in Test Plan

Test requirements included in Test Plan

See Test Plan for test requirements











Cycle Activities

Spec

ifica

tion

Prel

imin

ary

Des

ign

Det

aile

d D

esig

n

Cod

ing

Uni

t Tes

t

Inte

grat

ion

Valid

atio

n

UA

, Lat

er o

r Aud

it *

Doc

Nr.






upgrade project


upgrade project



upgrade project



Comments

Later 19 V&V Reports

Software Validation Test Report (SVTR) - Operational System Software for Safety Class Units

1 207 232 A/B/C 1 207 232 D 1 207 232 E 1 207 232 F Not

applicable

Execute the Tests X X

Audit 6

Individual Completed Test Procedures & Reports

Tests and test reports as required by the applicable Test Plan

See Test Plan for list of test reports






Software Quality Plan (SQP) - MC3 (This Plan + supporting instructions functioned as the SCMP)

8 303 429 A/B/C/D/E

8 303 429 E, § 5 & 9.1.6

8 303 429 E, § 5 & 9.1.6

Not applicable

Not applicable

Plan Configuration Management

X X UA 17a Vendor Software CM Plan

Software Configuration Management Plan for SPINLINE 3 Software Sub-assemblies Managed by CM Tool

Not applicable 1 208 878 A 1 208 878 B 1 208 878 E Not

applicable







Cycle Activities

Spec

ifica

tion

Prel

imin

ary

Des

ign

Det

aile

d D

esig

n

Cod

ing

Uni

t Tes

t

Inte

grat

ion

Valid

atio

n

UA

, Lat

er o

r Aud

it *

Doc

Nr.






upgrade project


upgrade project



upgrade project



Comments

SPINLINE 3 Software Configuration Management Plan - SCMP

Not applicable

Not applicable

Not applicable



Software Maintenance and Changes 1 206 624 A Not

applicable Not

applicable Not

applicable Not

applicable

Later 18a

Software Management Implementing Procedures Software Configuration

Management Process [IL_Gest_Conf]

1 207 875 A 1 207 875 B 1 207 875 C 1 207 875 G 1 207 875 G

Perform Configuration Identification

X X X X X X X Later 10 Final System Configuration Documentation

Apply processes defined in the applicable CM Plan and procedures

8 303 429 A/B/C/D/E

8 303 429 E, § 7.2, 7.3, 7.4

8 303 429 E, § 7.2, 7.3, 7.4

1 208 878 E, § 2.3, 2.6 &

3.1

8 307 209 B, § 4.1 & 5.2

The MC3 SQP, 8 303 429 E, served the function of the SCMP where indicated.







Cycle Activities

Spec

ifica

tion

Prel

imin

ary

Des

ign

Det

aile

d D

esig

n

Cod

ing

Uni

t Tes

t

Inte

grat

ion

Valid

atio

n

UA

, Lat

er o

r Aud

it *

Doc

Nr.






upgrade project


upgrade project



upgrade project



Comments

Perform Configuration Control

X X X X X X X Later 10 Final System Configuration Documentation


8 303 429 A/B/C/D/E

8 303 429 E, § 8

8 303 429 E, § 8

1 208 878 E, § 2.4, 2.5,

2.8, 2.10, 3.3 & 3.4

8 307 209 B, § 4.2, 5.3 &

6.3


Perform Status Accounting X X X X X X X Later 10

Final System Configuration Documentation


8 303 429 A/B/C/D/E

8 303 429 E, § 10.3

8 303 429 E, § 10.3

1 208 878 E, § 2.9

8 307 209 B, § 4.3, 5.4 &

6.3.4


Documentation Development Process

8 303 429 A/B/C/D/E

8 303 429 E, § 6

8 303 429 E, § 6

Not applicable

Not applicable

UA 12


Included in SQAP and other Plans identified above Not

applicable Not

applicable 1 208 686 A 1 208 686 B, § 4

8 307 208 B, § 4

Plan Documentation X X

Later 14


Documents and reference files management [Gest_Doc_Col_Ref]

8 303 638 A 8 303 638 A 8 303 638 A 8 303 638 B 8 303 638 B







Cycle Activities

Spec

ifica

tion

Prel

imin

ary

Des

ign

Det

aile

d D

esig

n

Cod

ing

Uni

t Tes

t

Inte

grat

ion

Valid

atio

n

UA

, Lat

er o

r Aud

it *

Doc

Nr.






upgrade project


upgrade project



upgrade project



Comments

Software Guideline: Software Document Evaluation Process [IL_Verif_Doc]

1 207 947 B/C 1 207 947 C 1 207 947 C 1 207 947 E 1 207 947 E

Implement Documentation X X X X X X X

UA, Later and

Audit

Many

Apply documentation processes defined in the applicable SQAP and other Plans identified above.

See Plan Documentatio

n above


n above


n above


n above


n above

Produce and Distribute Documentation

X X X X X X X

UA, Later and

Audit

Many

Apply documentation processes defined in the applicable SQAP and other Plans identified above.


n above


n above


n above


n above


n above

Training Process

UA 12



8 303 186 A/B/C/D 8 303 186 G 8 303 186 H 8 303 186 P,

§ 6.2.2 8 303 186 P,

§ 6.2.2 Plan the Training Program X X X

Later 14


Training New Team Members 1 207 104 A 1 207 104 A 1 207 104 A Not

applicable Not

applicable

Training for Rolls-Royce and EDF staff are in place. Training for U.S. licensee staff will be planned in connection with each plant-specific project.







Cycle Activities

Spec

ifica

tion

Prel

imin

ary

Des

ign

Det

aile

d D

esig

n

Cod

ing

Uni

t Tes

t

Inte

grat

ion

Valid

atio

n

UA

, Lat

er o

r Aud

it *

Doc

Nr.






upgrade project


upgrade project



upgrade project



Comments

Training of personnel 8 303 321 8 303 321 E 8 303 321 E 8 303 321 J 8 303 321 J

Training of personnel for on-site activities 8 303 386 8 303 386 F 8 303 386 G 8 303 386 J 8 303 386 J

Customer training process

No information

No information 8 303 706 A 8 303 706 D 8 303 706 D

Software Guideline: Software V&V Team Training Plan [IL_Plan_Form_VV]

1 208 210 B 1 208 210 B 1 208 210 B 1 208 210 C 1 208 210 C

System Training Plan Not applicable

Not applicable

Not applicable



Develop Training Materials X X X X X None

Apply processes defined in the applicable Training Plan

See above See above See above See above See above

A Training Center and training materials exist at the Rolls-Royce







Cycle Activities

Spec

ifica

tion

Prel

imin

ary

Des

ign

Det

aile

d D

esig

n

Cod

ing

Uni

t Tes

t

Inte

grat

ion

Valid

atio

n

UA

, Lat

er o

r Aud

it *

Doc

Nr.






upgrade project


upgrade project



upgrade project



Comments

Validate the Training Program X X X X X None



Implement the Training Program X X X X X X X None



Meylan, France facility.


Table 3.10-1. IEC 880-1986 Compliance Matrix IEC Recommendations Rolls-Royce Practice

B1 Design procedures

B1.a Changeability

Software design shall easily allow changes

At an early design stage it should be identified which characteristics of the software to be developed and its functional requirements are likely to change during its life cycle

During further design stages modules should be chosen such that the most probable modifications result in the change of one or two modules only

Modifiability should be carefully counter- balanced with resulting overhead in run time and memory space

OSS was designed with a modular top down approach (See B1.b) to allow:

• easy addition of support for new I/O boards

• easy addition of self-diagnostics.

High level control flow and data flow is device independent.

Implementation of specific details is included in low level modules.

No trade-off for run-time and memory space has been necessary due to support of changeability.

B1.b Top-down approach

A top-down approach shall be used in design

General aspects should precede specific ones

At each level of refinement the whole system should be completely described and verified

Areas of difficulty should be identified as far as possible at an early stage in the design procedure

Principal decisions should be discussed and documented as soon as possible

After any major decision affecting other system parts, the alternatives

A top down approach was used to specify, design and code the OSS in accordance with internal rules.

The V&V verified the consistency and the completeness of the design documentation at each phase of the development cycle when compared to the prior phase.

The comparison and explanation of design choices was documented in the Preliminary Design document.

The code was documented, in order to ensure a good understanding and traceability with the design documents.



should be considered and their risks be documented

Consequences for other system parts which are implied by individual decisions should be identified

The interval between levels should be small enough to permit a clear understanding of the decision process involved within the step

The program design and development should proceed using one or more higher level descriptive formalism, such as used in mathematical logic, set theory, pseudo code, decision tables, logic diagrams or other graphic aids or problem oriented languages

As far as possible automatic development aids should be used

Documentation should be such that the specifier is able to understand and check both the design and the program

Coding should be among the final steps taken

The coding was performed after the design phase

B1.c Intermediate verification

The intermediate product shall be continuously verified (Clause A1)

It should be shown that each level of refinement is complete and consistent in itself

It should be shown that each level of refinement is consistent with the previous level

Consistency checks should be made by neutral personnel

These personnel should only mark deficiencies and not recommend any action

All phases are verified by an independent V&V.

The verification activities are documented.



B1.d Changes during development

Changes which are necessary during program development shall begin at the earliest design stage which is still relevant to the change

Changes should proceed from the general stage to the more specific stages

If any module is changed, it should be retested according to the principles described earlier, before it is reintegrated into the system

In addition the environment of the changed module should be retested, as far as it is affected by the change

Documentation of major changes should include the requirements, code parts, data areas, control flow characteristics and time aspect that were affected or not affected

Changes affecting already tested parts or the work of other persons should be evaluated and reviewed prior to incorporation

NOTE – This procedure is valid for changes that affect the work of only one person and for modifications that affect the whole system. In the latter case the recommendations of Chapter 10 apply additionally.

The changes during development are tracked by a change request. The impact on all phases is analyzed.

Before any evolution of the SW, an impact analysis is written to analyze the impact of the change.

This analysis addresses all development phases : • Requirement, • Design, • Coding, • Unit Test, • Integration • Validation.



B1.d System reconfiguration

The experience gained with any system to be adapted for new applications shall be taken into account

The state of the system should be assessed before adaptation

One should rather try to use system parts or modules with extensive operating experience than to formally verify new ones

Decided changes or amendments should proceed as recommended in Table B1.b and B1.d and Chapter 9

At code level each change should be made separately

Already verified parts or modules should be left unchanged

NOTE – Any amendment of a system that does not result in a change according to Table B1.d spoils its clarity.

The SPINLINE 3 OSS is a new development based on our experience on previous project.

This clause is not applicable



B2 Software Structure

B2.a Control and access structure

Programs and program parts shall be grouped systematically

Specific system operations should be performed by specific parts

The software should be partitioned so that aspects which handle such functions as: - computer external interfaces (e.g. devices driving, interrupt handling); - real time signals (e.g. clock); - parallel processing (e.g. scheduler); - store allocation; - special functions (e.g. utilities); - mapping standard «functions» onto the particular computer hardware; are separated from «application» programs with well defined interfaces between them

The program structure should permit the implementation of anticipated changes with a minimum of effort (see also Table B1.a)

It should be made clear which structuring methods are being used

In one processor the program system should work sequentially, as far as possible

A program or a program part should be broken down into clear and intelligible modules when it contains more than 100 executable statements

The structure of the code reflects the architecture defined in the preliminary design and detailed design documents.

The design and the code reflect the generic system architecture used in the SPINLINE 3 Platform. There is a clear separation between Operational System Software (OSS) and Plant Specific Application Software.

Functions are designed to facilitate a good understanding and facilitate the OSS testing.

The scheduling of the OSS is based on an endless loop without interrupts.

The code has been divided in clear understandable parts.



B2.b Modules

Modules shall be clear and intelligible

Each module should correspond to a specific function

A module should have only one entry. Although multiple exits may be sometimes necessary, single exits are recommended

No module should exceed a limit specified for the particular system (e.g. 50 or 100 statements, or the amount of coding which can be placed on one page. Only under special circumstances are longer modules allowed)

The interfaces between modules should be as simple as possible, uniform throughout the system and fully documented

The number of input and output parameters of modules should be limited to a minimum

It should be clearly stated which interface data are only used, only defined or redefined

[[

Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Prop]]



B2.c Operating system

Operating system use shall be restricted

Only thoroughly tested operating systems should be used ; preferably the existing operating experience should be quantitatively known

If possible no operating system should be used

If an operating system is considered necessary its use should be restricted to a few simple functions

It should contain only the necessary functions

One particular operating system function should be called always in a similar way

Device drivers should be taken from the operating system rather than specially developed

Operating system functions should be rigorously defined and should have well defined interfaces

If a dedicated operating system or a dedicated part is developed for a special safety application, these recommendations should be followed

New releases should be treated according to Tables B1.d and B1.e

Other standardized programs or program parts should be treated as operating systems

This clause is not applicable to OSS development.



B2.d Execution time

Technical process behaviour influence on execution time shall be kept low

The execution time of any system or part of a system under peak load conditions should be short compared to the execution time beyond which the system safety requirements are violated

The results produced by a sequential program shall not be dependent on either

– the time taken to execute the program, or

– the time (referenced to an independent "clock") at which execution of the programs is initiated

Execution of sequential programs which receive or transmit data from / to other sequential programs shall be synchronized with those other programs

The programs should be designed so that operations are performed in a correct sequence independent of their speed of execution

Run time differences depending on input parameters should be small

Run time differences depending on input parameters should be documented

Code parts for which execution time depends on input parameters should be short

The amount of parameters read during one computation cycle should be constant

All inputs are processed cyclically, there is no interrupt based on events.

The OSS provides a function which controls and checks the cycle time.

The cycle time is always the same.

There is no synchronization for communication, the NERVIA protocol ensures that the data used are the most recent, no waiting time

All the parameters are read in the same computation cycle.



B2.e Interrupts

The use of interrupts shall be restricted

Interrupts may be used if they simplify the system

Software handling of interrupts must be inhibited during critical parts (e.g. time critical, critical to data changes) of the executed function

If interrupts are used, parts not interruptable should have a defined maximum computation time, so that the maximum time for which an interrupt is inhibited can be calculated

Interrupts usage and masking shall be thoroughly documented

Interrupts are not used in the OSS.

[[Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Propriet]]

B2.f Arithmetic expressions

Simple arithmetic expressions shall be used instead of complex ones

Decisions should not depend on voluminous arithmetic calculations

As far as possible, simplified previously verified arithmetic expressions should be used

If voluminous arithmetic expressions are used, they should be coded so that their consistency with the specified arithmetic expression can be shown easily from the code

Only simple integer computation is performed in the OSS



B3 Self supervision

B3.a Plausibility checks

Plausibility checks shall be performed (defensive programming)

The correctness or plausibility for intermediate results should be checked as often as possible, at least to within a small percentage of computer capacity (redundancy)

Where safety related results are involved identical results should be evaluated, using different methods (diversity)

Re-try procedures should be used

The ranges of:

– input variables;

– output variables;

– intermediate parameters

should be checked, including array bound checking

Defensive programming is used in the OSS. [[Proprietary text Proprietary text

Proprietary text Proprietary text Proprietary text Proprietary t ]]



B3.b Safe output

If a failure is detected the system shall produce a well defined output

If possible, complete and correct error recovery techniques should be used

Even if correct error recovery cannot be guaranteed, failure detection must lead to well-defined output

If error recovery techniques are used the occurrence of any error shall be reported

The occurrence of a persistent error affecting the system function shall be recorded

[[

Proprietary text Proprietary text Proprietary text Prop]]

B3.c Memory contents

Memory contents shall be protected or monitored

Memory space for constants and instructions shall be protected or supervised against changes

Unauthorized reading and writing should be prevented

The system should be secure against code or data changes by the plant operator

[[Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text

Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Propr]]

The code cannot be modified by the plant operator.



B3.d Error checking

Error checking shall be performed at a detailed coding level

Counters and reasonableness traps (relay runners) should insure that the program structure has been run through correctly

The correctness of any kind of parameter transfer should be checked, including parameters type verification

When addressing an array its bounds should be checked

Called routines should check whether the calling module is entitled to do so

The run time of critical parts should be monitored (e.g. by a watchdog timer)

Assertions should be used

[[

Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text

Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text


Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Propri]]



B4 Detailed design and coding

B4.a Branches and loops

Branches and loops should be handled cautiously

Conditional and unconditional branches should be avoided as far as they obscure the relationship between problem structure and program structure, as much sequential code as possible should be used

Backward going branches should be avoided, loop statements should be used instead (only for higher level languages)

Branches into loops, modules or subroutines must be barred

Branches out of loops should be avoided, if they do not lead exactly to the end of the loop. Exception: failure exit

In modules with complex structure, macros, procedures or subroutines should be used so that structure stands out clearly

As a special measure to support program proving and verification computed GOTO or SWITCH statements as well as label variables should be avoided

Where a list of alternative branches or case controlled statements are used, the list of branch or case conditions must be an exhaustive list of possibilities. The concept of a «default branch» should be reserved for failure handling

Loops should only be used with constant maximum loop variable ranges

[[Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text

Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text P ]]



B4.b Subroutines and procedures

Subroutines or procedures should be organized as simply as possible

They should have only a minimum number of parameters

They should communicate exclusively via their parameters to their environment

All parameters should have the same form (e.g. no mixing of call by name and value)

Subroutines should have only one entry point

Subroutines should return to only one point for each subroutine call. Exception; default exit

The return point should immediately follow the point of call

[[Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text


Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text]]

B4.c Nested structures

Nested structures shall be handled with care

Nested macros should be avoided

Procedure valued parameters should be avoided

Joining of different types of program action by means of nested loop statement or nested procedures should be avoided, if they obscure the relationship between problem structure and program structure

Hierarchies of procedures and loops should be used, if they clarify the system structure

[[

Proprietary textProprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary tex]]

.



B4.d Addressing and arrays

Simple addressing techniques shall be used

Only one addressing technique should be used for each data type

Bulky computations of indexes should be avoided

Arrays should have a fixed, predefined length

The number of dimensions in every array reference should equal the number of dimension in its corresponding declaration


Proprietary text Proprietary text Proprietary te ]]



B4.e Data structures

Data structures and naming conventions shall be used uniformly throughout the system

Variables, arrays and memory cells should have a single purpose and structure. The use of equivalence techniques should be avoided

Each variable's name should reflect:

– type (array, variable, constant);

– region of validity (local, global program, module);

– kind (input, output, internal, derived, count, array length);

– significance

System parameters that can changes should be identified and their values assigned at a well defined outstanding code position

Constants and variables should be located in different parts of the memory

NOTE – Many real time program systems make use of a universally accessible or similar resource. When such global data structures are used, they should be accessed via standard resource handling procedures or via communication with standard resource manipulating tasks.



Proprietary text Proprietary text Proprietary text Propri]]

B4.f Dynamic changes

Dynamic changes to executable code shall be avoided [[Proprietary text Proprietary text Proprietary text Propri]]



B4.g Intermediate tests

Intermediate tests shall be performed during the program development

The approach to testing should follow the approach to design (e.g. during top down design testing should be made by using simulation of not yet existing system parts - stubs - ; after completion of system development this should be followed by bottom up integration testing)

Each module should be tested thoroughly before it is integrated into the system and the test results documented

A formal description of the test inputs and results (test protocol) should be produced

Coding errors which are detected during program testing should be recorded and analysed

Incomplete testing should be recorded

In order to facilitate the use of intermediate test results during final validation the former degree of testing achieved should be recorded (e.g. all paths through the module tested)

[[

Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text]]



B5 Language dependent recommendations

B5.a Sequences and arrangements

Detailed rules shall be elaborated for the arrangement of various language constructs

The recommendations should include sequence of declarations

Sequence of initializations

Sequence of non-executable code / executable code

Sequence of parameters types

Sequence of formats

Dedicated Coding rules are written for the SPINLINE 3 projects.

They provide guidance on declaration, initialization, format, and comment.

Template used for the coding activities is provided.

B5.b Comments

Relations between comments and executable or non-executable code shall be fixed by detailed rules

It should be made clear what has to be commented

The position of comments should be uniform

Form and style of comments should be uniform

Rules for comments are defined in the Coding rules of the SPINLINE 3 project.



B5c Assembler

If an assembler language is used, extended programming rules shall be followed

Branching instructions using address substitution must not be used. Branch table contents should be constant

All indirect addressing should follow the same scheme

Indirect shifting should be avoided

Multiple substitutions or multiple indexing within a single machine instruction should be avoided

The same macro should always be called with the same number of parameters

Labels should be referred to by names rather than by absolute or relative addresses

Subroutine call conventions should be uniform throughout the system and specified by further rules


Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text Proprietary text ]]

B5.d Coding Rules

Detailed coding rules shall be issued

It should be made clear, where and how code lines are to be indented

Module layout should be fixed uniformly

Further details should be regulated according to need

Coding rules are written for the SPINLINE 3 projects based on rigorous coding instructions.


Table 3.10-2. Comparison of IEC 880-1986 & NRC Branch Technical Position 7-14 Requirements

BTP 7-14 Guidance Corresponding IEC 880 Guidance

Activity Group BTP

Section

IEC

Section

Plans Plans

Software Management Plan (SMP) B.3.1.1

Software Development Plan (SDP) B.3.1.2

Software Quality Assurance Plan (SQAP) B.3.1.3 Software Quality Assurance Plan 3.2

Software Integration Plan (Sent) B.3.1.4 System Integration Plan 7.1

Software Installation Plan (Snit) B.3.1.5

Software Maintenance Plan (Saint) B.3.1.6

Software Training Plan (SMTP) B.3.1.7 Training Program, Training Plan 10.2.1, 10.2.2

Software Operations Plan (SOP) B.3.1.8

Software Safety Plan (SSP) B.3.1.9

Software Verification Plan 6.2.1 Software Verification and Validation Plan (SVVP)

B.3.1.10

System Validation Plan 8

Software Configuration Management Plan (SCMP)

B.3.1.11

Planning

Software Test Plan (STP) B.3.1.12 Commissioning Test Plan 10.1.1

Design Outputs Design Outputs

Software Requirements Specification (SRS)

B.3.3.1 Software Functional Requirements Specification 4

Requirements

Process Implementation




Activity Group BTP

Section

IEC

Section

Software Requirements Safety Analysis

V&V Requirements Analysis Report Functional Requirements Verification Report 6.1

Software Configuration Management Requirements Report

Design Outputs Design Outputs

Software Architecture Description (SAD) B.3.3.2 Program Development Report 5.3

Software Design Specification (SDS) B.3.3.3 Software Performance Specification 5.4.1


Software Design Safety Analysis

Software Design Verification Report 6.1, 6.2.2 V&V Design Analysis Report

Software Coding Verification Report 6.1, 6.2.3

Design

(Development – Design and

Coding)

Software Configuration Management Design Report

Design Outputs

Software Test Specification 6.2.3.1 Code Listings (CL) B.3.3.4

Periodic Test Program 10.3.1


Code Safety Analysis Report

Software Test Report 6.2.3.2

Implementation

(Verification)

V&V Implementation Analysis & Test Report

Periodic Test Coverage Assessment 10.3.2




Activity Group BTP

Section

IEC

Section

Software Configuration Management Implementation Report

Design Outputs

System Build Documents (SBD) B.3.3.5


Integration Safety Analysis

V&V Integration Analysis & Test Report Integrated System Verification Test Report 7.7

Integration

Software Configuration Management Integration Report

Design Outputs

None


Validation Safety Report

Periodic Tests, Test Coverage Analysis Report 10.3.2 V&V Validation Analysis & Test Report

System Validation Report 8.1

Validation

Software Configuration Management Validation Report

Design Outputs

Installation Configuration Tables (ICT) B.3.3.6

Installation

Operation Manuals (OM) B.3.3.7 User Manual 10.2.2




Activity Group BTP

Section

IEC

Section

Software Maintenance Manuals (SMM) B.3.3.8

Software Training Manuals (STM) B.3.3.9


Installation Safety Analysis

V&V Installation Analysis & Test Report Commissioning Test Report 10.1.1

Software Configuration Management Installation Report

Design Outputs

None Software Modification Request 9.2

Periodic Test Requirements 10.3.2


Change Safety Analysis

V&V Change Report Software Modification Analysis Report 9.3

Operations and Maintenance

(Maintenance and Modification, Operations)

Software Configuration Management Change Report


Appendix B : Hardware Data Sheets

This Appendix contains the following hardware data sheets for SPINLINE 3 hardware items that are described in Section 4.3 of this LTR:

• RTD conditioning board: 8PT100

• I.8PT100 interface board

• Analog input board: 16E.ANA ISO

• I.16EANA interface board

• Digital isolated input board: 32ETOR TI SR

• I.32ETOR TI interface board

• Calibrated pulse acquisition board: ICTO

• I.ICTO interface board

• Actuator drive board: 32ACT

• I.32ACT interface board

• Analog output board: 6SANA ISO

• I.6SANA interface board

• CPU board: UC25 N+

• NERVIA+ daughter board

• I.NERVIA+ interface board

• ALIM 48V/5V-24V power supply board

• I.ALIM 48 interface board

• 120VAC/48VDC and 48VDC/48-24VDC power supply chassis

• 10MBps Ethernet Hub: 4TP

• 10MBps Ethernet Hub: 3TP/2FL

• Twisted-pair to fiber optic (TP/FL) converters

• Actuation voting module: MV16

• Output relays terminal block: 8SRELAY1 and 8SRELAY2

• 32ETOR Terminal Block

• Other terminal blocks

• PCI NERVIA+ board


[[


]]