uftr-qa1-02, uftr digital control system upgrade, software ... · the scmp follows the guidance of...

UF/NRE Project ID: QA-IUFIR QUALITY ASSURANCE DOCUMENT Revision 0 Copy 1

, of 54

Project Title: UFTR DIGITAL CONTROL SYSTEM UPGRADE

UFTR-QA1-02, Software Configuration Management Plan (SCMP)

Prepared by, Reviewed by,

Matthew Marzano and Dr. Gabriel Ghita

... ... (Signature)

Date:

Prof. DuWayne Schubring

Date: .. nW. .'

Approved by,

Prof Alireza Haghighat

. .. A... ./.J. (Signature)

Date: .,../4.7. /. -..

UFINRE Prepared by Reviewed by QA-I, UFTR-QAI-02Name: Name: Revision 0 Copy .1

UFTR Date : Initials: Date : Initials: of 54

THE DISTRIBUTION LIST OF THE DOCUMENT

UFINRE Prepared by Reviewed by QA-1, UFTR-QAI-02Name: Name: Revision 0 Copy 1


THE LIST OF THE REVISED PAGES OF THE DOCUMENT

Revision no. Reviewed by Approved by The Modified Pages Date

UFINRE Prepared by Reviewed by QA-1, UFTR-QAI-02

UFTR Name: Name: Revision 0 Copy IDate: Initials: Date: Initials: of 54

TABLE OF CONTENTS

1. Introduction .............................................................................................................................. 8

1.1 Purpose ............................................................................................................................. 8

1.2 Scope and Applicability ............................................................................................. 9

1.3 References ........................................................................................................................ 9

1.3.1 UFTR Documents ......................................................................................... 91.3.2 AREVA NP Inc. Documents ...................................................................... 91.3.3 Industry Standards .................................................................................... 101.3.4 NRC Documents ......................................................................................... 10

1.4 Definitions, Abbreviations And Acronyms ............................. 10

1.4.1 Definitions .................................................................................................... 10

1.4.2 Abbreviations And Acronyms ................................................................. 15

2. SCM M anagement ................................................................................................................. 17

2.1 Organization .................................................................................................................. 17

2.2 SCM Responsibilities .................................................................................................... 17

2.3 Applicable Policies, Directives, and Procedures ................................................... 18

3. SCM Activities ....................................................................................................................... 19

3.1 Configuration Identification ................................................................................... 19

3.1.1 Identifying Configuration Items ............................................................... 193.1.2 Naming Configuration Items .................................................................... 20

3.1.2.1 Identification of Software Components ........................................ 203.1.2.2 CRC Checksums ............................................................................ 21

3.1.2.3 Identification of TXS System Software ......................................... 22

3.1.2.4 Identification of TXS Application Software ............................... 233.1.2.5 Identification of Downloaded Software ........................................ 23

3.1.3 Acquiring Configuration Items ............................................................... 24

3.2 Configuration Control ............................................................................................. 24

3.2.1 Change Control ........................................................................................... 243.2.2 Configuration and Control Board (CCB) ............................................... 243.2.3 Code Control ................................................................................ .................. 24

3.2.4 TXS System and Tools Software Configuration Control ....................... 253.2.5 TXS Project-Specific Software Baseline Control .................................... 26

UFINRE Prepared by Reviewed by QA-), UFTR-QAI-02

UFTR Name: Name: Revision 0 Copy 1Date: Initials: Date: Initials: of 54

3.2.5.1 CM Procedure during Initial Generation of TXS Application

Software ........................................................................................... 263.2.5.1.1 Engineering ............................................................................. 27

3.2.5.1.1.1 Implementation of the Design in the Engineering Database

using SPACE .................................................................... 273.2.5.1.1.2 Functional Tests of Design ............................................. 27

3.2.5.1.2 Code Generation ...................................................................... 273.2.5.1.2.1 Check Identity of TXS System Software Configuration ...27

3.2.5.1.2.2 Setup of Engineering Database ...................................... 273.2.5.1.2.3 Backup of Engineering Database prior to Code Generation

............................................................................................. 273.2.5.1.2.4 Code Generation ............................................................. 283.2.5.1.2.5 Compiling / Linking / Locating of TXS Code ............... 28

3.2.5.1.2.6 Generation of Application Code for the TXS Gateway .... 283.2.5.1.2.7 Checksums of the Complete Code Directory ................ 29

3.2.5.1.2.8 Backup of the Specification Data after Code Generation.293.2.5.1.2.9 Creation of Software and Hardware Listing ................ 293.2.5.1.2.10 Analysis of MIC files .................................... 29

3.2.5.1.2.11 List of Changeable Parameters ...... ...... ........... 29

3.2.5.1.2.12 Software Release CD ...................................................... 303.2.5.1.3 Software Download .................................................................. 30

3.2.5.1.3.1 Creation of the Online Database.................................... 303.2.5.1.3.2 Download Procedure ...................................................... 30

3.2.5.2 CM Procedure during Modification of TXS Application Software

-................................ ..................................... 313.2.5.2.1 Engineering ............................................................................. 31

3.2.5.2.1.1 Tracking Changes ...... ..................................................... 31,3.2.5.2.1.2 Modification of the Engineering Database using SPACE.31

3.2.5.2.1.2.1 Software Release Modifications ............................................. 323.2.5.2.1.2.2 Interim Software Release Modifications .............................. 33

3.2.5.2.1.3 Functional Tests of Database Modifications ................. 34

3.2.5.2.2 Code Generation ...................................................................... 343.2.5.2.2.1 Check Identity of TXS System Software Configuration ...343.2.5.2.2.2 Setup of Engineering Database ...................................... 343.2.5.2.2.3 Backup of the Engineering Database prior to Code

Generation ........................................................................ 353.2.5.2.2.4 Check of Identity and Consistency of the previously

generated C Code ............................................................. 353.2.5.2.2.5 Code Generation ............................. 35

3.2.5.2.2.6 Compiling / Linking / Locating of TXS Code ............... 363.2.5.2.2.7 Generation of Application Code for TXS Gateway ........... 36

UF/NRE Prepared by Reviewed by QA-I, UFTR-QA I-02


3.2.5.2.2.8 Checksums of the complete Code Directory ................. 363.2.5.2.2.9 Backup of the Specification Data after Code Generation.373.2.5.2.2.10 Creation of Software and Hardware Listings ................ 373.2.5.2.2.11 Analysis of the MIC-files ................................................ 373.2.5.2.2.12 List of Changeable Parameters ...................................... 373.2.5.2.2.13 Software Release CD ........................................... 37

3.2.5.2.3 Software Download ................................................................ 383.2.5.2.3.1 Creation of the new Online Database .............. 383.2.5.2.3.2 Download Procedure ...................................................... 383.2.5.2.3.3 System Normalization ...................................................... 393.2.5.2.3.4 Software Download after Module Replacement ........... 393.2.5.2.3.5 Final Documentation ................................. ........................... 39

3.2.5.3 CM Procedure during Parameter Modifications ....................... 393.2.5.3.1 Changeable Parameters ........................................................ 403.2.5.3.2 Verification of Parameter Changes ...................................... 403.2.5.3.3 Constants ................................................................................. 40

3.2.6 Media Control ........ ..................................................................................... 413.2.6.1 Media Control for Documents ...................................................... 413.2.6.2 Media Control for TXS System Software and Additional Software

... ................................................................................. 413.2.6.3 Media Control for SPACE Function Diagrams, Test Scripts, and

Service Scripts ............................................................................... 413.2.6.4 Software Release CD ...................................................................... 41

3.3 Configuration Status Accounting ........................................................................... 42

3.4 Configuration Audits and Reviews ......................................................................... 42

3.4.1 Software Configuration Management Plan Reviews ............................. 433.4.2 Physical Configuration Audits .................................................................. 433.4.3 Functional Configuration Audits ............................................................. 433.4.4 Software Process Audits ............................................................................ 44

3.5 Interface Control ...................................................................................................... 44

3.5.1 Organizational Interfaces ........................................................................... 443.5.2 Project Software Interfaces to External Items ........................................ 44

3.6 Subcontractor/Vendor Control ........................................ ....................................... 44

3.7 Anomalies Identified after Release ......................................................................... 45

4. SCM Schedule ........................................................................................................................ 46

5. SCM Resources ...................................................................................................................... 47

5.1 Tools ............................................................................................................................... 47

UFINRE Prepared by Reviewed by QA-I, UFTR-QAI-02


5.1.1 Tools Overview ................................................. e .............................................. 475.1.2 Tools for Application Software .................................................................. 475.1.3 Tools for Sim ulation and Verification ................................................. ........ 47

5.2 Personnel ........................................................................................................................ 47

5.3 Software Librarian ................................................................................................. 47

6. SCM Plan Maintenance .............................................. 48

6.1 Responsibility ................................................................................................................ 48

6.2 Updates ........................................................................................................................... 48

6.3 Change Approval ...................................................................................................... 48

6.4 Change Distribution ...................................................................................................... 48

UFMRE Prepared by Reviewed by QA-1, UFTR-QAI-02

UFTR Name: Name: Revision 0 F Copy 1Date: Initials: Date: Initials: of 54

1. Introduction

The UFTR Digital Control System Upgrade Project is executed according to the project

phases defined in UFTR "Quality Assurance Project Plan (QAPP)," /3/, as follows:

Phase 1 Project Startup/Conceptual EngineeringPhase 2 Basic HW/SW Engineering

Phase 3 Detailed HW/SW Engineering

Phase 4 Manufacturing

Phase 5 TestingPhase 6 Installation and Commissioning

Phase 7 Final Documentation

During this process, the configuration of the software and its documentation is required to

be controlled by this Plan. This Plan controls:

a. Software code that is generated and loaded onto the TELEPERM XS (TXS) I&C

System

b. Documentation for the software (e.g., Software Requirements Specification).

Software Configuration Management (SCM) is the process that identifies the software

configuration items (CIs), identifies System and Application Software anomalies, controls

changes to the Application Software, records and reports the status of the changes, and

verifies the correctness and completeness of the released software.

Per IEEE Std 828-1990, /18/, processes and activities are established for:

* Identification and control of interface documentation

* Identification and establishment of baselines

e Review, approval, and control of software design and code

* Tracking and reporting of design changes

* Audits and reviews of the evolving software product

1.1 Purpose

The Software Configuration Management Plan (SCMP) is established to provide

the method and tools to identify and control the TXS Application Software developed for

the UFTR Reactor Protection System (RPS).The SCMP follows the guidance of IEEE Std 828-1990, /18/, and ANSI/IEEE Std

1042-1987, /20/, as endorsed in Regulatory Guide 1.169, /21/, with the exception of the

use of the configuration control board. The UFTR method meets the intent of IEEE Std

828-1990, /18/, and ANSI/IEEE Std 1042-1987, /20/.The intended audience and primary users of the SCMP are those that are planning

and executing SCM activities or conducting SCM audits.

UFINRE Prepared by Reviewed by QA-l, UFTR-QA1-02Name: Name: Revision 0 Copy IUFTRDate: Initials: Date: Initials: of 54

1.2 Scope and Applicability

This Plan applies to all software and related documentation for the design,

modification, and testing of TXS Application Software developed for the UFTR digital

control upgrade. In addition, this Plan applies to Graphic Service Monitor (GSM) Screen

development and the Qualified Display System (QDS). The Plan is applicable from theBasic Design Phase to the completion of the Final Documentation Phase. At the

completion of the Final Documentation Phase, SCM is controlled by UFTR's Software

Quality Assurance Plan (SQAP), /4/, and UFTR's Software Library and Control, /10/.

Configuration Management of the Application Software is the responsibility of theUFTR Software Development Group. The identification and reporting of Application

Software anomalies apply to all personnel involved in the UFTR Digital Control Upgrade

