Project ID: QA-I UFIR QUALITY ASSURANCE DOCUMENT Revision 0 Copy 1, Page 1 of 54. Approved by, Prof Alireza Haghighat. ... A.../.J.

Transcription

1 UF/NRE Project ID: QA-I UFIR QUALITY ASSURANCE DOCUMENT Revision 0 Copy 1, Page 1 of 54 Project Title: UFTR DIGITAL CONTROL SYSTEM UPGRADE UFTR-QA1-02, Software Configuration Management Plan (SCMP) Prepared by, Matthew Marzano and Dr. Gabriel Ghita Reviewed by, Prof. DuWayne Schubring......(Signature) Date:...' nw. Date: Approved by, Prof Alireza Haghighat... A..../.J. (Signature) Date:.,../4.7./. -..

2 UFINRE Prepared by Reviewed by QA-I, UFTR-QAI-02 Name: Name: Revision 0 Copy.1 UFTR Date : Initials: Date : Initials: Page 2 of 54 THE DISTRIBUTION LIST OF THE DOCUMENT

3 UFINRE Prepared by Reviewed by QA-1, UFTR-QAI-02 Name: Name: Revision 0 Copy 1 UFTR Date : Initials: Date : Initials: Page 3 of 54 THE LIST OF THE REVISED PAGES OF THE DOCUMENT Revision no. Reviewed by Approved by The Modified Pages Date

4 UFINRE Prepared by Reviewed by QA-1, UFTR-QAI-02 UFTR Name: Name: Revision 0 Copy I Date: Initials: Date: Initials: Page 4 of 54 TABLE OF CONTENTS 1. Introduction Purpose Scope and Applicability References UFTR Documents AREVA NP Inc. Documents Industry Standards NRC Documents Definitions, Abbreviations And Acronyms Definitions Abbreviations And Acronyms SCM M anagement Organization SCM Responsibilities Applicable Policies, Directives, and Procedures SCM Activities Configuration Identification Identifying Configuration Items Naming Configuration Items Identification of Software Components CRC Checksums Identification of TXS System Software Identification of TXS Application Software Identification of Downloaded Software Acquiring Configuration Items Configuration Control Change Control Configuration and Control Board (CCB) Code Control TXS System and Tools Software Configuration Control TXS Project-Specific Software Baseline Control... 26

5 UFINRE Prepared by Reviewed by QA-), UFTR-QAI-02 UFTR Name: Name: Revision 0 Copy 1 Date: Initials: Date: Initials: Page 5 of CM Procedure during Initial Generation of TXS Application Software Engineering Implementation of the Design in the Engineering Database using SPACE Functional Tests of Design Code Generation Check Identity of TXS System Software Configuration Setup of Engineering Database Backup of Engineering Database prior to Code Generation Code Generation Compiling / Linking / Locating of TXS Code Generation of Application Code for the TXS Gateway Checksums of the Complete Code Directory Backup of the Specification Data after Code Generation Creation of Software and Hardware Listing Analysis of MIC files List of Changeable Parameters Software Release CD Software Download Creation of the Online Database Download Procedure CM Procedure during Modification of TXS Application Software Engineering Tracking Changes , Modification of the Engineering Database using SPACE Software Release Modifications Interim Software Release Modifications Functional Tests of Database Modifications Code Generation Check Identity of TXS System Software Configuration Setup of Engineering Database Backup of the Engineering Database prior to Code Generation Check of Identity and Consistency of the previously generated C Code Code Generation Compiling / Linking / Locating of TXS Code Generation of Application Code for TXS Gateway... 36

