ND-19-0665, WCAP-15927-NP, Design Process for AP1000 Common Q Safety Systems, Revision 7 (Public Version)
| ML19171A095 | |
| Person / Time | |
|---|---|
| Site: | Vogtle  |
| Issue date: | 03/21/2019 |
| From: | Southern Nuclear Operating Co |
| To: | Office of New Reactors |
| Shared Package | |
| ML19171A096 | List:
|
| References | |
| ND-19-0665 WCAP-15927-NP, Rev 7 | |
| Download: ML19171A095 (34) | |
Text
Southern Nuclear Operating Company ND-19-0665 Vogtle Electric Generating Plant (VEGP) Units 3 and 4 WCAP-15927-NP, "Design Process for AP1000 Common Q Safety Systems," Revision 7 (Public Version)
(Enclosure 9 consists of 33 pages, plus this cover page)
SVP _SV0_005470 WCAP-15927-NP APP-GW-J1 R-001 Revision 7 Westinghouse Non-Proprietary Class 3 Design Process for AP1000 Common Q Safety Systems
@Westinghouse October 2018
- This record was final approved on 10/30/2018 7:41 :10 AM. (This statement was added by the PRIME system upon its validation)
May 23, 2019 Page 1 of 33 SVP _SV0_005470 WCAP-15927-NP APlOOO TABLE OF CONTENTS LIST OF TABLES....................................................................................................................................... iii LIST OF FIGURES..................................................................................................................................... iii REVISION HISTORY................................................................................................................................. iv REVISION HISTORY (cont.)....................................................................................................................... v 1
INTRODUCTION AND SCOPE................................................................................................. 1-1 2
DEFINITIONS.................................................................................... :......................................... 2-1 2.1 ACRONYMS................................................................................................................... 2-1 2.2 TERMS............................................................................................................................ 2-2 3
APl 000-SPECIFIC APPLICATION DEVELOPMENT.............................................................. 3-1 3.1 CONCEPTUAL PHASE.................................................................................................. 3-2 3.2 SYSTEM DEFINITION PHASE.................................................................................... 3-2 3.2.1 Platform RequirementAnalysis....................................................................... 3-2 3.2.2 System Requirements Analysis/Functional Design......................................... 3-3 3.2.3 System Architectural Design........................................................................... 3-5 3.2.4 Software Requirements Analysis..................................................................... 3-6 3.2.5 System Hardware Requirements..................................................................... 3-8 3.3 SOFTWARE DESIGN PHASE....................................................................................... 3-8 3.4 HARDWARE DESIGN PHASE...................................................................................... 3-9 3.5 SOFTWARE IMPLEMENTATION PHASE................................................................. 3-10 3.5.1 Final RSED.................................................................................................... 3-10 3.5.2 Final Software Definition Document............................................................ 3-10 3.6 HARDWARE IMPLEMENTATION (ASSEMBLY) PHASE....................................... 3-1 l
- 3. 7 SYSTEM INTEGRATION PHASE.............................................................................. 3-11 3.8 INSTALLATION PHASE............................................................................................. 3-ll 3.9 ALTERNATIVE METHODS TO PROCESSES DEFINED IN WCAP-16096-P-A.... 3-11 3.10 ALTERNATIVES TO PROCESSES AND DESCRIPTIONS INWCAP-16097-P-A.. 3-11 4
REFERENCES............................................................................................................................. 4-1 4.1 INDUSTRY STANDARDS AND CODES.....................................................................4-1 4.2 WESTINGHOUSE DOCUMENTS................................................................................ 4-1 APP-GW-JlR-001 Revision 7 ii
- This record was final approved on 10/30/2018 7:41 :10 AM. (This statement was added by the PRIME system upon its validation)
May 23, 2019 Page 2 of 33 SVP _SV0_005470 WCAP-15927-NP APlOOO Table 3-1 Table 3-2 Figure 3-1 Figure 3-2 LIST OF TABLES Alternative Methods to the Common Q SPM................................................................ 3-12 Alternative Methods to the Common Q Topical Report................................................ 3-17 LIST OF FIGURES Development Process..................................................................................................... 3-23 Correlation to Standard Life Cycle Phase...................................................................... 3-24 APP-GW-JlR-001 Revision 7 iii
- This record was final approved on 10/30/2018 7:41 :10 AM. (This statement was added by the PRIME system upon its validation)
May 23, 2019 Page 3 of 33 SVP _SV0_005470 WCAP-15927-NP Revision Author 0
Thomas M. Hayes 1
Steven W. Gore 2
WarrenR.
Odess-Gillett 3
WarrenR.
Odess-Gillett 4
Matthew A. Shakun APP-GW-JlR-001 Revision 7 APlOOO REVISION HISTORY RECORD OF CHANGES Description Completed Original issue.
9/18/02 Class 3 DCP changes as detailed below:
11/21/08 Added further definition of the Concept Phase (Section 1).
Added additional description of life cycle (Section 1 ).
Removed descriptions also in Common Q NRC docketed reports (Section 1 ).
Added missing acronyms and terms (Section 2).
Merged the application and platform design life cycle descriptions into one section to eliminate redundant descriptions common to both (Section 3 and throughout document).
Added clarification that critical anomalies had to be completed for each phase (Section 3).
Added Functional Design to System Requirements (Section 3.2).
Project Master Documents now referred to as Document Index (Section 3.1).
Updated Figure 3-1, "Development Process," with additional V&V methods.
Updated reference document numbers (throughout I
document and Section 4).
Removed explanation of Platform System Design Phase because it is not applicable to APlOOO PMS since it describes generic architecture (Section 4 of Rev. 0).
Changes are Class 3 as per NSNP 3.4.1. Updated 6/3/09 Figure 3-1 perRAI response RAI-SRP 7.l-ICE-10, reference the SPM for the operation, maintenance and retirement software life cycle phases, and technical editing changes Updated to reference the newly NRC-approved Common 4/10/13 Q' Topical Report (WCAP-16097-P-A, Rev. 3).
Updated to reference the newly NRC-approved Software Program Manual for Common Q Systems (WCAP-16096-P-A, Rev. 4).
Updated Section 3.1 to remove the term Document Index.
The following change was made to address 9/22/15 APP-GW-GEE-4380 and CAPAL 100320452:
Updated to include alternate processes to WCAP-16096-P-A, Rev. 4, "Software Program Manual for Common Q' Systems" and WCAP-16097-P-A, Rev. 3, "Common Qualified Platform Topical Report" IV
- This record was final approved on 10/30/2018 7:41 :1 O AM. (This statement was added by the PRIME system upon its validation)
May 23, 2019 Page 4 of33 SVP _SV0_005470 WCAP-15927-NP Revision Author 4 (cont.)
Matthew A. Shakun 5
Matthew A. Shakun 6
Matthew A. Shakun 7
Matthew A. Shakun APP-GW-JlR-001 Revision 7 REVISION HISTORY (cont.)
RECORD OF CHANGES (cont.)
Description The following editorial changes were made:
Section 2.1 was updated to fix the acronym for AMPL Sections 3 and 4 were updated to fix the title for IEEE Std. 1074-1995.
Reference 4.2.3 was deleted since it is not being cited in the document.
The following changes were made to address APP-GW-GEE-4380 and CAPAL 100405203:
Updated SPM alternative methods in Table 3-1 per APP-GW-GF-115; Rev. 0.
The following changes were made to address APP-GW-GEE-4380 and CAPAL 100444282:
Updated SPM alternative methods in Table 3-1 to remove alternative related to site test planning.
The following changes were made to address APP-FSAR-GEF-045:
Updated Table 3-2 to add alternative design descriptions to the Common Q Topical Report APlOOO Completed 9/22/15 9/8/16 2/17/17 See PRIME V
- This record was final approved on 10/30/2018 7:41 :10 AM. (This statement was added by the PRIME system upon its validation)
May 23, 2019 Page 5 of 33 svP _svo_oos470 WCAP-15927-NP APlOOO 1
INTRODUCTION AND SCOPE This document defines the process for system-level design, software design and implementation, and hardware design and implementation for the APlOOO protection and safety monitoring system development. This document supplements WCAP-16096-P-A, "Software Program Manual for Common Q' Systems" (Reference 4.2.1 ). Project definition activities are described in this document as a Conceptual Phase (see Section 3.1). The Conceptual Phase is a preparatory phase before the system design begins; it is described here because it forms the management and technical baseline for the development activities.
The objective of the development process is the production of a high quality instrumentation and control (I&C) system that is to be used for the AP 1000 protection and safety monitoring system. The design of the system is derived from functional and other requirements applicable to AP 1000 (in addition to general requirements that may apply to all similar applications).
The functional requirements of the software are, for the most part, a direct derivation of the system functional requirements. The end product of application development is an operating I&C system, so the life cycle extends through the retirement phase (the operation, maintenance and retirement phases are sufficiently covered in Reference 4.2.1 ).
The Common Q' platform consists primarily of the Asea Brown Boveri, Inc. (ABB) Advant Controller 160 (AC160) hardware and software product line, including the Advant development tools.
The development of the AC 160 hardware and software and Advant tools is outside the scope of this document. The AC 160 product line is developed commercially, and is qualified for use in Common Q applications by a process of commercial dedication. The commercial dedication process is defined in WCAP-16097-P-A, "Common Qualified Platform Topical Report" (Reference 4.2.2). The Common Q platform also has certain generic hardware and software modules that are developed by Westinghouse specifically for safety system applications and that are reusable for multiple systems of various types. The development of these reusable, generic modules is integrated into the life cycle process as described in this document.
APP-GW-JlR-001 Revision 7 1-1
- This record was final approved on 10/30/2018 7:41 :10 AM. (This statement was added by the PRIME system upon its validation)
May 23, 2019 Page 6 of 33 SVP _SV0_005470 WCAP-15927-NP 2
2.1 ABB AC160 AFlOO AMPL CHT CIT DCD DI EMC EST HSI HSL l&C 1/0 PMST RSED RTA RTM SAT SDD SDS SIT SRS SSD V&V DEFINITIONS ACRONYMS Asea Brown Boveri, Inc.
Part of the ABB Advant open control system family product line Advant Fieldbus I 00 ABB Master Programming Language Cabinet Hardware Test Channel Integration Test Design Control Document Document Index Electromagnetic Compatibility Element Software Test Human System Interface High Speed Datalink Instrumentation and Control Input/Output Processor Module Software Test Reusable Software Element Document Requirements Traceability Analysis Requirements Traceability Matrix Site Acceptance Testing Software Design Description System Design Specification System Integration Test Software Requirements Specification System Specification Document Verification and Validation APlOOO Advant is a trademark or registered trademark of its respective owner. Other names may be trademarks of their respective owners.
APlOOO and CommonQ are trademarks or registered trademarks of Westinghouse Electric Company LLC, its affiliates and/or its subsidiaries in the United States of America and may be registered in other countries throughout the world. All rights reserved. Unauthorized use is strictly prohibited. Other names may be trademarks of their respective owners.
All other product and corporate names used in this document may be trademarks or registered trademarks of other companies, and are used only for explanation and to the owners' benefit, without intent to infringe.
APP-GW-JlR-001 Revision 7 2-1
- This record was final approved on 10/30/2018 7:41 :10 AM. (This statement was added by the PRIME system upon its validation)
May 23, 2019 Page 7 of33 SVP _SV0_005470 WCAP-15927-NP APIOOO 2.2 TERMS Advant An ABB open control system family product line.
CommonQ Data Highway Datalink V&V APP-GW-JIR-001 Revision 7 Common Qualified Platform - a safety system l&C platform as defined in WCAP-16097-P-A, "Common Qualified Platform Topical Report" (Reference 4.2.2).
A serial digital communications circuit that provides communications among several devices.
A hardware link used for unidirectional or bi-directional communications between two process modules.
Verification and validation performed by an organization that is technically, managerially, and financially independent of the development organization.
2-2
- This record was final approved on 10/30/2018 7:41:10 AM. (This statement was added by the PRIME system upon its validation)
May 23, 2019 Page 8 of 33 SVP _SV0_005470 WCAP-15927-NP APlOOO 3
APlOOO-SPECIFIC APPLICATION DEVELOPMENT This section defines the process that is followed in the design of the APlOOO protection and safety monitoring system and in the design and implementation of application hardware and software that are applied to APl 000. The general relationship of hardware, software, and system verification and validation (V & V) (including testing) to this development process is shown, but the details are defined by the V & V Plan.
The following phases occur in the development of the APl 000 protection and safety monitoring hardware and software:
- l.
Conceptual (Project Definition)
- 2.
System Definition
- 3.
Software Design
- 4.
Hardware Design
- 5.
Software Implementation
- 6.
Hardware Implementation
- 7.
System Integration
- 8.
Installation Note that testing activities are defined as part of the V &V process.
Figure 3-1 illustrates the relationship of the application development phases to each other and to the V & V process. It also shows the outputs of each phase. The activities and products of these phases are described in the remainder of Section 3. The flow of activities shown in Figure 3-1 is intended to expand on the classic "waterfall" lifecycle model. These activities may be both iterative and overlapping. In particular, because of the constraints of I&C projects, and considering the distributed character of the AP 1000 I&C systems, work may commence on a given development phase before preceding phases are complete. For example, it is not necessary for the documentation of system functional requirements to be finished before software design and implementation can start on parts of the system for which the requirements have been defined. However, for a given development phase, all critical anomalies related to that phase must be resolved before the completion of that phase.
Figure 3-2 illustrates the relationship of the development phases defined in this document to the phases (or processes) defined in other documents, specifically IEEE Standard 1074-1995, "IEEE Standard for Developing Software Life Cycle Processes" (Reference 4.1.1); IEEE/EIA 12207.0-1996, "Industry Implementation oflnternational Standard ISO/IEC 12207: 1995 (ISO/IEC 12207) Standard for Information Technology-Software Life Cycle Processes" (Reference 4.1.2); and WCAP-16096-P-A, "Software Program Manual for Common Q' Systems" (Reference 4.2.1).
APP-GW-JlR-001 Revision 7 3-1
- This record was final approved on 10/30/2018 7:41 :10 AM. (This statement was added by the PRIME system upon its validation)
May 23, 2019 Page 9 of 33 SVP _SV0_005470 WCAP-15927-NP APIOOO 3.1 CONCEPTUAL PHASE The major tasks of the Conceptual, or Project Definition, Phase are project management planning and project baselining.
The project execution strategy is established and documented. Resources, personnel, and organizational interfaces and dependencies are identified. Planning for schedule, costs, risk management, communication, and project closure is performed. Requisite processes are identified, and may include acquisition, supply, development, operation, and maintenance, and the supporting processes of configuration management, quality assurance, safety, verification, validation, and problem resolution.
The technical baseline is established and documented. Project baseline information typically includes:
Definition of the scope of the development APlOOO Design Control Document (DCD)
System Specification Documents (SSDs)
Safety classification of all parts of the system included in the scope of development Plant documentation and databases Plant-wide I&C requirements Applicability of codes and standards, including decomposition of key codes and standards to specific requirements 3.2 SYSTEM DEFINITION PHASE There are three main tasks in the system definition phase-system requirements analysis, system architectural design, and software requirements analysis. These three tasks overlap in their execution, and there may be considerable iteration among them. The output of this phase is a System Requirements/Functional Design document, a System Design Specification (SOS), and a Software Requirements Specification (SRS).
3.2.1 Platform Requirement Analysis The Common Q platform is analyzed against the requirements for the APIOOO protection and safety monitoring system. Any modifications or additions to the Common Q platform are identified. These modifications or additions become first-time engineering projects that follow the same design process as described herein.
APP-GW-JIR-001 Revision 7 3-2
- This record was final approved on 10/30/2018 7:41 :10 AM. (This statement was added by the PRIME system upon its validation)
May 23, 2019 Page 10 of 33 SVP _SV0_005470 WCAP-15927-NP APlOOO 3.2.2 System Requirements Analysis/Functional Design In this task, the project technical baseline (Section 3.1) is analyzed to specify the system requirements.
This task produces the System Requirements document. Information in the System Requirements document includes system design requirements, system functional requirements (including function-related setpoints, and constants), system interface requirements, and human system interface (HSI) requirements. Detailed requirements for the interface of individual external signals and communications data are documented in an external signal database and an external communications database.
3.2.2.1 System Design Requirements The system design requirements comprise the overall requirements and constraints for the system design, aside from the specific system functions and specific interface signals. The application System Requirements document incorporates, by reference, the platform system design requirements and identifies additions and/or exceptions that apply specifically to AP 1000. The system design requirements include the following categories of requirements:
Applicability of codes and standards, either in whole, or in part, or as guidance (which may be defined by reference to the applicability documented in the technical baseline)
General design requirements: design basis, single failure criteria, integrity, independence, maintenance, manual capabilities, information display, access control, identification, calibration capabilities, reliability, and availability Hardware qualification: environmental, electromagnetic compatibility (EMC), and seismic Power and grounding External interface capabilities Performance requirements: time response, accuracy, and signal noise Test and diagnostic capabilities Design constraints and objectives 3.2.2.2 System Functional Requirements The system functional requirements provide a complete definition of the sense and command features within the scope of the system (including non-safety functions, such as provision of data to the plant information system, control interlocks, information displays, etc.). They include the following categories ofrequirements. The requirements are provided by a combination of textual description, logic diagrams, mathematical formulas, and tables.
Safety functions and corresponding protective actions (exact definition of the required response of the system for all design basis events)
APP-GW-JlR-001 Revision 7 3-3
- This record was final approved on 10/30/2018 7:41 :10 AM. (This statement was added by the PRIME system upon its validation)
May 23, 2019 Page 11 of33 svP _svo_oos470 WCAP-15927-NP APlOOO Non-safety-related functions (e.g., control interlocks, data to non-safety displays and systems)
Performance requirements associated with functions (time response, accuracy)
Setpoints and constants associated with functions (fixed value or range of adjustment, hysteresis)
Response to failures and out-of-range conditions (internal and external)
Functional diversity Signal diversity Separation and isolation requirements for individual functions or interfaces (e.g., assignment of signals and functions to separation divisions)
Required auxiliary features, such as:
Maintenance bypass and trip logic Automatic, manual, and/or continuous test capabilities Maintenance functions.
3.2.2.3 System Interface Requirements The system interface requirements define the interface between the protection system being specified and the rest of the physical plant. The requirements include the following categories:
System scope ( defines what is included in the scope of supply)
System boundaries:
Mechanical system (the plant process; generally, however, the actual boundary between the process and the protection system is the I&C boundary)
Electrical system (power and grounding)
I&C systems ( a general description of the signal interfaces-detailed definition of all external signals is recorded in the external interface database)
Functional interfaces (description of the external systems with which the protection system interfaces, and identification of the parameters, controls, indications, and functions that are monitored or actuated)
Requirements for associated equipment ( e.g., time response of actuated equipment)
Isolation requirements for external interfaces ( e.g., individual requirements for Class lE)
APP-GW-JlR-001 Revision 7 3-4 May 23, 2019 Page 12 of 33
- This record was final approved on 10/30/2018 7:41 :10 AM. (This statement was added by the PRIME system upon its validation)
- SVP _SV0_005470 WCAP-15927-NP APlOOO 3.2.2.4 HSI Requirements The HSI requirements identify all of the required operator and maintenance personnel interfaces; for example, displays, alarms, operator controls, and maintenance and test interfaces, including the associated functionality.
3.2.2.5 External Interface Database The external interface database supplements the System Requirements document and contains two categories of information: external signal information and external communications information.
The database identifies each external physical signal received by or produced by the system. When the database is initially populated, it provides a unique identifier by which each signal can be referenced, and it defines the signal type, signal range, functional description, source or destination (by external system),
and external identifier (e.g., tag number) of the signal. As the system design progresses, information is added to each signal to identify where the signal originates and terminates within the protection system, by cabinet, then, ultimately, by specific termination, including terminal identities and identity of the input/output (1/0) or communication module and point that provide the controller interface to each signal.
The database identifies each data item that the protection system receives or transmits via a data channel (datalink or data highway). The database identifies the data channel and defines, where applicable, the data type, range, functional description, update timing, and grouping with other data items. This database provides a unique identifier by which the data item can be referenced.
3.2.3 System Architectural Design The system architectural design task identifies the major hardware and software elements of the system and their interconnections. This task produces the SOS requirements that are allocated among these items.
In particular, the functional, HSI, and interface requirements are mapped to individual subsystems.
System hardware requirements are identified. External signals are allocated to individual subsystems, and this information is added to the external interface database, as noted in subsection 3.2.2.5. Intrasystem signals and communications data are identified; details may be documented in an intrasysteni interface database.
3.2.3.1 System Architecture A description is given of the architecture of the protection system as a whole. Information provided includes the following, and typically will include architecture diagrams, hardware configuration diagrams, and textual descriptions of the architectural elements:
Identification of all parts of the system, to the cabinet and subsystem level Interconnections among subsystems Assignment of power and grounding interfaces to specific cabinets or subsystems APP-GW-JlR-001 Revision 7 3-5
- This record was final approved on 10/30/2018 7:41 :1 O AM. (This statement was added by the PRIME system upon its validation)
May 23, 2019 Page 13 of 33 SVP _SV0_005470 WCAP-15927-NP APIOOO Definition of subsystem hardware configuration to a level of detail necessary to support software design and to identify any hardware or software that must be designed or procured (i.e., that is not part of the standard platform hardware and software)
Evaluation of the selected architecture against the product qualification of the standard platform hardware and software 3.2.3.2 Functional Mapping The system functions and performance requirements defined in the System Requirements document are assigned to individual subsystems. For most sense and command features (both safety and non-safety) this can be documented as a list or table of the functions that are defined in the system functional requirements (see subsection 3.2.2.2) with the subsystem assignment. If functions must be allocated to a particular processor within a subsystem because of separation requirements defined in the system functional requirements, that assignment is documented here as well. Auxiliary features, such as testing capabilities, are mapped to the architecture at a high level here.
3.2.3.3 Intrasystem Interface Database The intrasystem interface database contains two categories of information: intrasystem signal information and intrasystem communications information.
This database identifies each physical signal that is connected between different subsystems within the protection system. The intrasystem interface database defines the signal type, signal range, functional description, and the source and destination(s) (by subsystem) and provides a unique identifier by which the signal can be referenced. Ultimately, this database also includes specific termination information, including terminal identities and identity of the I/0 or communication module and point that provide the controller interface to each signal. The termination information, however, does not necessarily need to be included before hardware and software design can proceed.
The Intrasystem Interface Database also identifies each data item that the protection system receives or transmits via an intrasystem data channel ( datalink or data highway). It identifies the data channel and defines, where applicable, the data type, range, functional description, update timing, and grouping with other data items. It provides a unique identifier by which the data item can be referenced.
3.2.4 Software Requirements Analysis The software requirements analysis task completes the identification of the requirements for the software in the system. The outputs of this task are several reusable software element documents (RSEDs) and an SRS for the system-specific software. The requirements for the sense and command features typically will have been documented by the functional mapping documented in the SDS (see subsection 3.2.2.2). Any additional requirements will be identified in the SRS as defined in subsection 3.2.3.2.
APP-GW-JIR-00 I Revision 7 3-6
- This record was final approved on 10/30/2018 7:41 :10 AM. (This statement was added by the PRIME system upon its validation)
May 23, 2019 Page 14 of 33 SVP _SV0_005470 WCAP-15927-NP APlOOO 3.2.4.1 Reusable Software Element Document (Summary and Requirements)
Reusable common software elements can be created for the AC 160 product line in the form of type circuits and custom PC elements. A type circuit is a prearranged group of the smaller pre-existing commercially available software units (PC elements) into a larger, more complex software entity. Type circuits are not compiled code, but more like the ABB Master Programming Language (AMPL) macro definitions that can be saved individually and reused throughout one or more projects. Custom PC elements are compiled from source code and added to the library of standard PC elements available for AMPL programming. Common software elements that are type circuits or general purpose custom PC elements (new PC elements intended for common use in many different safety applications) are documented with a composite document referred to as an RSED. An RSED combines requirements, design description, and user information into a single document.
The portion of an RSED that contains the product of the software requirements analysis contains the following categories of information:
An element (type circuit, functional unit, custom PC element) summary consisting of a general functional description of the element Requirements Specification:
Functional requirements (functions implemented, timing, accuracy) 1/0 terminal descriptions (default values, data types, data ranges)
Overflow/error handling (range checking, failure modes, alarming)
Truth Table (outputs as a function of input combinations) 3.2.4.2 Software Requirements Specification The high-level requirements for auxiliary features are refined into detailed requirements in the SRS. The SRS ensures that all requirements are documented for the software in each subsystem. This information may be in the System Requirements as they are mapped to subsystems and processors by the SOS (including information in the signal and communications databases). Additional information is documented as detailed requirements in the SRS. Information in the software requirements analysis includes:
Software structure Software technical description Specific inputs and outputs, both those that are physical signals and information that is received from and supplied to human users and external data systems Valid input ranges Output ranges, if they must be specifically limited APP-GW-JlR-001 Revision 7 3-7
- This record was final approved on 10/30/2018 7:41 :10 AM. (This statement was added by the PRIME system upon its validation)
May 23, 2019 Page 15 of33 SVP _SV0_005470 WCAP-15927-NP APlOOO Required HSI formats (e.g., input screen formats, printed report formats)
Required sequences of operations ( e.g., test sequences, operator dialog sequences)
Functional processing of the data Timing requirements or constraints Response to abnormal conditions and error recovery Retention, use, and initialization of previous state information, where required Safety and security requirements Design constraints ( e.g., the required use of a particular programming tool or language, or the required use of particular platform software) 3.2.5 System Hardware Requirements The system hardware requirements describe the hardware requirements needed to support the architecture of the protection system. Information provided includes the following:
Identification of all the hardware elements used in the system, such as cabinets, panels, subassemblies, wiring, terminations and modules Definition of the hardware configuration needed to support the architecture of the protection system Cabinet power and grounding requirements Cabinet cooling requirements Cabinet labeling requirements Cabinet environmental requirements Cabinet shipping and storage requirements 3.3 SOFTWARE DESIGN PHASE In the software design phase, the software requirements are decomposed and allocated to individual software components. The use of existing software components to implement the requirements is described within an existing RSED. New software components that must be created are identified and likewise documented within an RSED. The portion ofan RSED that contains the product of the Software Design Phase contains any design information that is not obvious from the implementation (AMPL diagram or code comments).
APP-GW-JlR-001 Revision 7 3-8
- This record was final approved on 10/30/2018 7:41 :10 AM. (This statement was added by the PRIME system upon its validation)
May 23, 2019 Page 16 of 33 SVP _SV0_005470 WCAP-15927-NP APlOOO The software design is described in Software Design Description (SDD) documents. A preliminary SDD is produced in the software design phase, while a final SDD is produced in the software implementation phase. There is an SDD generated for each processor module that executes unique code. Redundant processors that execute identical, or nearly identical, code may have a single SDD; this includes processors in separate divisions, if they have essentially identical code (implement the same functions).
The preliminary SDD contains the following categories of information:
Decomposition of the required functions into software entities (modules, procedures, type circuits, etc.), including entity names and the reason for the existence of the entity Module timing and priority A description, where applicable, of how safety (sense and command) functions and auxiliary functions are combined ( e.g., the functionality required in bistable and logic processors to implement periodic testing; local functionality required to support maintenance functions, such as calibration data changes). In typical cases, this description may be made generic and included in the "Design Constraints" section of the application SRS, or even in platform (non-project-specific) documentation; a reference to such generic information should be made where applicable.
Identification of any generic type circuits or custom PC elements that need to be developed.
These may be project-universal elements, applicable in multiple processors in a specific project, or they may be new platform software. In either case, their design and implementation follows the platform software development process.
Where applicable, handling of software initialization, redundancy, and tracking 3.4 HARDWARE DESIGN PIJASE In the hardware design phase, the final construction configuration of the production hardware is specified.
The production unit specific cabinet assembly drawings and cabinet configuration drawings are issued at this stage. These drawings contain all of the information necessary to produce the production unit hardware. The drawings include the following information:
Cabinet layout details Cabinet assembly details Cabinet bill of materials Cabinet configuration details Cabinet termination frame details Cabinet internal wiring details APP-GW-JlR-001 Revision 7 3-9
- This record was final approved on 10/30/2018 7:41 :10 AM. (This statement was added by the PRIME system upon its validation)
May 23, 2019 Page 17 of 33 SVP _SV0_005470 WCAP-15927-NP APIOOO 3.5 SOFTWARE IMPLEMENTATION PHASE In the software implementation phase, the executable code modules are created, typically by use of the AMPL tools. (Non-AC160 subsystems require different tools.) The application modules are integrated with platform software to produce code modules that are downloaded into subsystem processors for V&V testing (described in a V&V plan). The final version of the RSED for all of the defined software components is an output of this phase. Descriptive information about the implementation is added to the preliminary SOD to produce the final SOD.
3.5.1 Final RSED The implementation description (a printout of the AMPL diagram) is added to the RSED and a User's Guide section is added (providing the developer with adequate instruction to incorporate the common element into an application program). The complete RSED then contains the following information:
The element summary The requirements specification Design information (as described in Section 3.3)
Implementation (printout of AMPL diagram for the type circuits)
Users Guide:
Detailed instantiation procedure (prerequisites, applicability, restrictions, signal connections)
Configuration/applications ( database elements connections, I/0 interfaces, high speed datalink [HSL] interfaces, Advant Fieldbus 100 (AFlOO) interfaces, default values used) 3.5.2 Final Software Definition Document The following categories of information are added to produce the final SOD:
Mapping of signal names used in the code to names used in the requirements documents and databases, where these differ Printouts of the AMPL function chart diagrams Any other non-obvious information that is needed to understand the software implementation and its interfaces. The intention is that this is an aid to the individuals who will verify or maintain the code. This should not repeat information that is clear to a knowledgeable individual reading the diagrams (or non-AMPL source code listings).
APP-GW-JIR-001 Revision 7 3-10
- This record was final approved on 10/30/2018 7:41 :1 O AM. (This statement was added by the PRIME system upon its validation)
May 23, 2019 Page 18 of33 svP _svo_oo5470 WCAP-15927-NP APlOOO 3.6 HARDWARE IMPLEMENTATION (ASSEMBLY) PHASE In this phase, the construction of the production unit hardware system is completed using the drawings specified in Section 3.4.
3.7 SYSTEM INTEGRATION PHASE In this phase, completed cabinets containing the applications software are connected together as an integrated system. Validation testing (described in the V&V plan) is performed to test system functionality that was not covered by the cabinet-level validation testing. System integration and testing
. may be done on appropriate portions (e.g., individual divisions) of the system or on the complete system.
3.8 INSTALLATION PHASE The completed system is installed at the site. Site Acceptance Testing (SAT), described in the V & V plan, is performed to assure that the system has not been damaged by shipping and installation. The SAT also confirms proper operation of any interfaces that were not completely tested by the factory validation testing; e.g., interfaces to other plant systems.
3.9 ALTERNATIVE METHODS TO PROCESSES DEFINED IN WCAP-16096-P-A Table 3-1 identifies alternatives to the processes defined in WCAP~l6096-P-A, "Software Program Manual for Common Q Systems" (Reference 4.2.1).
3.10 ALTERNATIVES TO PROCESSES AND DESCRIPTIONS IN WCAP-16097-P-A Table 3-2 identifies alternatives to the processes and design descriptions in WCAP-16097-P-A, "Common Qualified Platform Topical Report" (Reference 4.2.2).
APP~GW-JlR-001 Revision 7 3-11
- This record was final approved on 10/30/2018 7:41 :1 O AM. (This statement was added by the PRIME system upon its validation)
May 23, 2019 Page 19 of 33 SVP _SV0_005470 WCAP-15927-NP Table 3-1 Alternative Methods to the Common Q SPM WCAP-16096-P-A Section Glossary of Terms:
Project Quality Plan (PQP) 4.3.2.1 Initiation (Concept)
Phase 4.3.1 Organization Exhibit 2-1 Design/IV & V Team Organization APP-GW-JIR-001 Revision 7 WCAP-16096-P-A Text A document that specifies alternatives or supplements to the Westinghouse QMS, Level 2, or Level 3 procedures as required to meet contractual requirements or quality standards other than those specified in the Westinghouse QMS. When the SPM refers to a PQP, it includes the Project Quality Plan and Project Plan defined in the Westinghouse Quality Procedures.
Any alternatives to the SPM processes or additional project specific information for the SQAP, SVVP, SCMP or SOMP shall be documented and justified in the PQP.
The NA organization includes a Quality organization and an Engineering organization. The design team and the IV & V team are organized within the Engineering organization.
APIOOO Alternative Alternative A document that specifies alternatives or supplements to the Westinghouse QMS, Level 2, or Level 3 procedures as required to meet contractual requirements or quality standards other than those specified in the Westinghouse QMS. When the SPM refers to a PQP, it includes the Project Quality Plan and Project Plan (including the Software Development Plan) defined in the Westinghouse Quality Procedures.
Any alternatives to the SPM processes or additional project specific information for the SQAP, SVVP, SCMP or SOMP shall be documented and justified in the PQP.
Alternative The NA organization includes a Quality organization and an Engineering organization. The design team and the IV & V team are in separate organizations at least to the Director level.
See updated SPM Exhibit 2-1 Design/IV & V Team Organization following this table.
3-12
- This record was final approved on 10/30/2018 7:41 :10 AM. (This statement was added by the PRIME system upon its validation)
May 23, 2019 Page 20 of33 SVP _SV0_005470 WCAP-15927-NP APlOOO Table 3-1 Alternative Methods to the Common Q SPM (cont.)
WCAP-16096-P-A Section 4.6.2.10 Post Mortem Review 5.5.1 Management of IV&V 6.3.2 Configuration Change Control 6.3.4 Configuration Audits and Reviews APP-GW-JlR-001 Revision 7 WCAP-16096-P-A Text Suggestions for improvement and/or best practices that are identified during the Post Mortem Review should be documented via EXHIBIT 11-2 CORRECTIVE ACTIONS PROCESS.
The resources for performing the IV & V shall be identified in the Project Quality Plan (Reference 4) that is prepared by the Project Manager during the conception phase of the software life cycle.
Software Change Request Procedure, Step 5: Revised System Baseline: The SCR forms will be used as the basis to track all system changes and to verify that changes have been properly implemented and that documentation has been updated.
Configuration Audits and Reviews
- 3. External audits by customers or regulators shall be coordinated by the EPM [Engineering Project Manager]
who will schedule personnel to be available if additional support is required.
Alternative Alternative Suggestions for improvement and/or best practices that are identified during the Post Mortem Review should be documented via the Corrective Action, Prevention and Learning (CAPAL) system.
EXHIBIT 11-2 contains a screenshot of the Corrective Action Process (CAP) system. The CAP system has since been migrated to the Corrective Action, Prevention and Learning (CAPAL) system per Westinghouse Level 2 procedures.
Alternative The resources for performing the IV & V shall be identified in the APlOOO PMS SVVP that is prepared by the IV & V team during the conception phase of the software life cycle.
Alternative Software Change Request Procedure, Step 5: Revised System Baseline: The SCR forms will be used as the basis to track all software changes and to verify that changes have been properly implemented and that documentation has been updated.
Alternative External audits by customers or regulators shall be coordinated by QA or Licensing who will schedule personnel to be available, if additional support is required.
3-13
- This record was final approved on 10/30/2018 7:41 :10 AM. (This statement was added by the PRIME system upon its validation)
May 23, 2019 Page 21 of 33 SVP _SV0_005470 WCAP-15927-NP APlOOO Table 3-1 Alternative Methods to the Common Q SPM (cont.)
WCAP-16096-P-A Section 6.4 SCM Schedule 9.2.3 Control 10.5.1 Software Verification and Validation Plan 10.10 Computer Code Certificate APP-GW-JlR-001 Revision 7 WCAP-16096-P-A Text SCM milestones that shall be indicated on the project schedule include:
CCB establishment Establishment of a configuration baseline, and Implementation of change control procedures.
An SCR log shall be maintained for the specific Common Q' system implementation.
The Platform Lead shall confirm that the approved SCR is entered into this log.
Alternative Alternative SCM milestones that shall be indicated in the project schedule include:
Establishment of a configuration baseline, and Implementation of change control procedures.
Establishment of the Configuration Control Board (CCB) is captured in the APlOOO I&C program plan.
Alternative An SCR log shall be maintained for the specific Common Q' system implementation. The Platform Lead shall confirm that the approved SCR is entered into the SCR log for any internal generic software changes. The Lead Software Engineer shall confirm that the approved SCR is entered into the SCR log for any PMS-specific software changes.
The PQP shall also define the tracking Alternative and recording process for the hardware configuration pertinent to the software verification and validation process during all phases of the software life cycle.
The completion of the implementation and checkout phase Software Verification and Validation report is the basis for the issuance of a Computer Code Certificate (see EXHIBIT 10-1 COMPUTER CODE CERTIFICATE for content requirements).
The AP 1000 PMS S VVP shall define the tracking and recording process for the hardware configuration (i.e., test configuration records) pertinent to the software verification and validation process during all phases of the software life cycle.
Alternative The completion of the installation and checkout phase Software Verification and Validation report is the basis for the issuance of a Computer Code Certificate (see EXHIBIT 10-1 COMPUTER CODE CERTIFICATE for content requirements).
3-14
- This record was final approved on 10/30/2018 7:41 :10 AM. (This statement was added by the PRIME system upon its validation)
May 23, 2019 Page 22 of 33 SVP _SV0_005470 WCAP-15927-NP APlOOO Table 3-1 Alternative Methods to the Common Q SPM (cont.)
WCAP-16096-P-A Section 11.4 Corrective Action 12 Secure Development and Operational Environment Plan APP-GW-JlR-001 Revision 7 WCAP-16096-P-A Text Corrective actions shall be documented on Exception Reports and Common Q' Comment Records by the design team and shall be completed by the due date specified on the form... Once the independent reviewer is satisfied with the corrective action taken, the report
. form shall be signed.
Secure Development and Operational Environment Alternative Alternative Corrective actions shall be documented in RITS by the design team and shall be completed by the due date specified on the form... Once the RlTS independent reviewer is satisfied with the corrective action taken, the report form shall be closed.
Alternative The SPM, Section 12, details a Secure Development and Operational Environment Plan for Common Q systems. While this plan provides an acceptable method to comply with computer security requirements, APl 000 PMS will instead continue to use the Incorporated by Reference document APP-G W-JOR-012, "AP 1000 Protection and Safety Monitoring System Computer Security Plan."
3-15
- This record was final approved on 10/30/2018 7:41 :10 AM. (This statement was added by the PRIME system upon its validation)
May 23, 2019 Page 23 of 33 SVP _SV0_005470 WCAP-15927-NP Director (Design)
Manager (Design)
APP-GW-JIR-001 Revision 7 Exhibit 2-1 Westinghouse Organization Chart*
Vice President
- --- -- -- I Senior Vice President Director (IV&V**)
Manager (IV&V)
- This example organization chart shows the minimum level of separation required for the Design, IV&V, and Quality Teams
- System level validation testing is performed by another group. This group meets the same minimum level of independence required for the IV&V group depicted in this organization chart Vice President Director (Quality)
Manager (Quality)
APlOOO I:
3-16
- This record was final approved on 10/30/2018 7:41 :1 O AM. (This statement was added by the PRIME system upon its validation)
May 23, 2019 Page 24 of 33 SVP _SV0_005470 WCAP-15927-NP APlOOO Table 3-2 Alternative Methods and Design Descriptions to the Common Q Topical Report WCAP-16097-P-A Section References 5.2.1.1.1 5.2.1.1.1 5.2.1.2.1 5.2.1.2.1 1
5.2.1.2.1 APP-GW-JlR-001 Revision 7 WCAP-16097-P-A Text Alternative
- 27. WCAP-17266, Rev. 0, "Common Q Alternative Platform Generic Change Process,"
Westinghouse Electric Company LLC.
A Motorola MC68360 processor (application processor), l Mbyte nonvolatile memory (Flash PROM) for the user built application and 2 Mbytes of nonvolatile memory (Flash PROM) for the system software and 2 Mbytes of Static RAM (SRAM). At startup, the application and system software are copied from the nonvolatile memory into the SRAM memory where it is executed.
- 27. WCAP-17266, "Common Q Platform Generic Change Process,"
Westinghouse Electric Company LLC.
Alternative A Motorola MC68360 processor (application processor), 1 Mbyte nonvolatile memory (Flash PROM) for the user built application and 2 Mbytes of nonvolatile memory (Flash PROM) for the system software and 2 Mbytes of Static RAM (SRAM). At startup, the application software is copied from the nonvolatile memory into the SRAM memory where it is executed, whereas the system software is executed out of the nonvolatile memory.
A second Motorola MC68360 processor Alternative for HSL communications, with an extra 512 Kbytes nonvolatile memory (Flash PROM) for the system software and an extra 2 Mbytes SRAM is provided for communications.
]a,c A second Motorola MC68360 processor for HSL communications, with an extra 512 Kbytes nonvolatile memory (Flash PROM) for the system software and an extra 512 Kbytes SRAM is provided for communications.
]a,c 3-17
- This record was final approved on 10/30/2018 7:41 :1 O AM. (This statement was added by the PRIME system upon its validation)
May 23, 2019 Page 25 of 33 svP _svo_oos470 WCAP-15927-NP APlOOO Table 3-2 Alternative Methods and Design Descriptions to the Common Q Topical Report WCAP-16097-P-A Section 5.2.1.3 Figure 5-13 Table 5-1 5.3.1.1 5.4.1.4.1 APP-GW-JlR-001 Revision 7 WCAP-16097-P-A Text
[
J"'c
[See "Section 5.2.1.3 Watchdog Timer Text" following this table.}
[See Figure 5-13 Watchdog Timer Configuration following this table.}
{See Table 5-1 Processor Module WDT Arrangement Watchdog Timer Summary following this table.]
[
J"'c This error report can be used for alarm or screen indication to direct technicians to the specific AC 160 node that has the CI failure. Normally the failed module will be indicated by a red light on the front panel. However, if this was a transient error and the PM is able to reboot the CI, the CI will return to service and there will be no red light.
Alternative
[
]"*c Alternative
[See "Updated Section 5.2.1.3 Watchdog Timer Text" following this table.}
Alternative
[See Updated Figure 5-13 Watchdog Timer Configuration following this table.]
Alternative
[See Updated Table 5-1 Processor Module WDT Arrangement Watchdog Timer Summary following this table.]
[
]a,c Alternative This error report can be used for alarm or screen indication to direct technicians to the specific AC 160 node that has the CI failure. Normally the failed module will be indicated by a red light on the front panel.
3-18
- This record was final approved on 10/30/2018 7:41 :1 O AM. (This statement was added by the PRIME system upon its validation)
May 23, 2019 Page 26 of 33 SVP _SV0_005470 WCAP-15927-NP Section 5.2.1.3 Watchdog Timer Text:
Updated Section 5.2.1.3 Watchdog Timer Text:
APP-GW-JlR-001 Revision 7 APlOOO 3-19
- This record was final approved on 10/30/2018 7:41 :1 O AM. (This statement was added by the PRIME system upon its validation)
May 23, 2019 Page 27 of 33 SVP _SV0_005470 WCAP-15927-NP Figure 5-13 Watchdog Timer Configuration:
APP-GW-JlR-001 Revision 7 APlOOO a,c 3-20
- This record was final approved on 10/30/2018 7:41 :1 O AM. (This statement was added by the PRIME system upon its validation)
May 23, 2019 Page 28 of 33 SVP _SV0_005470 WCAP-15927-NP Updated Figure 5-13 Watchdog Timer Configuration:
APP-GW-JIR-00 I Revision 7 APIOOO May 23, 2019 Page 29 of 33 a,c 3-21
- This record was final approved on 10/30/2018 7:41 :10 AM. (This statement was added by the PRIME system upon its validation)
SVP _SV0_005470 May 23, 2019 Page 30 of 33 I
I I
I I
I WC AP-15927-NP Tab le 5-1 Processor Module WDT Arrangement Watchdog Timer Summary Up dated Table 5-1 Processor Module WDT Arrangement Watchdog Timer Summary AP P-GW-JlR-001 ision 7 Rev APlOOO a,c a,c 3-22
- T his record was final approved on 10/30/2018 7:41 :1 O AM. (This statement was added by the PRIME system upon its validation)
SVP _SV0_005470 WCAP-15927-NP PHASE Conceptual System Definition Software Design Software Implementation Hardware Design Hardware Implementation System Integration Installation APP-GW-JlR-001 Revision 7 PRODUCTS Project Plan, Schedules, etc.,
Process Plans and Procedures (Section 3.1)
Document Index (Technical Baseline)
(Section 3.1)
System Requirements (Section 3.2.2.1)
System Design Specification (Section 3.2.3)
Software Requirements Specification (Section 3.2.4.2)
Software Design Description (Initial)
(Section 3.3)
Executable Code Modules (Section 3.5.1)
Software Design Description (Final)
(Section 3.5.2)
Cabinet Assembly Drawings (Section 3.4)
Cabinet Configuration Drawings (Section 3.4)
Assembled Hardware (Section 3.6)
Integrated System (Section 3.7)
Installed System (Section 2.1.8)
APlOOO Verification & Validation Method (Defined by V&V Process, WNA-PV-0009-GEN)
May 23, 2019 Page 31 of 33 Design Team - Requirements Traceability Matrix (RTM)
V&V Team - Requirements Traceability Analysis (RTA)
Design Team - Requirements Traceability Matrix V&V Team - Requirements Traceability Analysis Design Team - Requirements Traceability Matrix V&V Team - Requirements Traceability Analysis Design Team - Requirements Traceability Matrix V&V Team - Requirements Traceability Analysis Design Team - Reusable Software Element Documents (RSEDs), Requirements Traceability Matrix V&V Team - Element Software Tests (EST),
Requirements Traceability Analysis, Processor Module SW Tests (PMST)
Design Team - Requirements Traceability Matrix V&V Team - Requirements Traceability Analysis Design Team - Hardware Assembly Tests V&V Team - Cabinet Hardware Tests (CHT)
VerificationfTest Team -
Channel Integration Tests (CIT)
System Integration Test (SIT)
Installation Team -
Site Acceptance Test (SAT)
Figure 3-1 Development Process 3-23
- This record was final approved on 10/30/2018 7:41 :10,AM. (This statement was added by the PRIME system upon its validation)
SVP _SV0_005470 WCAP-15927-NP IEEE 1074 Life Cycle Processes Project Management Concept Exploration System Allocation Requirements Design IEC, IEEE 12207 Software Development Program Manual Process Activities Management Process Process Implementation System Requirements Analysis System Architectural Design Software Requirements Analysis Software Architectural Design Software Detailed Design Life Cycle Phases Concept (Initiation)
~
Requirements V
Analysis Design Implementation >---------<
Software Coding and Testing Installation APP-GW-JlR-001 Revision 7 Software Integration Software Qualification Testing System Integration System Qualification Testing Software Installation Software Acceptance Support Test Installation and Checkout Figure 3-2 Correlation to Standard Life Cycle Phase APlOOO Safety System May 23, 2019 Page 32 of 33 Design Process Application Development Phases Conceptual (Project Definition)
Definition (System)
Software Design Hardware Design Software Implementation Hardware Implementation System Integration Installation 3-24
- This record was final approved on 10/30/2018 7:41 :1 O AM. (This statement was added by the PRIME system upon its validation) svP _svo_oos470 WCAP-15927-NP APlOOO 4
REFERENCES 4.1 INDUSTRY STANDARDS AND CODES 4.1.1 IEEE Standard 107 4-1995, "IEEE Standard for Developing Software Life Cycle Processes,"
Institute of Electrical and Electronics Engineers, 1995.
4.1.2 IEEE/EIA 12207.0-1996, "Industry Implementation oflnternational Standard ISO/IEC 12207:
1995 (ISO/IEC 12207) Standard for Information Technology-Software Life Cycle Processes,"
Institute of Electrical and Electronics Engineers/Electronic Industries Alliance, 1996.
4.2 WESTINGHOUSE DOCUMENTS 4.2.1 WCAP-16096-P-A (Proprietary), Rev. 4, "Software Program Manual for Common Q' Systems,"
Westinghouse Electric Company LLC.
4.2.2 WCAP-16097-P-A (Proprietary), Rev. 3, "Common Qualified Platform Topical Report,"
Westinghouse Electric Company LLC.
APP-GW-JlR-00 I Revision 7 4-1
- This record was final approved on 10/30/2018 7:41 :10 AM. (This statement was added by the PRIME system upon its validation)
May 23, 2019 Page 33 of 33