Project.This SCMP does not apply to the TXS system platform or software development

tools or changes. The TXS system platform and tools software development and changes

are performed by AREVA NP GmbH (Germany) on a project-independent (generic)

basis and are handled by their respective Configuration Management Plan. The TXS

system platform software is purchased for the UFTR digital upgrade. Each item of

project-independent software purchased from AREVA NP GmbH is delivered with a

Certificate of Conformance (CoC). Each CoC for the project independent software is

reviewed to be current and applicable for its intended purpose.

1.3 References

1.3.1 UFTR Documents

/1/ UFTR-QAP, "Quality Assurance Program (QAP)"

/2/ UFTR-QAP-0 1 -P, "Conduct of Quality Assurance"

/3/ UFTR QA1-QAPP, "Quality Assurance Project Plan (QAPP)"

/4/ UFTR-QA 1-01, "Software Quality Assurance Plan (SQAP)"/5/ UFTR-QA1 -03, "Software Verification and Validation Plan (SVVP)"

/6/ UFTR-QA1-09, "Software Operations and Maintenance Plan"

/7/ UFTR-QAI-10, "Software Training Plan"

/8/ UFTR-QA 1-11, "Software Reviews and Audits"

/9/ UFTR-QA1-105, "Cyber-Security"/10/ UFTR-QAI-109, "Software Library and Control"

/ 11/ UFTR-QA I-113, "Software Generation and Download"

1.3.2 AREVA NP Inc. Documents

/12/ AREVA NP Inc. Document No., 01-1007861-00, "TELEPERM XS

Software Authentication Tools reflist and scanmic (TXS Software

release 3.0.0 and Higher for LINUX) User Manual TXS-1034-76-

V1.0/02.03"

Prepared by Reviewed by QA-), UFTR-QAI-02U Name: Name: Revision 0 copy IUFTR Date: Initials: Date: . Initials: of 54

/13/ AREVA NP Inc. Document No. 01-1007773-01, "TELEPERM XSCode Generation (for TXS Software Release 3.0.0 and Higher for

LINUX) User Manual"

/14/ AREVA NP Inc. Document No. 01-5044046-01, "TELEPERM XSSIVAT-TXS Simulation Based Validation Tool (version 1.5.0 and

higher) User Manual TXS-1047-76-V2.1"

/15/ AREVA NP Inc. Document No. 01-1007859-00, TELEPERM XSSPACE Editor (TXS Software release 3.0.0 and Higher for LINUX)

User Manual"

/16/ AREVA NP Inc. Document No. 01-1007770-00, TELEPERM XSDatabase Administration Tool dbadmin (TXS Software release 3.0.0

and Higher for LINUX) User Manual

1.3.3 Industry Standards

/17/ IEEE Std 610.12-1990, "Standard Glossary of Software Engineering

Terminology"

/18/ IEEE Std 828-1990, "Standard for Software Configuration

Management Plans"

/19/ IEEE Std 1012-1998, "Standard for Software Verification and

Validation"

/20/ ANSI/IEEE Std 1042-1987, "An American National Standard IEEE

Guide to Software Configuration Management"

1.3.4 NRC Documents

/21/ Regulatory Guide 1.169, "Configuration Management Plans for Digital

Computer Software Used in Safety Systems of Nuclear Power Plants",

September 1997

1.4 Definitions, Abbreviations And Acronyms

1.4.1 Definitions

Anomaly, [IEEE Std 1012-1998, /19/]:

Any condition that deviates from the expected condition based on requirements,

specification, design, documents, user documents standards, etc., or from

someone's perceptions or experiences. Anomalies may be found during, but are notlimited to, the review, test, analysis, compilation, or use of software products or

applicable documentation.

Application Software

The plant specific functionality of the TXS I&C System that is documented andgenerated by the SPACE Engineering Tool. The platform System Software uses this



configuration data in order to carry out the application specific functionality of theI&C system.

Baseline, [IEEE Std 61 0.12-1990, /17/]:

A specification or product that has been formally reviewed and agreed upon, thatthereafter serves as the basis for further development, and that can be changed onlythrough formal change control procedures. Formal review and agreement meansthat responsible management has reviewed and approved a baseline. Baselines aresubject to change control. (Reg. Guide 1.169, /21/)

Baseline Management, [IEEE Std 610.12-1990, /17/]:

In configuration management, the application of technical and administrativedirection to designate the documents and changes to those documents that formallyidentify and establish baselines at specific times during the life cycle of aconfiguration item.

Component, [IEEE Std 610.12-1990, /17/]:

One of the parts that makes up a system. A component may be hardware orsoftware and may be subdivided into other components.

Configuration, [IEEE Std 610.12-1990, /17/]:

(1) The arrangement of a computer system or component as defined by the number,nature, and interconnections of its constituent parts. (2) In configurationmanagement, the functional and physical characteristics of hardware or software asset forth in technical documentation or achieved in a product.

Configuration Control, [IEEE Sid 610.12-1990, /17/]:

An element of configuration management, consisting of the evaluation,coordination, approval or disapproval, and implementation of changes to CIs afterformal establishment of their configuration identification.

Configuration Control Board (CCB), [IEEE Std 610.12-1990, /17/]:

A group of people responsible for evaluating and approving or disapprovingproposed changes to CIs, and for ensuring implementation of approved changes.

Configuration Identification, [IEEE Std 610.12-1990, /17/]:

An element of configuration management, consisting of selecting the CIs for asystem and recording their functional and physical characteristics in technicaldocumentation. The current approved technical documentation for a configurationitem as set forth in specifications, drawings, associated lists, and documentsreferenced therein.

UFINRE Prepared by Reviewed by QA-), UFTR-QA1-02Name: Name: Revision 0 Copy 1UFTRDate: Initials: Date: Initials: of 54

Configuration Item (CI), [IEEE Std 610.12-1990, /17/]:

An aggregation of hardware, software, or both, that is designated for configuration

management and treated as a single entity in the configuration management process.

Configuration Management (CM), [IEEE Std 610.12-1990,/17/]:

A discipline applying technical and administrative direction and surveillance to:

* Identify and document the functional and physical characteristics of aconfiguration item

* Control changes to those characteristics

* Record and report change processing and implementation status

" Verify compliance with specified requirements

Configuration Status Accounting, [IEEE Std 610.12-1990, /17/]:

An element of configuration management, consisting of the recording and reporting

of information needed to manage a configuration effectively. This information

includes a listing of the approved configuration identification, the status ofproposed changes to the configuration, and the implementation status of approved

changes.

Control Point, [IEEE Std 828-1990, /18/]:

A project agreed on point in time or times when specified agreements or controls

are applied to the software CIs being developed, e.g., an approved baseline orrelease of a specified document/code.

Functional Configuration Audit, [IEEE Sid 610.12-1990,/17/]:

An audit that is conducted to verify that the development of a configuration item

has been completed satisfactorily, that the item has achieved the performance andfunctional characteristics specified in the functional or allocated configurationidentification, and that its operational and support documents are complete and

satisfactory.

Functional Requirements Specification (FRS)

A document that is provided by the customer or his agent that describes in detail thefunctions of the system to be installed new or replaced. The FRS will include both

hardware and software functions of the system. This document can be called by adifferent name, but whatever document is provided by the customer to meet this

function will fit this definition.

Interface, [IEEE Std 610.12-1990, /17/]:

* A shared boundary across which information is passed. This boundary includes

design interfaces between design organizations (Reg. Guide 1.169, /21/)

UFINRE Prepared by Reviewed by QA-I, UFTR-QA 1-02UF/NR Name: Name: Revision 0T Copy I

Date: Initials: Date: Initials: of 54

* A hardware or software component that connects two or more other components

for the purpose of passing information from one to the other

* To connect two or more components for the purpose of passing information

from one to the other

" To serve as a connecting or connected component as in (2)

Interface Control, [IEEE Std 610.12-1990, /17/]:

In configuration management, the process of:

* Identifying all functional and physical characteristics relevant to the interfacing

of two or more CIs provided by one or more organizations, and

* Ensuring that proposed changes to these characteristics are evaluated and

approved prior to implementation.

MAC Address

Media Access Control Address - a 48-bit unique identifier assigned to network

communication hardware, commonly expressed as a string of six octets in

hexadecimal representation.

Open Item

Any item which constitutes an error or anomaly from the required status orcondition of a properly completed project. Open Items are each given a record witha unique (to the project) identifier and maintained by the Project Coordinator. The

entry contains information to track the cycle of the item from initiation to finalresolution.

Physical Configuration Audit, [IEEE Std 610.12-1990, /17/]:

An audit that is conducted to verify that a configuration item, as built, conforms to

the technical documentation that defines it.

Release, [IEEE Std 1042-198 7, /20/]:

A term that is used to designate certain promotions of CIs that are distributedoutside the development organization.

Scanmic, [TXS Software Authentication Tools reflist and scanmic, /12/]:

TXS software authentication tool that is used to analyze the software configuration

of loadable code (MIC file), as well as:

* Read the version strings of the application software components contained in aloadable MIC file from the MIC file itself

* Calculate the CRC Checksum for each software segment in the MIC file

* Calculate the CRC Checksum for the entire MIC file

UFINRE Prepared by Reviewed by QA-I, UFTR-QA I-02Name: Name: Revision 0 Copy 1UFTRDate: Initials: Date: Initials: of 54

This information can be output to a list that serves to document the generated

software version. Differences in the software configuration between the old version

and the new version can be determined from these lists and verified.

SIVAT, [TXS SI VA T, /14/]:

Allows the functionality of the I&C system engineered in SPACE to be tested by

simulation based on the code generated by the FDG code generator and the RTEcode generator. This enables engineering errors to be detected at an early stage.

The objective of the test is to verify that the requirements have been translated intofunction diagrams without errors, and that the software automatically generated

from these function diagrams provides the functionality required in terms of input

and output response. The tests cover interface to the RTE, use of correct functionblocks and whether they have been correctly connected and parameterized. The

failure of I/O modules, processing modules and data messages can be simulated.

The tests are run using scripts that define the input and output signals of the I&C

system and the simulation run. The test results are recorded in log files and plots forfurther evaluation. Process models can also be linked into the simulator to perform

closed-loop tests.

Software, [IEEE Std 610.12-1990, /17/]:

Computer programs, procedures, and possibly associated documentation and datapertaining to the operation of a computer system. Types of software included for a

TXS project are System Software, Application Software and tools.

Software Library, [IEEE Std 610.12-1990, /17/]:

A controlled collection of software and related documentation that is designed toaid in software development, use, or maintenance. Types include master library,

production library, software development library, software repository, and system

library.

Software Life Cycle, [IEEE Std 610.12-1990, /17/]:

The period of time that begins when a softwareproduct is conceived and ends when

the software is no longer available for use.