6 UF/NRE Prepared by Reviewed by QA-I, UFTR-QA I-02 UFTR Name: Name: Revision 0 Copy 1 Date: Initials: Date: Initials: Page 6 of Checksums of the complete Code Directory Backup of the Specification Data after Code Generation Creation of Software and Hardware Listings Analysis of the MIC-files List of Changeable Parameters Software Release CD Software Download Creation of the new Online Database Download Procedure System Normalization Software Download after Module Replacement Final Documentation CM Procedure during Parameter Modifications Changeable Parameters Verification of Parameter Changes Constants Media Control Media Control for Documents Media Control for TXS System Software and Additional Software Media Control for SPACE Function Diagrams, Test Scripts, and Service Scripts Software Release CD Configuration Status Accounting Configuration Audits and Reviews Software Configuration Management Plan Reviews Physical Configuration Audits Functional Configuration Audits Software Process Audits Interface Control Organizational Interfaces Project Software Interfaces to External Items Subcontractor/Vendor Control Anomalies Identified after Release SCM Schedule SCM Resources Tools... 47

7 UFINRE Prepared by Reviewed by QA-I, UFTR-QAI-02 UFTR Name: Name: Revision 0 Copy 1 Date: Initials: Date: Initials: Page 7 of Tools Overview... e Tools for Application Software Tools for Sim ulation and Verification Personnel Software Librarian SCM Plan Maintenance Responsibility Updates Change Approval Change Distribution... 48

8 UFMRE Prepared by Reviewed by QA-1, UFTR-QAI-02 UFTR Name: Name: Revision 0 F Copy 1 Date: Initials: Date: Initials: Page 8 of 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 Phase 2 Phase 3 Phase 4 Phase 5 Phase 6 Phase 7 Project Startup/Conceptual Engineering Basic HW/SW Engineering Detailed HW/SW Engineering Manufacturing Testing Installation and Commissioning 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 , /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 , /18/, and ANSI/IEEE Std , /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 , /18/, and ANSI/IEEE Std , /20/. The intended audience and primary users of the SCMP are those that are planning and executing SCM activities or conducting SCM audits.

9 UFINRE Prepared by Reviewed by QA-l, UFTR-QA1-02 UFTR Name: Name: Revision 0 Copy I Date: Initials: Date: Initials: Page 9 of 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 the Basic 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 the UFTR 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 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" AREVA NP Inc. Documents /12/ AREVA NP Inc. Document No., , "TELEPERM XS Software Authentication Tools reflist and scanmic (TXS Software release and Higher for LINUX) User Manual TXS V1.0/02.03"

10 Prepared by Reviewed by QA-), UFTR-QAI-02 U Name: Name: Revision 0 copy I UFTR Date: Initials: Date:. Initials: Page 10 of 54 /13/ AREVA NP Inc. Document No , "TELEPERM XS Code Generation (for TXS Software Release and Higher for LINUX) User Manual" /14/ AREVA NP Inc. Document No , "TELEPERM XS SIVAT-TXS Simulation Based Validation Tool (version and higher) User Manual TXS V2.1" /15/ AREVA NP Inc. Document No , TELEPERM XS SPACE Editor (TXS Software release and Higher for LINUX) User Manual" /16/ AREVA NP Inc. Document No , TELEPERM XS Database Administration Tool dbadmin (TXS Software release and Higher for LINUX) User Manual Industry Standards /17/ IEEE Std , "Standard Glossary of Software Engineering Terminology" /18/ IEEE Std , "Standard for Software Configuration Management Plans" /19/ IEEE Std , "Standard for Software Verification and Validation" /20/ ANSI/IEEE Std , "An American National Standard IEEE Guide to Software Configuration Management" NRC Documents /21/ Regulatory Guide 1.169, "Configuration Management Plans for Digital Computer Software Used in Safety Systems of Nuclear Power Plants", September Definitions, Abbreviations And Acronyms Definitions Anomaly, [IEEE Std , /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 not limited 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 and generated by the SPACE Engineering Tool. The platform System Software uses this

