ML100550677
| ML100550677 | |
| Person / Time | |
|---|---|
| Site: | 05000083 |
| Issue date: | 02/17/2010 |
| From: | Ghita G, Marzano M Univ of Florida |
| To: | Office of Nuclear Reactor Regulation |
| References | |
| UFTR-QA1-02 | |
| Download: ML100550677 (53) | |
Text
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, 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-02 Name: Name: Revision 0 Copy .1 UFTR Date : Initials:
Date : Initials:
Page 2 of 54 THE DISTRIBUTION LIST OF THE DOCUMENT 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 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
..............................................................................................................................
8 1.1 Purpose .............................................................................................................................
8 1.2 Scope and Applicability
.............................................................................................
9 1.3 References
........................................................................................................................
9 1.3.1 UFTR Documents
.........................................................................................
9 1.3.2 AREVA NP Inc. Documents
......................................................................
9 1.3.3 Industry Standards
....................................................................................
10 1.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 ...............................................................
19 3.1.2 Naming Configuration Items ....................................................................
20 3.1.2.1 Identification of Software Components
........................................
20 3.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 ...............................
23 3.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 ...........................................................................................
24 3.2.2 Configuration and Control Board (CCB) ...............................................
24 3.2.3 Code Control ................................................................................
..................
24 3.2.4 TXS System and Tools Software Configuration Control .......................
25 3.2.5 TXS Project-Specific Software Baseline Control ....................................
26 UFINRE Prepared by Reviewed by QA-), UFTR-QAI-02 UFTR Name: Name: Revision 0 Copy 1 Date: Initials:
Date: Initials:
Page 5 of 54 3.2.5.1 CM Procedure during Initial Generation of TXS Application Software ...........................................................................................
26 3.2.5.1.1 Engineering
.............................................................................
27 3.2.5.1.1.1 Implementation of the Design in the Engineering Database using SPACE ....................................................................
27 3.2.5.1.1.2 Functional Tests of Design .............................................
27 3.2.5.1.2 Code Generation
......................................................................
27 3.2.5.1.2.1 Check Identity of TXS System Software Configuration
...27 3.2.5.1.2.2 Setup of Engineering Database ......................................
27 3.2.5.1.2.3 Backup of Engineering Database prior to Code Generation
.............................................................................................
27 3.2.5.1.2.4 Code Generation
.............................................................
28 3.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 .... 28 3.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.29 3.2.5.1.2.9 Creation of Software and Hardware Listing ................
29 3.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 ......................................................
30 3.2.5.1.3 Software Download ..................................................................
30 3.2.5.1.3.1 Creation of the Online Database....................................
30 3.2.5.1.3.2 Download Procedure
......................................................
30 3.2.5.2 CM Procedure during Modification of TXS Application Software-................................
.....................................
31 3.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
.............................................
32 3.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
......................................................................
34 3.2.5.2.2.1 Check Identity of TXS System Software Configuration
...34 3.2.5.2.2.2 Setup of Engineering Database ......................................
34 3.2.5.2.2.3 Backup of the Engineering Database prior to Code Generation
........................................................................
35 3.2.5.2.2.4 Check of Identity and Consistency of the previously generated C Code .............................................................
35 3.2.5.2.2.5 Code Generation
.............................
35 3.2.5.2.2.6 Compiling
/ Linking / Locating of TXS Code ...............
36 3.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 UFTR Name: Name: Revision 0 Copy 1 Date: Initials:
Date: Initials:
Page 6 of 53 3.2.5.2.2.8 Checksums of the complete Code Directory
.................
36 3.2.5.2.2.9 Backup of the Specification Data after Code Generation.37 3.2.5.2.2.10 Creation of Software and Hardware Listings ................
37 3.2.5.2.2.11 Analysis of the MIC-files
................................................
37 3.2.5.2.2.12 List of Changeable Parameters
......................................
37 3.2.5.2.2.13 Software Release CD ...........................................
37 3.2.5.2.3 Software Download ................................................................
38 3.2.5.2.3.1 Creation of the new Online Database ..............
38 3.2.5.2.3.2 Download Procedure
......................................................
38 3.2.5.2.3.3 System Normalization
......................................................
39 3.2.5.2.3.4 Software Download after Module Replacement
...........
39 3.2.5.2.3.5 Final Documentation
.................................
...........................
39 3.2.5.3 CM Procedure during Parameter Modifications
.......................
39 3.2.5.3.1 Changeable Parameters
........................................................
40 3.2.5.3.2 Verification of Parameter Changes ......................................
40 3.2.5.3.3 Constants
.................................................................................
40 3.2.6 Media Control ........ .....................................................................................
41 3.2.6.1 Media Control for Documents
......................................................
41 3.2.6.2 Media Control for TXS System Software and Additional Software... .................................................................................
41 3.2.6.3 Media Control for SPACE Function Diagrams, Test Scripts, and Service Scripts ...............................................................................
41 3.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 .............................
43 3.4.2 Physical Configuration Audits ..................................................................
43 3.4.3 Functional Configuration Audits .............................................................
43 3.4.4 Software Process Audits ............................................................................
44 3.5 Interface Control ......................................................................................................
44 3.5.1 Organizational Interfaces
...........................................................................
44 3.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 UFTR Name: Name: Revision 0 Copy 1 Date: Initials:
Date: Initials:
Page 7 of 53 5.1.1 Tools Overview .................................................
e ..............................................
47 5.1.2 Tools for Application Software ..................................................................
47 5.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 1 Date: Initials:
Date: Initials:
Page 8 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 Engineering Phase 2 Basic HW/SW Engineering Phase 3 Detailed HW/SW Engineering Phase 4 Manufacturing Phase 5 Testing Phase 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-02 Name: Name: Revision 0 Copy I UFTR Date: Initials:
Date: Initials:
Page 9 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 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 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 V1.0/02.03" 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. 01-1007773-01, "TELEPERM XS Code Generation (for TXS Software Release 3.0.0 and Higher for LINUX) User Manual"/14/ AREVA NP Inc. Document No. 01-5044046-01, "TELEPERM XS SIVAT-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 XS SPACE Editor (TXS Software release 3.0.0 and Higher for LINUX)User Manual"/16/ AREVA NP Inc. Document No. 01-1007770-00, TELEPERM XS Database 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 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 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 61 0.12-1990, /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 610.12-1990, /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 610.12-1990, /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 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 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 610.12-1990, /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 610.12-1990, /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 610.12-1990, /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.
UFINRE Prepared by Reviewed by QA-), UFTR-QA1-02 Name: Name: Revision 0 Copy 1 UFTR Date: Initials:
Date: Initials:
Page 12 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 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 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 of proposed 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 or release 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 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 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-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 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 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 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 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 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 610.12-1990, /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 610.12-1990, /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 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 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 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 610.12-1990, /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 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 software configuration item.V&V (Verification and Validation), [IEEE Sid 610.12-1990,/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.
1.4.2 Abbreviations And Acronyms ANSI American National Standards Institute CCB Configuration Control Board CD Compact Disc CD-ROM Compact Disc -Read Only Memory CI Configuration Item CM Configuration Management CoC Certificate of Compliance CRC Cyclic Redundancy Check ECP Engineering Change Proposal EEPROM Electrically Erasable Programmable Read Only Memory FAT Factory Acceptance Test FDG Function Diagram Group FEPROM Flash Erasable Programmable Read Only Memory FRS Functional Requirements Specification GSM Graphic Service Monitor I&C Instrumentation and Control I/O Input/Output ICS I&C Systems ID Identification IEEE Institute of Electrical and Electronic Engineers IS Information System 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 Independent Verification
& Validation MAC Media Access Control MIC An executable file in the Micros system MSI Monitoring and Service Interface OAC Operator Aid Computer QA Quality Assurance QDS Qualified Display System RPS Reactor Protection System RTE Run Time Environment SCM Software Configuration Management SCMP Software Configuration Management Plan SDD Software Design Description SDQA Software & Data Quality Assurance SIVAT Simulation Based Validation Tool SPACE Specification and Coding Environment SRS Software Requirement Specification Std Standard SM Service Monitor SU Service Unit TXS TELEPERM XS V&V Verification
& Validation 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 54 2. 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 2.2-1. 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 3.2.2.Table 2.2-1 SCM Responsibilities Assignments Software Software SCM Activity Project Project Developmen Development Project QA Iv&v Manager Coordinator t Lead Group Team Configuration Approve Originate Identification Baseline Establishment Approve Approve Originate Change Identification Originate Originate Originate Originate Originate Originate Originate (Open Items)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 Approve Maintain Release Contron Release V&V Release Documents to Dont Document to Release Lb ay DocumentLi r y Library Libry Library Approve Release Release Administer/
Software Controlled Controlled Maintain Release Release Software to Software to (Software Library Library Librarian)
Subcontractor and Request Originate/
Vendor Control Request Approve 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 54 2.3 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/.
UFINRE Prepared by Reviewed by QA-1, UFTR-QAI-02 Name: Name: Revision 0 Copy 1 UFTR Date: Initials:
Date: Initials:
Page 19 of 54 3. 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 3.1.1.3.1.1 Identifying Configuration Items Table 3.1.1-1 identifies the CIs and the phase when each document is generated by UFTR personnel.
Table 3.1.1-1 UFTR Digital Control System Upgrade Project Configuration Items Phase When Generated Configuration Item (CI) (e .nrdcin_______________________________________________(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 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 3.1.1-2 identifies those System Software products that are generated by AREVA 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 Generated Configuration___tem_(CI__(See 1.0 Introduction)
TXS System Platform Software (GmbH-software)
Phase 2 Basic Design TXS Service Unit Software (GmbH-software)
Phase 2 Basic Design TXS Simulation Software SIVAT (GmbH-software)
Phase 2 Basic Design TXS Gateway Software (GmbH-software)
Phase 2 Basic Design TXS System Platform Documentation (GmbH-documents)
Phase 2 Basic Design SPACE Engineering System Software Configuration (GmbH-documents)
Phase 2 Basic Design SPACE Engineering System Software CoC (GmbH-documents)
Phase 2 Basic Design QDS 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 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 3.1.2 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/.3.1.2 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/.3.1.2.1 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 UF/NRE Prepared by Reviewed by QA-), UFTR-QAI-02 Name: Name: Revision 0 Copy I UFTR 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,.
3.1.2.2 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 2xl0-1 0.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 3x1 0-3 9.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.
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.3.1.2.3 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, pre-links, 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.
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.3.1.2.4 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.3.1.2.5 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.
UFINRE Prepared by Reviewed by QA-), UFTR-QAI-02 Name: Name: Revision 0 Copy I UFTR 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.
3.1.3 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/.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 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.
3.2.2 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.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-02 Name: Name: Revision 0 Copy 1 Date: Initials:
Date: Initials:
Page 25 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 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 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 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.
UFINRE Prepared by Reviewed by QA-I, UFTR-QAI-02 UFTR Name: Name: Revision 0 Copy 1 Date: Initials:
Date: Initials:
Page 26 of 54 4. 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/.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-02 Name: Name: Revision 0 Copy 1 UFTR Date : Initials:
Date : Initials:
Page 27 of 54 3.2.5.1.1 Engineering 3.2.5.1.1.1 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/.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 reviewer 2. 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 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.3.2.5.1.2.2 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.3.2.5.1.2.3 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.
UF/NRE Prepared by Reviewed by QA-I, UFTR-QAI-02 UFTR Name: Name: Revision 0 1 Copy I Date: Initials:
Date: Initials:
Page 28 of 54 3.2.5.1.2.4 Code Generation The next step consists of generation of the C source code using the code generatorsfdgm and rte.In the course of a complete generation, the code generatorsfdgm and rte shall be started with the option new. An empty code directory shall be set for generation.
The tables of the code generation shall be emptied, using the dbadmin tool with the option -clear <db-name>
-cgtables.Both toolsfdgm and rte create verbose protocols about the process of code generation (i.e. files:fdgm.txt, rte.txt) allowing the evaluation of the 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 the ic86 compiler.
Then the compiled code shall be linked with the pre-linked system software components (link). The operation system components, already included in a pre-link, shall be linked also to the generated code. The resulting code shall be converted to absolute addresses (locate) and converted to HEX format (*.mic files). The MIC files form the final software product to be downloaded into and started in the I&C system. The compiling, linking and locating shall be recorded allowing the evaluation of the successful creation of the MIC files.Check that no ERROR or FATAL entries are contained in the ic86 log file.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 the non-TXS systems, the application code shall be compiled using the respective compiler (i.e., the LINUX C compiler for the LINUX-based TXS TXP gateway, or the Microsoft C++ compiler for the Win32-based gateways).
The resulting executables shall be stored in the code directory created by the TXS code generators.
UFINRE Prepared by Reviewed by QA-I, UFTR-QAI-02 UFTR Name: Name: Revision 0 Copy ]Date: Initials:
Date: Initials:
Page 29 of 54 3.2.5.1.2.7 Checksums of the Complete Code Directory The CRC checksums of the complete code directory are calculated and recorded (reflist).
This includes the source code and the executables for 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 database has 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 next modification process.3.2.5.1.2.9 Creation of Software and Hardware Listing By means of the SPACE tools hwparams and swparams, hardware and software parameter listings are created. Using the SPACE tool dbadmin the following listings are extracted from the engineering database: 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.
By means 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 files shall be recorded.
The scanmic tool creates a list of the implemented software 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 SVEI/SVE2 CPUs.3.2.5.1.2.11 List of Changeable Parameters For each SVE1/SVE2, the list of all changeable parameters shall be generated (via "sms/sm/gsm").
UFINRE Prepared by Reviewed by QA-1, UFTR-QAJ-02 Name: Name: Revision 0 Copy I UFTR Date : Initials:
Date : fInitials:
Page 30 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 be installed on the SU after verification of the identity (reflist).
This database, 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 local download.
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 into the 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 CRC checksums 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 and will 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 field environment 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-02 Name: Name: Revision 0 Copy I UFTR Date : Initials:
Date : fInitials:
Page 31 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 the complete creation process in an overlapping manner are: engineering, generation, and download.
The modification 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.3.2.5.2.1 Engineering 3.2.5.2.1.1 Tracking Changes The creation of the TXS Application Software is started upon the release of a FRS that provides appropriate concepts for the Software Requirement Specification (SRS) and SDD. Subsequent modifications of the 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 Open Items process defined in the UFTR QAP, /1/, and the UFTR "Conduct of Quality 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 intended modification is based on the valid version of the Engineering Database.After the verification of the CRC checksums (reflist), either the copy of the Engineering Database after the previous code generation (from the Software Release CD) or a copy of the current online database shall be loaded into a newly created or cleared Engineering Database.In case some online changeable parameters have been modified in the I&C system after the last code generation, either the Online Database has to be loaded or these parameter modifications have to be repeated in the Engineering Database.Implementation of Database Modifications The released design changes out of the "Open Items List" shall be introduced into the application software code using the SPACE toolfde.During this work step, special attention shall be paid to the fact that only the desired modifications shall be implemented.
For this purpose four general features of the SPACE tools have to be considered:
UFINRE Prepared by Reviewed by QA-I, UFTR-QAI-02 UFTR Name: Name: Revision 0( Copy I Date: Initials:
Date: Initials:
Page 32 of 54" The modification date of the modified SPACE diagrams is updated automatically," The modification of a signal connection between two function diagrams leads to an update of the modification date of both diagrams," The SPACE tool does not distinguish between functional and graphical modifications; each modification causes an update of the modification date," Modifications in the network diagram influence the complete code generation.
The following precautions are derived from these features: " No "cosmetic" modifications should be done in function or network diagrams, which are not necessary in the course of the implementation of an Open Item,* No modifications are to be implemented temporarily (i.e., to be removed afterwards),* If a signal between two function diagrams needs to be repositioned on a diagram, the signal in question should be moved and/or redrawn without deleting it. This will prevent the modification date of the untouched diagram from changing.All modifications of function diagrams between two database versions shall be recorded.
For each Open Item, the design engineer shall print and document the changes of the SRS and SDD in accordance with the 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 be incorporated into the appropriate design document (i.e., the SDD), and the corresponding change(s) shall be implemented into the engineering database (i.e., SPACE database).
After the changes have been incorporated, all function diagrams that show an altered date from the previous valid version of the engineering database shall be fully traced to the corresponding description 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, /16/, should be used to list the names of the personnel responsible for preparing and reviewing each of the FDGs in the engineering database.
The UFINRE Prepared by Reviewed by QA-), UFTR-QAI-02 UFTR Name: Name: Revision 0 Copy 1 Date: Initials:
Date: Initials:
Page 33 of 54"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 ECP package 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 be implemented 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, the ECP 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 is completed, 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 version of the engineering database shall be fully traced to the corresponding description 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.
UF/NRE Prepared by Reviewed by QA-I, UFTR-QAI-02 UFTR Name: Name: Revision 0 Copy 1 Date: Initials:
Date: Initials:
Page 34 of 54 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 an early stage in the modification process. On site tests (electrical, functional or complex) can be carried out only after software download into I&C system in course of the commissioning.
Every modification is verified at first by visual checks. Scope and depth of further tests depend on the volume and type of the modifications.
For instance, change of parameters requires only a visual check and would not require further design testing (i.e., simulation SIVAT testing).
Any change in function diagrams that impacts the coding logic shall be retested.
All modification to Application Software, both code logic and parameter changes, shall be tested/verified during FAT or commissioning.
The complexity of the change and the stage of the project shall dictate where the testing is done, i.e., simulation SIVAT testing, FAT testing or Commissioning.
Justification for the decision of the scope of testing shall be documented on the Open Item Form.Every test (except the visual checks) shall be described in a test procedure 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 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 have to be checked in the same way as well.3.2.5.2.2.2 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 UF/NRE Prepared by Reviewed by QA-), UFTR-QAI-02 UFTR Name: Name: Revision 0 Copy 1 Date: Initials:
Date: Initials:
Page 35 of 54 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.3.2.5.2.2.3 Backup of the 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.
3.2.5.2.2.4 Check of Identity and Consistency of the previously generated C Code If a modified-only code generation is intended (and only in this case) the consistency and identity of the last valid generated C code has to be checked. The CRC checksum of the complete code directory is calculated, recorded and compared with the CRC checksums recorded during 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 the code generators fdgm and rte.Complete Generation In the course of a complete generation the code generatorsfdgm and rte shall be started with the option new. An empty code directory shall be set for generation.
The tables of the code generation shall be emptied, 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 generators fdgm and rte shall be started with the option modified only (and without option new). A copy of the last code directory shall be set for generation.
In this case, the code generatorfdgm creates code only for those diagrams that have been modified since last code generation.
In the case where the network diagram has been modified, the complete code is generated again, because the code generatorfdgm assumes fundamental UF/NRE Prepared by Reviewed by QA-), UFTR-QAI-02 UFTR Name: Name: Revision 0 t Copy 1 Date: Initials:
Date: Initials:
Page 36 of 54 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 process of code generation (i.e. files: fdgm. txt, rte. txt) allowing the evaluation of the successful code generation (number of errors, warnings, and infos).Using the SPACE tool "cmpcode" two versions of the generated C code shall be compared (i.e. file: code diff <dbnamel>_<db_name2>.
xt). Such an analysis is necessary in case modifications of MIC files cannot be explained by intended 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 the ic86 compiler.
Then the compiled code shall be linked with the pre-linked system software components (link). The operation system components, already included in a pre-link, are linked also to the generated code. The resulting code shall be converted to absolute addresses (locate) and converted to HEX format (*. mic files). The MIC files form the final software product to be downloaded into and started in the I&C system. The compiling, linking and locating are recorded allowing the evaluation of the successful creation of the MIC files.Check that no ERROR or FATAL entries are contained in the ic86 log file.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 perfdg e 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 application code shall be compiled using the respective compiler (i.e., the LINUX C compiler for the LINUX-based TXSTXP gateway, or the Microsoft C++compiler for the Win32-based gateways).
The resulting executables shall be 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 be calculated and recorded (reflist).
This includes the source code and the executables for TXS.
UFINRE Prepared by Reviewed by QA-I, UFTR-QAI1-02 UFTR Name: Name: Revision 0 Copy ]Date: Initials:
Date: Initials:
Page 37 of 54 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).
The resulting 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 implemented software 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/.
UFINRE Prepared by Reviewed by QA-I, UFTR-QAI-02 UFTR Name: Name: Revision 0 Copy I Date: Initials:
Date: Initials:
Page 38 of 54 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 be installed 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 described in Section 3.2.5.2.2.2, including the respective checks, a download strategy shall be determined as a pre-condition of the download release.The download shall be performed as central download or local download.
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 SVE1/SVE2 processors and written into the EEPROM of the respective processor.
After downloading the user-software and resetting the SVE1/SVE2 processor, the CRC checksums shall be read with the help of the SU and checked against the CRC checksums predicted by the scanmic tool. This proves that the code was correctly loaded into the right SVE1/SVE2 processor.
If the CRC checksums do not match, the download was not correctly executed and will have to be repeated.During software download, the respective processors are not available for calculation of functions.
The permission for downloading software 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, the SVE1/SVE2 can be loaded in any sequence (centrally or locally).
The download process can be carried out in parallel inside the train, or in a cross-train manner. However, this is not valid if certain functionalities have to remain active during an outage, or if certain operation mode releases for central software download are creating restrictions for parallel work. The normalization of the internal memories (calibrations, etc.), the harmonization of the redundant computers, and a release of computer outputs after download depend on the specific requirements.
UFINRE Prepared by Reviewed by QA-I, UFTR-QAI-02 UFTR Name: Name: Revision 0 Copy I Date: I Initials:
Date: Initials:
Page 39 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 the indications 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 all adjustment 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 the modified software shall be repeated after software download." Adjustment parameters shall be adjusted after download to the last 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 the tool 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 the TXS-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 as constants and cannot be modified without new software generation and download.
UF/NRE Prepared by Reviewed by QA-I, UFTR-QAI-02 UFTR Name: Name: Revision 0 Copy I Date: Initials:
Date: Initials:
Page 40 of 53 The CM measures necessary during modification of these parameters are described in this section.3.2.5.3.1 Changeable Parameters Changeable parameters normally include parameters that depend on the status of the reactor or on the fuel bum-up (e.g., boron concentration, calibrations, etc.). These parameters have to be modified by the operational or maintenance personnel on a regular basis. They are maintained in a special list ("list of changeable parameters").
The "list of changeable parameters" is printed after each modification.
Modifications of these parameters are carried out by means of the SM. If the parameter values have to be valid also after a re-start of the SVE 1/SVE2, the modification shall be carried out both in RAM and EEPROM. The correct use of the new parameter values is checked by 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 modifying changeable parameters.
In the course of modifying changeable parameters, the online database shall be updated in order to maintain the consistency of archived plant documentation, animated function diagrams and current software status.For subsequent new code generations (complete or modify-only), the modified changeable parameters are incorporated from the "list of changeable parameters" maintained by the plant. In case the modified changeable parameters are applied to update a specification, Open Item must be created to 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 be generated (sms/sm/gsm).
This list has to be compared line-by-line with the reference list generated during code generation using the "diff' tool. This verifies 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 to be modified in the SPACE engineering database.
For those parameters the modification procedure described in Section 3.2.5.2 is valid.
UFINRE UFTR Prepared by Reviewed by QA-I, UFTR-QAI-02 Name: Name: Revision 0 Copy I Date: Initials:
Date: Initials:
Page 41 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 UFTR Project Server, accessible only to the UFTR personnel and select AREVA NP Inc. engineers and reviewers identified in the UFTR QAPP, /3/. Procedures covering the organization, updating, and backup of the data on the Project Server are defined in the UFTR QAPP, /3/.The final documents shall be uploaded to the UFTR Project Server where they 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 entered into 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, and Service Scripts The SPACE project database, the QDS, the GSM screens, and all scripts are stored on a LINUX network server. All data is subject to periodic backups.Only the UFTR software designers and select AREVA NP Inc. employees identified in the UFTR QAPP, /3/, can access the server. Only the UFTR personnel involved in the specification process can access the project SPACE database.Modification, storage of modified function diagrams, and documentation of these modifications are described in Section 3.2.5. The organization of data backup procedures, schedules, and the storage of data saved on removable media 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 fully documented in the associated basic and detailed design documentation.
When generated, each Software Release shall correspond to an SRS, System Architecture, SDD, and Code Document.
Each Software Release shall be fully identified via a Code Configuration Document, Hardware Parameters Listing Document, 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 in the Software Library as a TXS Application Software Release in accordance with the UFTR "Software Library and Control," /10/.
UFINRE Prepared by Reviewed by QA-I, UFTR-QA I-02 UFTR Name: Name: Revision 0 Copy 1 Date: Initials:
Date: Initials: -Page 42 of 53 All GSM screens and scripts shall be generated as per the UFTR"Software Generation and Download" Procedure, /I1/, and archived in the Software Library as a TXS GSM Software Release in accordance with the UFTR "Software Library and Control," /10/.All the QDS components shall be generated and archived in the Software Library 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 Library in 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. Schedule reporting tracks the completion of the CIs throughout the project including additional activities documented to make changes.Status reports for CIs for the UFTR digital control project are maintained on the project dedicated server in accordance to the UFTR QAPP, /3/..One of the CIs for the UFTR project will be a Code Configuration document.
This reports 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 Checksums associated with the software.
The ID strings are used in controlling the configuration of the TXS System Software as the system is assembled, tested and delivered to the UFTR personnel by AREVA NP Inc.A similar process is used for the Application Software developed and loaded into the TXS System by the UFTR Software Development group. When the Application Software is completed and issued for release, a Code Configuration Document shall be issued. This document reports, using the scanmic tool, the exact configuration of all software that is part of the safety-related software portion of the TXS System. Included in this document are the configurations of the Application Software, System Software, L2 Software, and HI Software running on the system. This configuration is documented in accordance with the UFTR QAPP, /3/. The Code Configuration Document shall be published upon each release of the software.
The Code Configuration Document will be used 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 evaluate conformance of CIs to required physical and functional characteristics.
UF/NRE Prepared by Reviewed by QA-1, UFTR-QAI-02 UFTR Name: Name: Revision 0 Copy 1 Date: Initials:
Date: Initials:
Page 43 of 53 3.4.1 Software Configuration Management Plan Reviews This Plan shall be reviewed to evaluate the adequacy and the completeness of the configuration management methods defined herein. This review shall be performed prior to the start of the project design phase.The SCMP Review shall be performed by the Project Coordinator and members of the Software Development group, IV&V group, and other personnel per the UFTR "Software Reviews and Audits," /8/.Results that require action, either technical or administrative, shall be documented 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 the target 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 the software loaded on the target hardware is correct and identifiable.
All software loaded on the TXS safety processors, L2 Processors, Hi Processors, TXS Service Unit, 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 be used 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 of the Test group, IV&V group, and other QA personnel per UFTR "Software Reviews 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 shall be reviewed for adequacy during the Physical Configuration Audit.Results that require action, either technical or administrative, shall be documented 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 requirements specified in the SRS have been met by the Software tested during FAT. The FAT Reports and supporting test data shall be audited to ensure the completeness and the accuracy 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-02 Name: Name: Revision 0 Copy 1 Date: Initials:
Date: Initials:
Page 44 of 53 The Functional Configuration Audit shall be performed after the completion of the FAT. The Functional Configuration Audit shall be executed under the lead of members 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 adequacy during the Functional Configuration Audit.Results that require action, either technical or administrative, shall be documented 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 in accordance 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 the Project 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 AREVA NP Inc. ICS, which interfaces with the Hardware Design Group of AREVA NP GmbH. The processing and resolving of problems and non-conformances with the TXS System Software is handled in accordance with the UFTR QAP, /1/, and the UFTR "Conduct of Quality Assurance," /2/.System Integration and Integration Testing provides the Interface control for the final hardware and software configuration.
These activities are normally performed 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 Vendor control refers to software acquired in its finished form. The UFTR does not subcontract software development for the Digital Control Upgrade.The TXS System Software is purchased from AREVA NP GmbH, by AREVA NP Inc. ICS. AREVA NP GmbH has implemented an appropriate Quality Assurance program for the life cycle of the System Software.
AREVA NP GmbH is an approved safety related supplier for AREVA NP Inc., as defined by appropriate AREVA internal procedures.
AREVA NP Inc. ICS is the vendor of the TXS Platform and System Software for the UFTR project. SCM activities for the TXS Platform are maintained by UFINRE Prepared by Reviewed by QA-I, UFTR-QAI-02 UFTR Name: Name: Revision 0 Copy ]Date: Initials:
Date: Initials:
Page 45 of 53 appropriate AREVA NP Inc. documentation.
A CoC is issued for the TXS System received from AREVA NP Inc. ICS in order to ensure compliance.
All software in the TXS System Software package shall be uniquely identified as outlined in Section 3.1 of this Plan, and shall be controlled in accordance with Section 3.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 the UFTR project are defined in the UFTR QAP, /1/, and the UFTR "Conduct of Quality Assurance," /2/.All System and Tools software revisions received from AREVA NP are evaluated on a case-by-case basis to determine implementation requirements.
Vendor software is subject to an incoming inspection as per the UFTR QAP, /1/, and is processed in accordance 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 to the UFTR are handled in accordance with the UFTR QAP, /1/, and the UFTR "Software Operations and Maintenance Plan," /6/.The anomalies are examined for their impact on the safety functions.
According to this 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 in the operating instructions might be required, but not a modification of the software.* Change necessary for optimization:
a software update can be implemented during the next scheduled outage.* Change necessary for fulfilling the required safety function:
AREVA NP Inc. and the UFTR personnel will prepare a strategy for immediate action for the release and implementation of a new software update.In any case, software changes are processed under the control of this Plan.
UFINRE UFTR Prepared by Reviewed by QA-1, UFTR-QAI-02 Name: Name: Revision 0 Copy 1 Date : I Initials:
Date: .Initials:
Page 46 of 53 I 4. SCM Schedule Schedules are the responsibility of the Project Coordinator and Project Manager. The SCM activities shall be included in the overall project schedule.
Additional information on for establishing schedules and activities is governed by the UFTR QAPP, /3/.
UF/NRE Prepared by Reviewed by QA-), UFTR-QAI-02 UFTR Name: Name: Revision 0 Copy I Date: Initials:
Date: Initials:
Page 47 of 53 5. SCM Resources SCM resource information identifies the tools (software generating tools), the personnel that~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 in the following sections and shall be trained in their use. The IV&V personnel shall be familiar with their use.Configuration of the Tools is controlled by AREVA NP GmbH. These Tools are certified and purchased as Safety Related. No process for selecting configuration management Tools is specified because the configuration management Tools for the TXS technology have already been selected.The Project Manager shall ensure the current approved version of each Tool is used for the project. The Project Manager's approval is documented through the release 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 extensive verification and validation or testing to qualify their use because the end product is extensively reviewed and the Tools are not used in the on-line operation of the system.5.1.2 Tools for Application Software The Tools for the specification of the function diagrams (i.e., SPACE), the source code generators and the software for compiling, linking, and locating are part 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 software package (e.g., SWAT, rediff, hwparams, swparams, netload, and cpuload) or part of the test environment of the test field equipment.
5.2 Personnel The Software Development Lead shall ensure that software project personnel are trained in accordance with the UFTR "Software Training Plan," /7/. Personnel shall be approved by the Software Development Lead to perform software assignments on the project.5.3 Software Librarian The Software Librarian is designated by Software Development Lead and is a member of the Software Development Group. Refer to the UFTR "Software Library and Control," /10/, for a list of responsibilities associated with the Software Librarian.
UFINRE Project ID: QA-I UFTR QUALITY ASSURANCE DOCUMENT Revision 0 Copy 1 Page 48 of 53 6. SCM Plan Maintenance 6.1 Responsibility All the UFTR Project Group Leads, the Project Manager and the Project Coordinator are responsible for monitoring the SCMP to ensure it meets all the codes and standards required by the project specifications.
Each member of the Software Development group is responsible for ensuring compliance with the SCMP and that CIs are kept current with the project as the design evolves.6.2 Updates Updates to the SCMP will be made as necessary.
Minor or editorial changes identified 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 and approved in accordance with the UFTR QAP, /I/. This Plan shall be reviewed at the end of each project phase.6.4 Change Distribution Following approval of any change to the SCMP, each member of Software Development group and others as identified by the Software Development Lead shall be trained.
UFINRE Prepared by Reviewed by QA-I, UFTR-QAI-02 Name: Name: Revision 0 Copy 1 UFTR Date: Initials:
Date: Initials:
Page 49 of 53 Appendix 1 -Definition of Configuration Items 1. Software Configuration Items List -The Software CIs List identifies the UFTR Software CIs applicable to the project. This document reflects the configuration of the TXS 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 System Network Architecture Diagrams (referred to as YURs) and Cabinet Arrangement Diagrams (referred to as YDRs) configured using SPACE and a list of System Network Architecture parameters necessary for the operation of the configured TXS network.The information provided in this document describes the TXS System Network Architecture pertaining to communications between the TXS Central Processing Unit (CPU) modules, the TXS digital and analog 1/0 modules and the TXS subracks in the TXS cabinets.
The information provided in this document serves as design input for the Detailed Hardware and Application Software design phases of a project.3. Hardware Parameters Listing -This Hardware Parameters Listing document provides the complete set of hardware parameters for the TXS equipment implemented for a TXS project. It is based on the system requirements and function requirements, as well as the results of the Basic and Detailed Design Phases.4. Restricted Information
-The Restricted Information document provides the MAC addresses for various network devices.5. Software Configuration Management Plan -The SCMP is established to provide the method and tools to identify and control the TXS Application Software.6. Software Safety Plan -The Software Safety Plan (SSP) outlines the process for achieving high functional reliability and design quality for the safety-critical Application Software.
Planned and documented software safety analysis activities are used as factors to determine achievement of safety objectives to ensure that safety system software development is consistent with the defined system safety analyses.Software safety analysis activities are conducted during the Basic Design, Detailed Design and Testing Phases of the software development life cycle.7. ID Coding Concept -The ID Coding Concept document provides a standardized method of naming equipment, diagrams, and signals for the purpose of continuity in identification during the project development process. This document defines the rules for 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 Requirement Specification document.8. Software Requirements Specification
-This Software Requirements Specification (SRS) document provides the software requirements for the TXS Application Software running on the TXS processors.
These requirements are extracted from the Equipment Specifications, 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 1 Date: Initials:
Date: Initials:
Page 50 of 53 9. IV&V Activity Phase Summary Reports -The IV&V Activity Phase Summary Reports address software V&V activity identification, background information of standards, and source documents with revisions, synopsis of the review and confirmation that the plan was followed, Open Items found, and recommendations.
- 10. Software Design Description
-The SDD document provides a structured representation of the safety logic created to facilitate the design of the Application Software for a TXS project. The SDD translates the software design requirements specified in the SRS into a description of the software structure, software components, interfaces, and data necessary for the implementation of the design into the Application Software.
The SDD is comprised of various views of the Application Software, including an overview of the system architecture and a top-level presentation of the important system functions.
The SDD includes a description of all the standard SPACE design entities, Instrumentation and Control (I&C) Functions (FUs), I&C Submodule Inputs (SIs), I&C Submodule Outputs (SOs), and I&C Monitoring Processing Submodules (SMs) used in the project-specific system design. The SDD describes the important features in the design, such as how the FUs interact with the corresponding SIs, SOs and SMs. Other views include database tables listing the changeable parameters, information signals (with attributes), and communication interfaces.
The information provided in this document serves as design input for the detailed Application Software Code.11. TXS Application Software (Software Release) -The Application Software Code Release is the UFTR TXS Application Software produced using the SPACE Tool Code Generators.
- 12. Application Software Code (SPACE Function Diagrams)
-The Application Software Code document provides the complete set of software function diagrams for the UFTR TXS project. The function diagrams are produced with the TXS engineering tool SPACE. The application code is automatically generated from the function diagrams documented here by using the qualified SPACE code generators.
The document is based on the SDD, which implements the system requirements and function requirements, as well as the results of the basic design phase -specifically system architecture and ID coding concept.13. Code Configuration
-This Code Configuration document provides the Application Software Code Configuration for the UFTR TXS project and corresponds to a specific TXS Application Software (Software Release), as documented Application Software Code document.
This document also lists the resource usage and spare capacity of the hardware resources of the UFTR TXS project.14. Changeable Software Parameters List -The Changeable Software Parameters List document details the identification of Changeable Parameters in the SDD and the identification of the corresponding parameters and values in the SPACE Function Diagrams of the Application Software Code for the UFTR TXS project. The document describes how to understand the information presented in the List of Changeable Parameters for the TXS Application Software (Software Release), how to create this list, and also documents the list in a spreadsheet.
UFINRE Prepared by Reviewed by QA-I, UFTR-QAI-02 UFTR Name: Name: Revision 0 Copy I Date: Initials:
Date: Initials:
Page 51 of 53 15. Software Generation and Download Procedure
-The purpose of the Software Generation and Download Procedure is to provide instructions for the following TXS Software 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 software integration test plan using SIVAT for the UFTR TXS project. This plan supports the following 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 the software 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 the software design defined in the SDD was properly implemented in the SPACE database and to verify the validity of that design.18. Software Test Procedure
-The Software Test Procedure documents provide the software test procedure for application specific software for the inputs as outlined in the Software Test Plan. The test procedures are constructed of a variety of test scripts that institute the test cases defined in the Application Software Inputs Test Specification.
The test scripts contain the actual test procedure steps. The test scripts allow automated processing of the test procedure.
These test scripts were created by utilizing the SDD and the Application Software Code.19. Software Test Reports -The Software Test Reports document the software functional tests of the UFTR TXS project, as outlined in the Software Test Plan.
UFINRE Prepared by Reviewed by QA-1, UFTR-QAI-02 UF/R Name: Name: Revision 0 Copy 1 Date: Initials:
Date: Initials:
Page 52 of 53 20. Factory Acceptance Test Plan -The FAT Plan is to establish the framework for conducting FAT for the UFTR TXS project. This FAT Plan provides top level specification for the development of the individual Test Specifications
/ Procedures, the Test Log, the Test Incident Report, and the FAT Summary Report. The FAT Plan also provides the guidance for preparing, performing, documenting, resolving, and finalizing tests associated with FAT.21. Factory Acceptance Test Specification
-The FAT Specification documents provide the system and integration test specifications for application specific software for the UFTR TXS project, as outlined in the FAT Plan. The FAT Specifications specifies the test requirements that validate that the UFTR TXS system meets design specifications.
These test specifications validate functionality under a comprehensive set of realistic operating conditions.
Specific acceptance criteria are defined in the individual test specifications.
The test specifications identify the tools required to perform the test.22. Factory Acceptance Test Procedure
-The FAT Procedures provide the system and software integration test procedures for application specific software for the inputs as outlined in the FAT Plan. The test procedures are constructed of a combination of manual steps and test scripts that institute the test cases defined in the FAT Specification.
The test scripts contain the actual test procedure steps. The test scripts allow automated processing of the test procedure.
These test scripts were created by utilizing the SDD and the Application Software Code.23. Factory Acceptance Test Reports -The FAT Reports document the system and software 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 SRS provides the software requirements for the GSM Screens. This document also contains a description of the functionality of the GSM Screens and serves as a guide to the designers, developers, and testing personnel responsible for the engineering of the GSM Screens. The documentation following this SRS will be the GSM Screen Code document.26. Graphic Service Monitor Screen Code -The GSM Screen Code document captures the GSM screens and related scripts which satisfy the requirements identified in the System Functional Description and the GSM SRS. This document also describes the basic installation and start-up steps for GSM software.27. Gateway Historical Application Software Requirements Specification
-The Gateway Historical Application (GHA) SRS document provides the SRS of the Historical Application of the Communication Bridge (TXS Gateway) between the TXS System and the plant computer.
UFINRE Prepared by Reviewed by QA-I, UFTR-QAI-02 UFTR Name: Name: Revision 0 f Copy I Date: Initials:
Date: Initials:
Page 53 of 53 28. Gateway Historical Application Software Design Description
-The GHA-SDD document provides the SDD of the Historical Application of the Communication Bridge (TXS Gateway) between the TXS System and plant computer.29. Gateway Historical Application Code -The GHA Code document provides the code listing 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 Historical Application (Software Release) is the System Software utilized by the project for recording Historical information on the TXS Gateway.