SPACE, [TXS SPACE, /15/1:

Engineering system comprising the tools used for the engineering and maintenanceof the TXS I&C software. Engineering in this context refers to the overall process

of creating and testing the I&C software. SPACE tools cover the following:

* Specification of the I&C functions and hardware topology

* Automatic code generation

* Software authentication (reflist and scanmic)

* Software Loading

UF/NRE Prepared by Reviewed by QA-I, UFTR-QA 1-02


* Load Analysis tool* Database administration

Unit, [IEEE Std 610.12-1990, /17/]:

" A separately testable element specified in the design of a computer softwarecomponent

" A logically separable part of a computer program* A software component that is not subdivided into other components

Version, [IEEE Sid 610.12-1990, /17/]:

An initial release or re-release of a computer software configuration item,associated with a complete compilation or recompilation of the computer softwareconfiguration item.

V&V (Verification and Validation), [IEEE Sid 610.12-1990,/17/]:!

The process of determining whether the requirements for a system or componentare complete and correct, the products of each development phase fulfill therequirements or conditions imposed by the previous phase, and the final system orcomponent complies with specified requirements.

1.4.2 Abbreviations And Acronyms

ANSI American National Standards InstituteCCB Configuration Control BoardCD Compact DiscCD-ROM Compact Disc - Read Only MemoryCI Configuration ItemCM Configuration ManagementCoC Certificate of ComplianceCRC Cyclic Redundancy CheckECP Engineering Change ProposalEEPROM Electrically Erasable Programmable Read Only MemoryFAT Factory Acceptance Test

FDG Function Diagram GroupFEPROM Flash Erasable Programmable Read Only MemoryFRS Functional Requirements SpecificationGSM Graphic Service MonitorI&C Instrumentation and ControlI/O Input/OutputICS I&C SystemsID IdentificationIEEE Institute of Electrical and Electronic EngineersIS Information System



IV&V Independent Verification & ValidationMAC Media Access ControlMIC An executable file in the Micros systemMSI Monitoring and Service InterfaceOAC Operator Aid ComputerQA Quality AssuranceQDS Qualified Display SystemRPS Reactor Protection SystemRTE Run Time EnvironmentSCM Software Configuration ManagementSCMP Software Configuration Management PlanSDD Software Design DescriptionSDQA Software & Data Quality AssuranceSIVAT Simulation Based Validation ToolSPACE Specification and Coding EnvironmentSRS Software Requirement SpecificationStd StandardSM Service Monitor

SU Service UnitTXS TELEPERM XSV&V Verification & Validation

UFINRE Prepared by Reviewed by QA-I, UFTR-QAI-02Name: Name: Revision 0 f Copy IUFTRDate: Initials: Date: Initials: of 54

2. SCM Management

2.1 Organization

The project specific organizational units, their responsibilities and relationshipswith regard to TXS Platform software development are discussed in the UFTR SQAP,/4/.

The Software Development Lead shall be responsible for the quality of the safetysoftware under development and the SCM of that software. In addition, QualityAssurance oversight shall be provided per the UFTR "Quality Assurance Program(QAP),"/1/, and UFTR SQAP, /4/. The Project manager provides managerial (includingbudgeting and scheduling) and technical independence between the software design andVerification & Validation (V&V) efforts, the Software Development and IndependentV&V (IV&V) groups.

2.2 SCM Responsibilities

The general responsibilities for SCM are summarized in Table 2.2-1. AConfiguration Control Board (CCB) will be responsible for oversight of SCM activities.The objective, authority, membership, and procedures of the CCB are defined in Section3.2.2.

Table 2.2-1 SCM Responsibilities Assignments

Software SoftwareSCM Activity Project Project Developmen Development Project QA Iv&v

Manager Coordinator t Lead Group Team

Configuration Approve OriginateIdentification

BaselineEstablishment Approve Approve Originate

Change Identification Originate Originate Originate Originate Originate Originate Originate(Open Items)

Open Item Approve Approve Approve/ OriginateEvaluation /Originate /Originate OriginateOpen Item

Implementation Originate Originate Originate Originate

Open ItemVeifctinOriginate Originate Originate Originate

Open Item Approve Approve ApproveClosure

Configuration Status Approve Approve OriginateAccounting

Configuration Audits Originate/ Originate Respond Originate Originateand Reviews Respond

Interface Approve Administer Administer/ AdministerControl /Approve Approve

Configuration Approve Administer Administer! AdministerControl /Approve Approve

MaintainRelease Contron Release V&V

Release Documents to Dont Document toRelease Lb ay DocumentLi r yLibrary Libry Library

Approve Release Release Administer/Software Controlled Controlled MaintainRelease Release Software to Software to (Software

Library Library Librarian)

Subcontractor and Request Originate/Vendor Control Request Approve


UFTR Name: Name: Revision 0 f Copy 1Date: Initials: Date: Initials: of 54

2.3 Applicable Policies, Directives, and Procedures

All activities in this SCMP shall be conducted per the requirements of UFTRSQAP, /4/, UFTR "Conduct of Quality Assurance," /2/, and UFTR QAP, /1/.

UFINRE Prepared by Reviewed by QA-1, UFTR-QAI-02Name: Name: Revision 0 Copy 1UFTRDate: Initials: Date: Initials: of 54

3. SCM Activities

3.1 Configuration Identification

Configuration identification shall be applied to all the UFTR Digital Control ProjectCIs, specifically the safety related TXS Application and System Software, tools forengineering testing, and the associated documentation. A software configuration shall bemade up of software elements and the associated documentation.

The specific CIs and their association with a specific phase of the project areidentified in Section 3.1.1.

3.1.1 Identifying Configuration Items

Table 3.1.1-1 identifies the CIs and the phase when each document isgenerated by UFTR personnel.

Table 3.1.1-1 UFTR Digital Control System Upgrade Project Configuration Items

Phase When GeneratedConfiguration Item (CI) (e . nrdcin_______________________________________________(See 1.0 Introduction)

Software Configuration Items List (document) Phase 2, 3, 5, 6 &7System Architecture (document) Phase 2 Basic DesignHardware Parameters Listing (document) Phase 2 & 3Restricted Information (document) Phase 2 & 3Software Configuration Management plan (this document) Phase 2 Basic DesignSoftware Safety Plan (document) Phase 2 Basic DesignID Coding Concepts (document) Phase 2 Basic DesignSoftware Requirements Specification (document) Phase 2 Basic Design1V&V Activity Phase Summary Reports Phase 2, 3, 5, 6 &7Software Design Description (document) Phase 3 Detailed DesignTXS Application Software (software) (Software Release) Phase 3 Detailed DesignApplication Software Code (SPACE function diagrams) (document) Phase 3 Detailed DesignCode Configuration (document) Phase 3 Detailed DesignChangeable Parameters List (document) Phase 3 Detailed DesignSoftware Generation and Download Procedure (document) Phase 3 Detailed DesignSoftware Test Plan (document) Phase 3 Detailed DesignSoftware Test Specification/Procedures (document) Phase 3 Detailed DesignSoftware Test Reports (document) Phase 3 Detailed DesignFAT Plan (document) Phase 5 TestingSoftware FAT Specifications/Procedures (document) Phase 5 TestingFAT Reports (document) Phase 5 TestingGSM DeliverablesGSM Screen Code (software) (Software Release) Phase 3 Detailed DesignGSM Software Requirements Specification (document) Phase 2 Basic DesignGSM Code Documentation (document) Phase 3 Detailed DesignQDS DeliverablesQDS Software Requirements Specification (document) Phase 2 Basic DesignQDS Code (software) (Software Release) Phase 2 Basic DesignQDS Code Documentation (document) Phase 3 Detailed Design

Prepared by Reviewed by QA-), UFTR-QAI-02UF/R Name: Name: Revision 0 Copy IUFTR


Table 3.1.1-2 identifies those System Software products that are generated byAREVA NP Inc. ICS or its qualified vendors and become CIs on this project.

Table 3.1.1-2 AREVA NP Inc. or its qualified vendors Configuration Items

Configuration Item (CI) Phase When GeneratedConfiguration___tem_(CI__(See 1.0 Introduction)

TXS System Platform Software (GmbH-software) Phase 2 Basic DesignTXS Service Unit Software (GmbH-software) Phase 2 Basic DesignTXS Simulation Software SIVAT (GmbH-software) Phase 2 Basic DesignTXS Gateway Software (GmbH-software) Phase 2 Basic DesignTXS System Platform Documentation (GmbH-documents) Phase 2 Basic DesignSPACE Engineering System Software Configuration (GmbH-documents) Phase 2 Basic DesignSPACE Engineering System Software CoC (GmbH-documents) Phase 2 Basic DesignQDS Software (GmbH-software) Phase 2 Basic Design

CIs that are documents shall be approved in accordance with the UFTR QAP,/1/.

Baselines shall be established for the control of the CIs. The Control Pointsfor the CIs (baselines) coincide with UFTR Project Milestones (i.e., issue of SRS,issue of SDD, issue of code, and completion of testing) as outlined in the UFTRQAPP, /3/. Throughout the software development life cycle, at the discretion of theSoftware Development Lead, releases may be performed. The current status of allCIs at each baseline shall be reflected in the Software CIs List.

Identification of the CIs during the Software Life Cycle is conducted inaccordance with Section 3.1.2 of this procedure. Control of the CIs during theSoftware Life Cycle is conducted in accordance with Section 3.2 of this procedure.

Configuration control of documents associated with the System andApplication Software is established through the UFTR QAP, /1/.

3.1.2 Naming Configuration Items

Each System and Application Software Configuration Item shall be assigneda unique version number.

Assigning a Configuration Item number for software items shall be done inaccordance with UFTR "Software Library and Control," /10/.

3.1.2.1 Identification of Software Components

The precompiled components of the TXS system software and all TXStools shall be labeled with a unique version identifier, which consists of aversion number and the release date. This identification is part of each softwarecomponent. It is written into the original code in form of identification strings(ID-strings).

The SPACE code generators produce the source code for the applicationsoftware, which also contains ID-strings (Reference /13/). The applicationsoftware shall also be labeled with a unique version identifier, which consistsof a version number and the release date. This ensures that all generated

UF/NRE Prepared by Reviewed by QA-), UFTR-QAI-02Name: Name: Revision 0 Copy IUFTR Date: Initials: Date: Initials: of 54

function diagram modules and function diagram group (FDG) modules areunambiguously identifiable.

A cyclic redundancy check (CRC) checksum shall be calculated andrecorded as part of the respective Software Release documentation to check theidentity of whole software configuration for each file of the TXS systemsoftware and application software,.

3.1.2.2 CRC Checksums

In the data processing world, CRC methods are applied for identificationof data files in a directory. These CRC checksums are created over all bits ofdata files in a directory and are extremely sensitive for modifications of thisfile in any regard. For this purpose the authentication tool reflist shall be used.The reflist creates CRC checksums recursively for all the subdirectories andfiles within a directory and outputs them in a list. The date of the last changefor the file can also be output.

Unless specified otherwise, reflist generates an 8-digit CRC32 inaccordance with POSIX standards. This is a widespread algorithm providinggood security against random errors during data transport and storage. Theprobability that any two files have the same checksum is approximately2xl0-10 . A typical checksum computed using CRC-32 looks like this:1F77BED5.

In addition, CRC checksums can also be generated across all filesaccording to the following standards:

* CRC 16 acc. to CCITT, 4-digit: This is a widespread algorithmproviding adequate security against random errors during datatransport and storage. Due to the 4-digit checksum, the probability ofany two files possessing the same checksum is significantly largerthan CRC32, and is 2x10-5. Therefore, it is possible to construct fileswith identical checksums but different contents.

* MD55 acc. to RFC 1321, 32-digit: This is a popular algorithmproviding superior security against random errors. Using this method,the probability of having identical checksums is 3x1 0-39.

Checksums according to CRC32 are standard for the TXS platform. Thescope of files to be processed can be specified as a list of files and/ordirectories in the call or in an input file. Alternatively, the scope can be readfrom the standard input. This makes it possible to select the scope by means ofshell commands and for these files to be processed by reflist.

The reflist outputs the resulting list to the screen as standard. It can,however, also be redirected to a file.


UFTR Name: Name: Revision 0 f Copy 1Date: Initials: Date: Initials: of 53

This method shall be used for identification of the TXS system software,for project specific add-ons, for the application software implemented on anengineering platform (engineering workstation), as well as for softwaredownloaded into the I&C system.

3.1.2.3 Identification of TXS System Software

The identity of the TXS System Software is provided by AREVA NPwith the TXS platform and tools required for the UFTR digital controlupgrade. The identification process for the TXS System Software prior to andduring installation is described below.

The design specification of each TXS system software componentincludes a structured overview of all configuration elements. This overviewcovers all levels of the life cycle of the component, from the requirements tothe test. The version management of the configuration elements is carried outwithin a version management system. The implementation description formsthe decisive document on the implementation level. The implementationdescription of each software component contains a detailed description of thedevelopment results as well as the code and the installation configuration.

An installation configuration contains all data files which are deliveredwithin a TXS installation: executable programs, DLLs, object modules, pre-links, header files, etc.

For each data file included in the installation configuration, the followinginformation shall be given:

0 File name,* Version and date,0 File size,0 Howard Vigorita (HV)-CRC checksum.

The implementation documents, as well as the complete developmentdocumentation shall be subject to external (third party) evaluation. Thisincludes the fact that the installation configurations as well as the HTV-CRCchecksums of the data files are listed in the test certificate of a qualified TXSsystem software component.

The HV-CRC checksums of the data files have to be calculated on-site(upon delivery to the UFTR) and compared with the certified checksums inorder to prove the identity of the system software components contained in agiven TXS installation. The components of the TXS operating system softwareare delivered in the form of pre-links.

That means that the object files of the qualified components (identifiedwith HV-CRC checksums) are linked together and the created pre-link isidentified by a HV-CRC checksum, too.

UF/NRE Prepared by Reviewed by QA-I, UFTR-QA 1-02Name: Name: Revision 0 Copy 1UFTRDate: Initials: Date: Initials: of 53

The CRC checksum of the complete TXS system software installation("SPACE directory") forms a unique identification of the reference version.The system installation contains (generic) software components.

The configuration list must be verified using the TXS tool reflist. Thereflist will calculate and record CRC checksums of all files in the SPACEdirectory. The comparison of this listing with the reference listing stored on theinstallation CDs shall be done using the LINUX diff command.

3.1.2.4 Identification of TXS Application Software

The application software is created strictly according to the single sourceprinciple. The process is divided into three phases:

* Application specification in the Engineering Database," Code generation,* Creation of the MIC files (executable code).

The result of each phase can be identified using CRC checksums:

" By using the tool-supported conversion of Engineering Databasetables into ASCII backup files (dbadmin -unload) and calculation ofCRC checksums of these files (reflist), a certain version of theapplication software can be identified unambiguously. These backupfiles form an unambiguous image. Thus the database created byrestoring these files is identical to the original one.

" The code generation results are identified by creation of a CRCchecksum of the complete software directory using reflist.

" The executable code (one MIC file per CPU) is identified by creationof CRC checksums for each of these files using reflist.

3.1.2.5 Identification of Downloaded Software

The MIC files are downloaded into memory areas (segments) of theFlash Erasable Programmable Read Only Memory (FEPROM) of therespective SVE1/SVE2 module in a centralized way (using the ServiceMonitor Server, sins) or locally (using the program sveload). For each segmentof the FEPROM, the download method (sins or sveload) creates a CRCchecksum, which is stored in the Electrically Erasable Programmable ReadOnly Memory (EEPROM) of this SVE1/SVE2 (FS-CRC).

Using the TXS tool scanmic on each MIC file, the HV-CRC checksumand the Message Digested 5 (MD5)-CRC checksum, as well as, the FlashSegment (FS)-CRC checksums, are generated in advance on the engineeringworkstation. A certain version of the complete software (pre-integrated andapplication-specific software) is identifiable on the hard disk of theengineering workstation using the HV-CRC and MD5-CRC checksums.

UFINRE Prepared by Reviewed by QA-), UFTR-QAI-02Name: Name: Revision 0 Copy IUFTRDate: Initials: Date: Initials: of 54