11 UFINRE Prepared by Reviewed by QA-I, UFTR-QAI-02 UFTR Name: Name: Revision 0 Copy I Date: Initials: Date: Initials: Page 11 of 54 configuration data in order to carry out the application specific functionality of the I&C system. Baseline, [IEEE Std , /17/]: A specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures. Formal review and agreement means that responsible management has reviewed and approved a baseline. Baselines are subject to change control. (Reg. Guide 1.169, /21/) Baseline Management, [IEEE Std , /17/]: In configuration management, the application of technical and administrative direction to designate the documents and changes to those documents that formally identify and establish baselines at specific times during the life cycle of a configuration item. Component, [IEEE Std , /17/]: One of the parts that makes up a system. A component may be hardware or software and may be subdivided into other components. Configuration, [IEEE Std , /17/]: (1) The arrangement of a computer system or component as defined by the number, nature, and interconnections of its constituent parts. (2) In configuration management, the functional and physical characteristics of hardware or software as set forth in technical documentation or achieved in a product. Configuration Control, [IEEE Sid , /17/]: An element of configuration management, consisting of the evaluation, coordination, approval or disapproval, and implementation of changes to CIs after formal establishment of their configuration identification. Configuration Control Board (CCB), [IEEE Std , /17/]: A group of people responsible for evaluating and approving or disapproving proposed changes to CIs, and for ensuring implementation of approved changes. Configuration Identification, [IEEE Std , /17/]: An element of configuration management, consisting of selecting the CIs for a system and recording their functional and physical characteristics in technical documentation. The current approved technical documentation for a configuration item as set forth in specifications, drawings, associated lists, and documents referenced therein.

12 UFINRE Prepared by Reviewed by QA-), UFTR-QA1-02 UFTR Name: Name: Revision 0 Copy 1 Date: Initials: Date: Initials: Page 12 of 54 Configuration Item (CI), [IEEE Std , /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 ,/17/]: A discipline applying technical and administrative direction and surveillance to: * Identify and document the functional and physical characteristics of a configuration item * Control changes to those characteristics * Record and report change processing and implementation status " Verify compliance with specified requirements Configuration Status Accounting, [IEEE Std , /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 of proposed changes to the configuration, and the implementation status of approved changes. Control Point, [IEEE Std , /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 or release of a specified document/code. Functional Configuration Audit, [IEEE Sid ,/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 and functional characteristics specified in the functional or allocated configuration identification, 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 the functions 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 a different name, but whatever document is provided by the customer to meet this function will fit this definition. Interface, [IEEE Std , /17/]: * A shared boundary across which information is passed. This boundary includes design interfaces between design organizations (Reg. Guide 1.169, /21/)

13 UFINRE Prepared by Reviewed by QA-I, UFTR-QA 1-02 UF/NR Name: Name: Revision 0T Copy I Date: Initials: Date: Initials: Page 13 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 , /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 or condition of a properly completed project. Open Items are each given a record with a 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 final resolution. Physical Configuration Audit, [IEEE Std , /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 , /20/]: A term that is used to designate certain promotions of CIs that are distributed outside 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 a loadable 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

14 UFINRE Prepared by Reviewed by QA-I, UFTR-QA I-02 Name: Name: Revision 0 Copy 1 UFTR Date: Initials: Date: Initials: Page 14 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 RTE code 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 into function 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 function blocks 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 for further evaluation. Process models can also be linked into the simulator to perform closed-loop tests. Software, [IEEE Std , /17/]: Computer programs, procedures, and possibly associated documentation and data pertaining 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 , /17/]: A controlled collection of software and related documentation that is designed to aid 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 , /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 maintenance of 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

15 UF/NRE Prepared by Reviewed by QA-I, UFTR-QA 1-02 UFTR Name: Name: Revision 0 Copy I Date: Initials: Date: Initials: Page 15 of 54 * Load Analysis tool * Database administration Unit, [IEEE Std , /17/]: " A separately testable element specified in the design of a computer software component " A logically separable part of a computer program * A software component that is not subdivided into other components Version, [IEEE Sid , /17/]: An initial release or re-release of a computer software configuration item, associated with a complete compilation or recompilation of the computer software configuration item. V&V (Verification and Validation), [IEEE Sid ,/17/]:! The process of determining whether the requirements for a system or component are complete and correct, the products of each development phase fulfill the requirements or conditions imposed by the previous phase, and the final system or component complies with specified requirements Abbreviations And Acronyms ANSI CCB CD CD-ROM CI CM CoC CRC ECP EEPROM FAT FDG FEPROM FRS GSM I&C I/O ICS ID IEEE IS American National Standards Institute Configuration Control Board Compact Disc Compact Disc - Read Only Memory Configuration Item Configuration Management Certificate of Compliance Cyclic Redundancy Check Engineering Change Proposal Electrically Erasable Programmable Read Only Memory Factory Acceptance Test Function Diagram Group Flash Erasable Programmable Read Only Memory Functional Requirements Specification Graphic Service Monitor Instrumentation and Control Input/Output I&C Systems Identification Institute of Electrical and Electronic Engineers Information System

