KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0
Software Program Manual
for the APR1400
Revision 0
Non-Proprietary
September 2013
Copyright ⓒ 2013
Korea Electric Power Corporation & Korea Hydro & Nuclear Power Co., Ltd All Rights Reserved
KEPCO & KHNP
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0
REVISION HISTORY
Revision Date Page Description
September 0 All Original Issue 2013
This document was prepared for the design certification application to the U.S. Nuclear Regulatory Commission and contains technological information that constitutes intellectual property. Copying, using, or distributing the information in this document in whole or in part is permitted only by the U.S. Nuclear Regulatory Commission and its contractors for the purpose of reviewing design certification application materials. Other uses are strictly prohibited without the written permission of Korea Electric Power Corporation and Korea Hydro & Nuclear Power Co., Ltd.
KEPCO & KHNP i
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0
ABSTRACT
This Technical Report (TeR) provides the software design process of the digital computer-based instrumentation and control (I&C) system which is intended to be used for NRC design certification (DC) application of the APR1400.
This report describes the processes which ensure the reliability and design quality of the software throughout its entire life cycle.
By implementing the processes in this report, the digital I&C system software achieves the following:
Desired level of quality and reliability required for nuclear power plants (NPPs) Safety related I&C functions for protecting and securing the safe operation of the NPPs Satisfactory conformance to nuclear codes and standards
KEPCO & KHNP ii
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0
TABLE OF CONTENTS
1.0 INTRODUCTION 1-1 1.1 Purpose 1-1 1.2 Scope 1-1
2.0 SOFTWARE LIFE CYCLE PROCESS CONTROL 2-1 2.1 Purpose 2-1 2.2 Organization and Responsibilities 2-1 2.2.1 Organization 2-2 2.2.2 Responsibilities 2-2 2.3 General Requirements 2-3 2.3.1 Overview of Life Cycle 2-3 2.3.2 Software Classification and Categorization 2-3 2.3.3 Documentation 2-6
3.0 SOFTWARE LIFE CYCLE PLANS 3-1 3.1 Software Management Plan 3-2 3.1.1 Purpose 3-2 3.1.2 Organization/Responsibilities 3-2 3.1.3 Oversight 3-2 3.1.4 Security 3-3 3.1.5 Measurement 3-3 3.1.6 Procedures 3-4 3.1.7 Budget 3-5 3.1.8 Methods/Tools 3-6 3.1.9 Personnel 3-6 3.1.10 Standards 3-6 3.2 Software Quality Assurance Plan 3-7 3.2.1 Purpose 3-7 3.2.2 Organization/Responsibilities 3-7 3.2.3 Security 3-7 3.2.4 Measurement 3-7 3.2.5 Procedures 3-7 3.2.6 Record Keeping 3-22 3.2.7 Methods/Tools 3-23
KEPCO & KHNP iii
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0
3.2.8 Standards 3-23 3.3 Software Verification and Validation Plan 3-28 3.3.1 Purpose 3-28 3.3.2 Organization/Responsibilities 3-28 3.3.3 Oversight 3-28 3.3.4 Risks 3-29 3.3.5 Measurement 3-29 3.3.6 Procedures 3-29 3.3.7 Methods/Tools 3-39 3.3.8 Standards 3-40 3.4 Software Configuration Management Plan 3-41 3.4.1 Purpose 3-41 3.4.2 Organization/Responsibilities 3-41 3.4.3 Security 3-42 3.4.4 Measurement 3-42 3.4.5 Procedures 3-42 3.4.6 Record Keeping 3-45 3.4.7 Methods/Tools 3-45 3.4.8 Standards 3-46 3.5 Software Development Plan 3-47 3.5.1 Purpose 3-47 3.5.2 Organization 3-47 3.5.3 Oversight 3-47 3.5.4 Risks 3-47 3.5.5 Measurement 3-48 3.5.6 Procedures 3-48 3.5.7 Schedule 3-49 3.5.8 Methods/Tools 3-49 3.5.9 Standards 3-50 3.6 Software Integration Plan 3-51 3.6.1 Purpose 3-51 3.6.2 Organization/Responsibilities 3-51 3.6.3 Measurement 3-51 3.6.4 Procedures 3-52 3.6.5 Methods/Tools 3-53 3.6.6 Standards 3-53
KEPCO & KHNP iv
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0
3.7 Software Installation Plan 3-54 3.7.1 Purpose 3-54 3.7.2 Organization/Responsibilities 3-54 3.7.3 Measurement 3-54 3.7.4 Procedures 3-54 3.7.5 Methods/Tools 3-55 3.7.6 Standards 3-55 3.8 Software Training Plan 3-56 3.8.1 Purpose 3-56 3.8.2 Organization/Responsibilities 3-56 3.8.3 Measurement 3-56 3.8.4 Procedures 3-56 3.8.5 Methods/Tools 3-57 3.8.6 Standards 3-57 3.9 Software Operation and Maintenance Plan 3-58 3.9.1 Purpose 3-58 3.9.2 Organization/Responsibility 3-58 3.9.3 Risks 3-58 3.9.4 Security 3-58 3.9.5 Measurement 3-58 3.9.6 Procedures 3-59 3.9.7 Methods/Tools 3-60 3.9.8 Standards 3-60 3.10 Software Safety Plan 3-61 3.10.1 Purpose 3-61 3.10.2 Organization/Responsibilities 3-61 3.10.3 Risks 3-61 3.10.4 Measurement 3-61 3.10.5 Procedures 3-61 3.10.6 Methods/Tools 3-66 3.10.7 Standards 3-66 3.11 Software Test Plan 3-67 3.11.1 Purpose 3-67 3.11.2 Organization/Responsibilities 3-67 3.11.3 Security 3-67 3.11.4 Measurement 3-67
KEPCO & KHNP v
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0
3.11.5 Procedures 3-68 3.11.6 Record Keeping 3-71 3.11.7 Methods/Tools 3-71 3.11.8 Standards 3-71 3.12 Secure Development and Operational Environment 3-72 3.12.1 System Design Features for Security 3-72 3.12.2 Development Processes for Security 3-74 3.12.3 Security Processes for COTS Software 3-80
4.0 APPLICABLE CODES AND REGULATIONS 4-1 4.1 Regulatory Guidance and Codes 4-1 4.2 Standards endorsed by Regulatory Guides 4-1 4.3 Other Documentation 4-2
KEPCO & KHNP vi
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0
LIST OF TABLES
Table 2-1 Correspondence to BTP 7-14 2-1 Table 3-1 Hardware and Software Classification 3-24 Table 3-2 Tasks Required for Software Categories 3-26 Table 3-3 Software Tasks and Responsibilities for Software Classifications 3-27
KEPCO & KHNP vii
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0
LIST OF FIGURES
Figure 2-1 Organizational Structure to Control the Software Life Cycle Process 2-2 Figure 3-1 Overview of Software Life Cycle Plan and Engineering Process 3-1 Figure 3-2 Verification and Validation Plan Overview 3-31
KEPCO & KHNP viii
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0
Acronyms and Abbreviations
ALMS Acoustic Leak Monitoring System AMI Accident Monitoring Instrumentation APC Auxiliary Process Cabinet BTP Branch Technical Position CBP Computer-Based Procedure CCB Configuration Control Board CCF Common-Cause Failure CD-ROM Compact Disc Read-Only Memory CEA Control Element Assembly CEAC Control Element Assembly Calculator CI Configuration Item CM Configuration Management COTS Commercial Off-The-Shelf CPC Core Protection Calculator CPCS Core Protection Calculator System CPEN Computer Program Error Notification CPP CEA Position Processor CR Comment Record CRC Cyclic Redundancy Check DAS Diverse Actuation System DCN-I Data Communication Network - Information DCS Distributed Control System DIS Diverse Indication System DPS Diverse Protection System DRCS Digital Rod Control System DT Design Team DTM Design Team Manager EDM Engineering Department Manager ENM Existing Not to be Modified ESCM ESF-CCS Soft Control Module ESFAS Engineered Safety Features Actuation System ESF-CCS Engineered Safety Features – Component Control System ETBM Existing To Be Modified FAT Factory Acceptance Test(ing)
KEPCO & KHNP ix
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0
FCA Functional Configuration Audit FIDAS Fixed In-core Detector Amplifier System FMEA Failure Modes and Effects Analysis FPGA Field Programmable Gate Array FWCS Feedwater Control System GC Group Controller GP General Purpose I&C Instrumentation and Control I/O Input/Output IPS Information Processing System IRD Interface Requirements Document ITA Important to Availability ITP Interface and Test Processor ITS Important to Safety IV&V Independent Verification and Validation IVMS Internals Vibration Monitoring System KHNP Korea Hydro & Nuclear Power Co., Ltd. LAN Local Area Network LC Loop Controller LCL Local Coincidence Logic LDP Large Display Panel LPMS Loose Parts Monitoring System MTP Maintenance and Test Panel N/A Not Applicable NAPS Nuclear Application Programs NIMS NSSS Integrity Monitoring System NPCS NSSS Process Control System NSSS Nuclear Steam Supply System NPP Nuclear Power Plant OM Operator Module P-CCS Process – Component Control System PCA Physical Configuration Audit PCS Power Control System PM Project Manager PPS Plant Protection System QA Quality Assurance
KEPCO & KHNP x
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0
QAM Quality Assurance Manual QATM Quality Assurance Team Manager QIAS-N Qualified Indication and Alarm System – Non-safety QIAS-P Qualified Indication and Alarm System – P RCP Reactor Coolant Pump RCPVMS RCP Vibration Monitoring System RG Regulatory Guide RPCS Reactor Power Cutback System RPS Reactor Protection System RRS Reactor Regulating System RSR Remote Shutdown Room RTM Requirements Traceability Matrix SAT Site Acceptance Test(ing) SBCS Steam Bypass Control System SC Safety Critical SCI Software Configuration Identification SCM Software Configuration Management SCMP Software Configuration Management Plan SCR Software Change Request SDD Software Design Description SDL Serial Data Link SDN Safety System Data Network SDOE Secure Development and Operational Environment SDP Software Design Plan SIL Software Integrity Level SInstP Software Installation Plan SIntP Software Integration Plan SMP Software Management Plan SOE Sequence of Event SOMP Software Operation and Maintenance Plan SPADES+ Safety Parameter Display and Evaluation System+ SQA Software Quality Assurance SQAP Software Quality Assurance Plan SRS Software Requirements Specification STrngP Software Training Plan SysRS System Requirements Specification
KEPCO & KHNP xi
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0
SSP Software Safety Plan STP Software Test Plan SVVP Software Verification and Validation Plan SVVR Software Verification and Validation Report TER Test Exception Report TeR Technical Report TS Trade Secret V&V Verification and Validation VT Verification and & Validation Team VTM Verification and & Validation Team Manager
KEPCO & KHNP xii
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 1.0 INTRODUCTION
1.1 Purpose
The purpose of this Technical Report (TeR) is to specify systematic approach to be used for the software engineering process of computer based instrumentation and control (I&C) systems. This report provides the software program plans based on the guidance of Branch Technical Position (BTP) 7-14, “Guidance on Software Reviews for Digital Computer-Based Safety Systems” (Reference 4.1.1).
1.2 Scope
This report is applied to the design, production, and maintenance of software for the l&C systems. The software life cycle is implemented, operated, and maintained based on this report. During the operation of the I&C systems, the responsibility for the software life cycle becomes the responsibility of the nuclear power plant (NPP) maintenance and/or engineering organization. In this case, the NPP organization maintains the software in accordance with the plans of this report and it’s quality assurance manual (QAM).
This report is intended to be applied to the software engineering process for software based I&C systems including the field programmable gate array (FPGA)-based I&C systems. This report defines software engineering processes to be followed in creating and revising the software based I&C systems. The software engineering process and outputs are described in each section separately.
This report contains the following basic elements based on NUREG-0800:
Software management plan (SMP)
The SMP is the basic governing document for the entire development effort. Project oversight, control, reporting, review, and assessment are all carried out within the scope of the SMP.
Software quality assurance plan (SQAP)
The SQAP describes the process and practice of developing and using software. The SQAP addresses software classification, software categories, software development process, security, software management, documentation, standards, practices and conventions, review requirements, problem reporting, and other software quality issues.
Software verification and validation plan (SVVP)
The SVVP describes requirements for the verification and validation (V&V) process to be applied to systems. The SVVP addresses overview of V&V, V&V principles, V&V process, V&V testing strategy and V&V activities.
Software configuration management plan (SCMP)
The SCMP describes the methodology used in managing the configuration control of software for the systems.
KEPCO & KHNP 1-1
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 Software development plan (SDP)
The SDP provides necessary information on the technical aspects of systems that are required by the design team (DT) in order to carry out the project.
Software integration plan (SIntP)
The SIntP describes integration of software elements, the hardware/software integration process, and testing the result of the integrated product.
Software installation plan (SInstP)
The SInstP describes the process for installing the software product to the target hardware.
Software training plan (STrngP)
The STrngP describes the process for training the operators of the software system.
Software operation and maintenance plan (SOMP)
The SOMP specifies the requirements for the operation and maintenance of computer software utilized for the systems after delivery to the user or customer.
Software safety plan (SSP)
The SSP describes the process and measures to maintain and improve the safety of the software system.
Software test plan (STP)
The STP describes the process and measures to test intermediate, integrated, and/or final software products.
KEPCO & KHNP 1-2
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 2.0 SOFTWARE LIFE CYCLE PROCESS CONTROL
2.1 Purpose
This report is applied to the digital computer based I&C system software. This report excludes hardware part of the digital I&C system.
This report describes the overall management of the software life cycle including design, manufacturing, integration, tests, installation, operation, maintenance, training, safety analyses, V&V, and configuration management (CM).
Table 2-1 shows the software life cycle plans described in this report and their correlation to the plans described in BTP 7-14. Also, Section 3.12 describes the secure development and operational environment (SDOE) required by Regulatory Guide (RG) 1.152 (Reference 4.1.3).
Table 2-1 Correspondence to BTP 7-14
Plan proposed by BTP 7-14 Section of this report discussing the plan
Software management plan (SMP) 3.1
Software quality assurance plan (SQAP) 3.2
Software verification and validation plan (SVVP) 3.3
Software configuration management plan (SCMP) 3.4
Software development plan (SDP) 3.5
Software integration plan (SIntP) 3.6
Software installation plan (SInstP) 3.7
Software training plan (STrngP) 3.8
Software operations plan (SOP) 3.9
Software maintenance plan (SMaintP) 3.9
Software safety plan (SSP) 3.10
Software test plan (STP) 3.11
2.2 Organization and Responsibilities
The organization and responsibilities that pertain to controlling the software life cycle process for the I&C systems are as described in the QAM (Reference 4.3.1).
KEPCO & KHNP 2-1
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 2.2.1 Organization
The organizational structure to control the software life cycle process is shown in Figure 2-1. TS
Figure 2-1 Organizational Structure to Control the Software Life Cycle Process
Figure 2-1 is intended to show that the DT, the software V&V team (VT), and the quality assurance (QA) team are independent of one another.
2.2.2 Responsibilities
The roles and responsibilities of the managers of the organization are as described in this section.
Project manager (PM)
The PM represents the company in relation to the project. The PM takes overall responsibility for the project quality and the interface control. The PM approves design documents for external submission.
I&C system engineering department manager (EDM)
The I&C system EDM approves documents for external submission. The I&C system EDM has ultimate responsibility for the software design.
KEPCO & KHNP 2-2
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 Safety analysis department manager
The safety analysis department manager approves documents for external submission. The safety analysis department manager has ultimate responsibility for the software V&V.
Design team manager (DTM)
The DTM supervises the DT and approves software design documents. The DT establishes software requirements, designs the software, and performs the software coding. The DTM assures that the DT correctly designs the software based on technical requirements in accordance with the development process of the SQAP and QAM.
V&V team manager (VTM)
The VTM supervises the VT and approves software V&V documents. The VT performs software design verification and software validation to confirm that the requirements from the design specification are incorporated into the input and output documents for each phase of the software development process. The VT has technical competence equivalent to the DT and does not involve in software design activities. The VT reports to a department manager who is different from the department manager reported by the DT.
QA team manager (QATM)
The QA team conducts independent audits on the DT and VT activities to confirm that requirements and implementation of the software life cycle process are appropriately planned and executed in accordance with the QAM. The QATM is responsible for all activities of the QA team.
2.3 General Requirements
2.3.1 Overview of Life cycle
This report is based on a software life cycle model consistent with RG 1.173 (Reference 4.1.10) and IEEE Std. 1074 (Reference 4.2.8) which includes the following phases:
Concept phase (planning phase) Requirements phase Design phase Implementation phase Test phase Installation and checkout phase Operation and maintenance phase
2.3.2 Software Classification and Categorization
All software that are developed and/or used within the I&C system is classified according to the functionality and importance related to safety as the following:
KEPCO & KHNP 2-3
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 Safety critical (SC; Protection): Software whose function is necessary to directly perform reactor protection system (RPS) initiation actions, engineered safety features actuation system (ESFAS) control actions, and safe shutdown control actions. Important to safety (ITS): Software whose function is necessary to perform diverse actuation system (DAS) control actions, software that is relied on to monitor or test SC functions, or software that monitors plant critical safety functions. Important to availability (ITA): Software that is relied on to maintain operation of plant systems and equipment that are critical to operate the plant. General purpose (GP): Software that is not assigned to SC, ITS, or ITA class.
The SC class software is classified as software integrity level (SIL) 4 in accordance with IEEE Std. 1012 (Reference 4.2.6). The ITS class software is classified as SIL 3 in accordance with IEEE Std. 1012. The distinction between these two classes of software are mainly associated with the V&V programs (level of independence, component testing, and hazard analysis) for each one. The software classification for I&C systems is provided in the Table 3-1.
The DAS software for diverse protection system (DPS) and diverse indication system (DIS), as augmented quality, is classified as ITS class as their functions are diverse from safety functions in case of the common-cause failure (CCF) of safety I&C systems.
The mapping of the software classifications to IEEE Std. 1012 SILs are as follows:
SC : High (SIL 4) ITS : Major (SIL 3) ITA : Moderate (SIL 2) GP : Low (SIL 1)
Throughout this report, distinctions are made regarding the methods applied to each class. Table 3-3 provides the development and V&V distinctions between the different software classifications. Specific parts of the software in a single computer system may be assigned to different classes. However, each part of the software has an assigned class that is equal to the highest class. The software of a safety I&C system that is within a computer is of all the same classification (i.e., SC class software and ITS software is not mixed within a processor).
In addition to the software classification, this report makes distinctions regarding methods applied to each of the following categories of software:
Original (developed for specific project) Existing to be modified Existing not to be modified
Every software item is assigned to one of the above categories. In practice, software items in several categories are included in each system. The tasks required for these three categories of software are shown in Table 3-2.
KEPCO & KHNP 2-4
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 2.3.2.1 Classification of the software for the safety I&C systems
The software for the safety I&C systems is classified as one of the two software classes: SC class and ITS class. Both classes of the software for the safety I&C systems are implemented on Class 1E hardware.
IEEE Std. 603 (Reference 4.2.1), Clause 5.3 requires that components and modules be of a quality that is consistent with minimum maintenance requirements and low failure rates. IEEE Std. 603 is supplemented by IEEE Std. 7-4.3.2 (Reference 4.2.9), as endorsed by RG 1.152 for computer-based safety I&C systems. IEEE Std. 7-4.3.2, Clause 5.3.3, “Verification and validation” states that software V&V effort shall be performed in accordance with IEEE Std. 1012 and the IEEE Std. 1012 V&V requirements for the highest integrity level (level 4) apply to systems developed using IEEE Std. 7-4.3.2. Performing adequate V&V is a critical part of ensuring a high quality development process for safety I&C systems. TS
KEPCO & KHNP 2-5
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 TS
2.3.3 Documentation
Each software life cycle plan requires output documentation. The documentation provides evidences for the integrity of the development process so that the reliability of the safety software may be ensured. The software products for all phases of the life cycle are documented correctly so that the designer and V&V engineer completely understand all the stages of development and verify the completeness and correctness of each stage.
The typical documents produced during the software life cycle are as follows:
KEPCO & KHNP 2-6
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 Software design documentation - System requirements specification (SysRS) - Software requirements specification (SRS) - Software design description (SDD) - Source code documentation Software V&V documentation - Software V&V phase report - Final software V&V report (SVVR) Software configuration management (SCM) documentation User documentation Computer code certificate
Traceability of requirements is provided when documents are produced or updated at the end of each phase. The documents produced during the design process are updated through the whole process of repetitive development including trial operation and ongoing operations and maintenance. The designer is aware of all documentation requirements at the initial stage of the project.
Precise documentation is essential for maintenance. Well prepared documentation helps in preventing errors when anything is changed in a way that adversely affects maintenance in the future. Documents are easy to understand and amend. Documents provide correctness, traceability, completeness, consistency, verifiability, and correctness.
KEPCO & KHNP 2-7
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 3.0 SOFTWARE LIFE CYCLE PLANS
Figure 3-1 shows the relationship between each phase of the software life cycle and the software life cycle plans for the SC class software. The numbers in Figure 3-1 represent the section numbers in this report. For the other software classes, some of the plans in Figure 3-1 are not prepared. Refer to Table 3-3 for the software life cycle plans for each software class.
3. 1 SMP Concept Software Planning Phase Documents 3. 2 SQAP System Requirements Specification Requirement Phase 3. 5 Software SDP Requirements Requirements Verification 3. 3 Specification SVVP 3. 11 STP Software Design Design Phase Design Verification Description Hardware Engineering Code Code Implementation Verification 3. 4 SCMP Implementation Phase Procedures Module/ Unit Testing 3. 6 Reports SIntP
Procedures Integration Testing 3. 10 Reports SSP Test Phase
System Testing Procedures ( FAT) Reports
3.7 Installation & SInstP Checkout Installation Phase 3. 12 3. 8 SDOE 3. 9 STrngP Operation & Operation & SOMP Maintenance Phase Maintenance
3 . 1 Software Management Plan ( SMP ) 3 . 7 Software Installation Plan ( SInstP) 3 . 2 Software Quality Assurance Plan (SQAP ) 3 . 8 Software Training Plan (STrngP ) 3 . 3 Software Verification and Validation Plan( SVVP ) 3 . 9 Software Operation and Maintenance Plan( SOMP ) 3 . 4 Software Configuration Management Plan( SCMP ) 3 . 10 Software Safety Plan ( SSP) 3 . 5 Software Development Plan ( SDP) 3 . 11 Software Test Plan ( STP) 3 . 6 Software Integration Plan (SIntP ) 3 . 12 Secure Development and Operational Environment( SDOE )
Figure 3-1 Overview of Software Life Cycle Plans and Engineering Process
KEPCO & KHNP 3-1
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 3.1 Software Management Plan
3.1.1 Purpose
The SMP is the basic governing plan for the entire development efforts. The SMP establishes the managerial process for the project management, control, reporting, review, and assessment for systems.
3.1.2 Organization/Responsibilities
The SMP addresses organizational issues; the process model, organizational structure, boundaries and interfaces, and project responsibilities. Software development and V&V organization is described in Section 2.0.
3.1.2.1 Process Model
Process model defines the relationships among major project functions and activities. The following specifications are provided:
Timing of major milestones. Software project baselines. Timing of project reviews and audits. Work products of the software project Project deliverables
3.1.2.2 Organization Structure
The SMP describes the following internal management structure of the project:
Lines of authority Responsibility for the various aspects of the project Lines of communication within the software project Means by which the SMP is updated if the project organization changes
3.1.2.3 Organization Boundaries
The SMP describes the administrative and managerial boundaries, and interfaces across those boundaries, between the project and the external entities.
3.1.3 Oversight
The I&C system EDM is in charge of project administration and controls on implementation of activities specified in Sections 3.1 to 3.12. The time table defines software project milestones, and all the software development and maintenance related activities are controlled according to the milestones of the time table. On either pre-scheduled or interim basis, project control meetings are held for the purpose of checking and confirming the project status, and to identify/avoid loopholes or problems to be resolved.
KEPCO & KHNP 3-2
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 Team members of development and V&V task under the supervision of the team manager report the status of the project and present any problems to be resolved or addressed.
When in need of changing milestones or problems are presented, remedial actions together with implementation schedule are established, and responsibility for corrective actions is delegated to proper personnel. Whether corrective actions adequately provide the resolution for the raised issue is reported to the PM.
SMP is under configuration management (CM) control. The review and approval process for changing SMP includes responsible members of the DT, project organization.
3.1.4 Security
The following describes the security management which is performed throughout each phase of the software life cycle:
Source code and the development environment are installed in an area where only authorized personnel can enter. (i.e. an area that requires a security card or number key for entry and exit) The computer used for development is made inaccessible to unauthorized personnel using password and physical separation. The software development tool is checked regularly to ensure it is free from computer viruses and other malicious codes. There is no connection between the software development tools and the business local area network (LAN) or the Internet. The software development tool is checked regularly to ensure they are free from “Trojan horses” computer viruses, worms and any other malicious codes.
In addition to the general security requirements described above, additional security measures for specific software life cycle process are described in the other life cycle plans described within this report.
Above security requirements of the SMP are conducted in accordance with RG 1.152.
The details for SDOE are described in Section 3.12.
3.1.5 Measurement
The progress of documents preparation against its time table and the resource usage against its time table is monitored regularly and reported to management. The management or personnel delegated by the management collects data for effectiveness of scheduling, technical problems and its resolutions, and analyzes the effectiveness of project management.
Risk management is included as part of the internal project review process. The categories of risk that are reviewed include organization and interfaces, resources, technical work scope, schedule, and commercial/financial. Identified risks are assessed and mitigating actions are defined on a monthly basis.
Risk that may occur in project execution is assessed during all phases of the software life cycle, and actions identified to mitigate identified risks. The mitigating actions are presented to
KEPCO & KHNP 3-3
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 project management. The categories of risk that are reviewed include, at a minimum: organization and interfaces, resources, technical, work scope, schedule, and commercial/financial.
3.1.6 Procedures
3.1.6.1 Management Procedures
The SMP describes the general management procedures that are followed during the project development life cycle. Topics that can affect safety are listed here; additional information is included in order to completely describe the management procedures.
The following aspects of the SMP fall into the category of management procedures.
3.1.6.1.1 Priorities
The SMP describes the priorities for management activities during the software development for the systems. Topics include:
Relative priorities among system requirements Functional requirements schedule and budget Frequency and mechanisms for reporting
3.1.6.1.2 Assumptions, Dependencies and Constraints
The SMP states the followings:
The assumptions upon which the project is based. The external events upon which the project is dependent. The constraints under which the project is conducted.
3.1.6.1.3 Risk Management
The SMP identifies and assesses the risk factors associated with the systems. All of the items that have an impact on safety are listed in the SMP. And this impact is described with a method for managing that risk.
Financial risks Schedule risks Contractual risks Technology change risks Size and complexity risks Scale-up risks
3.1.6.1.4 Monitoring and Controlling Methods
The SMP describes reporting requirements, report formats, information flows, and review and audit mechanisms.
KEPCO & KHNP 3-4
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 Internal reporting: within the DT External reporting: to auditors and regulators
3.1.6.2 Technical Procedures
The SMP describes management aspects of the technical procedures that are followed during software development life cycle. Topics that can affect safety are listed in the SMP. Additional information is included in order to completely describe the technical procedures. In some cases, these procedures are documented in other documents, and this portion of the SMP is merely reference those documents. In particular, the technical aspects of the development effort are described in the SDP. (See Section 3.5.)
3.1.6.2.1 Methods, Tools, and Techniques
The SMP specifies all of the methods, tools, and techniques for development of the software. For the methods, tools, and techniques, refer to Section 3.2.
3.1.6.2.2 Software Documentation
The documents are listed throughout this report.
3.1.7 Budget
The SMP identifies the work packages and the dependency relationships among them. The SMP states the resource requirements and provides the allocation of budget and resources to work packages. The SMP also establishes a software development schedule.
3.1.7.1 Work Packages
The SMP specifies the work packages for the activities and tasks that are completed in order to satisfy the project agreement.
3.1.7.2 Dependencies
The SMP specifies the ordering relations among work packages to account for interdependencies among them and dependencies on external events.
3.1.7.3 Resource Requirements
The SMP provides, as a function of time, estimates of the total resources required to complete the software development process.
3.1.7.4 Budget and Resources Allocation
The SMP specifies the allocation of budget and resources to the various project functions, activities, and tasks.
3.1.7.5 Schedule
The SMP provides the schedule for the software development process including system functions, activities, and tasks which take into account the precedence relations and the required
KEPCO & KHNP 3-5
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 milestone dates. Schedules may be expressed in absolute calendar time or in increments relative to a key software development process milestone.
3.1.8 Methods/Tools
The project status is presented at regular project management meetings for schedule and risk management.
Appropriate commercial tool can be used for schedule and resource allocation to track schedule and risk management of the project. The progress report for project status including design document delivery schedule is produced regularly.
3.1.9 Personnel
The SMP specifies the numbers and types of personnel required in order to achieve development of a reliable software system that meets safety requirements.
Skill levels required Start times and duration of needs Training requirements
3.1.10 Standards
The SMP complies with the following standards and guidelines:
IEEE Std. 1074-1995 (Reference 4.2.8), Clause 3, as endorsed by RG 1.173 (Reference 4.1.10) IEEE Std. 1058-1998 (Reference 4.2.11) NUREG/CR-6101 (Reference 4.1.11), Section 3.1.1
KEPCO & KHNP 3-6
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 3.2 Software Quality Assurance Plan
3.2.1 Purpose
The SQAP describes the QA requirements, security, and methodology to be followed by each team (DT, VT) that develops, acquires, uses, and maintains software and performs V&V on the software to be used for the design and operation of software-based systems.
This SQAP ensures that procedures and controls are in place to govern and monitor the software life cycle thus providing an auditable record of the production process and of the operational life of the system.
3.2.2 Organization/Responsibilities
The implementation of an effective SQAP is the responsibility of all persons involved during the software development process. Each person responsible for the software development performs his work in accordance with established standards, methods, and procedures identified in this SQAP. Each team is responsible for the execution of all QA tasks including SCM on the hardware, software, or documentation that they generate or procure.
Management of the SQAP is overseen by the DTM and VTM. The VT helps securing quality to products generated by the DT throughout independent V&V.
Tasks are listed in the life cycle phase for which they are performed. Tasks include software design and development, software QA (SQA) planning, verification reviews, audits, test planning, test execution, and test reporting. Tasks required are based on software categorization. Table 3-1 shows the software tasks for each category in each phase. Table 3-3 shows the division of responsibilities for document preparation and verification review activities between the DT and the VT. If required, the procedure for the activities shown in the table 3-3 is written as an internal document.
3.2.3 Security
Section 3.12 describes the activities for each life cycle phase in compliance with SDOE requirements in RG 1.152.
3.2.4 Measurement
The QA data for monitoring and controlling is systematically collected and analyzed to determine software quality.
3.2.5 Procedures
The DT and VT ensure that software and associated documentation are developed in accordance with the standards specified in the SQAP. This includes ensuring that the coding standards, testing standards established in the STP, and documentation standards (Section 3.2.5.2) are followed.
In general, SCM responsibilities for the DT span all phases of the software life cycle for:
Development of SCMPs
KEPCO & KHNP 3-7
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 Execution of SCM activities per the SCMP Control of software through a librarian Baselining and integration of new software versions
The following is some procedural actions that are performed to ensure traceability throughout the development and verification stages:
The project system description and design specification documents are dated and signed by the designer and the DTM. Each original or revision of a software module written by a programmer is dated and signed by the programmer of the software module. The corresponding project software verification report and software test procedures documents are dated and signed by the author and VTM. Each software module is verified and documented. Throughout the software life cycle, a software requirements traceability analysis is performed and the corresponding requirements traceability matrix (RTM) is maintained. (See Section 3.3.7.2.)
3.2.5.1 Tasks in the Software Life Cycle
Within each software class, there are categories of software which the SQAP addresses. These categories are described as follows:
Original software Existing software - To be modified - Not to be modified
All software modules developed or used within a system are documented by class. (See Table 3-1.) This is performed by the DT and may be included in the SRS.
Software that is initially assigned to one software class can be reassigned to any other class provided that all tasks appropriate for the new class, up to the current phase of the software life cycle, are completed and satisfactorily reviewed.
Existing software is software that has been created, but not under this report. To qualify for use under this report, the software is evaluated by the DT to meet the following criteria:
Existing commercial software may be used for SC class software if it is qualified in accordance with EPRI TR-106439 (Reference 4.2.13). To qualify existing commercial software for the other classes of software, the DT selects applicable portions of EPRI TR-106439 and qualifies the software to those portions. Existing NPP non-commercial software that has been actively used in a NPP may be used for the same class of software under this report, provided that it has been maintained under an acceptable quality plan with an active program for problem reporting and corrective action reporting to the project during the software life cycle. This software also has adequate design documentation, user documentation and
KEPCO & KHNP 3-8
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 well commented source code. This software has been verified and validated under another program that is judged by the VT to be acceptable. Other existing non‐commercial software may be used if a review by the DT and VT concludes that it is well organized and has adequate design documentation, user documentation, and source code commentary.
For existing software that is qualified as above, design documentation and code may be used without revision to meet format or content requirements of this report. Modifications to this software may be made in accordance with prior documentation and code format. Qualified existing commercial software and NPP non-commercial software does not require verification of design documents and code. Other qualified existing non‐commercial software requires verification of design documentation and source code in accordance with this report.
Under the SQAP, a software product that is contracted for development by a subcontractor is treated as original software unless the software already exists and is in use.
Specific SQA activities are defined below in accordance with the software life cycle.
3.2.5.1.1 Concept (Acquisition, Planning, and Concept) Phase
During this phase, SMP, SQAP, SVVP, SCMP, SDP, SIntP, SInstP and coding standards based on this report are developed by the responsible entity.
3.2.5.1.2 Requirements Phase
During this phase, two kinds of requirements specifications are developed. The first is the SysRS, and the second is the SRS.
The STP is prepared based on the SVVP and identify how the test activities are implemented.
System requirements specification
The SysRS provides overall system configuration, design considerations and operational requirements. Also, the SysRS provides the necessary details to develop software and hardware requirements.
Software requirements specification
The SRS involves analyzing and documenting the requirements for the software. The input to this task is the SysRS and the output is the SRS. The SRS contains the requirements of the SysRS which are pertinent to the software.
The DT is responsible for developing, maintaining, and updating its SRS. An SRS is developed for each system based on functional requirements specification, and provides the detailed information sufficient to design the software. The SRS is used as the source document for the design of the software including: the description of major software components and technical description of the software. For software which have functions spanning more than one software class (see Table 3-1), the SRS is divided to describe software requirements for the software in each class. The SRS inclusions are listed in Section 3.2.5.2.1.2.
KEPCO & KHNP 3-9
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 Each SRS is verified by the teams indicated in table 3-3. The verification review ensures that the functional requirements identified in the SysRS are properly reflected in the SRS. Verification of SRS is performed in accordance with Section 3.3.6.1.2.
3.2.5.1.3 Design Phase
The design phase generates a detailed software design which satisfies the requirements specified in the SRS. The SDD gives a precise description of all the software. The inputs to the design phase are the SRS and the computer hardware related requirements, and the output is the SDD.
The DT is responsible for developing, maintaining and updating the SDD for each software unit. Each SDD is traceable to the requirements set forth in the SRS, and includes details sufficient to begin coding in the implementation phase. The verification review ensures that the software requirements identified in the SRS are properly reflected in the SDD.
Each SDD is verified by the teams indicated in table 3-3. The verification review ensures that the software requirements identified in the SRS are properly reflected in the SDD.
3.2.5.1.4 Implementation Phase
The original software development and modifications to existing software begin with module coding by the DT in accordance with the appropriate coding standard(s). The input to this phase is the SDD. The output is the executable code. The existing software which has been qualified as described in Section 3.2.5.8 may be integrated and tested during this phase.
Verification of code listings is performed by the teams identified in table 3-3.
Testing can be accomplished by the process that hierarchically assemble the software units and perform an integration test, and subsequently assemble all the software units.
Module/unit testing falls under implementation phase. Module/unit testing is performed in accordance with the STP. The responsibility for testing is assigned to the VT or DT depending on software classification. See the Table 3-3.
After successful module/unit testing, the software test results reports document that the software has been tested in accordance with the STP, all code reviews have been completed, and all errors have been resolved or documented.
3.2.5.1.5 Test Phase
In test phase, the components of a software product are evaluated and integrated into the hardware, and the software product is evaluated to determine whether or not the requirements have been satisfied.
The test phase for systems covers software integration testing, and system testing (factory acceptance testing; FAT). The test engineer ensures through software testing that the software and system requirements are satisfied by execution system. Test procedures and reports are documented and verified by the responsible teams. (See the Table 3-3.) Also, test procedures and reports are developed consistent with the STP.
KEPCO & KHNP 3-10
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 After successful integration and system testing (FAT), the software test results report is prepared by VT or test engineer. The software test results report is reviewed at the conclusion of the test phase.
The final SVVR for the deliverable software is prepared during this phase.
3.2.5.1.6 Installation and Checkout Phase
The utility/equipment supplier has the responsibility for the installation and checkout phase and associated requirements.
During this phase the software becomes part of the installed equipment incorporating applicable software components, hardware, and data. The process of integrating the software with applicable components may consist of installing hardware, installing the program, and verifying that all components have been included.
An installation log is maintained during the installation and checkout process. After installation, the equipment and software is checked according to the STP and the site acceptance test (SAT) procedure.
User documentation, which is written by the DT, is to provide sufficient information about the software to permit users to employ the code as it was intended. User documentation is developed to the extent practical during the test phase and delivered to the user during the installation and checkout phase. User documentation includes error messages and identifies the necessary corrective-action procedures.
3.2.5.1.7 Operation and Maintenance Phase
The utility has the responsibility for the operation and maintenance phase and associated V&V requirements.
Activity in this phase consists of maintenance of the software to:
remove identified latent errors respond to new requirements, or adapt the software to changes in the operating environment.
Software modifications are approved, documented, verified and validated, and controlled in the same manner as described previously in the design, implementation and test phases. Each SVVP, in conjunction with the SCMP, is also be used to assist in the management of these activities and procedures.
3.2.5.2 Documentation
This section provides guidance for the development of documents. Software documentation is provided for all computer software to be used or delivered.
KEPCO & KHNP 3-11
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 3.2.5.2.1 Software Design Documentation
3.2.5.2.1.1 System Requirements Specification
The interface between functional requirements document(s) and the design documents are subject to QA provisions. SysRS includes:
Overall system configuration Design considerations Diagnostics Operational requirements Performance requirements Theoretical basis Design constraints External interfaces
3.2.5.2.1.2 Software Requirements Specification (SRS)
The SRS is used as the source document for design of the software, including:
Description of major software components which reflect the software requirements Technical description of the software (i.e. control flow, data flow, control logic, data structures) Description of all interfaces and allowable ranges of inputs and outputs Any other design items which are translated into code A description of the intended platform and programming language(s) expected to be utilized Data necessary for final implementation such as setpoints Abnormal conditions to be accommodated by the software are described, including resulting functional operations. Plant input signal transient conditions to be accommodated by this software are described.
Each requirement in the SRS is defined such that its achievement is capable of being verified by the SVVP. The SRS specifies any V&V requirements that are included in the SVVP.
3.2.5.2.1.3 Software Design Descriptions (SDD)
The purpose of the SDD is to depict how the software is structured to satisfy the requirements of the SRS. The design is described such that it can be translated into software code.
The SDD is a detailed description of the software to be coded. It describes decomposition of the software into entities. Each entity is described by its type, purpose or function, subordinate entities, dependencies, interfaces, resources, processing and data.
KEPCO & KHNP 3-12
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 Each design feature is described and defined such that its achievement is capable of being verified and validated per the SVVP. The adequacy of the SDD is verified against how the requirements of the software as documented in the SRS are to be implemented in code, and how the design is traceable to the requirements in the SRS.
3.2.5.2.1.4 Source Code Documentation
Source code documentation includes source code listings which reflect the translated design representation into a programming language. Also, any associated documentation generated during the coding is included with the source code listings.
Source code is traceable to the software design documented in the SDD and the requirements in the SRS. It includes sufficient comments to provide the user of the source code with an understanding of the functioning and programming of each module. All source code, whether developed or modified from existing software, is documented in accordance with the coding standards.
3.2.5.2.2 Software Verification and Validation Documentation
Software V&V documentation includes SVVP, software V&V phase report, and final software V&V report (SVVR).
3.2.5.2.2.1 Software Verification and Validation Plan
The SVVP identifies the software items to be evaluated and describes the V&V evaluation and reporting activities.
For custom software to be developed, the SVVP is developed as early as during the Concept Phase.
For existing software to be modified, the SVVP includes methods for verifying and validating modifications to this existing software.
The SVVP provides adequate planning for the following:
Software V&V process for the various software classes described in Section 2.3.2 Software V&V process for existing software to be modified and to be used "as‐is" Software V&V process for prototype software
The SVVP also facilitates the tracking and recording of the hardware configuration pertinent to the software V&V process during all phases of the software life cycle.
3.2.5.2.2.2 Software V&V Phase Report
This report is produced for each phase, describing the results of V&V tasks performed.
Each report contains a discussion of:
Description of V&V tasks performed, Summary of task results,
KEPCO & KHNP 3-13
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 Summary of anomalies and resolution, and Recommendations.
3.2.5.2.2.3 Final Software Verification and Validation Report
A V&V file is maintained by the VT throughout the software life cycle to document all V&V activities. It is an ongoing compilation of all validation test results, problem reports and corrective actions, verification review results, and the results of all QA audits. This file forms the basis for the development of the SVVR upon site installation and checkout.
Each SVVR is developed by the VT. It also includes sections for the following:
Summary of tests performed and results Test Procedures Test Results (including all test exception reports (TERs))
3.2.5.2.3 User Documentation
The purpose of user documentation is to provide sufficient information about the software to permit users to employ the code as it was intended. It is written by the DT. User documentation is developed to the extent practical during the test phase and delivered to the user during the installation and checkout phase.
User documentation consists of vendor documents and documents prepared as part of the project. Project prepared user documents are as follows:
User manual Installation and operation manual Maintenance manual
User documentation includes all error messages and identifies the necessary corrective‐action procedures. Also, it provides the means for the user to report problems to the DT.
3.2.5.2.4 Software Configuration Management Documentation
The DT is responsible for developing the SCMP to satisfy the unique requirements of their software development process.
3.2.5.2.5 Computer Code Certificate
The completion of the SVVR is the basis for the issuance of a computer code certificate.
Computer code certificates are issued for SC class software, and for ITS, if necessary. The issuance of a computer code certificate allows the release of a configuration item (CI) for use in a SC application and in an ITS application. Issuing of the certificate is controlled by the responsible team.
KEPCO & KHNP 3-14
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 3.2.5.3 Verification and Reviews
The purpose of this section is to address the verification and review requirements throughout the software life cycle. The software verification required by this SQAP addresses software classes described in Section 2.3.2. Verifications and reviews are technical in nature and are designed to verify the technical adequacy and completeness of the design and development of the software.
Review activities applicable for original software are listed as below:
Requirements verification Software design review Code verification Program documentation verification including each SVVR and testing review
The methodology of performing verifications is included in each SVVP. Verifications within the DT are performed by peers who have an equivalent knowledge of the topic but who are not directly involved with the software.
3.2.5.3.1 Requirements Verification
Functional requirements review
The objective of the Functional requirements review process is
- to evaluate the adequacy of the allocation of system requirements to hardware and software, - to evaluate the feasibility of accomplishing the system objectives and goals with the assigned requirements, - to ensure design requirements are complete, accurate, testable, and as unambiguous as possible
Software requirements review
The software requirements review examines the SRS to verify that it is clear, verifiable, consistent, modifiable, traceable, and usable during the operations and maintenance phase. The software requirements review includes evaluation of the software requirements against the user's software application which is described in a higher level requirements document such as a system design specification.
Specific software requirements review items are described in detail as necessary in the SVVP. As a minimum, the following items are included:
- Traceability and completeness of the requirements - Adequacy of rationale for derived requirements - Testability of functional requirements - Adequacy and completeness of verification and acceptance requirements - Conformance to documentation standards - Adequacy and feasibility of performance requirements
KEPCO & KHNP 3-15
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 - Adequacy and completeness of interface requirements
3.2.5.3.2 Design Verification
Software design review
The software design review is to determine the acceptability of the detailed design as depicted in the SDD in satisfying the requirements of the SRS. Software design review items are described in detail as necessary in the SVVP. The software design review is performed at the completion of the SDD and generally addresses the following items:
- Technical adequacy - Completeness of design requirements - Consistency - Correctness of software design - Traceability of software design to software requirements
Responsibilities, methodologies, and reporting of results are described in detail in the SVVP. Frequently encountered categories or types of errors normally found in the SDD may also be included in the SVVP in order to aid the independent reviewer.
3.2.5.3.3 Code Verification
Code review
The objective of code review process is
- to verify that the code implementation decisions are consistent with good software engineering practice based on expert opinion, - to verify that the code meets the coding guidelines and other requirements - to verify the executable code listing against SDD to ensure that no errors were introduced during the code generation process.
3.2.5.4 Test
The overall objective of testing is to find faults introduced in the software.
Each testing process includes:
Preparing test procedures to specify the manner and environment in which the code is tested detailing the steps to be followed by the tester, and specifying the set of inputs, execution conditions, and expected results. Verifying the test procedure with the objective to ensure that: - the required test coverage is provided; - the procedures are specified so tests can be repeated. Verifying the software referenced in the test procedures is qualified for usage. Implementing the test procedure, recording the resultant outputs, and assessing the test results. Producing the test result report
KEPCO & KHNP 3-16
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 Verifying the test result report with the objective to ensure that: - tests were executed as specified in the test procedures, - test results were recorded and properly analyzed, and - test results reporting checklist was completed.
3.2.5.4.1 Module Testing and Unit Testing
The objective of module and unit testing is:
to test that the executable code (i.e., module or unit) of each program behaves as specified in the SDD, to test that the executable code of each program does not perform unintended functions, to test that the program interfaces behave as specified in the SDD.
3.2.5.4.2 Integration Testing
The objective of integration testing is:
to test that the software modules integrated together meet the requirements specified in the SRS with the target hardware and pre-developed software, to find errors in the software, hardware, and pre-developed software interfaces, to find errors in handling stress conditions, timing, fail-safe features, error conditions, and error recovery.
3.2.5.4.3 System Testing (FAT)
The objective of system testing is:
to test that the entire executable code integrated with the target hardware and any pre-developed software meets the requirements specified in the SysRS.
3.2.5.5 Problem Reporting and Corrective Actions
The purpose of a formal procedure of software problem reporting and corrective action is to ensure that all software errors and failures are acted upon promptly and in a uniform manner encompassing all project software. This procedure ties together with the requirements of the SVVP and the SCMP. V&V activities are the primary vehicle to uncover software problems, while the SCMP ensures that actions taken to correct problems by changing configured software are consistent and traceable. Problem reporting and corrective action procedures span the entire software life cycle and all software classes identified in this report.
3.2.5.5.1 Problem Reporting
Discrepancies, deficiencies, or comments identified as a result of testing, review, or other means are documented in a formal manner. This includes any general discrepancy found outside of the normal V&V test process. The following table illustrates the type of report required by Section 3.2.4.
KEPCO & KHNP 3-17
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 METHOD REPORT Verification reviews Comment records (CRs) Validation tests TERs General findings TERs
The appropriate configuration identification data for each deficient software item or document is included on the appropriate form (or report). The form (or report) also includes a description of the observed deficiency, the name of the individual reporting the deficiency, and the date of the report finding.
In the case of a TER, each form includes the description of the resolution and any retest or review required after the resolution. If retest is performed, a copy of the test procedure or test case used is attached to the completed TER. Copies of all completed TER forms are distributed by the independent reviewer to DT and managed by the VT. All TER forms also are placed in a lifetime records. The steps which cause the discrepancy also are included on the TER form in order to reproduce the problem. These steps are noted as best as possible if the problem is not repeatable.
The extent of the retest is determined by the DT and VT based on the relative impact of the software change on the overall system operation. For SC and ITS software, all changes require complete retest of the system or function, unless otherwise justified in writing including steps to ensure that new errors were not introduced.
3.2.5.5.2 Corrective Action
The DT and VT establish as a clear objective the goal of resolving all validation test problems (via TERs) and verification review comments (via CRs) expeditiously to minimize the potential for unidentified effects during later life cycle phases.
The corrective action procedures used are based on the level of problem reported. In addition, the DT adheres to the following corrective action methodology that:
Problems are identified, evaluated, documented and, if required, corrected by the appropriate reporting mechanism. Corrections or changes are controlled per the appropriate sections of the SCMP. Preventive actions and corrective actions are documented on the appropriate form and distributed to the DT.
Corrective actions are documented on TERs and CRs by the cognizant engineer and are completed by the due date specified on the form.
3.2.5.6 Code Control
The purpose of this section is to describe the methods and facilities used to maintain, store, secure and document controlled versions of the identified software during all phases of the software life cycle.
KEPCO & KHNP 3-18
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 3.2.5.6.1 Software Configuration Management
The purpose of SCM is to:
Maintain historical records of software, as it is developed, used, and delivered, and its relation to functional documents, Control changes to the software, and Record and report change processing and implementation status.
All software items and associated documentation are controlled to maintain the items in a known and consistent state at all times. Original software and modifications to existing software follow the configuration requirements for all life cycle phases. Existing software which is not modified only falls under configuration control procedures upon its introduction into the software system.
The SCMP provides the necessary means to enable traceability of software and documentation products following their origination.
3.2.5.7 Media Control
The methods and facilities used to protect computer program physical media from unauthorized access or inadvertent damage or degradation are described herein.
3.2.5.7.1 Media Identification
Each removable disk pack, floppy disk, CD-ROM, or tape cartridge contains a serial number and description which lists the file(s) backed up on the medium. A log is maintained which cross references serial numbers to file(s) backed up. Disk packs, floppies and tape cartridges are not switched, renamed, or initialized without prior approval from the DT. A cabinet and disk file cabinet are provided for storage and easy access. A log is not required if alternate methods are in place to identify software release version accurately.
3.2.5.7.2 Archival Requirements
A locked fire/water proof facility is installed and maintained at a separate premise from the computer facility to store all project software. This facility is able to accommodate the storage of all utilized types of media.
After important software development milestones or baseline configurations are archived, a known software configuration is completely backed up and stored in the facility.
3.2.5.8 Supplier Control
The purpose of this section is to describe the level of SQA measures to be applied to software supplied from parties other than the DT.
3.2.5.8.1 Existing Software
This SQAP defines existing software as software which was previously developed to satisfy a general market need and may be considered for use on this project. The software may be subsequently modified prior to delivery, or it may be used "as is".
KEPCO & KHNP 3-19
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 Existing software includes commercial software which is integral to the delivered system and software which is determined to be in support of the delivered system.
Examples of integral software would be:
Operating systems Compilers, linkers, loaders Database software Communication drivers Man-machine interface software Display building software
All commercial software which is used in safety I&C systems meets the requirements established in EPRI TR-106439 and are based on the software's classification as follows:
SC - All requirements ITS - All requirements, except as modified or reduced by the DT in the following areas: Software service experience data, software inspection and testing techniques, software problem reporting, software change control
For existing software which is modified prior to delivery, all software requirements specified in this SQAP for original software are in effect for at least the modifications, except that modifications may conform to coding standards already in use.
The minimum V&V activities applicable for modifications to existing software are software modifications requirements verification, software modifications design verification, program modification documentation verification, and software validation.
Regression testing using test cases is conducted to ensure that the modifications do not produce unintended adverse effects, and to ensure that the modified software still meets the original software requirements.
Existing software that is not modified is qualified for use according to Section 3.2.5.1
Once qualified for use, the software falls under the SCMP. Once installed, the software meets the following requirements:
V&V during installation and operation per the SVVP Configuration management during installation and operation per the SCMP Documentation including: STPs, procedures, SVVR, and user manuals Problem reporting and corrective action procedures Configuration management for the records of delivered documents and software
KEPCO & KHNP 3-20
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 3.2.5.9 Sub-Contract Software/Services
Original software which is developed by a contractor and purchased by project adheres to the QA requirements specified in this SQAP for original software. This applies regardless of whether the software modification.
Where available, third party contractors who supply software are required to provide feedback of problems encountered by the supplier of other users of similar software. Where available, this feedback information is supplied automatically without request from project. Also, DT has the responsibility for informing the supplier any problems encountered by the user in the use or maintenance of the software.
Additional requirements for subcontracted software and services are as follows:
Software and services are procured from approved supplier per the QAM. Suppliers have written QA policies which meet the principles and intent of this SQAP. Purchase orders require the supplier to make available documents which are evidence of compliance with the principles and intent of this SQAP. Purchase orders require the supplier to deliver adequate user documentation, test procedures and test reports.
3.2.5.10 Training
The manager ensures that there is sufficient, independent, technically qualified and trained resource to implement the requirements of the SQAP.
3.2.5.10.1 Staff Qualifications and Training
The manager assures that all personnel participating in the design, implementation, test and verification of software are qualified to perform their assigned tasks. The manager assesses the capabilities of candidates and selects appropriately qualified personnel based on the manager's experience.
In determining whether any candidate is qualified, the manager considers whether the candidate:
Understands the system; Understands the job to be performed; Has, or is capable of obtaining, working knowledge of system software and tools required to do the job; Possesses the combination of skills and knowledge to perform the job through a proper level of formal education, supplemental training, and experience; Understands the applicable SQAPs, SCMPs, and SVVPs; Is able to produce reliable software, good documentation, and can implement required QA practices.
KEPCO & KHNP 3-21
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 3.2.5.10.2 Post Development Training of Owner/Operator Personnel
It is important that the recipient owner/operator personnel be trained and qualified to use or maintain the software. The training program is the responsibility of Owner with possible support by the engineering team and includes training for the users, operators, maintenance, and management personnel, as appropriate. The training program includes: A training record for each training session recording the instructor, date, material covered, and personnel attending, to ensure that the appropriate training has been obtained before using the system.
3.2.6 Record Keeping
All activities are recorded and documented. The documents are properly stored in the library and controlled with CM.
3.2.6.1 Records Collection
All SQA related documentation is collected and archived including the following:
Results of all reviews and audits Software life cycle plans and other documentation Completed V&V checklists (as provided in the SVVP) STPs, test procedures, and test reports Acquired metrics data and analysis results Certificates and forms Programs and materials used in performance of tests Site installation log Training records Other documentation deemed important to software quality
3.2.6.2 Records Maintenance
All SQA records are collected and stored in an electronic format.
If the records do not initially exist in electronic format they are scanned into electronic format for subsequent storage.
Records are archived in a secure facility that has safeguards to protect the records from fire, theft, or environmental deterioration.
The record retention facility provides a means for searching, locating, and retrieving copies of archived records while maintaining the security and integrity of the archived backup copy.
3.2.6.3 Records Retention
All records are lifetime records for the duration of the project, until the time of decommissioning. The retention period for any SQA record may be subsequently changed from lifetime retention to shorter retention duration by the management. Management review includes a records retention evaluation of the SQA records retention period.
KEPCO & KHNP 3-22
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 The evaluation either reaffirms the lifetime storage duration for all records or specifies revised storage duration along with justification for the various media types. The results of the records retention evaluation become a quality record.
3.2.7 Methods/Tools
During software development, a number of techniques are used to help assure all software is designed, implemented, and documented in accordance with the objectives of building software which meets the requirements and which is maintainable over time in the most cost effective manner. The tools, techniques and methodologies employed in this process ensure that the software is verifiable from each phase of the project to the next.
The use of commercially available automated tools for SCM is employed to the maximum extent possible.
Use of the waterfall model of software development and testing techniques to help assure that the requirements are correctly translated into design and implementation products.
3.2.8 Standards
The SQAP complies with the following standards and guidelines:
IEEE Std. 7-4.3.2-2003 (Reference 4.2.9), Clause 5.3.1, as endorsed by RG 1.152, Revision 3 (Reference 4.1.3) IEEE Std. 1074-1995 (Reference 4.2.8), Clause 3.3, as endorsed by RG 1.173 (Reference 4.1.10) IEEE Std. 1028-1997 (Reference 4.2.7), as endorsed by RG 1.168, Revision 1 (Reference 4.1.5) IEEE Std. 603-1991 (Reference 4.2.1), as endorsed by RG 1.153, Revision 1 (Reference 4.1.4) IEEE Std. 730-2002 (Reference 4.2.10) NUREG/CR-6101 (Reference 4.1.11), Section 3.1.2
KEPCO & KHNP 3-23
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 Table 3-1 Hardware and Software Classification
Electrical Safety Software System Subsystem Classification Classification
Bistable processor Class 1E SC Plant protection system (PPS) LCL processor Class 1E SC
Core protection calculator Class 1E SC (CPC) Core protection calculator CEA calculator (CEAC) Class 1E SC system (CPCS)
CEA position processor (CPP) Class 1E SC
Group controller (GC) Class 1E SC
Engineered safety features - Loop controller (LC) Class 1E SC component control system Diverse manual ESF actuation (ESF-CCS) Class 1E N/A switch ESF-CCS soft control module Class 1E ITS (ESCM)
Serial data link (SDL) Class 1E SC
Safety system data network Data communication system Class 1E ITS (SDN)
DCN-I Class 1E ITA
Interface and test processor Class 1E ITS (ITP) Maintenance and test panel Safety system ITP/MTP/OM* Class 1E ITS (MTP)
Operator module (OM) Class 1E ITS
QIAS-P processor Class 1E ITS Qualified indication and alarm system – P (QIAS-P) QIAS-P displays Class 1E ITS
* The safety system ITP, MTP, and OM are shared between PPS, CPCS, and ESF-CCS.
KEPCO & KHNP 3-24
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 Table 3-1 Hardware and Software Classification (cont’d)
Electrical Safety Software System Subsystem Classification Classification
QIAS-N controllers Non-Class 1E ITS Qualified indication and alarm system – non-safety (QIAS-N) QIAS-N displays Non-Class 1E ITS
Controller Non-Class 1E ITS
Diverse protection system Operator module (OM) Non-Class 1E ITS (DPS) Maintenance and test panel Non-Class 1E ITS (MTP)
Power control system (PCS) RRS, RPCS, DRCS Non-Class 1E ITA
NPCS (FWCS, SBCS, etc.) Non-Class 1E ITA
Controller & I/O cabinets Non-Class 1E ITA Process - component control system (P-CCS) DCS gateway Non-Class 1E ITA
Channelized SOE data Non-Class 1E ITA acquisition cabinets
DIS cabinet Non-Class 1E ITS Diverse indication system (DIS) DIS display Non-Class 1E ITS
Fixed in-core detector amplifier N/A Non-Class 1E ITA system (FIDAS)
Large display panel (LDP) N/A Non-Class 1E ITA
NSSS integrity monitoring ALMS, IVMS, LPMS, Non-Class 1E GP system (NIMS) RCPVMS Computer-based procedure Non-Class 1E ITS (CBP) system Information processing system Safety parameter display and Non-Class 1E ITS (IPS) evaluation system (SPADES+) Nuclear application programs Non-Class 1E ITA (NAPS)
KEPCO & KHNP 3-25
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 Table 3-2 Tasks Required for Software Categories TS
KEPCO & KHNP 3-26
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 Table 3-3 Software Tasks and Responsibilities for Software Classifications TS
KEPCO & KHNP 3-27
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 3.3 Software Verification and Validation Plan
3.3.1 Purpose
The purpose of the SVVP is to establish requirements for the V&V process to be applied to software based I&C systems. The section includes various V&V methodologies aimed to increase the system reliability and availability. Some of these methodologies employ systematic checks for detecting errors in the software during the system development and implementation process. This section explains requirements for the V&V processes starting with the system design document stage and all necessary V&V activities to verify and/or validate software based I&C systems.
The goals of this SVVP are to:
Improve the system reliability and availability Reduce system costs by exposing errors as early as possible Provide a systematic process of objectively evaluating the system's performance Demonstrate compliance with customer requirements, industry standards and licensing requirements.
3.3.2 Organization/Responsibilities
The organization is described in Section 2.2.1. The VT responsibilities are described in this section.
The VT is independent from the DT. Also the VTM is organizationally, financially and administratively independent from the DTM. VT performs and/or evaluates the test documentation and results, and performs supplemental testing as deemed necessary.
The actual assignments of teams for the different software classifications for engineering, verification, testing, and validation are shown in Table 3-3.
The requirements and the implementation of design are evaluated to ensure that the resulting system operation is functionally correct and meets the performance objectives.
In case of SC class software, full independent testing is performed without evaluating or using DT's test data base/bed, or test results. Based on the SSP, the critical functional requirements are identified and monitored as the development progresses. The full independent analysis of the system requirements, design specifications, test specifications and results is confirmed.
3.3.3 Oversight
The management of V&V spans all life‐cycle phases. Software development is a cyclic and iterative process. The V&V effort re-performs previous V&V tasks or initiates new V&V tasks to address software changes. V&V tasks are re-performed if errors are discovered in the V&V inputs or outputs.
Management of V&V includes:
SVVP: Generate the SVVP outlining resources and schedule the V&V activities.
KEPCO & KHNP 3-28
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 Baseline change assessment: Evaluate proposed software changes for effects on previously completed V&V tasks. When changes are made, plan iteration of affected tasks which includes re‐performing previous V&V tasks or initiating new V&V tasks to address the software changes. Management review: Conduct periodic reviews of the V&V process in the area of technical accomplishments, resource utilization, future planning and risk assessment. Support daily management of V&V phase activities. Review final and interim V&V reports. Evaluate V&V results and anomaly resolution to determine when to proceed to the next life cycle phase and to define changes to V&V tasks to improve the process. Review support: Support management and technical reviews (e.g., software requirements review, software design review, code review, etc.). Identify key review support milestones in SVVP and schedule V&V tasks to meet milestones. Establish methods to exchange V&V data and results with DT.
3.3.4 Risks
Potential risks associated with the development, maintenance and assurance of high quality software CIs and life cycle process outputs are identified and managed.
The following risk areas are considered:
Previous project experience and lessons learned Internal and external organizational interfaces Schedule pressure Insufficient resources Need for specialized resources
3.3.5 Measurement
Comments and TERs identified by the VT during document review and testing are required to be assured, recorded, analyzed and reported. The resolutions of comments and successful completion of testing satisfying evaluation criteria is key measures of software quality.
The review process utilizes checklist to check for omissions, inconsistencies, inaccuracies, errors of omission, irrelevant requirements and deviation from guidelines.
The test procedure includes the criteria for test completion. The errors found during software reviews and software testing are measured, recorded, analyzed, and reported. Supplemental testing is recommended when found necessary.
3.3.6 Procedures
V&V process checks and determines whether the system requirements are met, the products of each development phase successfully implement the criteria and requirements governed by the previous phase and design requirements/documents, and the implemented system complies with project specific criteria and requirements. The determining work may include analysis, evaluation, review, inspection, assessment, and testing of products and processes.
KEPCO & KHNP 3-29
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 The verification process provides a step-by-step assurance of correct development work through the requirements, design, and implementation phases. The initial verification activity is the review of system functional requirements before any detailed software design work is launched. Verification activities are performed at each phase. These activities determine that all requirements have been properly transferred from the input products to the output products of the phase, and thereon satisfying the design criteria and requirements imposed on each phase. Validation activities are performed at the final completion stage of the software development work.
These activities determine that the operation of the system conforms to the system requirements set out in the higher and lower level requirement documents. Thus V&V activities are inseparably performed along with project’s software development activities throughout the whole life cycle.
Figure 3-2 shows SVVP overview. This overall SVVP details the V&V process and activities involved during the various phases, and details various tools and techniques that can be used. V&V details are developed before the start of system design, including schedule, resources, titles of documents, and software classification.
3.3.6.1 Life Cycle Verification and Validation
The following sections describe the V&V procedures for each phase of the software life cycle.
3.3.6.1.1 Concept Phase V&V
Concept phase V&V is the period prior to formal definition of the system requirements, which may include a feasibility phase. The SVVP, including schedule and personnel requirements is developed at this time. The SVVP reflects the V&V activities to be performed during each phase. Any specific tools to be used are stated in the SVVP. Concept documents such as the contract, technical specification, QAM, and codes and standards are checked for readiness.
The actual reporting of concept phase activities may be combined with the requirements phase. TS
KEPCO & KHNP 3-30
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 TS
Figure 3-2 Verification and Validation Plan Overview
KEPCO & KHNP 3-31
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 TS
Reporting of the concept review activities can be incorporated in the requirements phase report including identification of deficiencies.
3.3.6.1.2 Requirements Phase V&V
The intent of verifying the functional requirements and software requirements is to ascertain that the requirements are correct, complete, accurate, testable and consistent. Requirements phase V&V consists of SysRS, SRS and interface requirements documents (IRDs) review.
The principal purpose of a requirements document is:
To clearly define the objectives and needs of the system design and development process. Both the designer and the user are able to understand and perform a meaningful assessment of the system. To serve as a means against which an implementation can be validated and the intermediate steps can be verified.
The goal of verification activities during this phase is to ensure that the requirements documents do indeed serve the above purpose.
The specific V&V tasks are as follows:
Prepare the RTM to include all functional, hardware, software, performance, interface, and user requirements. This RTM is a document to be used throughout each phase of the V&V process. Complete the requirements phase V&V checklist. Review previously-developed or sub-vendor software and produce a report stating whether this software is adequate for its intended use.
The inputs, tasks, and outputs of requirements phase V&V are as follows:
TS
KEPCO & KHNP 3-32
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 TS
3.3.6.1.3 Design Phase V&V
The purpose of this verification phase is to ascertain that the SDD represents a faithful translation of the system's functional requirements and SRS before the design is committed for implementation.
Design phase V&V inputs TS
KEPCO & KHNP 3-33
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 3.3.6.1.4 Implementation Phase V&V
The purpose of the implementation verification phase is to ascertain the implementation documents are clear, understandable, and logically correct, and the SDD is faithfully translated. The objectives of the implementation documents are to facilitate the effective production, testing, use, transfer, and conversion to a different environment, future modifications, and traceability to design specifications.
The implementation phase V&V activities also include verification by inspection of source code program to assess the performance of resulting assembled codes. Also, the VT reviews detailed test procedures in preparation for the next stage of unit testing. Unit testing in the implementation phase is to test that the executable code of each program behaves as specified. Test procedures and reports for unit testing are documented and verified by the relevant team members. Unit tests are conducted by the relevant teams. TS
KEPCO & KHNP 3-34
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 3.3.6.1.5 Test Phase V&V
The overall objective of testing is to find faults in the software. The test phase covers integration testing and system testing (FAT).
Integration testing is to test that the software modules integrated together with the target hardware and pre-developed software meet the requirements specified in the SRS. The testing is also to find errors in the software, hardware, and pre-developed software interfaces, errors in handling stress conditions, timing, fail‐safe features, error conditions, and error recovery. Test procedures and reports for Integration Testing are documented and verified by the relevant team members.
System testing (FAT) is to test that the entire executable code meets the requirements specified in the SysRS. System testing (FAT) is conducted, per the STP, during this phase in the development environment when all of the system components have been integrated by DT. Test procedures and reports for system testing (FAT) are documented and verified by the VT. Integration and system tests are conducted by the relevant team members.
The final SVVR for the deliverable software is prepared during test phase.
All user documentation is developed by the DT and verified by the VT during this phase.
TS
KEPCO & KHNP 3-35
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 TS
3.3.6.1.6 Installation and Checkout Phase V&V
The system installation package is reviewed to ensure that all elements necessary to install and operate the system have been correctly and completely specified.
TS
Installation and checkout phase V&V process is the responsibility of utility.
The software and/or system supplier may provide assistance in preparing the necessary activities to the utility when requested.
3.3.6.1.7 Operation and Maintenance Phase V&V
Operation and maintenance phase V&V process is the responsibility of utility. This section provides recommended practices with respect to software V&V to follow:
KEPCO & KHNP 3-36
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 Modifications are made in the hardware which may cause the software to be changed. Modifications are made to the program for enhancements. Errors may be discovered which require software modifications.
V&V Tasks that are typical for the operation and maintenance phase are;
Evaluation of new constraints, proposed change assessment, operating procedures evaluation and SVVP revision, anomaly evaluation, and retirement assessment
Records of all the software changes are documented by the due personnel of the utility.
3.3.6.2 Software V&V Reporting
V&V reporting occurs throughout the entire software life cycle and includes the following (which have been identified in the software life cycle activities).
3.3.6.2.1 Required Reports
Software V&V phase report
This report is separately produced for concept/requirements, design, implementation, test, installation and checkout, and operation and maintenance phase. Each report summarizes the results of V&V tasks performed during each V&V phase.
This report contains the following:
- Description of V&V tasks performed. - Summary of task results. - Summary of discrepancies and resolution. - Assessment of software quality. - Recommendations
Final SVVR
This report is issued at the end of the V&V task to summarize and documents the V&V activities performed throughout all life cycle phases.
The report includes:
- Summary of life cycle V&V tasks. - Summary of task results. - Summary of discrepancies and resolutions. - Assessment of overall software and system quality. - Recommendations for enhancements. - Code certificate.
KEPCO & KHNP 3-37
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 3.3.6.3 Software V&V Administrative Procedures
Proposed software changes are evaluated for effects on previously completed V&V tasks. If changes are made, previous V&V tasks are re-performed or new V&V tasks are initiated. The V&V administrative procedures used in conjunction with the V&V activities described in this SVVP are outlines in the following subsections.
3.3.6.3.1 Anomaly Reporting and Resolution
Any discrepancies detected during any phase of the V&V process are immediately brought to the attention of the DT. Resolution is made in writing by the DT. The VT documents the resolution in the software V&V phase reports as well as the final SVVR.
V&V anomaly reports contain the following information, as a minimum:
Anomaly report number Project name, number and applicable phase The date the anomaly was detected The name of the V&V engineer that detected the anomaly The V&V activity and task that were underway when the anomaly was detected The V&V Input document that was being verified or validated A detailed description and summary of the anomaly The impact of the V&V anomaly The final disposition of the anomaly, including documents and/or software that were affected, and the V&V activities and tasks that were performed
3.3.6.3.2 Task Iteration Policy
If the V&V task is reprogrammed, for whatever reason, the task is identified in the reports identifying the rationale and the results of the V&V task. This information is documented in a revision abstract for revised V&V reports.
3.3.6.3.3 Deviation Policy
If any deviation from the reviewed and approved V&V task plan is required, the change is identified, rationale for the change provided, and a determination of effect on software quality provided. Any deviation is approved by the VTM and management.
3.3.6.3.4 Record Retention
All reports and records of V&V activities in the course of development or change projects, as described in the SVVP, are retained in accordance with the QAM.
3.3.6.4 V&V Test Documentation Requirements
The test documents are composed of the purpose, format and contents as described in the STP.
KEPCO & KHNP 3-38
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 The test documents to be prepared consist of the following:
Test specifications
The test procedure contains the following components:
- Test-design - Test-case - Test-procedure Test designs
This portion of the test procedure specifies the details of the test approach for a software, requirement or combination of requirements, and identifies the associated tests.
Test cases
This portion of the test procedure specifies the inputs, predicted results and a set of conditions for executing the test case.
Test procedures
This portion of the test procedure specifies a sequence of actions for the execution of a test.
Test reports
The test report summarizes the testing activities and documents the results. It also contains an evaluation of the corresponding test items. Typically the test procedure document containing the hand‐written entries by the tester becomes part of document. The test report also contains the TER log and copies of the TERs. Together these identify the status of outstanding test exceptions reported during testing.
3.3.7 Methods/Tools
The following V&V activities are performed to every system (irrespective of the selected verification test strategy).
3.3.7.1 V&V process TS
KEPCO & KHNP 3-39
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 TS
3.3.7.2 Requirement Traceability Matrix (RTM) Preparation
Throughout the project life‐cycle, a software requirements traceability analysis is performed and an RTM maintained. The RTM lists all of the requirements discovered and traced in the V&V process.
The use of commercially available automated tools for requirements traceability analysis is recommended to the maximum extent possible.
3.3.7.3 Criticality Analysis and Risk Analysis
For SC class software, criticality and risk analyses are performed at each phase. The guidelines in IEEE Std. 1228 (Reference 4.2.12) can be for this work.
3.3.7.4 V&V Tools
Testing for V&V activities is implemented in accordance with the procedures specified in Section 3.3.6, where facilities, equipment, techniques and tools to be used are specified. The tools to be used for V&V are based on an evaluation of the tools’ readiness for use on a project involving software. This evaluation considers tool’s past performance and the extent of tool validation already performed. The tools to be used for V&V are controlled under CM.
3.3.8 Standards
The SVVP complies with the following standards and guidelines:
IEEE Std. 7-4.3.2-2003 (Reference 4.2.9), Clause 5.3, as endorsed by RG 1.152, Revision 3 (Reference 4.1.3) IEEE Std. 1012-1998 (Reference 4.2.6), as endorsed by RG 1.168, Revision 1 (Reference 4.1.5) IEEE Std. 1028-1997 (Reference 4.2.7), as endorsed by RG 1.168, Revision 1 (Reference 4.1.5) NUREG/CR-6101 (Reference 4.1.11), Section 3.1.4 NUREG/CR-6430 (Reference 4.1.12)
KEPCO & KHNP 3-40
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 3.4 Software Configuration Management Plan
3.4.1 Purpose
The SCMP describes the process for identifying, collecting and controlling the complete set of software CIs associated with each system. The SCMP identifies software CIs, invokes controls on the process of making changes to software, and records and reports on the status of changes.
The important goals of SCM are to:
Record and document work in progress on each software item to permit understanding of current project status. Identify all software code and data associated with a system including revision level, completion status, test status and history. Maintain an association between software problem reports, change reports, and affected documentation, lines of code, and data items. Implement appropriate controls and approvals for changes to the software configuration. Identify the organization responsible for a software item and its associated problem reports and changes. Ensure that existing and prior revisions of software can be reconstituted in the future. Maintain the status of released software, users of this software, and associated problem reports. Maintain the association among software documents, code and data. Backup the software (in progress or completed) to protect against disaster.
All software items and associated documentation are controlled in such a manner as to maintain the items in a known and consistent state at all times.
The software of I&C systems to be developed by a subcontractor meet the requirements of and are maintained by an SCMP which is to be prepared by the subcontractor and to be equivalent to this SCMP.
3.4.2 Organization/Responsibilities
The organization is described in Section 2.2.1.
The DT is generally responsible for the SCM. The DTM is responsible for the implementation of adequate measures to manage and control the software configuration in accordance with the SCMP. All SCM tasks are confirmed by the VT.
A librarian maintains all controlled software items as well as all control records. The librarian also maintains multiple backups of these items at alternate locations to assure sufficient disaster recovery capability. The librarian may be a member of the DT for the system, but reports to the DTM.
KEPCO & KHNP 3-41
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 A single librarian may be used for more than one system under the cognizance of more than one manager.
A system administrator, who may also be the librarian, is responsible for performing ongoing backup of work in progress for the system.
Configuration control board (CCB) sets out the ground rules and policies of configuration control. The DTM and VTM are included in the CCB members.
3.4.3 Security
All software documents and software CIs under configuration control are protected against the SDOE threats. Each organization described in this report is responsible for ensuring that the security related configuration controls and restrictions are maintained, as described in other sections and Section 3.12.
3.4.4 Measurement
The SCMP requires periodic reviews and audits of the configuration base line, including physical audits of the baseline. The effectiveness of the CM is systematically collected and analyzed to determine the effectiveness of the CM procedure. Any failure of the CM is analyzed and appropriate corrections are reflected in the CM procedure.
3.4.5 Procedures
3.4.5.1 Identification and Numbering of Configuration Items
Throughout the software life cycle, all versions of all software items are tracked along with their associations. For example, the association of a particular version of a code item and related design and requirements documents, test reports, etc. is maintained in lifetime software records per the QAM. The association of software items with each particular software baseline is also maintained in lifetime software records. The scheme by which this is done is developed by the DT.
Each software item has a numbering method that uniquely identifies the item and its versions. The configuration identification scheme is consistent with the numbering method for all software items. Software documents are identified by character string appearing on the cover sheet of each document. Software identifier is described in the SCMP.
All software and documentation is uniquely identified by a system name, number, and corresponding revision date, appropriate category and appropriate software classification. Reviews, audits, problem reports, and test reports specifically identify the system name, number, revision number, and revision date to minimize confusion. This identification structure also has the ability to track resolution of test results and subsequent retesting of software modules and integrated systems.
This configuration identification data is defined as part of the baseline at the completion of each major phase of the software project. In order for the baseline to change, it incorporates all approved changes and represents the most recent approved software configuration.
Appropriate baselines are defined at control points within the project life cycle in terms of the following:
KEPCO & KHNP 3-42
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 The event that creates the baseline The items that are to be controlled in the baseline The procedures used to establish and change the baseline The authority required to approve baseline documents
3.4.5.2 Configuration Control
Following the original baseline after the implementation phase, software and documentation is placed under configuration control by the DT. Configuration change control by the DT continues up to the point when the software is no longer expected to be changed. Software configuration control includes limited access to master copies of documentation and software in either hard copy or magnetic form. Access to software and documentation is controlled by the librarian.
The SCMP addresses how software changes are managed. Software configuration control is performed in a single software environment or in multiple software environments such as the following:
The development environment is where all software is written, changed, and unit tested by the DT and controlled by the librarian. The control library is where all master copies of software modules reside for integration test purposes, and are controlled by the librarian. The platform or FAT environment is where all software is tested and integrated in preparation for final FAT on the deliverable equipment.
Changes to software are formally documented. This documentation contains a description of the change, the rationale for the change, and the identification of affected software element(s). Software V&V is performed on the change, in accordance with the SVVP, to ensure the necessary traceability, consistency, and correctness of the change.
3.4.5.3 Software Change Request (SCR)
The SCR is the mechanism by which change requests are approved by the DTM and presented to the librarian. This action allows a developer to check out software/documentation from the SCM controlled libraries. An SCR may be generated from an action documented in a TER. Refer to Section 3.2.5.5 for a description of problem reporting. The mechanism for requesting authorization is to present the SCR to the DTM and request approval for work to begin.
The DTM is responsible for assigning personnel to perform and develop requirements and procedures for the following activities of "Requesting Change", "Evaluating Change", "Approving or Disapproving Change", and "Implementing Changes".
3.4.5.4 Software Release History
The documentation of software release history is performed. This enables the CM program to maintain an accurate status of the software at all times and enable the reconstruction of a given release at any time in the future. The document includes the software version and indicates which modules are affected in the revision.
KEPCO & KHNP 3-43
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 3.4.5.5 Baselines
Baselines may be established for the control of design, product, and engineering changes and are time phased to the development effort. Baselines may be established by the DT to capture a software stage in the development effort. The Baseline Release History form is used to document the date of a baseline.
3.4.5.6 Interface Control
Interface Control is handled in the same manner as other types of software or documentation. Interface control is the coordination of the software configuration identifications (SCIs) which are outside of the scope of the plan, but which interface with the SCIs controlled by the plan.
3.4.5.7 Subcontractor/Vendor Control
Subcontractor/vendor control activities incorporate items developed outside the project environment into the project CIs. Included are software developed by contract and software acquired in its finished form. Special attention is directed to these SCM activities due to the added organizational and legal relationships.
3.4.5.8 SCM Schedules
The following are the major milestones or baselines:
Configuration baseline based on available baseline software Intermediate baseline with requirements for major modules Requirements implemented (ready for test and error correction) Test and error correction completed Final software release
3.4.5.9 SCMP Maintenance
The SCMP is updated as deemed necessary by the DT. Changes to SCMP are documented and approved to the same level as the original issue of the document and transmitted to each engineer for software configuration control effectiveness.
3.4.5.10 Control Points
The SCMP describes the criteria for selecting control points and establishes the correspondence between control points identified in the plan and baselines, project milestones, and life cycle milestones.
3.4.5.11 Configuration Status Control Log
A software configuration status control log is maintained by the DT for a record of the revision history and current status of each controlled software element. This log includes:
Identification of approved baseline configuration
KEPCO & KHNP 3-44
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 Status of proposed changes Status of approved changes
An automated CM system may be incorporated on this project. If this is the case, the features of the configuration log described above are included in such a tool.
3.4.5.12 Audits and Reviews
There is a physical configuration audit (PCA) and a functional configuration audit (FCA) of CIs prior to the release of a product baseline or an updated version of a product baseline. The PCA portion of the audit consists of determining that all items identified as being part of the configuration are present in the product baseline. The FCA portion is similar, in that someone acknowledges having inspected or tested each item to determine that it satisfies the functions defined in the specifications or contract for which it was developed.
The audits and reviews define way to ensure that established CM procedures are followed.
3.4.6 Record Keeping
Record keeping of SCM items plus related activities is one of the cardinal processes of SCM. Record keeping starts with identifying the required approach for protection of CM target items and setting up proper documentation structure for record keeping of SCM items. Procedures are established for determining, maintaining, re-acquisition, and transferring the SCM items. The SCM items typically include source and executable modules of software, utility software (such as compiler and linker of matching versions with the software developed), development tool software, test data set, and documents including the test results. The procedures allow the system configuration to be traced. For SCM activities, backup copy media are of reasonable longevity considering the speed of development in media technologies. Naturally for the convenient development and V&V work, the procedures allow the latest and earlier versions of all documentation and software to be easily retrieved.
At least, multiple backup copies of the following are maintained in physically isolated locations:
Documents and records Deliverable software in a separate area for security and hazards prevention Software tools used in development, integration, and testing Test data set
Multiple backup copies of CM record and SCM items are required to protect the resources against any hazardous infiltrations by outside people, security, or any other harshness caused by the environment or accidents like fire, smoke, or flooding.
3.4.7 Methods/Tools
The DTM identifies in the appropriate tools, techniques, methodologies which may assist in SCM activities. These may include commercially available products for code control, version identification, and media backup/control. The followings are to be used as minimum requirements:
KEPCO & KHNP 3-45
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 At project baseline, a list of software is maintained by the DT in the design file to include module name, version revision, and executable file identification. In addition, a list of software tools (compilers, linkers, and others.) and their version/revision is maintained by the DT. These lists may be maintained by commercially available word processing, spreadsheet, or database programs and kept in the archive. Software backups of all program files, including tools, is started upon baseline and updated on a regular basis. Backup methodology and strategy is established by the DT. Backup files are kept in multiple separate places. Keeping multiple copies applies to all physical or electronic media. Backups may be kept as read-only as long as the file locations are physically separate from the software development location.
3.4.8 Standards
The SCMP complies with the following standards and guidelines:
IEEE Std. 1074-1995 (Reference 4.2.8), Clause 7.2, as endorsed by RG 1.173 (Reference 4.1.10) IEEE Std. 828-1990 (Reference 4.2.2), as endorsed by RG 1.169 (Reference 4.1.6) ANSI/IEEE Std. 1042-1987 (Reference 4.2.14), as endorsed by RG 1.169 (Reference 4.1.6) IEEE Std. 7-4.3.2-2003 (Reference 4.2.9), Clauses 5.3.5 and 5.4.2.1.3, as endorsed by RG 1.152, Revision 3 (Reference 4.1.3) NUREG/CR-6101 (Reference 4.1.11), Section 3.1.3
KEPCO & KHNP 3-46
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 3.5 Software Development Plan
3.5.1 Purpose
The purpose of the SDP is to describe the necessary information on the technical aspects for software development that are required by the DT throughout software life cycle phases. The DT develops the software life cycle model for systems according to RG 1.173 and IEEE Std. 1074 for information on life cycle processes.
This SDP provides the guidance and the detailed information to develop software of the digital I&C system.
3.5.2 Organization
The organization and responsibilities are described in Section 2.2.1. The software life cycle along with its inputs and outputs of each phase in Section 3.2 is defined in detail in the SDP.
3.5.3 Oversight
To achieve the high reliability and enhance design quality of software development works,
Ensure all deliverables are to go through the appropriate review process. The review is required to ensure that each deliverable is of acceptable quality, following guidelines and procedures. Make sure that document configuration controls are provided. Estimate adequacy of the resources assigned to the project and facilities to be used. Make sure that the SDP is followed. Institute measures to prevent delays in case of deviation from the plan.
In case of error or changes during development, the DTM is notified by the DT personnel. The DT is responsible for corrective actions and changes. All corrective actions and changes are tracked in accordance with the SCMP. Outputs generated by the DT during software development are independently verified by the VT in accordance with Table 3-3.
3.5.4 Risks
The typical risks of software development include system risk, hardware risk, size risk, complexity risk, schedule risk, technical risks, and interface risks. Risk items are periodically assessed through the software life cycle.
It may include, as applicable, an overview of:
Requirements and constraints on the system and software to be developed Requirements and constraints on project schedule and resources Other requirements and constraints, such as on methods and standards in software
KEPCO & KHNP 3-47
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 3.5.5 Measurement TS
3.5.6 Procedures
The SDP describes the software life cycle model that is used on the project. The SDP discusses the various processes that make up this life cycle. For each process, the SDP gives the input information required in order to carry out the process, a description of the actions that take place during the process, and the output information produced by the process. Since the output of one process is likely to be used as input to another, a data flow diagram is appropriate. The processes suggested in the SDP are based on software life cycle of RG 1.173 and IEEE Std. 1074.
TS
KEPCO & KHNP 3-48
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 TS
3.5.7 Schedule
The software development schedule is defined in the SMP and a more detailed plan may be defined further in the SDP. The SDP provides the list of the technical milestones that is met and describe what is expected at each milestone.
3.5.8 Methods/Tools TS
KEPCO & KHNP 3-49
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 TS
3.5.9 Standards
The SDP complies with the following standards and guidelines:
IEEE Std. 1074-1995 (Reference 4.2.8), as endorsed by RG 1.173 (Reference 4.1.10) IEEE Std. 7-4.3.2-2003 (Reference 4.2.9), Clause 5.3.1, as endorsed by RG 1.152, Revision 3 (Reference 4.1.3) IEEE Std. 830-1993 (Reference 4.2.4), as endorsed by RG 1.172, Revision 0 (Reference 4.1.9) IEEE Std. 603-1991 (Reference 4.2.1), as endorsed by RG 1.153, Revision 1 (Reference 4.1.4) NUREG/CR-6101 (Reference 4.1.11), Section 3.1.6
KEPCO & KHNP 3-50
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 3.6 Software Integration Plan
3.6.1 Purpose
The SIntP provides description of the integration process for software modules, and the methodology that supports the software integration and hardware-software integration.
The process of hardware/software integration is the combining of verified hardware and software modules into a system that is capable of performing specified functions.
The purpose of the SIntP is to:
Describe the organization and responsibilities of individuals or groups involved in the test activities. Provide the requirements and guidelines necessary to prepare, execute, and document software tests. Define measurements and metrics for error tracking and resolution, and assess the success or failure of the software integration and software test effort.
Software integration consists of three steps: TS
3.6.2 Organization/Responsibilities
The organization is described in Section 2.2.1.
Software is integrated by the DT. If an error occurs during the process of software integration, the DT notifies the DTM. Errors are recorded and tracked to closure.
3.6.3 Measurement
Integration refers to installation of developed software units, and integration of developed software with platform hardware and system software. The following is confirmed:
KEPCO & KHNP 3-51
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 TS
When an error occurs during the process of software integration, the DT identifies the cause by determining, recording and analyzing the error. Errors that may impact the schedule of the DT or the work being done by other teams are reported to other teams by the DTM.
3.6.4 Procedures
3.6.4.1 Identification of the Integration Process
3.6.4.1.1 Integration Level
Multiple levels of integration may be necessary, depending on the complexity of the software system that is being developed. Several integration steps may be required at some levels.
The SIntP provides the different levels of integration and the scope of each integration step at each level. And the SIntP provides a general description of the various objects that are included in each step at each level.
3.6.4.1.2 Integration Objects and Strategies
The SIntP provides a complete list of all objects, computer hardware, instrumentation, software, and data that are included in each integration step.
The SIntP describes the strategy that is used for each integration step.
3.6.4.2 Integration Marginal Conditions
3.6.4.2.1 Integration and Testing Environment
The SIntP describes the environment that is used to perform and test each integration step.
The SIntP provides the lists of the tools that are used in each integration step.
3.6.4.2.2 Integration Priorities
The SIntP provides the priority allocation for each integration step, based on schedule, dependence along the integration products, risk, and the allocation of any other factors deemed important.
3.6.4.2.3 Integration Risks
The SIntP provides the risks that refer primarily to budget and schedule and other forms of risk that can be considered, at the option of the DT.
KEPCO & KHNP 3-52
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 If any integration step involves significant risk, the SIntP describes the potential problems and the preventive measures that are taken to avoid them.
3.6.4.3 Integration Procedures
A procedure is prepared which defines the integration process that is to be followed. The organization that is responsible for integration prepares the integration procedure. The procedure addresses any unique requirements imposed by the computer environment on the integration process. The procedure also addresses the recording and analysis of metrics related to integration errors (as may be required by the SQAP).
The integration may occur gradually, in a number of discrete steps throughout the implementation phase, or it may occur as a single activity. The cognizant organization determines the most appropriate approach and timing for integration, and prepares the integration procedure accordingly.
The procedure is issued prior to commencing the integration activities and considers the following items: TS
The software integration sequence is implemented in compliance with the integration procedure. The relevant practice refers to methods, procedures and management. The outcome of integration is reported to the related teams.
3.6.5 Methods/Tools
The SIntP includes the system build document that describes precisely how the system hardware and software components are combined into the specific operational system. And it describes how the system is assembled, including hardware and software component names and versions, the particular hardware components, the method by which the hardware components are connected together and to the sensors, actuators, and terminals, and the assignment of logical paths connecting software modules to hardware communication paths.
Integration tools are qualified with a degree of rigor and level of detail appropriate to the safety significance of the software which is to be created using the tools.
3.6.6 Standards
The SIntP complies with the following standards and guidelines:
IEEE Std. 1074-1995 (Reference 4.2.8), Clauses 5.3.7 and 5.3.8, as endorsed by RG 1.173 (Reference 4.1.10) NUREG/CR-6101 (Reference 4.1.11), Section 3.1.7
KEPCO & KHNP 3-53
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 3.7 Software Installation Plan
3.7.1 Purpose
The SInstP describes the general procedures for installing the software product. For any particular installation, modifications or additions may be required to account for local conditions.
The SInstP provides all of the installation requirements included as an actual plan. Installation testing is included in the system specific SInstP, STP, and/or SVVP.
The SInstP consists of the transportation and installation of software from the development environment to the installation environment. This plan includes the formal customer acceptance requirements.
This SInstP provides the guidance and the detail information to install software of the digital I&C system.
After installation is complete, the functions that could not be adequately tested in the factory are tested. When installation test is complete, the system is turned over to plant operations. It is noted that it may not be possible to adequately test some functions until plant startup.
3.7.2 Organization/Responsibilities
The utility is responsible to prepare the installation procedures, execute the Installation and prepare an installation report and the associated V&V activities of the software installation. Software developer or equipment supplier is responsible for providing information to utility that ensures that delivered software can be installed properly at the site. The site V&V engineer is responsible for performance of the V&V tasks that are identified in the software life cycle
3.7.3 Measurement
Installation quality is determined by an assessment of installation errors. When an error is identified, the cause of the error is determined. All errors are recorded and analyzed to assess the potential for similar errors.
3.7.4 Procedures
The SInstP describes completely the procedure for installing the software in the operational environment. This is a step- by-step procedure, written for the customer (contractor). Anticipated error conditions are described, with the appropriate recovery procedures. The following installation activities are categorically described in the specific SInstP: TS
KEPCO & KHNP 3-54
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 TS
3.7.5 Methods/Tools
Installation is conducted in accordance with a written installation procedure. The tools used during and after installation have industry proven records.
3.7.6 Standards
The SInstP complies with the following standards and guidelines:
IEEE Std. 1074-1995 (Reference 4.2.8), Clause 6.1, as endorsed by RG 1.173 (Reference 4.1.10) NUREG/CR-6101 (Reference 4.1.11), Section 3.1.8
KEPCO & KHNP 3-55
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 3.8 Software Training Plan
3.8.1 Purpose
The purpose of STrngP is to describe the software training activities that are used to train operators, maintenance personnel, and managers of the software system.
Training considers the following types of customer training needs: - Operator training needs - Maintenance personnel training needs - Management personnel training needs
3.8.2 Organization/Responsibilities
Training material for all trainees is prepared, or reviewed and approved, by the DT or VT.
All persons assigned in the software life cycle process are trained by qualified instructors. Instructor possesses expertise in software and digital systems, and has in-depth knowledge of the related system for their specific training area.
The training is the responsibility of utility with possible support by the engineering organization.
3.8.3 Measurement
The implementing documents of the customer training ensure that feedback is gathered and incorporated into the training process. The training programs allow for self-study or practical exams based on course objectives relevant to the task responsibilities. The training processes are reviewed periodically to ensure that they address recent operating experience and technology advances. The test results or training results obtained at the end of the training activities are measured, recorded, analyzed and reported to determine the effectiveness of the training.
3.8.4 Procedures
The following activities are executed in the software training program:
Preparation of training program
The DT determines the personnel in need for training, the category and the level of the training program, prepares the pertinent training programs and documents them.
Training is essential for operators, technical support staff, and maintenance staff. Therefore, an operator training program is required so that the operators may learn the correct ways to use the system. The training manual is an important part of the training program. It is provided by the system developer and/or the customer.
Preparation of training materials
The DT prepares the training materials to be used in the program in accordance with this STrngP. The training material for each training course includes the following items:
KEPCO & KHNP 3-56
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 - Training content and lesson plan - Documentation of training techniques and tools for training
Training materials are produced and delivered to the training location sufficiently in advance of the scheduled training activities to assure they are available at the start of training.
Implementation of the training program
Qualified instructors implement the training of personnel in accordance with this training plan including training material and equipment.
Plant personnel, including operation personnel, maintenance personnel and engineering personnel receive the following training to acquire the knowledge and capability to perform their activities:
- Lecture on outline of NPPs - Lecture on hardware including software - Knowledge of operation of system through hands-on trainings with engineering tool including access control, bypass operation etc. - Operation when system failure including plant operation and system operation has occurred. - Lecture and hands-on training of system maintenance, for example, replacement of card etc. - Training records are collected and retained for each trainee.
The training is implemented by qualified instructors in accordance with the training program and STrngP.
Training records are collected and retained for each trainee.
3.8.5 Methods/Tools
Training is executed with appropriate materials. Vendor manuals are also provided as an aid to training.
Any training aids (such as videos or CDs) are prepared, controlled and distributed in accordance with the training policy and procedure.
If practical, training is carried out on a training system which is equivalent to the actual system.
3.8.6 Standards
The SIntP complies with the following standards and guidelines:
IEEE Std. 1074-1995 (Reference 4.2.8), Clause 7.4, as endorsed by RG 1.173 (Reference 4.1.10) NUREG/CR-6101 (Reference 4.1.11), Section 3.1.10
KEPCO & KHNP 3-57
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 3.9 Software Operation and Maintenance Plan
3.9.1 Purpose
The purpose of the SOMP is to define how the system is operated at the plant and describe the process for owner’s identification of latent software errors, owner’s evaluation of the correction errors discovered.
3.9.2 Organization/Responsibility
The utility is the responsibility of the software operation and maintenance plan. The utility is responsible for operation and maintenance phase of the software life cycle.
During the project’s warranty period, equipment supplier or software developer is responsible ensuring that errors discovered by utility. The utility establishes procedures for problem reporting to the software developer or equipment supplier which is responsible for coordinating activities necessary to maintain the software, to remove latent errors, respond to new or revised requirements or to adapt the software to changes in the operating environments.
After the project’s warranty period, the utility is responsible for the overall software maintenance of the related system.
3.9.3 Risks
The utility assesses the risks associated with maintenance related software changes regarding the potential to compromise plant safety. Maintenance is executed correctly based on an established formal procedure and by qualified staff.
3.9.4 Security
Throughout the operation and maintenance phase, security management is performed as follows: TS
3.9.5 Measurement TS
KEPCO & KHNP 3-58
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 3.9.6 Procedures
3.9.6.1 Operation Phase
TS
3.9.6.2 Maintenance Phase
The DTM is responsible for coordinating activities necessary to maintain the software, to remove latent errors, respond to new or revised requirements or to adapt the software to changes in the operating environments. Software modifications include the activities of the development cycle phases as appropriate, including V&V. These activities and their documentation are limited to those portions of the program that are actually modified except that the validation phase includes testing as necessary to verify that the modifications have not caused unintended adverse effects.
The DTM is responsible for ensuring that errors reported by users or the software developer are evaluated, documented and reported to other users, and to the software developer for correction if required.
The TER is prepared to document a problem with the system. If the problem is determined by the VT to be a defect in the software, the DT notifies all users that are affected by the defect. TS
KEPCO & KHNP 3-59
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 The DTM responsible for notifying external users returns the response receipt with evidence that notice was sent to the user.
3.9.7 Methods/Tools
Software operation and maintenance is implemented in accordance with written procedures. The same tools used during the original software development process are used for operation and maintenance of the software. The detailed list of these tools for software, hardware and associated documents is included in the SOMP.
3.9.8 Standards
The SOMP complies with the following standards and guidelines:
IEEE Std. 7-4.3.2-2003 (Reference 4.2.9), Clause 5.4.2.3, as endorsed by RG 1.152, revision 3 (Reference 4.1.3) NUREG/CR-6101 (Reference 4.1.11), Section 3.1.9
KEPCO & KHNP 3-60
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 3.10 Software Safety Plan
3.10.1 Purpose
The purpose of SSP is to provide procedures and methodologies for the development, procurement, maintenance, and retirement processes of SC software to mitigate the potential of a software defect jeopardizing the health and safety of the public.
To ensure that safety I&C system software development is consistent with the defined system safety analyses, planned and documented software safety analysis activities are conducted during the basic design and overall system design of the software development life cycle.
3.10.2 Organization/Responsibilities
The DT is responsible to ensure the requirements of the SSP are followed throughout the software life cycle. The VT confirms that system documents define critical software functions, software hazards that can prevent the functions, and precautions to prevent these hazards. The DT and VT are additionally responsible and accountable for plans, schedules, procedures, methods and techniques required in the technical and administrative performance.
3.10.3 Risks
The SSP describes the method to be used to ensure that hazards which software is expected to control are resolved in an acceptable manner. In order to identify and resolve software hazards as early as possible in the project schedule, the software safety analysis is performed during each life cycle process.
The software safety analysis assures proper documentation of:
TS
The safety analysis is also referred to as a software hazards analysis.
3.10.4 Measurement
The deficiency metrics related to the SSP may be recorded and maintained together with all other deficiencies.
Metrics are periodically reported in the V&V phase summary reports.
3.10.5 Procedures
3.10.5.1 Software Safety Management
This section describes the resources, documentation, techniques and methodologies used in the development of the software. Many requirements described in Section 3.1.5 of NUREG/CR-6101 and Section 4.3 of IEEE Std. 1228 are covered by other sections of this report.
KEPCO & KHNP 3-61
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 Therefore, the description of each sub-section of the following software safety management only refers to the section numbers of other sections of this report.
3.10.5.1.1 Resources
The management develops an early understanding of the resources required to develop SC software, so that these resources are put in place when they are required. The DTM and VTM determine and assign the resources required to implement the SC software. The following resources are typically considered:
Personnel Equipment support Test materials and data Computers and other equipment Tools Financing and Schedule
The manager maintains an up-to-date resource plan and assures that the resources are made available when required.
A project schedule, which includes the software safety activities, is established and maintained to monitor progress throughout the project.
3.10.5.1.2 Staff Qualification and Training
One of the most important factors in developing reliable software is the development and use of a qualified staff. SC software needs to be prepared by carefully selected personnel who can produce a reliable product. Although staff selection is one means of establishing a capable staff, training is also a key factor in establishing and maintaining a qualified staff. In assessing the training requirements, the manager considers that:
Training needs vary by individual; Training and retraining may be needed at various project phases; Staff qualification and training need to be periodically reassessed.
The manager assures that all personnel participating in the design, implementation, test and certification of SC software are qualified to perform their assigned tasks. Since there is currently no industry sanctioned certification program for SC software personnel, the manager assesses the capabilities of candidates and appropriately selects qualified personnel based on his experience.
In determining whether any candidate is qualified, the DTM considers whether the candidate:
Understands the system and its potentially hazardous effects; Understands the job to be performed; Has, or is capable of obtaining working knowledge of system software and tools required to do the job;
KEPCO & KHNP 3-62
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 Possesses the combination of skills and knowledge to perform the job through a proper level of formal education, supplemental training, and experience; Understands the related SQAPs, SCMPs, and SVVPs; Is able to produce reliable software, good documentation, and can implement required QA practices.
Throughout a project, requirements and tasks may change. These changes, which are sometimes subtle, may result in previously qualified personnel being unqualified for the changed work. Therefore, the manager periodically reassesses the qualifications of all personnel working on SC software, particularly when specific changes to the project become known. The manager may direct additional training before the changes are effective, in order to maintain a fully qualified project team.
3.10.5.1.3 Software Life Cycle
The phases of the software life cycle and assented activities for SC software are described in SVVP. The software life cycle plan to comply with Section 3.1.5 of Reference 4.1.11 and Section 4.3.4 of IEEE Std. 1228-1994 is described in other sections of this report.
3.10.5.1.4 Document Requirements
The documentation for SC software is prepared in accordance with the requirements in SQAP, and incorporates the software safety documentation requirements. The change and approval process for software SC portions of the project documentation is the same as for other documentation as specified in SQAP.
3.10.5.1.5 Software Safety Program Records
Software safety program records are generated, maintained and preserved.
3.10.5.1.6 Software Project Management
The SMP identifies project organization and management activities that are used to coordinate both the system development activities and the QA activities to ensure that both are done according to prescribed procedures and that adequate resources are allocated for their proper execution.
3.10.5.1.7 Software Configuration Management
The DTM is responsible for developing its own SCMP, prepared according to Reference 4.2.2 to satisfy the unique requirements of software development process. It addresses the following areas as a minimum:
Description of software covered Change control procedures Documentation required Baseline identification and configuration
The SCMP for each DT covers the following phases of life cycle:
KEPCO & KHNP 3-63
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 Concept phase Requirements phase Design phase Implementation phase Test phase
The formal SCM activities during the installation and checkout life cycle phase is the responsibility of the Utility.
3.10.5.1.8 Software Quality Assurance
The SQAP describes the requirements and methodology to be followed by the DT and VT in developing, acquiring, using and maintaining software to be used for the design and operation of software systems. This SQAP is compliant to Reference 4.2.10.
3.10.5.1.9 Software Verification and Validation
The software V&V documentation is described in Section 3.3.
3.10.5.2 Software Safety Analysis
3.10.5.2.1 Software Safety Analysis Preparation TS
KEPCO & KHNP 3-64
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 TS
3.10.5.2.2 Software Safety Requirements Analysis
In preparing the Software Requirements, the software developer considers techniques that can avoid a hazardous condition. The result of the requirements phase may be a set of required or forbidden design, coding or testing techniques. The requirements phase may also identify tests to be performed or the implementation of certain hazard recovery techniques. When there are more than one software system environment incorporated in the whole system under development, IEEE Std. 1228 requires that a different software system analysis may be performed.
3.10.5.2.3 Software Safety Design Analysis
The activities in Section 3.10.5 provide reasonable assurance that each software safety requirement is satisfied by the software safety design. A safety analysis is performed on the software design of any computer-controlled reactor protection system. The analyses are as follows:
Design Logic Analysis Design Data Analysis Design Interface Analysis Design Constraint Analysis Timing and Sizing Analysis
3.10.5.2.4 Software Safety Code Analysis
The activities in Section 3.10.5 provide reasonable assurance that each software safety design element is satisfied by the software safety code. A safety analysis is performed to verify that the implementation correctly and consistently incorporates the system safety requirements, identifies safety critical software module and data structures, and detects errors that might results in violations of the system safety requirements.
3.10.5.2.5 Software Safety Test Analysis
The activities in Section 3.10.5 provide reasonable assurance that each system and software safety requirement is tested. The test analysis ensures the comprehensiveness of the integration testing effort. The system testing (FAT) ensures that the correct version of all hardware. Manual tests are conducted to confirm operability of all portions of the system that are not automatically tested, such as system binary/analog inputs and outputs.
KEPCO & KHNP 3-65
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 3.10.5.2.6 Software Safety Change Analysis
The activities in Section 3.10.5 provide reasonable assurance that changes to SC software do not create, impact a previously resolved, or exacerbate a currently existing hazard, and does not adversely affect any SC software design elements.
3.10.6 Methods/Tools
Tools may be used for specific safety analysis for the automation of repetitive or time consuming tasks.
Traceability of the identified hazard mitigation requirements are documented using the RTM as described in the SVVP.
3.10.7 Standards
The SSP complies with the following standards and guidelines:
IEEE Std. 1228-1994 (Reference 4.2.12) RG 1.173 (Reference 4.1.10), Section C.3 NUREG/CR-6101 (Reference 4.1.11), Sections 3.1.5, 3.2.2, 3.3.3, 3.4.1, 3.5.2, 3.6.1, 3.7.5, and 3.8
KEPCO & KHNP 3-66
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 3.11 Software Test Plan
3.11.1 Purpose
The purpose of the STP is to describe the scope, approach, resources, and schedule for the software testing activities of the project. It identifies the test items, the requirements to be tested, the testing tasks, and the required resources to perform these tasks.
It also complements the SVVP (described in Section 3.3) and provides additional details and minimum information requirements for the test activities:
3.11.2 Organization/Responsibilities
The organization is described in section 2.2.1.
Each testing is prepared and performed by the responsible entity (See Table 3-3). The responsible entity establishes test methods and procedures. The responsible entity selects test input conditions and defines test output acceptance criteria in the form of documentation, and test practices. The responsible entity is responsible for defining and implementing practical tests.
The VT verifies all software testing activities, including test specifications, test procedures and test reports. This verification ensures adequate test coverage for all system requirements, including operation under failure conditions.
3.11.3 Security
The SDOE for the software testing activities as described in the STP and the SVVP is assured in accordance with RG 1.152 (Reference 4.1.3). The detailed discussion on security issues is described in the Section 3.12.
3.11.4 Measurement
The errors discovered during the validation testing are identified through the use of TER forms so that all errors discovered can be resolved during the validation testing and that the number of errors discovered can be tracked for error discovery metric reporting. The overall goal is to identify a decreasing number and severity of errors as the testing progresses from validation testing to SAT.
Validation testing errors are reported through the use of TERs and the number and severity are identified for error discovery metric reporting.
Software errors discovered after validation testing and before SAT are tracked through the use of TERs and the number and severity are identified for error discovery metric reporting.
A key measure is the number and severity of anomalies identified by the VT during V&V activities. V&V anomalies are measured, recorded, analyzed, and reported.
KEPCO & KHNP 3-67
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 3.11.5 Procedures
3.11.5.1 Test Documentation
3.11.5.1.1 Test Specifications
Tests are designed to determine whether software contains an error and whether all the required functions are included. Test specifications include the following:
Test items to be tested Features to be tested Features not to be tested Approaches to be adopted The test cases and their descriptions Expected results of the test cases with acceptance criteria (pass/fail) Test Environment (test equipment and test tools) CM for modifications Scope of responsibility Approval
Test results are documented in a test report. The report can consist of a completed copy of the test procedure with all blanks information filled out.
A timetable is provided taking activities of other designing sectors into consideration, including procedures for implementing respective test items.
3.11.5.1.2 Test Designs
Test designs include the following information:
Test design identifier Features to be tested Approach refinements Test identification Feature pass/fail criteria
3.11.5.1.3 Test Cases
Test case documentation includes the following information:
Test case identifier Related Test Specifications and Test Designs Input specifications Output specifications
KEPCO & KHNP 3-68
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 Environmental needs Special procedural requirements Interface dependencies
3.11.5.1.4 Test Procedures
Test procedures include the following information:
Test procedure identifier Purpose Test Cases to be executed Special requirements Procedure steps
3.11.5.1.5 Test Reports
Testing activities and test results are documented as the test report. It also contains evaluations on the test results. Any skipped test steps are clarified with the reasons for skips. Handwritten parts of the report, modified by the tester, are considered as a part of the test report. TER log and copies of the TERs are attached to the report. Any outstanding TERs are brought to the attention of DTM and/or VTM.
Test reports include the following information:
Test report identifier Summary Variances Comprehensive assessment Summary of results List of V&V Anomaly Reports Evaluation Summary of activities Test Log - Test log identifier - List of tools and equipment used - Description - Activity and event entries Approvals
V&V anomaly reports typically are prepared separately from test reports, as described in the SVVP.
KEPCO & KHNP 3-69
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 3.11.5.2 Tests to be performed
3.11.5.2.1 Module / Unit Test
The objective of module test or unit test is to verify that executable code of each program behaves as specified in the SDD and ensure that the executable code of each program does not perform unintended functions.
3.11.5.2.2 Integration Test
The objective of integration test is to verify that the software modules integrated together meet the requirements specified in the SRS with target hardware and pre-developed software. And the test finds errors in handling stress conditions, timing, fail-safe features, error conditions, and error recovery.
Integration Tests are designed, in accordance with the SIntP, to check all software unit interfaces and all interfaces between software and hardware.
3.11.5.2.3 System (Factory Acceptance) Test
The objective of system test (FAT) is to verify that the entire executable code, including newly developed code, modified code, and any commercial or existing code, that have been integrated with the target hardware, successfully functions and fulfills all the requirements specified in the SysRS.
A comprehensive system test (FAT) is conducted for any safety I&C system. The system test (FAT) evaluates the system performance in an environment that is real, or as close to real as can reasonably be created. Typically this environment is at the factory. A fully integrated system with the hardware and software, that is similar to the site environment, is required. The system test (FAT) process demonstrates and proves correct and successful implementation of safety requirements and correct functioning of hardware-software combined system.
System test (FAT) includes the following tasks:
TS
System test (FAT) procedure is prepared based upon the requirements of the design documents. The test specifications (if any) and procedures include test cases including the full range of data expected of the system.
KEPCO & KHNP 3-70
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 3.11.6 Record Keeping
All test documents described in the SVVP and STP are managed under the CM system in accordance with the SCMP. All revisions of the test documents are retained as QA records in accordance with QAM.
3.11.7 Methods/Tools
The test facilities, methods, techniques and tools to facilitate to perform the testing are identified in the test procedures. The description of detailed steps to carry out the testing including acceptance criteria is included in the test procedures.
3.11.8 Standards
The STP complies with the following standards and guidelines:
IEEE Std. 829-1983 (Reference 4.2.3), as endorsed by RG 1.170 (Reference 4.1.7) IEEE Std. 1008-1987 (Reference 4.2.5), as endorsed by RG 1.171 (Reference 4.1.8)
KEPCO & KHNP 3-71
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 3.12 Secure Development and Operational Environment
3.12.1 System Design Features for Security
The safety I&C system is designed with features that minimize the potential for security vulnerabilities. The system uses a combination of personnel access controls, and hardware and software design features to protect the safety-related software from unauthorized alteration and to protect the deterministic performance of the safety I&C system. This is achieved through a combination of features within the common digital platform and features within the system applications. These features prevent the system from adverse operating caused by either intentional or unintentional sources. RG 1.152 security guidance is implemented during the software development process.
This section describes the design features that prevent unintended changes to hardware or software code, and to detect those unintended changes if they occur. These design features are based on the assumption that potential intruders have a detailed knowledge of the safety I&C system, and that unintended functions can be included during initial development or through unintended modifications.
3.12.1.1 Physical Access Controls
The hardware or software of the safety I&C system can only be altered by physically accessing the safety I&C system. Security controls that prevent changes through electronic access are described in Sections 3.12.1.2 and 3.12.1.3.
Personnel access to the safety I&C system is controlled by the following: TS
3.12.1.2 Electronic Access Controls
The following design features are applicable to all of the electronic interfaces: TS
KEPCO & KHNP 3-72
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 3.12.1.3 Software Alteration Controls TS
3.12.1.4 Deterministic Performance Controls
Deterministic behavior is a key attribute of the safety I&C system that ensures predictable performance for all abnormal plant conditions. This section describes the key features of the safety I&C system that achieve deterministic performance, the security design features that protect that performance against external threats, and the security features that ensure any disruption to deterministic performance is detected and alarmed.
Deterministic performance is achieved by the following key design features of the common digital platform operating system, which is unaffected by the application software: TS
KEPCO & KHNP 3-73
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 TS
The following security design features of the common digital platform operating system protect the deterministic performance of the safety I&C system against external threats: TS
The following security design features of the common digital platform detect and alarm disturbance to the deterministic performance of the safety I&C system if it occurs:
TS
3.12.2 Development Processes for Security TS
KEPCO & KHNP 3-74
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 3.12.2.1 Concept Phase
The following generic defenses against undesired software changes are applicable throughout each phase of the software development life cycle process: TS
These security processes are checked periodically by the QA organization, which is independent of the Engineering organization.
3.12.2.2 Requirements Phase
During this phase, two kinds of requirements specifications are developed:
KEPCO & KHNP 3-75
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 System requirements specification
The SysRS provides overall system configuration, design considerations, and operational requirements. The SysRS provides the necessary detail to develop software specifications.
Software requirements specification
During this phase, specifications for software are produced. The software specification involves the functions and architecture of the software, including key partitions and interfaces. The functional design is documented primarily in logic diagrams and graphical screen display. TS
3.12.2.3 Design Phase
During this phase the SDD is created. The SDD provides the necessary system and functional design detail, software specifications and software interface requirements to implement all system functions, including all security features described in Section 3.12.1. The SDD reflects
KEPCO & KHNP 3-76
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 the requirements documented in the SysRS and SRS, which is provided from the system requirements phase. TS
3.12.2.4 Implementation Phase
Software code is created during the implementation phase for the common digital platform and for the software that is implemented on each target processor of the common platform
KEPCO & KHNP 3-77
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 for each safety I&C system. The software is documented in source code listings and in graphical diagrams that show the interconnection of various common platform software function blocks.
The software code reflects the detailed designs documented in the SDD, which is provided from the design phase. Software is configured in units that represent logical groupings of platform or application functions. TS
KEPCO & KHNP 3-78
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 3.12.2.5 Test Phase
During this phase common digital platform operating system software is integrated with the common digital platform hardware, and application software is integrated with the common digital platform hardware and software for each system. The test phase covers two types of testing:
Integration Testing
This testing confirms that the software modules, which are integrated together with the actual common platform hardware, meet the requirements specified in the SRS. The testing looks for errors in the software, errors in the hardware and software interfaces, errors in timing and fail- safe features, errors in handling self-test detected failure conditions, and errors in failure recovery. Integration tests are conducted on multiple units that form a logical test entity or subsystem.
System Testing (FAT)
This is a test of the fully integrated hardware and software for a complete system to validate that the system meets the requirements specified in the SysRS. The system test is conducted with all connected system interfaces, including those that pose security threats. The system testing demonstrates that all requirements in the SysRS function correctly in the final integrated system. FAT is the final test performed by the equipment supplier, prior to delivery of the equipment. TS
KEPCO & KHNP 3-79
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 TS
3.12.2.6 Document and Software Storage Security Measures TS
3.12.3 Security Processes for COTS Software TS
KEPCO & KHNP 3-80
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 TS
KEPCO & KHNP 3-81
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 4.0 Applicable Codes and Regulations
In this section, specific references referred in this report and other general applicable codes and regulations are described. Each reference is the latest revision, unless listed specifically.
4.1 Regulatory Guidance and Codes
4.1.1 NUREG-0800, BTP 7-14, Revision 5, “Guidance on Software Reviews for Digital Computer-Based Instrumentation and Control System,” March 2007.
4.1.2 10 CFR 50, Appendix B, “Quality Assurance Criteria for Nuclear Power Plants and Fuel Reprocessing Plants.”
4.1.3 Regulatory Guide 1.152, Revision 3, “Criteria for Use of Computers in Safety Systems of Nuclear Power Plants,” July 2011.
4.1.4 Regulatory Guide 1.153, Revision 1, “Criteria for Safety Systems,” June 1996.
4.1.5 Regulatory Guide 1.168, Revision 1, “Verification, Validation, Reviews, and Audits for Digital Computer Software Used in Safety Systems of Nuclear Power Plants,” February 2004.
4.1.6 Regulatory Guide 1.169, Revision 0, “Configuration Management Plans for Digital Computer Software Used in Safety Systems of Nuclear Power Plants,” September 1997.
4.1.7 Regulatory Guide 1.170, Revision 0, “Software Test Documentation for Digital Computer Software Used in Safety Systems of Nuclear Power Plants,” September 1997.
4.1.8 Regulatory Guide 1.171, Revision 0, “Software Unit Testing for Digital Computer Software Used in Safety Systems of Nuclear Power Plants,” September 1997.
4.1.9 Regulatory Guide 1.172, Revision 0, “Software Requirements Specifications for Digital Computer Software Used in Safety Systems of Nuclear Power Plants,” September 1997.
4.1.10 Regulatory Guide 1.173, Revision 0, “Developing Software Life Cycle Processes for Digital Computer Software Used in Safety Systems of Nuclear Power Plants,” September 1997.
4.1.11 NUREG/CR-6101, “Software Reliability and Safety in Nuclear Reactor Protection Systems,” June 1993.
4.1.12 NUREG/CR-6430, “Software Safety Hazard Analysis,” February 1996.
4.1.13 Regulatory Guide 1.97, Revision 4, “Criteria for Accident Monitoring Instrumentation for Nuclear Power Plants,” June 2006.
4.2 Standards endorsed by Regulatory Guides
4.2.1 IEEE Std. 603-1991, “IEEE Standard Criteria for Safety System for Nuclear Power Generating Stations.”
4.2.2 IEEE Std. 828-1990, “IEEE Standard for Software Configuration Management Plans.”
4.2.3 IEEE Std. 829-1983, “IEEE Standard for Software Test Documentation.”
KEPCO & KHNP 4-1
KEPCO & KHNP SOFTWARE PROGRAM MANUAL APR1400-Z-J-NR-13003-NP, Rev.0 4.2.4 IEEE Std. 830-1993, “IEEE Recommended Practice for Software Requirements Specifications.”
4.2.5 IEEE Std. 1008-1987, “IEEE Standard for Software Unit Testing.”
4.2.6 IEEE Std. 1012-1998, “IEEE Standard for Software Verification and Validation.”
4.2.7 IEEE Std. 1028-1997, “IEEE Standard for Software Reviews and Audits.”
4.2.8 IEEE Std. 1074-1995, “IEEE Standard for Developing Software Life Cycle Processes.”
4.2.9 IEEE Std. 7-4.3.2-2003, “IEEE Standard Criteria for Digital Computers in Safety Systems of Nuclear Power Generating Stations.”
4.2.10 IEEE Std. 730-2002, “IEEE Standard for Software Quality Assurance Plans.”
4.2.11 IEEE Std. 1058-1998, “IEEE Standard for Software Project Management Plans.”
4.2.12 IEEE Std. 1228-1994, “IEEE Standard for Software Safety Plans.”
4.2.13 EPRI TR-106439, “Guidance on Evaluation and Acceptance of Commercial Grade Digital Equipment for Nuclear Safety Stations.”
4.2.14 ANSI/IEEE Std, 1042-1987, “IEEE Guide to Software Configuration Management (reaffirmed in 1993).”
4.3 Other Documentation
4.3.1 APR1400 DC Quality Assurance Manual.
KEPCO & KHNP 4-2