Using the FS-CRC checksums, a certain version of the downloadedsoftware is uniquely identifiable and checkable at any time (the FS-CRC

checksums can be read-out by the Service Unit at any time).The FS-CRC checksums are calculated and checked against the stored

FS-CRC checksums by the self-monitoring software during CPU startup as

well as during cyclic operation. Thus, identity and integrity of the downloaded

software is checked by the TXS automatically.

3.1.3 Acquiring Configuration Items

Physical storage, archiving, and retrieval of CI documentation and magneticmedia is performed in accordance the UFTR "Software Library and Control," /10/,

covers the administrative controls for Application Software Cis that describes theformat, documentation, inspection, and access control for code and data stored ineach library.

3.2 Configuration Control

Configuration control activities request, evaluate, approve or disapprove, and

implement changes to baseline CIs. Changes encompass both error correction andenhancement. The change control process is implemented via the Open Items process

defined in the UFTR QAP, /1/, and the UFTR "Conduct of Quality Assurance," /2/.

3.2.1 Change Control

Changes shall be initiated, evaluated, approved or disapproved, implemented,tracked, and closed out in accordance with the Open Items process outlined in the

UFTR QAP, /1/, and the UFTR "Conduct of Quality Assurance," /2/. Open Itemsidentified by IV&V shall be processed in accordance with the UFTR "Software

Verification and Validation Plan (SVVP)," /5/, which governs IV&V discrepancy

reporting and resolution procedures.

3.2.2 Configuration and Control Board (CCB)

UFTR does not use CCB meetings on a regularly basis. Since all changes aretracked via the Open Item process governed by the UFTR QAP, /1/, and thatprocess requires an evaluation of document and software changes, board meetingsin addition to the Open Item Process are unnecessary; therefore, the Open Item

process and associated evaluation shall be used in place of the CCB meetings when

making minor modifications to the software. CCB membership and activity is

detailed in the UFTR QAPP, /3/, and includes the project team key members from

all the project supporting groups.

3.2.3 Code Control

The code control defines the methods and facilities used to maintain and

store versions of controlled software. It shall be divided into two tasks:

UFINRE Prepared by Reviewed by QA-I, UFTR-QAI-02Name: Name: Revision 0 Copy 1Date: Initials: Date: Initials: of 54

1. Code Control of the TXS System, Tools, and additional Software:

AREVA NP Inc. ICS purchases the TXS System Software from AREVA

NP GmbH. The responsibilities and requirements for identification,

processing, and resolving of non-conformances, and evaluation andimplementation of System and Tools software revisions between AREVA

NP Inc. ICS and AREVA NP GmbH is governed by internal AREVA NPInc. procedures. The TXS System Software and Tools are received from

AREVA NP Inc. ICS. Control over purchasing and acquisition, as well asNonconformance/Open Items reporting, of the TXS Platform is definedin the UFTR QAP, /1/, and UFTR "Conduct of Quality Assurance".

2. Code Control of the TXS Application Software, QDS, and GSM Screens

and Scripts:

The TXS Application Software is the result of the automatic code

generation, based on the specified function diagrams. The TXS GSM

Screens are developed in conjunction with the TXS ApplicationSoftware. The process of modification, storing, and identifying the

function diagrams, the resulting source code, executable programs, QDS,

and GSM screens, and scripts is described in 3.2.5.

3.2.4 TXS System and Tools Software Configuration Control

To ensure the correct tools are used for code generation and the correct

System Software components are linked to Application Software, the configurationof the System Software components installed on the SPACE Engineering

Workstation is checked prior to each code generation process.

The software version of each System Software component running on RPSprocessors can be read back by the Service Unit (SU) at any time. The SU accesses

the RPS processors through Service Messages that originate from the SU. The

messages are routed to the addressed RPS processor via the Monitoring and ServiceInterface (MSI). An additional feature of the SU is that several cyber security

measures are in place to ensure that the SU cannot adversely affect the software

configuration control of the RPS processors. These cyber security measures are as

follows:1. The SU is physically located within a Limited Access Controlled Area.

2. The SU access is protected via user name logins and passwords. User

levels can be configured to allow different user logins with different

system access rights.3. The MSI only accepts Service Messages that originate from the SU. This

is controlled by Media Access Control (MAC) addressing. Messages

originating from any other location are disregarded.



4. Service Messages are transmitted using predefined data packagestructures. Messages not matching this data structure are disregarded.

5. The Service Messages are handled by each RPS processor within the

defined processing sequence. This sequence is controlled by the TXS

System Software residing on the RPS processor. This sequence is

executed once every predefined cycle (e.g., 50 ms, 25 ms, etc.). The

Safety Application Software is executed first and in the remaining time

available within the cycle, the valid Service Messages are processed, and

then the TXS self diagnostics are processed.

6. Service Messages requesting processor data can be processed regardlessof processor operating mode (i.e., the processor will send a data message

back to the SU). This does not interfere with safety function processing.7. An example of an additional security feature is to control the changing of

operating modes of the TXS processor via keyswitches. These

keyswitches would then give permission for the SU to change the

operating mode of the TXS processor. These keyswitches would be read

by the Application Software and sent to the Run Time Environment

(RTE) via the RTE-Input Function Block. Any request to change

operating modes is handled by the TXS System Software running on theTXS processor and is allowed only if the permission for the requested

operating mode is present.

Additional design infrastructure and applications design cyber security

requirements are described in UFTR "Cyber-Security," /9/.

3.2.5 TXS Project-Specific Software Baseline Control

The Control Points for the Application Software baselines are established

through the release of the Software CIs List (as noted in Table 3.1.1-1). The

Software CIs List shall be issued at the end of the Design, Testing, Installation and

Commissioning, and Final Documentation phases.The Software CIs List shall document the status of all CIs when it is issued.

Any CIs that do not exist at the time of issue of the Software CIs List shall be

marked as future. Items in addition to the CIs identified in this document may be

added to the Software CIs List.

3.2.5.1 CM Procedure during Initial Generation of TXS Application

Software

The overlapping steps of the design of TXS I&C systems and control of

the complete creation process are: engineering, generation and download. The

creation process shall be recorded completely on a data storage media (CD-

ROM or DAT cartridge). The data to be stored on these carriers is described in

the following sections.

UF/NRE Prepared by Reviewed by QA-I, UFTR-QAI-02Name: Name: Revision 0 Copy 1


3.2.5.1.1 Engineering

3.2.5.1.1.1 Implementation of the Design in the EngineeringDatabase using SPACE

The design required by the Software Design Description (SDD)shall be implemented in the Engineering Database using the SPACE tool"fde," /15/.

3.2.5.1.1.2 Functional Tests of Design

The Code shall be checked by:

1. Visual check of SPACE diagrams by an independent reviewer2. Validation of the functionality in the SIVAT test environment.

3.2.5.1.2 Code Generation

3.2.5.1.2.1 Check Identity of TXS System Software Configuration

Prior to code generation, the identity and consistency of the TXS

system software installation shall be checked. The CRC checksum of thecomplete system software installation is calculated using "reflist", andcompared to the reference configuration using "diff'. By means of thismethod, all released software components including the operation systempre-links are checked. The project specific Add-Ons shall be checked aswell in the same way.

3.2.5.1.2.2 Setup of Engineering Database

The definition tables of the Engineering Database contain theproduct information of all TXS system software components, as well asthe definitions of templates, function blocks, etc. This information isstored in setup files as part of the TXS system software configurationand shall be implemented in the TXS project database using the SPACEtool dbadmin (option: -setup). This step assures that the correctdefinitions and system configurations are implemented in theEngineering Database.

3.2.5.1.2.3 Backup of Engineering Database prior to CodeGeneration

Directly prior to code generation, a backup copy of the EngineeringDatabase shall be created using the SPACE tool dbadmin (option: -unload) and the CRC checksums of the backup files shall be calculated(reflist). Thus, the database version prior to code generation isreproducible.

UF/NRE Prepared by Reviewed by QA-I, UFTR-QAI-02

UFTR Name: Name: Revision 0 1 Copy IDate: Initials: Date: Initials: of 54

3.2.5.1.2.4 Code Generation

The next step consists of generation of the C source code using thecode generatorsfdgm and rte.

In the course of a complete generation, the code generatorsfdgmand rte shall be started with the option new. An empty code directoryshall be set for generation. The tables of the code generation shall beemptied, using the dbadmin tool with the option -clear <db-name> -cgtables.