16 UFINRE Prepared by Reviewed by QA-), UFTR-QAI-02 UFTR Name: Name: Revision 0 Copy 1 Date: Initials: Date: Initials: Page 16 of 54 IV&V MAC MIC MSI OAC QA QDS RPS RTE SCM SCMP SDD SDQA SIVAT SPACE SRS Std SM SU TXS V&V Independent Verification & Validation Media Access Control An executable file in the Micros system Monitoring and Service Interface Operator Aid Computer Quality Assurance Qualified Display System Reactor Protection System Run Time Environment Software Configuration Management Software Configuration Management Plan Software Design Description Software & Data Quality Assurance Simulation Based Validation Tool Specification and Coding Environment Software Requirement Specification Standard Service Monitor Service Unit TELEPERM XS Verification & Validation

17 UFINRE Prepared by Reviewed by QA-I, UFTR-QAI-02 Name: Name: Revision 0 f Copy I UFTR Date: Initials: Date: Initials: Page 17 of SCM Management 2.1 Organization The project specific organizational units, their responsibilities and relationships with 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 safety software under development and the SCM of that software. In addition, Quality Assurance oversight shall be provided per the UFTR "Quality Assurance Program (QAP),"/1/, and UFTR SQAP, /4/. The Project manager provides managerial (including budgeting and scheduling) and technical independence between the software design and Verification & Validation (V&V) efforts, the Software Development and Independent V&V (IV&V) groups. 2.2 SCM Responsibilities The general responsibilities for SCM are summarized in Table A Configuration Control Board (CCB) will be responsible for oversight of SCM activities. The objective, authority, membership, and procedures of the CCB are defined in Section Table SCM Responsibilities Assignments Software Software SCM Activity Project Manager Project Coordinator Developmen t Lead Development Group Project Team QA Iv&v Configuration Approve Originate Identification Baseline Establishment Approve Approve Originate Change Identification (Open Items) Originate Originate Originate Originate Originate Originate Originate Open Item Approve Approve Approve/ Originate Evaluation /Originate /Originate Originate Open Item Implementation Originate Originate Originate Originate Open Item VeifctinOriginate Originate Originate Originate Open Item Approve Approve Approve Closure Configuration Status Approve Approve Originate Accounting Configuration Audits Originate/ Originate Respond Originate Originate and Reviews Respond Interface Approve Administer Administer/ Administer Control /Approve Approve Configuration Approve Administer Administer! Administer Control /Approve Maintain Approve Release Release Release Contron Release V&V Documents to Dont Lb ay DocumentLi Document to r y Library Libry Library Software Approve Release Controlled Release Controlled Administer/ Maintain Release Release Software to Library Software to Library (Software Librarian) Subcontractor and Request Originate/ Vendor Control Request Approve

18 UFINRE Prepared by Reviewed by QA-1, UFTR-QAI-02 UFTR Name: Name: Revision 0 f Copy 1 Date: Initials: Date: Initials: Page 18 of Applicable Policies, Directives, and Procedures All activities in this SCMP shall be conducted per the requirements of UFTR SQAP, /4/, UFTR "Conduct of Quality Assurance," /2/, and UFTR QAP, /1/.