Both toolsfdgm and rte create verbose protocols about the processof code generation (i.e. files:fdgm.txt, rte.txt) allowing the evaluation ofthe successful code generation (number of errors, warnings, and infos).

3.2.5.1.2.5 Compiling / Linking / Locating of TXS Code

Application code files of generated code shall be compiled with theic86 compiler. Then the compiled code shall be linked with the pre-linked system software components (link). The operation systemcomponents, already included in a pre-link, shall be linked also to thegenerated code. The resulting code shall be converted to absoluteaddresses (locate) and converted to HEX format (*.mic files). The MICfiles form the final software product to be downloaded into and started inthe I&C system. The compiling, linking and locating shall be recordedallowing the evaluation of the successful creation of the MIC files.Check that no ERROR or FATAL entries are contained in the ic86 logfile.

In the course of this step the following data files are created:

" an *.obj file and a *.lst file per function diagram (fd)" an *. obj file, a *. 1st file and a *.plk file per function diagram

group (fdg)" a *.hex file, a *.mpl file, a *.mp2 file, a *.lst file, a *mic file and

a *.sym file per SVEI/SVE2

3.2.5.1.2.6 Generation of Application Code for the TXS Gateway

In projects that use a TXS Gateway for communication with thenon-TXS systems, the application code shall be compiled using therespective compiler (i.e., the LINUX C compiler for the LINUX-basedTXS TXP gateway, or the Microsoft C++ compiler for the Win32-basedgateways). The resulting executables shall be stored in the code directorycreated by the TXS code generators.


UFTR Name: Name: Revision 0 Copy ]Date: Initials: Date: Initials: of 54

3.2.5.1.2.7 Checksums of the Complete Code Directory

The CRC checksums of the complete code directory are calculatedand recorded (reflist). This includes the source code and the executablesfor TXS and Gateways.

3.2.5.1.2.8 Backup of the Specification Data after Code Generation

After code generation, a backup copy of the engineering databasehas to be created using the SPACE tool dbadmin (option: -unload), /16/.The resulting ASCII tables have to be identified by CRC checksums(reflist). This copy serves for online database as well as for the nextmodification process.

3.2.5.1.2.9 Creation of Software and Hardware Listing

By means of the SPACE tools hwparams and swparams, hardwareand software parameter listings are created. Using the SPACE tooldbadmin the following listings are extracted from the engineeringdatabase:

fbs. txt.' Versions of all function blocks (dbadmin -list <dbname> -fbs)hbs.txt. Versions of all hardware blocks (dbadmin -list <dbname>-hbs)products. txt: Versions of all software components (dbadmin -list<dbname> -products)fds.txt: Listing of all SPACE diagrams (dbadmin -list <dbname> -fds)

By means of the tool netload the network load is calculated. Bymeans of the tool cpuload the CPU load is calculated.

3.2.5.1.2.10 Analysis of MIC files

By means of the SPACE tool scanmic the contents of the MIC filesshall be recorded. The scanmic tool creates a list of the implementedsoftware components, as well as the function diagrams including theversion. scanmic also produces the predicted FS-CRC for download ofthe MIC file into the SVEI/SVE2 CPUs.

3.2.5.1.2.11 List of Changeable Parameters

For each SVE1/SVE2, the list of all changeable parameters shall begenerated (via "sms/sm/gsm").

UFINRE Prepared by Reviewed by QA-1, UFTR-QAJ-02Name: Name: Revision 0 Copy I

UFTR Date : Initials: Date : fInitials: of 54

3.2.5.1.2.12 Software Release CD

A Software Release shall be generated as per the UFTR "Software

Generation and Download" Procedure, /11/, and shall be archived in the

Software Library as a TXS Application Software Release in accordance

with the UFTR "Software Library and Control," /10/.

3.2.5.1.3 Software Download

3.2.5.1.3.1 Creation of the Online Database

The current Engineering Database (after code generation) shall beinstalled on the SU after verification of the identity (reflist). Thisdatabase, hereby, becomes the Online Database.

3.2.5.1.3.2 Download Procedure

After successful completion of the modification process described

above including the respective checks, a download strategy shall be

determined as a pre-condition of the download release.

The download can be performed as central download or localdownload. The central download utilizes the SU. Local download means

that the software is downloaded by directly connecting to the respective

processor itself.

Downloads shall be controlled and documented as per the UFTR"Software Generation and Download" Procedure, /11/. The CRC

checksums are calculated by the SVEI/SVE2 processors and written intothe EEPROM of the respective processor. After downloading the user-

software and resetting the SVE 1/SVE2 processor, the CRC checksums

shall be read with the help of the SU and checked against the CRCchecksums predicted by the scanmic tool. This proves that the code was

correctly loaded into the right SVEI/SVE2 processor. If the CRC

checksums do not match, the download was not correctly executed andwill have to be repeated.

During software download, the respective processors are not

available for calculation of functions. The permission for downloading

software and the access to the processors (directly or via the SU) are

subject to the administrative measures.

It is assumed that the first software download is done in a test fieldenvironment during system integration. Therefore, the sequence of

download is not important (it does become important for software

download in an environment as described below).

UF/NRE Prepared by Reviewed by QA-), UFTR-QAI-02Name: Name: Revision 0 Copy I

UFTR Date : Initials: Date : fInitials: of 54

3.2.5.2 CM Procedure during Modification of TXS Application Software

The steps in the design of TXS Application Software and control of thecomplete creation process in an overlapping manner are: engineering,generation, and download. The modification process shall be recordedcompletely on a data storage media (CD-ROM or DAT cartridge). The data tobe stored on these carriers is described in the following sections.

3.2.5.2.1 Engineering

3.2.5.2.1.1 Tracking Changes

The creation of the TXS Application Software is started upon therelease of a FRS that provides appropriate concepts for the SoftwareRequirement Specification (SRS) and SDD. Subsequent modifications ofthe TXS I&C systems can be necessary for different reasons, such as:

* Functional (plant process) improvements,

* I&C improvements/optimization of functionality,* Error correction.

Such modifications shall be recorded in accordance with the OpenItems process defined in the UFTR QAP, /1/, and the UFTR "Conduct ofQuality Assurance," /2/.

3.2.5.2.1.2 Modification of the Engineering Database using SPACE

Check of Identity and Consistency of the Engineering Database

Before starting a modification, assure that the intendedmodification is based on the valid version of the Engineering Database.After the verification of the CRC checksums (reflist), either the copy ofthe Engineering Database after the previous code generation (from theSoftware Release CD) or a copy of the current online database shall beloaded into a newly created or cleared Engineering Database.

In case some online changeable parameters have been modified inthe I&C system after the last code generation, either the Online Databasehas to be loaded or these parameter modifications have to be repeated inthe Engineering Database.

Implementation of Database Modifications

The released design changes out of the "Open Items List" shall beintroduced into the application software code using the SPACE toolfde.During this work step, special attention shall be paid to the fact that onlythe desired modifications shall be implemented. For this purpose fourgeneral features of the SPACE tools have to be considered:


UFTR Name: Name: Revision 0( Copy IDate: Initials: Date: Initials: of 54

" The modification date of the modified SPACE diagrams isupdated automatically,

" The modification of a signal connection between two functiondiagrams leads to an update of the modification date of bothdiagrams,

" The SPACE tool does not distinguish between functional andgraphical modifications; each modification causes an update ofthe modification date,

" Modifications in the network diagram influence the completecode generation.

The following precautions are derived from these features:

" No "cosmetic" modifications should be done in function ornetwork diagrams, which are not necessary in the course of theimplementation of an Open Item,

* No modifications are to be implemented temporarily (i.e., to beremoved afterwards),

* If a signal between two function diagrams needs to berepositioned on a diagram, the signal in question should bemoved and/or redrawn without deleting it. This will prevent themodification date of the untouched diagram from changing.

All modifications of function diagrams between two databaseversions shall be recorded. For each Open Item, the design engineer shallprint and document the changes of the SRS and SDD in accordance withthe Open Items process defined in the UFTR QAP, /1/ and the UFTR"Conduct of Quality Assurance," /2/.

3.2.5.2.1.2.1 Software Release Modifications

In preparation of a Software Release all Open Items are to beincorporated into the appropriate design document (i.e., the SDD),and the corresponding change(s) shall be implemented into theengineering database (i.e., SPACE database). After the changes havebeen incorporated, all function diagrams that show an altered datefrom the previous valid version of the engineering database shall befully traced to the corresponding description in the SDD. Themodifications to the software shall be fully tested as described inSection 3.2.5.2.1.3.

The database administration tool "project data" as described inthe Database Administration Tool User Manual, /16/, should be usedto list the names of the personnel responsible for preparing andreviewing each of the FDGs in the engineering database. The



"revision notes" as described in the SPACE Editor Manual, /15/,

should also be used to record the changes to each function diagram in

the engineering database.

3.2.5.2.1.2.2 Interim Software Release Modifications

In preparation of an Interim Software Release, which involves

an Engineering Change Proposal (ECP) Preliminary Release Activity,the design change to be implemented shall be included in the ECPpackage as red-line markups attached to the Preliminary Release

Form, as outlined in the UFTR QAPP, /3/. Following approval of the

Preliminary Release Activity, corresponding change(s) shall beimplemented into the engineering database (i.e., SPACE database).

After the corresponding change(s) are completed, all function

diagrams that show an altered date from the previous valid version of

the engineering database shall be fully traced to the ECP Preliminary

Release.NOTE: Successive Interim Software Releases may be implemented

prior to a complete baseline Software Release. Each Interim Software

Release shall build upon all other previous approved Interim Software

Releases until a baseline Software Release is completed.

If an Interim Software Release does not function as desired, theECP Preliminary Release shall be revised to void all modifications to

the Software and the voided Interim Software Release shall be

excluded from all successive Interim Software Releases or baseline

Software Releases. Once the Interim Software Release process iscompleted, the red-line markups are then to be incorporated into the

design documents as part of completing the associated final ECP.

Following completion of the final ECP, all function diagrams

that show an altered date from the previous officially released versionof the engineering database shall be fully traced to the correspondingdescription in the SDD. The modifications to the software shall be

fully tested as described in Section 3.2.5.2.1.3.

The database administration tool "project data" as described in

the Database Administration Tool User Manual, /18/, should be used

to list the names of the personnel responsible for preparing and

reviewing each of the FDGs in the engineering database. The"revision notes" as described in the SPACE Editor Manual, /15/,

should also be used to record the changes to each function diagram in

the engineering database.



3.2.5.2.1.3 Functional Tests of Database Modifications

The modifications introduced into the application software code

can be checked by different means:

" Visual check of SPACE diagrams by an independent reviewer," Validation of the functionality in the SIVAT test environment," Validation in a test field environment,* Electrical and functional tests on site,* Technological (complex) tests.

Visual checks and software validation shall be carried out at anearly stage in the modification process. On site tests (electrical,functional or complex) can be carried out only after software downloadinto I&C system in course of the commissioning.

Every modification is verified at first by visual checks. Scope anddepth of further tests depend on the volume and type of themodifications. For instance, change of parameters requires only a visualcheck and would not require further design testing (i.e., simulationSIVAT testing). Any change in function diagrams that impacts thecoding logic shall be retested. All modification to Application Software,both code logic and parameter changes, shall be tested/verified duringFAT or commissioning. The complexity of the change and the stage ofthe project shall dictate where the testing is done, i.e., simulation SIVATtesting, FAT testing or Commissioning. Justification for the decision ofthe scope of testing shall be documented on the Open Item Form.

Every test (except the visual checks) shall be described in a testprocedure and recorded in a test log.

3.2.5.2.2 Code Generation

3.2.5.2.2.1 Check Identity of TXS System Software Configuration

Prior to code generation, the identity and consistency of the TXS

system software installation shall be checked. The CRC checksum of thecomplete system software installation is calculated using "reflist", andcompared to the reference configuration using "diff'. By means of thismethod, all released software components including the operation systempre-links are checked. The project specific Add-Ons have to be checkedin the same way as well.

3.2.5.2.2.2 Setup of Engineering Database

The definition tables of the Engineering Database contain theproduct information of all TXS system software components, as well asthe definitions of templates, function blocks, etc. This information is

UF/NRE Prepared by Reviewed by QA-), UFTR-QAI-02