19 UFINRE Prepared by Reviewed by QA-1, UFTR-QAI-02 UFTR Name: Name: Revision 0 Copy 1 Date: Initials: Date: Initials: Page 19 of SCM Activities 3.1 Configuration Identification Configuration identification shall be applied to all the UFTR Digital Control Project CIs, specifically the safety related TXS Application and System Software, tools for engineering testing, and the associated documentation. A software configuration shall be made up of software elements and the associated documentation. The specific CIs and their association with a specific phase of the project are identified in Section Identifying Configuration Items Table identifies the CIs and the phase when each document is generated by UFTR personnel. Table UFTR Digital Control System Upgrade Project Configuration Items Configuration Item (CI) Phase (e When. nrdcin Generated (See 1.0 Introduction) Software Configuration Items List (document) Phase 2, 3, 5, 6 &7 System Architecture (document) Phase 2 Basic Design Hardware Parameters Listing (document) Phase 2 & 3 Restricted Information (document) Phase 2 & 3 Software Configuration Management plan (this document) Phase 2 Basic Design Software Safety Plan (document) Phase 2 Basic Design ID Coding Concepts (document) Phase 2 Basic Design Software Requirements Specification (document) Phase 2 Basic Design 1V&V Activity Phase Summary Reports Phase 2, 3, 5, 6 &7 Software Design Description (document) Phase 3 Detailed Design TXS Application Software (software) (Software Release) Phase 3 Detailed Design Application Software Code (SPACE function diagrams) (document) Phase 3 Detailed Design Code Configuration (document) Phase 3 Detailed Design Changeable Parameters List (document) Phase 3 Detailed Design Software Generation and Download Procedure (document) Phase 3 Detailed Design Software Test Plan (document) Phase 3 Detailed Design Software Test Specification/Procedures (document) Phase 3 Detailed Design Software Test Reports (document) Phase 3 Detailed Design FAT Plan (document) Phase 5 Testing Software FAT Specifications/Procedures (document) Phase 5 Testing FAT Reports (document) Phase 5 Testing GSM Deliverables GSM Screen Code (software) (Software Release) Phase 3 Detailed Design GSM Software Requirements Specification (document) Phase 2 Basic Design GSM Code Documentation (document) Phase 3 Detailed Design QDS Deliverables QDS Software Requirements Specification (document) Phase 2 Basic Design QDS Code (software) (Software Release) Phase 2 Basic Design QDS Code Documentation (document) Phase 3 Detailed Design

20 Prepared by Reviewed by QA-), UFTR-QAI-02 UF/R Name: Name: Revision 0 Copy I UFTR Date: Initials: Date: Initials: Page 20 of 54 Table identifies those System Software products that are generated by AREVA NP Inc. ICS or its qualified vendors and become CIs on this project. Table AREVA NP Inc. or its qualified vendors Configuration Items Configuration Item (CI) Configuration tem_(ci (See TXS System Platform Software (GmbH-software) TXS Service Unit Software (GmbH-software) TXS Simulation Software SIVAT (GmbH-software) TXS Gateway Software (GmbH-software) TXS System Platform Documentation (GmbH-documents) SPACE Engineering System Software Configuration (GmbH-documents) SPACE Engineering System Software CoC (GmbH-documents) QDS Software (GmbH-software) /1/. Phase When Generated 1.0 Introduction) Phase 2 Basic Design Phase 2 Basic Design Phase 2 Basic Design Phase 2 Basic Design Phase 2 Basic Design Phase 2 Basic Design Phase 2 Basic Design Phase 2 Basic Design CIs that are documents shall be approved in accordance with the UFTR QAP, Baselines shall be established for the control of the CIs. The Control Points for 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 UFTR QAPP, /3/. Throughout the software development life cycle, at the discretion of the Software Development Lead, releases may be performed. The current status of all CIs at each baseline shall be reflected in the Software CIs List. Identification of the CIs during the Software Life Cycle is conducted in accordance with Section of this procedure. Control of the CIs during the Software Life Cycle is conducted in accordance with Section 3.2 of this procedure. Configuration control of documents associated with the System and Application Software is established through the UFTR QAP, /1/ Naming Configuration Items Each System and Application Software Configuration Item shall be assigned a unique version number. Assigning a Configuration Item number for software items shall be done in accordance with UFTR "Software Library and Control," /10/ Identification of Software Components The precompiled components of the TXS system software and all TXS tools shall be labeled with a unique version identifier, which consists of a version number and the release date. This identification is part of each software component. It is written into the original code in form of identification strings (ID-strings). The SPACE code generators produce the source code for the application software, which also contains ID-strings (Reference /13/). The application software shall also be labeled with a unique version identifier, which consists of a version number and the release date. This ensures that all generated

21 UF/NRE Prepared by Reviewed by QA-), UFTR-QAI-02 UFTR Name: Name: Revision 0 Copy I Date: Initials: Date: Initials: Page 21 of 54 function diagram modules and function diagram group (FDG) modules are unambiguously identifiable. A cyclic redundancy check (CRC) checksum shall be calculated and recorded as part of the respective Software Release documentation to check the identity of whole software configuration for each file of the TXS system software and application software, CRC Checksums In the data processing world, CRC methods are applied for identification of data files in a directory. These CRC checksums are created over all bits of data files in a directory and are extremely sensitive for modifications of this file in any regard. For this purpose the authentication tool reflist shall be used. The reflist creates CRC checksums recursively for all the subdirectories and files within a directory and outputs them in a list. The date of the last change for the file can also be output. Unless specified otherwise, reflist generates an 8-digit CRC32 in accordance with POSIX standards. This is a widespread algorithm providing good security against random errors during data transport and storage. The probability that any two files have the same checksum is approximately 2xl A typical checksum computed using CRC-32 looks like this: 1F77BED5. In addition, CRC checksums can also be generated across all files according to the following standards: * CRC 16 acc. to CCITT, 4-digit: This is a widespread algorithm providing adequate security against random errors during data transport and storage. Due to the 4-digit checksum, the probability of any two files possessing the same checksum is significantly larger than CRC32, and is 2x10-5. Therefore, it is possible to construct files with identical checksums but different contents. * MD55 acc. to RFC 1321, 32-digit: This is a popular algorithm providing superior security against random errors. Using this method, the probability of having identical checksums is 3x Checksums according to CRC32 are standard for the TXS platform. The scope of files to be processed can be specified as a list of files and/or directories in the call or in an input file. Alternatively, the scope can be read from the standard input. This makes it possible to select the scope by means of shell 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.

22 UFINRE Prepared by Reviewed by QA-1, UFTR-QAI-02 UFTR Name: Name: Revision 0 f Copy 1 Date: Initials: Date: Initials: Page 22 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 an engineering platform (engineering workstation), as well as for software downloaded into the I&C system Identification of TXS System Software The identity of the TXS System Software is provided by AREVA NP with the TXS platform and tools required for the UFTR digital control upgrade. The identification process for the TXS System Software prior to and during installation is described below. The design specification of each TXS system software component includes a structured overview of all configuration elements. This overview covers all levels of the life cycle of the component, from the requirements to the test. The version management of the configuration elements is carried out within a version management system. The implementation description forms the decisive document on the implementation level. The implementation description of each software component contains a detailed description of the development results as well as the code and the installation configuration. An installation configuration contains all data files which are delivered within a TXS installation: executable programs, DLLs, object modules, prelinks, header files, etc. For each data file included in the installation configuration, the following information 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 development documentation shall be subject to external (third party) evaluation. This includes the fact that the installation configurations as well as the HTV-CRC checksums of the data files are listed in the test certificate of a qualified TXS system 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 in order to prove the identity of the system software components contained in a given TXS installation. The components of the TXS operating system software are delivered in the form of pre-links. That means that the object files of the qualified components (identified with HV-CRC checksums) are linked together and the created pre-link is identified by a HV-CRC checksum, too.