stored in setup files as part of the TXS system software configurationand shall be implemented in the TXS project database using the SPACEtool dbadmin (option: -setup). This step assures that the correctdefinitions and system configurations are implemented in theEngineering Database.

3.2.5.2.2.3 Backup of the Engineering Database prior to CodeGeneration

Directly prior to code generation, a backup copy of the EngineeringDatabase shall be created using the SPACE tool dbadmin (option: -unload) and the CRC checksums of the backup files shall be calculated(reflist). Thus, the database version prior to code generation isreproducible.

3.2.5.2.2.4 Check of Identity and Consistency of the previouslygenerated C Code

If a modified-only code generation is intended (and only in thiscase) the consistency and identity of the last valid generated C code hasto be checked. The CRC checksum of the complete code directory iscalculated, recorded and compared with the CRC checksums recordedduring the last code generation (reflist).

3.2.5.2.2.5 Code Generation

The next step consists in generation of the C source code using thecode generators fdgm and rte.

Complete Generation

In the course of a complete generation the code generatorsfdgmand rte shall be started with the option new. An empty code directoryshall be set for generation. The tables of the code generation shall beemptied, using the dbadmin tool with the option -clear <db-name> -cgtables. Information about the last code generation is then ignored.

Modified-only Generation

In the course of a modified-only generation the code generatorsfdgm and rte shall be started with the option modified only (and withoutoption new). A copy of the last code directory shall be set for generation.In this case, the code generatorfdgm creates code only for thosediagrams that have been modified since last code generation. In the casewhere the network diagram has been modified, the complete code isgenerated again, because the code generatorfdgm assumes fundamental

UF/NRE Prepared by Reviewed by QA-), UFTR-QAI-02UFTR Name: Name: Revision 0 t Copy 1


modifications of the system topology. Naturally in this case no modified-only generation and download is possible.

Both toolsfdgm and rte create verbose protocols about the processof code generation (i.e. files: fdgm. txt, rte. txt) allowing the evaluation ofthe successful code generation (number of errors, warnings, and infos).

Using the SPACE tool "cmpcode" two versions of the generatedC code shall be compared (i.e. file:code diff <dbnamel>_<db_name2>. xt). Such an analysis isnecessary in case modifications of MIC files cannot be explained byintended modifications of the specification.

3.2.5.2.2.6 Compiling / Linking / Locating of TXS Code

Application code files of generated code shall be compiled with theic86 compiler. Then the compiled code shall be linked with the pre-linked system software components (link). The operation systemcomponents, already included in a pre-link, are linked also to thegenerated code. The resulting code shall be converted to absoluteaddresses (locate) and converted to HEX format (*. mic files). The MICfiles form the final software product to be downloaded into and started inthe I&C system. The compiling, linking and locating are recordedallowing the evaluation of the successful creation of the MIC files.Check that no ERROR or FATAL entries are contained in the ic86 logfile.

In course of this step the following data files shall be created:

* an *. obj file and a *./ st file perfd

e an *.obj file, a *.lst file and a *.plk file perfdge a *.hex file, a *.mpl file, a *.mp2 file, a *.1st file, a *mic file and

a *.sym file per SVE1/SVE2

3.2.5.2.2.7 Generation of Application Code for TXS Gateway

For communication with the non-TXS systems, the applicationcode shall be compiled using the respective compiler (i.e., the LINUX Ccompiler for the LINUX-based TXSTXP gateway, or the Microsoft C++compiler for the Win32-based gateways). The resulting executables shallbe stored in the code directory created by the TXS code generators.

3.2.5.2.2.8 Checksums of the complete Code Directory

The CRC checksums of the complete code directory shall becalculated and recorded (reflist). This includes the source code and theexecutables for TXS.

UFINRE Prepared by Reviewed by QA-I, UFTR-QAI1-02


3.2.5.2.2.9 Backup of the Specification Data after Code Generation

After code generation, a backup copy of the engineering database

shall be created using the SPACE tool dbadmin (option: -unload). Theresulting ASCII tables shall be identified by the CRC checksums

(reflist). This copy serves for online database as well as for the next

modification process.

3.2.5.2.2.10 Creation of Software and Hardware Listings

By means of the SPACE tools hwparams and swparams, hardware

and software parameter listings shall be created. Using the SPACE tool

dbadmin the following listings are extracted from the engineering

database:

Jbs.txt: Versions of all function blocks (dbadmin -list <db_name> -

Ibs)hbs.txt: Versions of all hardware blocks (dbadmin -list <db_name>

-hbs)

products. xt: Versions of all software components ("dbadmin -list

<dbname> - products")

fds. txt: Listing of all SPACE diagrams (dbadmin -list <db_name> -

fds)

By means of the tool netload the network load shall be calculated.

By means of the tool cpuload the CPU load shall be calculated.

3.2.5.2.2.11 Analysis of the MIC-files

By means of the SPACE tool scanmic the contents of the MIC files

shall be recorded. The scanmic tool creates a list of the implementedsoftware components, as well as the function diagrams including the

version. scanmic also produces the predicted FS-CRC for download of

the MIC file into the SVEl/SVE2 CPUs.

3.2.5.2.2.12 List of Changeable Parameters

For each SVE1/SVE2, the list of all changeable parameters shall be

generated (via sms/sm/gsm).

3.2.5.2.2.13 Software Release CD

A Software Release shall be generated as per the UFTR "Software

Generation and Download" Procedure, /11/, and shall be archived in the

Software Library as a TXS Application Software Release in accordance

with the UFTR "Software Library and Control," /10/.



3.2.5.2.3 Software Download

3.2.5.2.3.1 Creation of the new Online Database

The current Engineering Database (after code generation) shall beinstalled on the SU after verification of the identity (reflist and"verification of Changeable parameters"). This database, hereby,becomes the Online Database.

3.2.5.2.3.2 Download Procedure

After successful completion of the modification process describedin Section 3.2.5.2.2.2, including the respective checks, a downloadstrategy shall be determined as a pre-condition of the download release.

The download shall be performed as central download or localdownload. The central download utilizes the SU. Local download meansthat the software is downloaded by directly connecting to the respectiveprocessor itself.

Downloads shall be controlled and documented as per the UFTR"Software Generation and Download" Procedure, /11/. The CRCchecksums are calculated by the SVE1/SVE2 processors and written intothe EEPROM of the respective processor. After downloading the user-software and resetting the SVE1/SVE2 processor, the CRC checksumsshall be read with the help of the SU and checked against the CRCchecksums predicted by the scanmic tool. This proves that the code wascorrectly loaded into the right SVE1/SVE2 processor. If the CRCchecksums do not match, the download was not correctly executed andwill have to be repeated.

During software download, the respective processors are notavailable for calculation of functions. The permission for downloadingsoftware as well as the access to the processors (directly or via the SU)shall be subject to UFTR administrative measures.

Download During Outage

In the course of software download during a UFTR outage, theSVE1/SVE2 can be loaded in any sequence (centrally or locally). Thedownload process can be carried out in parallel inside the train, or in across-train manner. However, this is not valid if certain functionalitieshave to remain active during an outage, or if certain operation modereleases for central software download are creating restrictions forparallel work. The normalization of the internal memories (calibrations,etc.), the harmonization of the redundant computers, and a release ofcomputer outputs after download depend on the specific requirements.


UFTR Name: Name: Revision 0 Copy IDate: I Initials: Date: Initials: of 53

3.2.5.2.3.3 System Normalization

By means of the SM, the status of all CPUs after download shall be

checked (status mode *, status flags *, status error *). Using theindications on the Control Room panels and the Process Information

System verify that the system is normalized completely. Special attention

has to be paid to the fact that no I&C failures are pending and that alladjustment parameters are set to the last valid values.

3.2.5.2.3.4 Software Download after Module Replacement

The following aspects shall be considered in the course of software

download after module replacement:

" The first software download into a SVEl/SVE2 module is

carried out locally (software download via SU requires a

running software on the SVE1/SVE2).

* Modifications of changeable parameters carried out in the I&C

system prior to the modification and not taken over into themodified software shall be repeated after software download.

" Adjustment parameters shall be adjusted after download to thelast valid value (see UFTR list of adjustment parameters).

The software download process is recorded in a protocol manually

filled-in (local software download) or in a protocol automatically created

by the SM (central software download).

After software download the FS-CRC checksums recorded in the

download protocols shall be checked against the sums calculated by thetool scanmic. This check assures that the correct code has been

downloaded completely into the SVE 1/SVE2.

3.2.5.2.3.5 Final Documentation

Each modification of the TXS application software shall be

recorded with a filled out log for Software Generation and Download,/11/, to confirm that the methods and procedures defined in this

document are followed and maintained.

3.2.5.3 CM Procedure during Parameter Modifications

In the course of engineering with the SPACE tools, all parameters of theTXS-based I&C system are grouped into two different types: changeable

parameters, which can be modified directly in the I&C system without new

code generation and not-changeable parameters, which are declared asconstants and cannot be modified without new software generation and

download.



The CM measures necessary during modification of these parameters aredescribed in this section.

3.2.5.3.1 Changeable Parameters

Changeable parameters normally include parameters that depend on thestatus of the reactor or on the fuel bum-up (e.g., boron concentration,calibrations, etc.). These parameters have to be modified by the operationalor maintenance personnel on a regular basis. They are maintained in a speciallist ("list of changeable parameters"). The "list of changeable parameters" isprinted after each modification. Modifications of these parameters are carriedout by means of the SM. If the parameter values have to be valid also after are-start of the SVE 1/SVE2, the modification shall be carried out both inRAM and EEPROM. The correct use of the new parameter values is checkedby read-back of the new values from the SVE1/SVE2 or by creation of a new"list of changeable parameters".

The online database is not modified in the course of modifyingchangeable parameters.

In the course of modifying changeable parameters, the online databaseshall be updated in order to maintain the consistency of archived plantdocumentation, animated function diagrams and current software status.

For subsequent new code generations (complete or modify-only), themodified changeable parameters are incorporated from the "list of changeableparameters" maintained by the plant. In case the modified changeableparameters are applied to update a specification, Open Item must be createdto track the changes in the specification.

3.2.5.3.2 Verification of Parameter Changes

After a parameter change, the List of Changeable Parameters has to begenerated (sms/sm/gsm). This list has to be compared line-by-line with thereference list generated during code generation using the "diff' tool. Thisverifies that only the intended parameters have been changed.

3.2.5.3.3 Constants

Parameters declared as constants during engineering (i.e., not-

changeable parameters) cannot be modified by means of the SM and have tobe modified in the SPACE engineering database. For those parameters themodification procedure described in Section 3.2.5.2 is valid.

UFINREUFTR

Prepared by Reviewed by QA-I, UFTR-QAI-02Name: Name: Revision 0 Copy IDate: Initials: Date: Initials: of 53

3.2.6 Media Control

3.2.6.1 Media Control for Documents

The work in progress documents shall be stored on the secure UFTRProject Server, accessible only to the UFTR personnel and select AREVA NPInc. engineers and reviewers identified in the UFTR QAPP, /3/. Procedurescovering the organization, updating, and backup of the data on the ProjectServer are defined in the UFTR QAPP, /3/.

The final documents shall be uploaded to the UFTR Project Server wherethey are retained in accordance with the UFTR QAPP, /3/.

3.2.6.2 Media Control for TXS System Software and Additional

Software

The TXS System Software is received on a certified CD and is enteredinto the Software Library in accordance with the provisions of the UFTR"Software Library and Control," /10/.

3.2.6.3 Media Control for SPACE Function Diagrams, Test Scripts, andService Scripts

The SPACE project database, the QDS, the GSM screens, and all scriptsare stored on a LINUX network server. All data is subject to periodic backups.Only the UFTR software designers and select AREVA NP Inc. employeesidentified in the UFTR QAPP, /3/, can access the server. Only the UFTRpersonnel involved in the specification process can access the project SPACEdatabase.

Modification, storage of modified function diagrams, and documentationof these modifications are described in Section 3.2.5. The organization of databackup procedures, schedules, and the storage of data saved on removablemedia is the responsibility of the Software Development Lead.

3.2.6.4 Software Release CD

A Software Release is an official baseline of software that is fullydocumented in the associated basic and detailed design documentation. Whengenerated, each Software Release shall correspond to an SRS, SystemArchitecture, SDD, and Code Document. Each Software Release shall be fullyidentified via a Code Configuration Document, Hardware Parameters ListingDocument, and Changeable Parameters List Document.

All code, databases, and listing shall be generated as per the UFTR"Software Generation and Download" Procedure, /11/, and shall be archived inthe Software Library as a TXS Application Software Release in accordancewith the UFTR "Software Library and Control," /10/.

UFINRE Prepared by Reviewed by QA-I, UFTR-QA I-02

UFTR Name: Name: Revision 0 Copy 1Date: Initials: Date: Initials: - of 53

All GSM screens and scripts shall be generated as per the UFTR"Software Generation and Download" Procedure, /I1/, and archived in theSoftware Library as a TXS GSM Software Release in accordance with theUFTR "Software Library and Control," /10/.

All the QDS components shall be generated and archived in the SoftwareLibrary as a TXS QDS Software Release in accordance with the UFTR"Software Library and Control," /10/.

Software Release CDs shall be maintained in the UFTR Software Libraryin accordance with the UFTR "Software Library and Control," /10/.

3.3 Configuration Status Accounting

The project work breakdown structure addresses the production, review, approval,and control of CIs. Those CIs are identified in Tables 3.1.1-1 and 3.1.1-2. Schedulereporting tracks the completion of the CIs throughout the project including additionalactivities documented to make changes.

Status reports for CIs for the UFTR digital control project are maintained on theproject dedicated server in accordance to the UFTR QAPP, /3/.

. One of the CIs for the UFTR project will be a Code Configuration document. Thisreports the configuration for all of the delivered software.

The TXS System Software (the specific software products are listed in Table 3.1.1-2) has a controlled ID string and is identifiable by the ID strings and the CRC Checksumsassociated with the software. The ID strings are used in controlling the configuration ofthe TXS System Software as the system is assembled, tested and delivered to the UFTRpersonnel by AREVA NP Inc.

A similar process is used for the Application Software developed and loaded intothe TXS System by the UFTR Software Development group. When the ApplicationSoftware is completed and issued for release, a Code Configuration Document shall beissued. This document reports, using the scanmic tool, the exact configuration of allsoftware that is part of the safety-related software portion of the TXS System. Included inthis document are the configurations of the Application Software, System Software, L2Software, and HI Software running on the system. This configuration is documented inaccordance with the UFTR QAPP, /3/. The Code Configuration Document shall bepublished upon each release of the software. The Code Configuration Document will beused in support of the Physical Audit as defined in the UFTR QAP, /1/.

3.4 Configuration Audits and Reviews

During the progress of the project, periodic configuration reviews and audits shall

be held which are described in the UFTR QAP, /1/, and UFTR SQAP, /6/, to evaluateconformance of CIs to required physical and functional characteristics.

UF/NRE Prepared by Reviewed by QA-1, UFTR-QAI-02


3.4.1 Software Configuration Management Plan Reviews

This Plan shall be reviewed to evaluate the adequacy and the completeness ofthe configuration management methods defined herein. This review shall beperformed prior to the start of the project design phase.

The SCMP Review shall be performed by the Project Coordinator andmembers of the Software Development group, IV&V group, and other personnelper the UFTR "Software Reviews and Audits," /8/.

Results that require action, either technical or administrative, shall bedocumented as a Nonconformance/Open Item in accordance with the UFTR QAP,/1 / and the UFTR "Conduct of Quality Assurance," /2/.

Once the Review is complete, the project design phase is allowed to begin.

3.4.2 Physical Configuration Audits

The Physical Configuration Audit shall compare the software loaded on thetarget hardware to the information contained in the Code Configuration Document,Software Library records, and the CIs List.

The Physical Configuration Audit shall confirm that the status of thesoftware loaded on the target hardware is correct and identifiable. All softwareloaded on the TXS safety processors, L2 Processors, Hi Processors, TXS ServiceUnit, TXS Gateway, and any supporting TXS Test Equipment (i.e., TXS ERBUS)shall be confirmed during this Audit.

The Physical Configuration Audit shall be performed after the software to beused during FAT is installed on the target hardware and before the start of FAT.The Physical Configuration Audit shall be executed under the lead of a member ofthe Test group, IV&V group, and other QA personnel per UFTR "SoftwareReviews and Audits," /8/.

In addition to the Code Configuration Document, Software Library records,and the CIs List, Task Letters used to install the software, as well as Test Logs shallbe reviewed for adequacy during the Physical Configuration Audit.

Results that require action, either technical or administrative, shall bedocumented as a Nonconformance/Open Item in accordance with the UFTR QAP,/1/, and the UFTR "Conduct of Quality Assurance," /2/.

Once the Audit is complete, FAT is allowed to begin.

3.4.3 Functional Configuration Audits

The Functional Configuration Audit shall verify that that all requirementsspecified in the SRS have been met by the Software tested during FAT. The FATReports and supporting test data shall be audited to ensure the completeness and theaccuracy of the FAT tests. This includes verifying all the areas of the FAT Plan,Specifications and Procedures are addressed.

UF/NRE Prepared by Reviewed by QA-I, UFTR-QAI-02Name: Name: Revision 0 Copy 1Date: Initials: Date: Initials: of 53

The Functional Configuration Audit shall be performed after the completionof the FAT. The Functional Configuration Audit shall be executed under the lead ofmembers of the Test group, IV&V group, and other QA personnel per the UFTR"Software Reviews and Audits," /8/.

In addition to the FAT Reports and supporting test data, the FAT Plan,Specifications and Procedures, and Test Logs shall be reviewed for adequacyduring the Functional Configuration Audit.

Results that require action, either technical or administrative, shall bedocumented as a Nonconformance/Open Item in accordance with the UFTR QAP,/1/, and the UFTR "Conduct of Quality Assurance," /2/.

3.4.4 Software Process Audits

Software Process Audits are performed on this Plan on an annual basis inaccordance with the UFTR QAP, /1/, and the UFTR SQAP, /4/.

3.5 Interface Control

3.5.1 Organizational Interfaces

Interface Control with AREVA NP Inc. ICS shall be maintained by theProject Manager and the Project Coordinator who interface with AREVA NP Inc.ICS personnel and attend Project Status Meetings.

The TXS Hardware received for the UFTR Project is delivered by AREVANP Inc. ICS, which interfaces with the Hardware Design Group of AREVA NPGmbH. The processing and resolving of problems and non-conformances with theTXS System Software is handled in accordance with the UFTR QAP, /1/, and theUFTR "Conduct of Quality Assurance," /2/.

System Integration and Integration Testing provides the Interface control forthe final hardware and software configuration. These activities are normallyperformed during the FAT.

3.5.2 Project Software Interfaces to External Items

There are no external items to which the UFTR project software interfaces.

3.6 SubcontractorNendor Control

Subcontractor control refers to software developed by contract, while Vendorcontrol refers to software acquired in its finished form. The UFTR does not subcontractsoftware development for the Digital Control Upgrade.

The TXS System Software is purchased from AREVA NP GmbH, by AREVA NPInc. ICS. AREVA NP GmbH has implemented an appropriate Quality Assuranceprogram for the life cycle of the System Software. AREVA NP GmbH is an approvedsafety related supplier for AREVA NP Inc., as defined by appropriate AREVA internalprocedures. AREVA NP Inc. ICS is the vendor of the TXS Platform and SystemSoftware for the UFTR project. SCM activities for the TXS Platform are maintained by



appropriate AREVA NP Inc. documentation. A CoC is issued for the TXS Systemreceived from AREVA NP Inc. ICS in order to ensure compliance.

All software in the TXS System Software package shall be uniquely identified asoutlined in Section 3.1 of this Plan, and shall be controlled in accordance with Section3.2.2 of this Plan. The responsibilities and requirements for identification, processing,and resolving of the open items with regard to the TXS System Software used in theUFTR project are defined in the UFTR QAP, /1/, and the UFTR "Conduct of QualityAssurance," /2/.

All System and Tools software revisions received from AREVA NP are evaluatedon a case-by-case basis to determine implementation requirements. Vendor software issubject to an incoming inspection as per the UFTR QAP, /1/, and is processed inaccordance with the UFTR "Software Library and Control," /10/.

3.7 Anomalies Identified after Release

Anomalies identified after the release of the TXS System Software from AREVA tothe UFTR are handled in accordance with the UFTR QAP, /1/, and the UFTR "SoftwareOperations and Maintenance Plan," /6/.

The anomalies are examined for their impact on the safety functions. According tothis examination it will be decided if the anomaly is to be rated as:

* No change necessary: the software functions as required by the SRS, a change inthe operating instructions might be required, but not a modification of thesoftware.

* Change necessary for optimization: a software update can be implemented duringthe next scheduled outage.

* Change necessary for fulfilling the required safety function: AREVA NP Inc. andthe UFTR personnel will prepare a strategy for immediate action for the releaseand implementation of a new software update.

In any case, software changes are processed under the control of this Plan.

UFINREUFTR

Prepared by Reviewed by QA-1, UFTR-QAI-02Name: Name: Revision 0 Copy 1Date : I Initials: Date: .Initials: of 53 I

4. SCM Schedule

Schedules are the responsibility of the Project Coordinator and Project Manager. TheSCM activities shall be included in the overall project schedule. Additional information onrequirerqe•,s for establishing schedules and activities is governed by the UFTR QAPP, /3/.

UF/NRE Prepared by Reviewed by QA-), UFTR-QAI-02


5. SCM Resources

SCM resource information identifies the tools (software generating tools), the personnelthat~use the tools and the training necessary for implementation of SCM activities.

5.1 Tools

5.1.1 Tools Overview

The UFTR Development group comprises the users of the Tools described inthe following sections and shall be trained in their use. The IV&V personnel shallbe familiar with their use.

Configuration of the Tools is controlled by AREVA NP GmbH. These Toolsare certified and purchased as Safety Related. No process for selectingconfiguration management Tools is specified because the configurationmanagement Tools for the TXS technology have already been selected.

The Project Manager shall ensure the current approved version of each Toolis used for the project. The Project Manager's approval is documented through therelease of the Software CIs List at each phase as shown in Table 3.1.1 -1.

Project Tools, such as Microsoft Office or FunBase, do not require extensiveverification and validation or testing to qualify their use because the end product isextensively reviewed and the Tools are not used in the on-line operation of thesystem.

5.1.2 Tools for Application Software

The Tools for the specification of the function diagrams (i.e., SPACE), thesource code generators and the software for compiling, linking, and locating arepart of the TXS software package.

5.1.3 Tools for Simulation and Verification

The Tools for simulation and verification are either part of the TXS softwarepackage (e.g., SWAT, rediff, hwparams, swparams, netload, and cpuload) or partof the test environment of the test field equipment.