23 UF/NRE Prepared by Reviewed by QA-I, UFTR-QA 1-02 Name: Name: Revision 0 Copy 1 UFTR Date: Initials: Date: Initials: Page 23 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. The reflist will calculate and record CRC checksums of all files in the SPACE directory. The comparison of this listing with the reference listing stored on the installation CDs shall be done using the LINUX diff command Identification of TXS Application Software The application software is created strictly according to the single source principle. 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 Database tables into ASCII backup files (dbadmin -unload) and calculation of CRC checksums of these files (reflist), a certain version of the application software can be identified unambiguously. These backup files form an unambiguous image. Thus the database created by restoring these files is identical to the original one. " The code generation results are identified by creation of a CRC checksum of the complete software directory using reflist. " The executable code (one MIC file per CPU) is identified by creation of CRC checksums for each of these files using reflist Identification of Downloaded Software The MIC files are downloaded into memory areas (segments) of the Flash Erasable Programmable Read Only Memory (FEPROM) of the respective SVE1/SVE2 module in a centralized way (using the Service Monitor Server, sins) or locally (using the program sveload). For each segment of the FEPROM, the download method (sins or sveload) creates a CRC checksum, which is stored in the Electrically Erasable Programmable Read Only Memory (EEPROM) of this SVE1/SVE2 (FS-CRC). Using the TXS tool scanmic on each MIC file, the HV-CRC checksum and the Message Digested 5 (MD5)-CRC checksum, as well as, the Flash Segment (FS)-CRC checksums, are generated in advance on the engineering workstation. A certain version of the complete software (pre-integrated and application-specific software) is identifiable on the hard disk of the engineering workstation using the HV-CRC and MD5-CRC checksums.

24 UFINRE UFTR Prepared by Reviewed by QA-), UFTR-QAI-02 Name: Name: Revision 0 Copy I Date: Initials: Date: Initials: Page 24 of 54 Using the FS-CRC checksums, a certain version of the downloaded software 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 Acquiring Configuration Items Physical storage, archiving, and retrieval of CI documentation and magnetic media is performed in accordance the UFTR "Software Library and Control," /10/, covers the administrative controls for Application Software Cis that describes the format, documentation, inspection, and access control for code and data stored in each library. 3.2 Configuration Control Configuration control activities request, evaluate, approve or disapprove, and implement changes to baseline CIs. Changes encompass both error correction and enhancement. 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/ 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 Items identified 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 Configuration and Control Board (CCB) UFTR does not use CCB meetings on a regularly basis. Since all changes are tracked via the Open Item process governed by the UFTR QAP, /1/, and that process requires an evaluation of document and software changes, board meetings in 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 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:

25 UFINRE Prepared by Reviewed by QA-I, UFTR-QAI-02 Name: Name: Revision 0 Copy 1 Date: Initials: Date: Initials: Page 25 of 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 and implementation of System and Tools software revisions between AREVA NP Inc. ICS and AREVA NP GmbH is governed by internal AREVA NP Inc. procedures. The TXS System Software and Tools are received from AREVA NP Inc. ICS. Control over purchasing and acquisition, as well as Nonconformance/Open Items reporting, of the TXS Platform is defined in 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 Application Software. 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 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 configuration of 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 RPS processors 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 Service Interface (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.

26 UFINRE Prepared by Reviewed by QA-I, UFTR-QAI-02 UFTR Name: Name: Revision 0 Copy 1 Date: Initials: Date: Initials: Page 26 of Service Messages are transmitted using predefined data package structures. 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 regardless of 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 the TXS 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/ 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 ). 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 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.

27 UF/NRE Prepared by Reviewed by QA-I, UFTR-QAI-02 Name: Name: Revision 0 Copy 1 UFTR Date : Initials: Date : Initials: Page 27 of Engineering Implementation of the Design in the Engineering Database using SPACE The design required by the Software Design Description (SDD) shall be implemented in the Engineering Database using the SPACE tool "fde," /15/ Functional Tests of Design The Code shall be checked by: 1. Visual check of SPACE diagrams by an independent reviewer 2. Validation of the functionality in the SIVAT test environment Code Generation 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 the complete system software installation is calculated using "reflist", and compared to the reference configuration using "diff'. By means of this method, all released software components including the operation system pre-links are checked. The project specific Add-Ons shall be checked as well in the same way Setup of Engineering Database The definition tables of the Engineering Database contain the product information of all TXS system software components, as well as the definitions of templates, function blocks, etc. This information is stored in setup files as part of the TXS system software configuration and shall be implemented in the TXS project database using the SPACE tool dbadmin (option: -setup). This step assures that the correct definitions and system configurations are implemented in the Engineering Database Backup of Engineering Database prior to Code Generation Directly prior to code generation, a backup copy of the Engineering Database 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 is reproducible.