5.2 Personnel

The Software Development Lead shall ensure that software project personnel aretrained in accordance with the UFTR "Software Training Plan," /7/. Personnel shall beapproved by the Software Development Lead to perform software assignments on theproject.

5.3 Software Librarian

The Software Librarian is designated by Software Development Lead and is amember of the Software Development Group. Refer to the UFTR "Software Library andControl," /10/, for a list of responsibilities associated with the Software Librarian.

UFINRE Project ID: QA-I

UFTR QUALITY ASSURANCE DOCUMENT Revision 0 Copy 1 of 53

6. SCM Plan Maintenance

6.1 Responsibility

All the UFTR Project Group Leads, the Project Manager and the ProjectCoordinator are responsible for monitoring the SCMP to ensure it meets all the codes andstandards required by the project specifications. Each member of the SoftwareDevelopment group is responsible for ensuring compliance with the SCMP and that CIsare kept current with the project as the design evolves.

6.2 Updates

Updates to the SCMP will be made as necessary. Minor or editorial changesidentified during a given design phase may be held for issue until the end of that phase.Minor changes refer to clarifications or improvements that do not alter the function of,add to the function of, or conflict with the Plan as it exists at that time.

6.3 Change Approval

Any changes to the Plan must be made via an official revision, to be reviewed andapproved in accordance with the UFTR QAP, /I/. This Plan shall be reviewed at the endof each project phase.

6.4 Change Distribution

Following approval of any change to the SCMP, each member of SoftwareDevelopment group and others as identified by the Software Development Lead shall betrained.

UFINRE Prepared by Reviewed by QA-I, UFTR-QAI-02Name: Name: Revision 0 Copy 1UFTRDate: Initials: Date: Initials: of 53

Appendix 1 - Definition of Configuration Items

1. Software Configuration Items List - The Software CIs List identifies the UFTRSoftware CIs applicable to the project. This document reflects the configuration of theTXS System at the end of the each Design Phase as defined in the UFTRQAPP, /3/.

2. System Architecture - The System Architecture document provides the TXS SystemNetwork Architecture Diagrams (referred to as YURs) and Cabinet ArrangementDiagrams (referred to as YDRs) configured using SPACE and a list of System NetworkArchitecture parameters necessary for the operation of the configured TXS network.The information provided in this document describes the TXS System NetworkArchitecture pertaining to communications between the TXS Central Processing Unit(CPU) modules, the TXS digital and analog 1/0 modules and the TXS subracks in theTXS cabinets. The information provided in this document serves as design input forthe Detailed Hardware and Application Software design phases of a project.

3. Hardware Parameters Listing - This Hardware Parameters Listing documentprovides the complete set of hardware parameters for the TXS equipment implementedfor a TXS project. It is based on the system requirements and function requirements, aswell as the results of the Basic and Detailed Design Phases.

4. Restricted Information - The Restricted Information document provides the MACaddresses for various network devices.

5. Software Configuration Management Plan - The SCMP is established to provide themethod and tools to identify and control the TXS Application Software.

6. Software Safety Plan - The Software Safety Plan (SSP) outlines the process forachieving high functional reliability and design quality for the safety-criticalApplication Software. Planned and documented software safety analysis activities areused as factors to determine achievement of safety objectives to ensure that safetysystem software development is consistent with the defined system safety analyses.Software safety analysis activities are conducted during the Basic Design, DetailedDesign and Testing Phases of the software development life cycle.

7. ID Coding Concept - The ID Coding Concept document provides a standardizedmethod of naming equipment, diagrams, and signals for the purpose of continuity inidentification during the project development process. This document defines the rulesfor the assignment of ID codes to I&C equipment, I&C diagrams, and I&C signals.This document forms an essential design input for the Software RequirementSpecification document.

8. Software Requirements Specification - This Software Requirements Specification(SRS) document provides the software requirements for the TXS Application Softwarerunning on the TXS processors. These requirements are extracted from the EquipmentSpecifications, System Functional Description, Ancillary Design Inputs documents,Keyswitch Specification, and industry standards.

UFINRE Prepared by Reviewed by QA-l, UFTR-QAI-02

UFTR Name: Name: Revision 0_1 Copy 1Date: Initials: Date: Initials: of 53

9. IV&V Activity Phase Summary Reports - The IV&V Activity Phase SummaryReports address software V&V activity identification, background information ofstandards, and source documents with revisions, synopsis of the review andconfirmation that the plan was followed, Open Items found, and recommendations.

10. Software Design Description - The SDD document provides a structuredrepresentation of the safety logic created to facilitate the design of the ApplicationSoftware for a TXS project. The SDD translates the software design requirementsspecified in the SRS into a description of the software structure, software components,interfaces, and data necessary for the implementation of the design into the ApplicationSoftware. The SDD is comprised of various views of the Application Software,including an overview of the system architecture and a top-level presentation of theimportant system functions. The SDD includes a description of all the standard SPACEdesign entities, Instrumentation and Control (I&C) Functions (FUs), I&C SubmoduleInputs (SIs), I&C Submodule Outputs (SOs), and I&C Monitoring ProcessingSubmodules (SMs) used in the project-specific system design. The SDD describes theimportant features in the design, such as how the FUs interact with the correspondingSIs, SOs and SMs. Other views include database tables listing the changeableparameters, information signals (with attributes), and communication interfaces. Theinformation provided in this document serves as design input for the detailedApplication Software Code.

11. TXS Application Software (Software Release) - The Application Software CodeRelease is the UFTR TXS Application Software produced using the SPACE Tool CodeGenerators.

12. Application Software Code (SPACE Function Diagrams) - The ApplicationSoftware Code document provides the complete set of software function diagrams forthe UFTR TXS project. The function diagrams are produced with the TXS engineeringtool SPACE. The application code is automatically generated from the functiondiagrams documented here by using the qualified SPACE code generators. Thedocument is based on the SDD, which implements the system requirements andfunction requirements, as well as the results of the basic design phase - specificallysystem architecture and ID coding concept.

13. Code Configuration - This Code Configuration document provides the ApplicationSoftware Code Configuration for the UFTR TXS project and corresponds to a specificTXS Application Software (Software Release), as documented Application SoftwareCode document. This document also lists the resource usage and spare capacity of thehardware resources of the UFTR TXS project.

14. Changeable Software Parameters List - The Changeable Software Parameters Listdocument details the identification of Changeable Parameters in the SDD and theidentification of the corresponding parameters and values in the SPACE FunctionDiagrams of the Application Software Code for the UFTR TXS project. The documentdescribes how to understand the information presented in the List of ChangeableParameters for the TXS Application Software (Software Release), how to create thislist, and also documents the list in a spreadsheet.



15. Software Generation and Download Procedure - The purpose of the SoftwareGeneration and Download Procedure is to provide instructions for the following TXSSoftware processes:

* Generation and storage of the TXS Application Software" Loading of the TXS Application Software onto the Service Unit" Loading of the Application Software onto the TXS Gateway* Loading of the System Segment Software onto the TXS processing modules* Loading of the Application Software onto the TXS processing modules" Loading of the L2-CP Firmware onto the TXS communication processors" Loading of the H1-CP Firmware onto the TXS SCP2 communication processor" Preparation of the Configuration File for the TXS communication processors" Parameterization of the L2-CP Firmware for the TXS communication

processors

16. Software Test Plan - The Software Test Plan document provides the softwareintegration test plan using SIVAT for the UFTR TXS project. This plan supports thefollowing objectives:

* To define the Software Test Items to be tested.* To detail the approach required to prepare for and conduct SIVAT testing.* To define the resources needed to perform the testing.* To communicate to all responsible parties the tasks that they are to perform and

the schedule to be followed in performing the tasks.* To define the test tools and environment needed to conduct SIVAT testing.* To describe the acceptance (pass/fail) criteria for the Software Test Items being

tested.This testing is executed in order to verify that the functional requirements of the

Software Requirement Specification and the software design in the SDD are properly

implemented in the SPACE application.

17. Software Test Specification - The Software Test Specification documents provide thesoftware test specifications for application specific software for the UFTR TXS project,as outlined in the Software Test Plan. This testing is executed in order to verify that thesoftware design defined in the SDD was properly implemented in the SPACE databaseand to verify the validity of that design.

18. Software Test Procedure - The Software Test Procedure documents provide thesoftware test procedure for application specific software for the inputs as outlined in theSoftware Test Plan. The test procedures are constructed of a variety of test scripts thatinstitute the test cases defined in the Application Software Inputs Test Specification.The test scripts contain the actual test procedure steps. The test scripts allow automatedprocessing of the test procedure. These test scripts were created by utilizing the SDDand the Application Software Code.

19. Software Test Reports - The Software Test Reports document the software functionaltests of the UFTR TXS project, as outlined in the Software Test Plan.

UFINRE Prepared by Reviewed by QA-1, UFTR-QAI-02UF/R Name: Name: Revision 0 Copy 1


20. Factory Acceptance Test Plan - The FAT Plan is to establish the framework forconducting FAT for the UFTR TXS project. This FAT Plan provides top levelspecification for the development of the individual Test Specifications / Procedures, theTest Log, the Test Incident Report, and the FAT Summary Report. The FAT Plan alsoprovides the guidance for preparing, performing, documenting, resolving, and finalizingtests associated with FAT.

21. Factory Acceptance Test Specification - The FAT Specification documents providethe system and integration test specifications for application specific software for theUFTR TXS project, as outlined in the FAT Plan. The FAT Specifications specifies thetest requirements that validate that the UFTR TXS system meets design specifications.These test specifications validate functionality under a comprehensive set of realisticoperating conditions. Specific acceptance criteria are defined in the individual testspecifications. The test specifications identify the tools required to perform the test.

22. Factory Acceptance Test Procedure - The FAT Procedures provide the system andsoftware integration test procedures for application specific software for the inputs asoutlined in the FAT Plan. The test procedures are constructed of a combination ofmanual steps and test scripts that institute the test cases defined in the FATSpecification. The test scripts contain the actual test procedure steps. The test scriptsallow automated processing of the test procedure. These test scripts were created byutilizing the SDD and the Application Software Code.

23. Factory Acceptance Test Reports - The FAT Reports document the system andsoftware acceptance tests of the UFTR TXS project, as outlined in the FAT Plan.

24. Graphic Service Monitor Screen Code (Software Release) - The GSM Screen Code(Software Release) is the UFTR GSM software.

25. Graphic Service Monitor Software Requirements Specification - The GSM SRSprovides the software requirements for the GSM Screens. This document also containsa description of the functionality of the GSM Screens and serves as a guide to thedesigners, developers, and testing personnel responsible for the engineering of the GSMScreens. The documentation following this SRS will be the GSM Screen Codedocument.

26. Graphic Service Monitor Screen Code - The GSM Screen Code document capturesthe GSM screens and related scripts which satisfy the requirements identified in theSystem Functional Description and the GSM SRS. This document also describes thebasic installation and start-up steps for GSM software.

27. Gateway Historical Application Software Requirements Specification - TheGateway Historical Application (GHA) SRS document provides the SRS of theHistorical Application of the Communication Bridge (TXS Gateway) between the TXSSystem and the plant computer.


UFTR Name: Name: Revision 0 f Copy IDate: Initials: Date: Initials: of 53

28. Gateway Historical Application Software Design Description - The GHA-SDDdocument provides the SDD of the Historical Application of the CommunicationBridge (TXS Gateway) between the TXS System and plant computer.

29. Gateway Historical Application Code - The GHA Code document provides the codelisting for the Historical Application of the Communication Bridge (TXS Gateway)between the TXS System and the plant computer.

30. Gateway Historical Application (Software Release) - The Gateway HistoricalApplication (Software Release) is the System Software utilized by the project forrecording Historical information on the TXS Gateway.