ML081270222
| ML081270222 | |
| Person / Time | |
|---|---|
| Site: | Oconee  |
| Issue date: | 04/29/2008 |
| From: | Duke Energy Carolinas |
| To: | Office of Nuclear Reactor Regulation |
| References | |
| Download: ML081270222 (110) | |
Text
PDuke CEnergy Apil29, LA2 tj April 29, 2008 1~-~
Oconee Nuclear Station
kDuke Wnergy Objectives
- Address NRC concerns on SIVAT tool o# Address NRC concerns on Testing and V&V j
2
Duke Energy Agenda
- .Qualification of SIVAT Tool for Testing
- . Testing and V&V for Oconee RPS/ESPS Project
- SIVAT Demonstration
- . Action Items
- ..- Closing Remarks 3
Duke Action Items and I
Energy Closing -Remarks 4
I ILý i
ii
Meeting with NRC on April 29, 2008 1
Discussion of TXS Simulation-Based Validation Tool (SIVA T)
AREVA NP Meeting with NRC on April 29, 2008 2 COPYRIGHT 2008 AREVA NP INC.
Agenda
> Introduction and Background Mark Burzynski'
> TXS Simulation-based Validation Tool Steffen Richter Andreas Kunzel
> SIVA T Documentation Mark Burzynski
> Closing 3
ARE AREVA NP VA NP Meeting with Meeting with NRC April 29, 2008 on April29, NRC on 2008 3
Background Information
> TXS Topical Report describes the simulator-basedvalidationprocess for TXS applicationsoftware (Section 2.4.3.3.2).
L: The simulator validation tool described in the report is SIVA T.
D The role of the simulator validation tool in the standardAREVA NP engineering process for TXS project implementation is shown in TXS Topical Report (Figure 2.8).
> The correctnessof TXS code generation in the course of applicationprojects is covered by validation activities (i.e., SIVA T and factory acceptance testing).
El RETRANS analysis was not considered to be part of the standard TXS engineering process for applicationsoftware, as noted in the revised response to Software ProgramManual RAIs I and 53.
> The TXS Topical Report described generic qualification activities for the TXS SPACE tool automatic code generator(Section 2.4.3.3.3).
F- RETRANS is the independent code verification tool used in the qualificationprocess of the TXS automatic code generatorin the SPACE Tool.
> Discussed during December 19, 2007, NRC audit of the TXS Software Program Manual.
El Supported by original 1999 slides from initial meeting with NRC.
AREVA NP Meeting with NRC on April 29, 2008 4
TXS Topical Report Background Information SIEMENS TELEPERM XS
- SPACE Qualification -
SIEMENS PROPRIETARY TELEPERM XS © Siemens Power Corporation 1999 SPC - 11/99 - TXS SW lifecycle.ppt /20 5
NP ARE VA NP AREVA Meeting with NRC Meeting with April 29, on April NRC on 2008 29, 2008 5
TXS Topical Report Background Information 6
AREVA NP ARE VA NP Meeting NRC on with NRC Meeting with April 29, 2008 on April29, 2008
TXS Topical Report Background Information 7
NP ARE VA NP AREVA Meeting Meeting with NRC on with NRC 29, 2008 April 29, on April 2008 7
TXS Topical Report Background Information SIEMENS TELEPERM XS
- Engineering -
SIEMENS PROPRIETARY TELEPERM XS - Overview © Siemens Power Corporation 1999 SPC/Wkl - 10/99 - TXS-ppI /26 AREVA NP Meeting with NRC on April 29, 2008 8
TXS Topical Report Background Information AREVA NP Meeting with NRC on April 29, 2008 9
a CaMruý
- ~i I MOmu NUan =ase VodUorin TOM L
AREVA NP >Meeting with NRC on April 29, 2008 10
Purpose of Simulation Testing using SIVA T
> Validation of the applicationsoftware functionality of a specified TELEPERM XS /&C system
> Verification of the specified /&C system as againstthe functional requirements
> Early identification of specification errors in order to reduce effort for correction
> Features:
U Automatic generation of the simulatorprogram
- Wide variety of manipulation functions (i.e. built-in malfunctions)
AREVA NP Meeting with NIRC on April 29, 2008 11
SIVA T in the TELEPERM XS EngineeringProcess 2
ARE VA NP Meeting with NRC on April 29, 2008 12
Two Tasks of SIVA T AREVA NP Meeting with NRC on April 29, 2008 13
Basic Requirements for the TXS SIVA T Utilization of a modern simulatorcontrol system Visibility of all signals and variables (up to 400,000)
Restart ability by using Initial Conditions (IC)
No functional changes to the original TXS code Simulation of malfunctions for I/0 boards, CPU boards and communication bus failure Simple including of own models (process,aggregate)
(C and FORTRAN modules)
AREVA NP Meeting with NRC on April 29, 2008 14
Basic Requirements for the TXS SIVA T (cont.)
Easy handling by graphicaluser interface for the automatic generation and the use of the simulation tool Script-based simulation (to reconstructsimulation any time)
Interface with the dynamic function diagram logic viewer for monitoring Creatingan individual simulation environment for each project database and user Running on LINUX workstation or PC (SUSE LINUX distribution)
Short time for generation of the simulatormodels 15 NP ARE VA NP AREVA Meeting NRC on with NRC Meeting with April29, on April 2008 29, 2008 15
Software Validation by SIVA T Capabilities Using the original TXS application C code Full-scope function test of applicationsoftware Test of specified parts of the applicationsoftware Test of safety setpoints and safety criteria Test of the correctness of specified alarm messages Test of system behaviourfor assumed failure of individual system components 11 Malfunctions of input signals, CPUs, messages 16 ARE AREVA NP VA NP Meeting NRC on with NRC Meeting with 29, 2008 April 29, on April 2008 16
Application of SIVA T ProjectReferences through 2005 (since 1998)
Plant/nuclear power plant TXS system Unterweser (Germany) Reactor control and limitation Neckarwestheim 1 (Germany) Reactor control and limitation Bohunice V1 (Slovakia) Reactor safety system Bohunice V2 (Slovakia) Reactor safety system Philippsburg 1 (Germany) Emergency system EKU, local nucleus monitoring LKU and VENO Research reactor FRM2 (Germany) Complete safety I&C Beznau 1 and 2 (Switzerland) Reactor safety system and control Tianwan 1 and 2 (China) Complete safety I&C (incl. Diesel and ventilation facility)
Research reactor AKR2 (Germany) Complete safety I&C Biblis B (Germany) Reactor control and limitation Biblis A and B (Germany) Emergency supply steam generator (secondary)
Paks 1-4 (Hungary) Reactor safety system F6rsmark (Sweden) Rod control Oskarsham 1-3 (Sweden) Neutron flux Atucha (Argentina) Reactor safety (second heat sink)
Diverse systems (Germany) I&C for turbine-generator set (LAT)
Emsland (Germany) Reactor control Kozloduy-(Bulgaria) Diesel control, coolant pressure monitoring Grohnde (Germany) Power distribution monitoring (LVUE) 17 NP ARE VA NP AREVA Meeting NRC on with NRC Meeting with 29, 2008 April 29, on April 2008 17
Components of SIVA T Tool AREVA NP Meeting with NRC on April 29, 2008 18
Generationof the TXS Simulator Tasks of CA TS-SDE
> Controlling the whole process of generation of the simulator for a certain TXS project data base (SPACE data base)
" Starting the TXS code generatorsfdg-cg / rte-cg
" Adding all necessary TXS signals to the simulatordatabase using the SDE-Tool DBE
" Adapting applicationsoftware for each TXS CPU to run under SDE
- Automatic generation of special models (optional)
- Controllingthe compiling and linking of the simulator using the SDE-Tool DBB 19 AREVA NP ARE VA NP Meeting with Meeting on April NRC on with NRC April.29, 2008 29, 2008 19
Principleof the TXS Simulation AREVA NP Meeting with NRC on April 29, 2008 20
Components of the TXS Simulator AREVA NP Meeting with NRC on April 29, 2008 21
Using Test Scripts for Simulation AREVA NP Meeting with NRC on April 29, 2008 22
Test Script - Example FD 4 BDA99CE811 X11 F1 1compi__Q1 FD 4 BDA99CE811 __XE04 GW =7.5' KV HYS = 0.1 kV iSimTime-set 0.00 Initialization vset PBDA99CE81 1 XQ01 8.0 ;# voltage=8,OkV plot FD 4 BDA99C E811_XQ11.v ;# voltage Define signals to plot plot FD_4_BDA99C E811 XE04.v ;# voltage<7,5kV Open plotfile = plot-open voltage limit.dat Check limit value *= ramp P BDA99CE81 1 XQ01 7.0 5 Sgo-for 6 Check hysteresis *l~[ramp PBDA99CE81 1 XQ01 8.0 10 go-for 12 Close plotfile ~ plot-close Zýý AREVA NP Meeting with NRC on April 29, 2008 23
Test Script - Result
- Time FD_4_BDA99CE811 XQI 1.v FD_4_BDA99CE811 XE04.v
> .,,i p; -9IFlr3 7.52 0 7.51 0 2001-02-22 / jw / trainingl.dat I 7.5 0 8.5 .......... ......... .......... .......... .......... ........ ........
FD_4_BDA99CE811__XQ11.v
...... "k 7.49 7.48 1 7.47 0 1
0 7.59 1 7.595 1 7.6 6.5 7.605 0 7.61 0 6.5 I I I III 7.615 0 0 2 4 6 8 10 12 14 16 18 20 time [sec]
1 [ SII Ii
- I I I FD4_BDA99CE8I1__XEO4.v I
Content of the 0 * "1. . . . . . . . . .. . ... . ... . .. . . . .4 . . . . . . .. " I. . . III . . ."
plotfile (extract) 0 2 4 6 8 10 12 14 16 18 20 time [sec]
24 AREVA NP ARE VA NP Meeting NRC on with NRC Meeting with 29, 2008 April 29, on April 2008 . 24
Monitoring the Simulation Process using the Dynamic Logics Viewer AREVA NP Meeting with NRC on April 29, 2008 25
ManipulationFunctions- Malfunctions Example: One Faulty I/0 Board AREVA NP Meeting with NRC on April 29, 2008 26
ManipulationFunctions - Malfunctions Example: Two Faulty I/0 Boards 2
AREVA NP Meeting with NRC on April 29, 200 8 27
ManipulationFunctions - Malfunctions Example: Three Faulty I/0 Boards 28 ARE NP VA NP AREVA Meeting with NRC Meeting with April 29, 2008 on April29, NRC on 2008 28
Advantages of SIVA T Application
> Allows for simulation testing early in the course of engineering U Early identification of specification errors
- long time before having TXS hardwareavailable in test-bay
> Efficient tool environment for V&V activities during project implementation of TXS /&C systems
> Suitable to evaluate effects of planned changes to alreadyinstalled systems AREVA NP Meeting with NRC on April 29, 2008 29
Limitations of SIVA T Simulation
> The following system characteristicsare not tested by SIVA T AREVA NP Meeting with NRC on April 29, 2008 30
Full-scope Test Bay Environment ERBUS TXS Monitoring &
service network Peripheral I/0 interface I I I I
"-i TELEPERM XS I&C Cabinets I
31 ARE AREVA A/P VA NP Meefti NRC on with NRC MeetIng with April 29, an Apitl 2008 29, 2008 31
Validation and Use of SIVA T Tool
> SIVA T simulation of NPP Unterweserapplication(1996; 2000)
" Retrofit of reactorcontrol & limitation system using TELEPERM XS
" Validated in 1996 in a test bay and with a linked process model
- In addition, test cases were verified with the UNISYS simulatorcontrol system (predecessorto SIVA T).
- Functionalupgrade of this system preparedin 2000, but no test bay was available (TXS hardwarealready in operation in the plant)
- Validation approach based on SIVA T (availableas V&V tool for TXS since 1998).
- Test cases from UNISYS simulation environment and the test bay were recalculated with SIVA T.
Since the results matched, the verification of the modified /&C functionality was also implemented with SIVA T.
- A closed-loop system test (load shedding from 71% reactorpower to own power consumption) was recalculatedby SIVA T and the process model (system model NLOOP Unterweser)
" Very high concordance between the actual system behavior and the simulation results lead to the authorizationfor installing the modified TXS applicationfunctions based on SIVA T validation
" Plant commissioning took place without findings concerning the new /&C application functions (just some adjustments to parametersettings)
AREVA NP Meeting with NRC on April 29, 2008 32
Validation and Use of SIVA T Tool
> SIVA T simulation of NPP Philippsburg1 application(2000-2001)
- Step-wise retrofit of emergency system using TELEPERM XS (redundanttrains 7 and 6)
- A number of test field tests were verified with SIVA T as part of the TXS retrofittingin the Philippsburg I nuclearpower plant IN Very high concordance made it possible to implement individual changes in the TXS application after the test bay tests.
@ OK to commissioning after validation exclusively with SIVA T
> SIVA T applicationbeing part of standardTXS engineering process N Many references of successful tool application, 10 years of experience
- Activities for comparing SIVA T and test bay results in every new project
- Majority of specification errorsidentified by SIVA T; before start of test bay AREVA NP Meeting with NRC on April 29, 2008 33
Life Cycle Management of SIVA T Tool Configurationmanagement New change requests due to changes in TXS-Core SW Acc. to procedure FAW TXS 1.5 or the LINUX distribution f ....
New change requests due Analysis and to new or modified I- I- I Implementation of the functionality Change-Requenst New change requests due to error reports new CRs analysis, coding, usage test Occured differing results Iool integration test and CR implementation test Simulation New SIVAT functional Test field t
by SIVAT release regression tests SPACE Project Database and Testcases Life cycle of SIVAT AREVA NP Meeting with NRC on April 29, 2008 34
SIVA T Documentation Summary of Information
> AREVA NP Report No. NGLP/2004/en/O094, "TELEPERMXS Simulation - Concept of Validation and Verification," provides a detailed description of SIVA T.
- Section 2.0 describes SIVAT and its use U Section 2.4.7 provides an example of the testing methodology.
- Section 4.1 describes the development processes and procedures
- Section 4.2 summarizes experience in using SIVA T for testing TXS application software.
> SIVA T conforms to Clause 5.3.2 of IEEE Std 7-4.3.2
- The quality assuranceprocess and operating experience provide basis for conformance.
SIVA T report has been submitted to NRC to support the Oconee LAR (Item 25)
AREVA NP Meeting with NRC on April 29, 2008 35
SIVA T Conclusions
> SIVA T provides a effective simulation-basedtest environment for project-relatedTXS applicationsoftware used to validate the applicationsoftware priorto installationinto the target hardware.
> SIVA T was developed and is maintained with quality-relatedlife-cycle and configuration management processes.
> AREVA NP has substantialexperience in using SIVA T in the development of TXS application software.
> SIVA T conforms to the guidance in clause 5.3.2 of IEEE Std 7-4.3.2-2003.
36 ARE AREVA NP VA NP Meeting on April29, NRC on with NRC Meeting with 2008 April 29, 2008 36
>Closing 37 ARE NP VA NP AREVA Meeting with Meeting on April29, NRC on with NRC April 29, 2008 2008 37
I.
..... - I-
-q
.1~
'~
17114ý -;
0 r,ý 1,Y I Ulm i""m L 1I
,AAI~Lil
.9 A REVA >Meeting with NRC on April 29, 2008 1
Discussion-of Testing and V&V for Oconee Project COPYRIGHT 2008 AREVA NP INC. 2 AREVA NP Inc. with NRC
>Meeting with
>Meeting April 29, on April NRC on 2008 29, 2008 COPYRIGHT 2008 AREVA NP INC. 2 L
Agenda Background on Testing Mark, Burzynski Oconee Factory Acceptance Testing Werner Baltes POconee SIVAT Testing Farhad Abbasbanaey Discussion on Testing V&V Steve Yang Closing AREVA NP Inc. >Meeting with NRC on April 29, 2008 3 I
Background on Testing
'Mark Burzynski m
RV >Meeting with NRC on April 29, 2008 4
Background on Testing TXS System Development Testing TXS system is a fully integrated suite of hardware and software designed specifically for nuclear safety applications.
TXS system has significant nuclear operating experience.
TXS system is described in the TXS Topical Report.
NRC approved the TXS Topical Report in a safety evaluation report issued in May 2000.
Overall'application independent qualification process is described in Section 2.2 of the TXS Topical Report.
The TXS platform has been fully qualified as an integratedplatform 5
AREVA NP Inc. >Meeting with NRC
>Meeting with April 29, on April NRC on 2008 29, 2008 5 i
Background on Testing TXS System Development Testing Spedcif -ybe Qualia Oualficaan tepstme ob doeiHec-rodae h.sgadoeIa SWysum Too H
CasuomnuntTypOW~ Oulkao steps towe to be done once W a sysem famy Hardware I Do w
>Meeting with NRC on April 29, 2008 6
Background on Testing TXS Project-SpecificActivities o Application software is implemented using the TXS Specification and Coding Environment (SPACE) tool.
o This tool is used to implement functional logic.
o Software code is automatically generated from Function Diagrams by the code generation tools.
The project-specific TXS system is developed from qualified hardware and software modules using the qualified development tools 7
AREVA N with NRC
>Meeting with
>Meeting April 29, on April NRC on 2008 29, 2008 7
Background on Testing SPACE - GraphicalUser Interface for Engineeringand Service
ý Logical 'software integration'occurs at this stage ý RVmNn >Meeting with NRC on April 29, 2008 8
Background on Testing SPACE - Graphical User Interface for Engineering -andService ol SPACE is an engineering design tool that connects qualified components into network diagrams and qualified function blocks into function diagrams.
SIt issimilar to designing a module-based analog system.
Po There is no manual code generation for the safety system software.
" Software is,automatically generated from the networks diagrams and function diagrams by the qualified SPACE tool.
" SPACE provides tools to verify proper links of the function blocks.
SSPACE can also generate diagrams that can be checked by an independent team, similar to the conventional design quality assurance requirements.
TXS SPACE to'ol eliminates certain important human errors and supports independent verification I AREVA NP Inc I
>Meeting with NRC on April 29, 20089 9
Background on Testing TXS Project-Specific SIVA T Testing SIVAT tests the same C Code produced by SPACE tools for the safety system.
SIVAT tests validate that the specified safety system software requirements have been correctly implemented in the SPACE function diagrams.
Access to all the internal and external signals as well as the function block parameters and internal memory is available during testing in the simulation environment.
If realistic feedback is required from the process for the purpose of assessing the functional response, the code to be tested can also be coupled to a plant or component model.
>Meeting with NRC on April 29, 2008 10 i AREVA NP Inc. I
Background on Testing SIVAT in the EngineeringProcess SIVA T testing validates that software automaticallygeneratedfrom SPACE satisfies requiredfunctionality for input/output response AREVA NP >Meeting with NRC on April 29, 2008 11 I...
Background on Testing TXS Project-Specific FA T Physical software integration occurs during the factory acceptance test (FAT) stage, when the application software is loaded on the TXS processors.
The project-specific FAT Plans cover the approach and activities associated with the Software and Hardware Integration.
A project-specific Software Generation and Download Procedures is issued for each project to control and document the generation of each application software release.
12 I AREVA NP Inc. I >Meeting with
>Meeting on April NRC on with NRC 29, 2008 April 29, 2008 12
Background on Testing Alignment with IEEE Std 1012 Testing Activities IEEE Std 1012-1998 describes four testing activities:
" Component Testing
" Integration Testing
" System Testing
" Acceptance Testing IEEE Std 1012-1998 Figure 2 shows a progression of test activities occurring during the development process.
>Meeting with NRC on April 29, 2008 13 i AREVA NP Inc.. I
Background on Testing Alignment with IEEE Std 1012 Testing Activities IEEE td enri'dTXSProject-Speci 1fý ,ic 'testing Testing ~Activity. Testi ng.s __________________________
Component X Not Applicable Testing (hardware and (based on use of qualified hardware and software software type tests) modules)
Application Software: SIVAT for integration of Function Block modules Integration x Optional X Testing (see Note 1)
System Components: Pre-FAT prerequisites and procedure dry runs (manufacturing tests)
System Testing X X (integrated in FAT based on use of qualified system Acceptance Not Applicable components and development tools)
Testing Legend: X indicates alignment with IEEE Std 1012 testing.
Note 1 - For the case where SIVAT testing is performed by development organization with a complete FAT of application software functionality, the V&V team only performs the reviews of the SIVAT plan and results.
Alternately, the V&V team can trace the requirements through the SIVAT testing as performed by development group, in which case application software integration tests can be eliminated from the scope of the FAT (called
'reduced' FAT).
AREVA NP In'c. I L >Meeting with NRC on April 29, 2008 14
Background on Testing Conclusion P The project-specific TXS system can only be developed from qualified hardware and software modules through the use of the qualified SPACE tool.
r SIVAT testing validates that software automatically generated from SPACE satisfies required functionality for input/output response.
> The combination of TXS generic qualification testing and project-specific testing addresses all of the testing activities in IEEE Std 1012-1998.
I AREVA N
>Meeting with NRC on April 29, 2008 15
Oconee Factory Acceptance Testing Werner Baltes 16 on April NRC on with NRC 2008 29, 2008 April 29, I AREVA NP Inc. IL
>Meeting with
>Meeting 16
Oconee FAT FAT Plan P The FAT plan is the document that
" Specifies the scope of FAT testing
" Provides an overview of FAT preparation and FAT activities
" Provides an overview of the test coverage
"> Provides an overview of the test field environment PFAT Plan and revisions are approved in accordance with the AREVA NP Quality Management Manual and by Duke Energy.
17 I AREVA NP Inc. I
>Meeting with NRC
>Meeting with April 29, on April NRC on 2008 29, 2008 17
Oconee FAT Test Objectives
- o. The FAT tests validate the correct functionality of the RPS/ESPS as an integrated system, i.e. with all software implemented, with all interfaces and all peripheral equipment that is in the scope of the delivery.
- 0. Additional tests are performed to provide sufficient overlap with equipment that cannot be involved in the functional channel tests.
Tests are performed,to validate functional requirementsin design and customer specifications I RV PIc >Meeting with NRC on April 29, 2008 18
Oconee FAT Test Objects and Interfaces 09 -
__ __a Figure 1: Test Objects and Interfaces of the ONS RPS/ESPS TXS System 19
>AEeoting with
>Meeting NRC on wfth NRC April 29, on April 2008 29~ 2008 19
Oconee FAT Test Field Environment 4-I 6
S S
ma mu LAN 4HW wiring 20
>Meeting with AIRC
>Meeting with April29, on Apr#
NRC on 2008 29, 2008 20
Oconee FAT General Approach opoGeneral overview of the FAT activities and support activities:
- 1. Plan the FAT activities
- 2. Develop the Test Specifications IProcedures using approved design documents
- 3. Prepare test field and test equipment for FAT
- 4. Complete FAT prerequisites
- 5. Perform test activities
- 6. Evaluate test results to acceptance criteria
- 7. Develop the Test Summary Report and the Test-Incident Report P Inc. >Meeting with NRC on April 29, 2008 2 21
Oconee FAT GeneralApproach Figure 2: General Approach to the Factory Acceptance Test mRV PIc >Meeting with NRC on April 29, 2008 22
Oconee FAT Major System Segment and.Test Procedure Test Objects and Interfaces Corresponding Tests (from Figure 1) (from Figure 2)
Field Connections & Isolation Devices 1, 2, 12, 13 Test Machine Connections 3, 4, 5, 6, 9, 10, 11 Communication Modules & Cabling 3, 4, 7, 8,14 TXS Service Unit (including GSM) 3, 4, 7,14 TXS Gateway 3,4,8 System & Application Software 3, 4, 5, 6, 9, 10, 11, 12, 13, 14 TXS Modules & Cabinet Internal 1, 2, 3,4, 5, 6,12,13 Wiring Nuclear Instrumentation Equipment 2, 12 DLPIAS/DHPIAS Equipment 1, 13 AREVA NP Inc. I i >Meeting with NRC on April 29, 2008 23
Oconee FAT Software Test Documentation Po.The following tests are considered software tests:
C. RPS Functional Test ESPS Functional Test Graphic Service Monitor (GSM) 0 Gateway to OAC PThe Test Specifications incorporate the Test-Design Specificatic )n and Test-Case Specification, as defined in IEEE Std 829-1983, Ii into a single document.
P Each Test Specification shall have the following information and structure:
- Test verifv and document that the svstem meets desion and customer specifications.
c> Validate functionality under a comprehensive set of realistic operating conditions.
C. Specific acceptance criteria With individual Test Procedures developed using the Software and Hardware design documents.
24 AREVA NP Inc. >Meeting with NRC
>Meeting with April 29, on April NRC on 2008 29, 2008 24
Oconee FAT Test Procedures
" For Software Tests: Test Specifications and Test Procedures are utilized.
" Test specifications outline the test design and describe the test cases and the test steps.
" Software Test Procedures follow the test steps described inthe.
Test Specifications.
SSoftware Test Procedures largely consist of Test Scripts, the necessary steps for executing them, and the detailed expected results.
0Test Scripts allow for the test steps to be performed automatically.
" For Hardware Tests: Only utilize Test Procedures.
SThe Hardware Test Procedures describe the procedural steps in detail, specify the expected results and, contain auxiliary Test Scripts (if needed).
0 Test Scripts facilitate the process, but they will not make up a majority of the work as they do in Software Test Procedures.
25 AREVA NP Inc. >Meeting with
>Meeting NRC on with NRC April 29, on April 29, 2008 2008 25 L
Oconee FAT RPS Function Tests l RPS Functions are tested to validate compliance with design and customer specifications.
" RPS Trip #1: Nuclear Overpower (Neutron Flux) Trip
" RPS Trip #3: Nuclear Overpower Flux/Flow/Imbalance Trip
" RPS Trip #4: RCS High Pressure Trip
" RPS Trip #5: RCS Low Pressure Trip
" RPS Trip #6: RCS Variable Low Pressure Trip
" RPS Trip #7: RCS High Outlet Temperature Trip
" RPS Trip #8: Reactor Building High Pressure Trip
" RPS Trip #9: Loss of Both Main Feedwater Pumps Trip
" RPS Trip #10: Main Turbine Trip
" RPS Trip #11: Reactor Coolant Pump Power/Flux Trip
" RCS Delta Pressure Average Function
" RPS Channel E/MSI Functions
"> RPS Miscellaneous Functions
>Meeting with NRC on April 29, 2008 26 I AREVA NP Inc.
Oconee FAT ESPS Function Tests o ESPS Functions are tested to validate compliance with design and customer specifications.
" ESPS Trip #1: RCS Pressure Low Trip
" ESPS Trip #2: RCS Pressure Low Low Trip
" ESPS Trip #3: Reactor Building Pressure High Trip
" ESPS Trip #4: Reactor Building Pressure High High Trip
" ESPS Miscellaneous Functions The trip function for each RPS and ESPS channel is tested independently and then the trip functions are tested as a combined system 27 I AREVA NP Inc. I
>Meeting with
>Meeting on April NRC on with NRC 29, 2008 April 29, 2008 27
Oconee FAT Additional Tests v> Additional tests are performed to validate functionality of support. and monitoring equipment, and other functionality as required by design and customer specifications.
" Cabinet Alarm Monitoring
" DP o Diverse Low Pressure Injection Actuation System o Diverse High Pressure Injection Actuation System c> Reactor Coolant Pump Power Monitor o Nuclear Instrumentation o RPS/ESPS Hardware Failures RPS/ESPS Response Times oSystem Tests ANPInc L
>Meeting NRC on with NRC
>Meeting with 29, 2008 April 29, on April 2008 28 28
Oconee FAT FeaturesNot Tested P Features not within the scope of AREVA NP supplied equipment.
00 Features validated by other means.
0o Features that are of a nature that does not impact overall system functionality.
29 i AREVA NP Inc. I
>Meeting with NRC
>Meeting with April 29, on April NRC on 2008 29, 2008 29
Oconee FAT Acceptance Criteria r> Each Test Specification / Procedure details the specific, required acceptance criteria in order to determine if the test is completed successfully.
r> These criteria are developed from design and customer specifications.
" Test results are evaluated during testing to ensure compliance with test requirements.
" Any deviations between the test results and the acceptance criteria (i.e., the expected results) shall be dealt with in accordance with the FAT Plan.
"> The role of V&V with regards to V&V test acceptance is described in the Software V&V Plan.
" Software Quality Assurance with regards to item pass / fail criteria is described in the Software Quality Assurance Plan 30
>Meetng with NRC
>Meeting April29, NRC on April 2008 29, 2008 30 i AREVA NP Inc.
Oconee FAT Handling of Variances Preliminary FAT PCA -*
test specs and ]
procedures Ready for FAT, FAT validation -
procedure_
AREVA RI-G-Testlield manual_
SWII-IW change-management 31
>Meeting with
>Meeting NRC on with NRC April 29, 2008 on April29, 2008 31
Oconee FAT Coverage and Overlap of SW and HW Tests o The following three tables provide an overview of which test checks which parts of the system and how sufficient overlap between the tests and for hardware and software is ensured.
i The following legend applies to the tables:
Legend:
Softwar e X this test covers the corresponding HW / SW F includes testing of failure behavior 32 with NRC
>Meeting with
>Meeting on April NRC on 29, 2008 April29, 2008 32
Oconee FAT Coverage and Overlap of SW and HW Tests 33 AREVA NP Inc. I >Meeting with NRC
>Meeting with April29, on April NRC on 2008 29, 2008 33 L
Oconee FAT Coverage and Overlap of SW and HW Tests 34 AREVA NP Inc. >Meeting with
>Meeting on April NRC on with NRC 29, 2008 April29, 2008 34
Oconee FAT Coverage and Overlap of SW and HW Tests I AREVA NP Inc. Ik
>Meeting with NRC on April 29, 2008 35
Oconee FAT Conclusions.
> The Oconee Unit 1 FAT satisfies the project-specific aspects of IEEE Std 1012-1998 requirements for application software integration, system, and acceptance testing to satisfy IEEE Std 1012 testing requirements.
> The Oconee Units 2 and 3 FATs satisfies the project-specific aspects of IEEE Std 1012-1998 requirements for system and acceptance testing to satisfy IEEE Std 1012-1998 testing requirements.
Project-specific application software integration testing will be performed with SIVAT to satisfy IEEE Std 1012-1998 testing requirements.
36 AREVA NP Inc. I
>Meeting with
>Meeting on April NRC on with NRC 29, 2008 April29, 2008 36
A AR- A Proprietar Oconee SIVAT Testing Farhad Abbasbanaey mRVPIc >Meeting with NRC on April 29, 2008 37
Oconee Unit I SIVA T o Oconee Unit 1 SIVAT testing was used as a debug tool during the detailed software design phase prior to FAT.
P SIVAT testing verified that the functional requirements of the SRS and the software design in the SDD were properly implemented into the project database as shown in the Application Software Code document.
o Test Item was the RPS/ESPS Application Software that was compiled and linked using the SIVAT simulation-environment of the TXS system.
38 AREVA NP Inc. I >Meeting with NRC
>Meeting with April 29, on April NRC on 2008 29, 2008 38 L
Oconee SIVA T RPS Function Tests P RPS Functions were tested to validate compliance with design and customer specifications.
RPS Trip #1: Nuclear Overpower (Neutron Flux) Trip RPS Trip #3: Nuclear Overpower Flux/Flow/Imbalance Trip RPS Trip #4: RCS High Pressure Trip RPS Trip #5: RCS Low Pressure Trip
< RPSTrip #6: RCS Variable Low Pressure Trip RPS Trip #7: RCS High Outlet Temperature Trip RPS Trip #8: Reactor Building High Pressure Trip RPS Trip #9: Loss of Both Main Feedwater Pumps Trip RPS Trip #10: Main Turbine Trip RPS Trip #11: Reactor Coolant Pump Power/Flux Trip
< RCS Delta Pressure Average Function
< RPS Channel E/MSI Functions
< RPS Miscellaneous Functions AREVA NP Inc. >Meeting with NRC on April 29, 2008 39
Oconee SIVA T ESPS Function Tests SESPS Functions were tested to validate compliance with design and customer specifications.
" ESPS Trip #1: RCS Pressure Low Trip
" ESPS Trip #2: RCS Pressure Low Low Trip
" ESPS Trip #3: Reactor Building Pressure High Trip
" ESPS Trip #4: Reactor Building Pressure High High Trip
" ESPS Miscellaneous Functions The trip function for each RPS and ESPS channel is tested independently and then the trip functions are tested as a combined system 40 AREVA >Meeting with
>Meeting April29, on April NRC on with NRC 2008 29, 2008 40
Oconee SIVA T Featuresto be Tested P Functionality specified in the Unit 1 SDD was tested to determine if the software elements correctly implement the software requirements.
" Compliance with functional requirements.
" Performance at boundaries, interfaces, and under error conditions.
P The following characteristics were checked:
" Signals to Output boards must have no fault status at all times, even under error conditions.
">Test results must be verified from start of test until the completion of the test in order to verify that no unexpected intermediate results are present.
" Correct setting of function block parameters must be verified against software requirements.
41 AREVA NP Inc. >Meeting with
>Meeting on April NRC on with NRC 29, 2008 April 29, 2008 41
Oconee SIVA T FeaturesNot Tested o The testing of TXS system software components (Operating System, I/O Drivers, Communication Software, Runtime Environment, and Function Blocks) were not within the scope of this test.
< These system software components were validated through the TXS generic qualification process 42 April29, on April NRC on with NRC 2008 I AREVA NP Inc. k
>Meeting with
>Meeting 29, 2008 42
Oconee SIVA T Test Results P Baseline Test Summary
" Four separate SIVAT runs performed on Unit 1 software
" Two functional errors identified in software
" Other problems identified with test procedures, acceptance criteria descriptions, and test scripts
- These problems were corrected and tests reperformed
" One software design error identified after SIVAT testing during previous equipment testing
- Software error corrected and retested Software design errors have been corrected and successfully retested 43 I AREVA NP Inc. IL
>Meeting with
>Meeting April29, on April NRC on with NRC 2008 29, 2008 43
Oconee SIVA T Test Results i Supplemental Test Summary o Testing was created because of design changes from Open Item and changes to customer requirements o One SIVAT run was performed on the updated Unit 1 software o Zero functional errors identified in software o Zero problems identified with test procedures, acceptance criteria descriptions, and test scripts Software design errors have been correctedand successfully retested 44 I AREVA NP Inc. I
>Meeting with
>Meeting on April NRC on with NRC 29, 2008 April29, 2008 44
Oconee SIVA T Test Results
> Insights and Lessons Learned c Lessons learned from Baseline SIVAT testing incorporated into the Supplemental Testing methodology c> Eliminated errors produced o Automation of script execution allows less error likely situations (e.g., script typos, signal ID verification) o Lessons learned to be factored in to Unit 2 and 3 SIVAT testing 45
>Meeting with NRC
>Meeting with April 29, on April NRC on 2008 29, 2008 45 i AREVA NP Inc.
Oconee SIVA T Unit I Test Documentation r> PositionPaper:Deviation of the Simulation Based Validation Tool (SIVA T) Documentation Compared to IEEE Std 829-1983 and IEEE Std 1008-1987
" Assessed specific deviations between Oconee Unit 1 SIVAT test documentation and IEEE Stds 829-1983 and 1008-1987.
o> Deviations are primarily format or have minor content variations, with no technical inadequacies.
" AREVA NP and Duke Energy have determined that Unit 1 SIVAT test documentation is of sufficient technical content and clarity.
> Regulatory Guides 1.170 and 1.171 provide a certain amount of latitude in development of testing documentation, as stated in the Regulatory Positions.
o Variances in test documentation are allowed as long as the documentation meets the regulatory requirements.
> Subsequent Unit 1 test reports correct the deviations noted in the position paper.
46 AREVA >Meeting with NRC
>Meeting with April 29, on April NRC on 2008 29, 2008 46
Oconee SIVA T Conclusions P Oconee Unit 1 SIVAT testing was used as a debug tool in the detailed software design phase.
o Unit 1 SIVAT test results were not used to demonstrate independent validation of software functional requirements.
" V&V did not review Unit 1 SIVAT test specifications and procedures Original test document did not conform to IEEE Std 829.
o Unit 2 and 3 SIVAT testing will be used for integration testing of the application software to satisfy IEEE Std 1012-1998 testing requirements.
47 I AREVA NP Inc. I
>Meeting with NRC
>Meeting with Apr11 29, on April NRC on 2008 29, 2008 47
Oconee Testing Verification and Validation Steve Yang
>Meeting with NRC on April 29, 2008 48 L- AREVA NP Inc.
Oconee V&V Organization 49 AREVA NP Inc. I >Meeting with NRC on April 29, 2008 49 B
TXS Software ProgramManual Testing and V&V Options
> TXS Software Program Manual outlines three methods for software testing and V&V:
- 1. SIVAT testing is performed by design engineering, with a 'complete' FAT (standard FAT augmented with software integration tests), the V&V team only reviews SIVAT plan and results, and a FAT with software tests is performed.
- 2. SIVAT testing as performed by design engineering, V&V traces requirements through the SIVAT testing, and with a standard FAT (called 'reduced' FAT in Software Program Manual).
- 3. V&V team can plan and perform SIVAT testing in addition to tracing, in which case a standard FAT is performed.
50 AREVA NP Inc. >Meeting with
>Meeting April 29, on April NRC on with NRC 2008 29, 2008 50
Software ProgramManual Testing Option 1 Oconee Unit I Testing Scope of the Design Scone of the V&v v
I System part
(= HW + SW)
Hardware part k
Software part Implementation Code
>Meeting with NRC on April 29, 2008 51
Software ProgramManual Testing Option 2 Oconee Units 2 and 3 Testing Scope of the Design team _I _ Scope of the V&V team on - -F System part
(= HW+ SW)
Hardware part Software part I
52
>Meetfng with NRC
>Meeting with NRC on Aptil 29, 2008 on April29, 2008 52
Testing V&V TXS Approach to Simulation Testing Layers of V&V are used to ensure quality to demonstrate proper application software functionality.
- 1. TXS development process has features specifically designed to improve application software reliability.
" Use of standard Function Block library provides large experience base for standard modules.
" Use of SPACE tool to automatically generate code eliminates important human error sources associated with manual code generation (errors of translation and introduction of complexity by engineers optimizing coding).
< SPACE tool and Function Block library are generically qualified, which provides a very high degree of V&V independence commensurate with the importance of generic system qualification.
TXS development process requires use of SPACE tool and Function Block library to create code from Function Diagrams and Function Diagram Group modules.
53 with NRC
>Meeting with on April NRC on 2008 29, 2008 April 29, I AREVA NP Inc. IL
>Meeting 53
Testing V&V TXS Approach to Simulation Testing
- 2. SIVAT testing is performed by the development group and is an integral part of the TXS engineering process.
" SIVAT is an additional layer of development testing performed on Function Diagrams and Function Diagram Group Modules.
" SIVAT test plans, procedures, and results are prepared in accordance with 10 CFR Part 50 Appendix B quality assurance requirements.
" The SIVAT tool is used to validate application software functionality using a wide variety of manipulation functions (i.e. built-in malfunctions).
54 April29, on April NRC on with NRC 2008 I AREVA NP Inc. I
>Meeting with
>Meeting 29, 2008 54
Testing V&V TXS Approach to Simulation Testing
- 3. SIVAT test plan and results are verified by V&V group to ensure software functionality.
o V&V group is completely independent of software development.
- I&C functionality can be fully assessed by verification of SPACE diagrams.
- Equivalent to code verification in other code development systems.
- Code generation verification checks performed by SPACE can be readily verified.
- SIVAT testing methods and results can be readily verified.
- Verification of function diagrams is facilitated by commonly understood notation used to prepare Function Diagrams.
- NRC evaluation of the automatic code generation process was documented in SER for TXS topical report.
V&V group can also trace requirements through SIVAT testing specifications and procedures or perform independent testing, and can require additional test cases and analysis.
55 AREVA NP Inc. with NRC
>Meeting with
>Meeting April 29, on April NRC on 2008 29, 2008 55
Testing V&V Simulation Testing for Oconee v For Unit 1, the V&V group reviews SIVAT test plans and results.
" V&V documents problems identified during review as Open Items.
" V&V ensures that resolution of Open Items generated during the reviews is acceptable.
" V&V method for SIVAT testing is different for Unit 1.
o SIVAT tests were performed prior to the test plan review by V&V group.
o Unit 1 SIVAT test results are not used to demonstrate independent validation of software functional requirements.
o FAT for Unit 1 will test all elements of the application software.
> For Units 2 and 3, the V&V group will perform the independent verification (including requirements tracing) and Appendix B design review of the SIVAT test plans, procedures, and results to ensure software functionality.
" V&V will document problems identified during the review as Open Items.
" V&V ensures that resolution of Open Items generated during the reviews is acceptable.
" Resolution of Open Items may include performing selected SIVAT testing again, performing new SIVAT test cases, or ensuring that FAT fully tests software functionality not tested by SIVAT.
t The V&V group also has the authority to perform independent SIVAT testing, as deemed necessary.
56 AREVA NP Inc. >Meeting with
>Meeting on April NRC on with NRC 29, 2008 April29, 2008 56
Testing V&V Value of Formal SIVA T Testing rA balance is drawn between performing software tests during complete FAT (later in the development process) to support customer quality assurance observation and monitoring and performing more formal software testing with SIVAT earlier in the process.
> IEEE Standard 1008-1987, IEEE Standard for Software Unit Testing," recognizes that:
There are significant economic benefits in the early detection of faults. This implies that test set development should start as soon as practicalfollowing availabilityof the unit requirements documentation because of the resulting requirements verification and validation. It also implies that as much as practicalshould be tested at the unit level. (Paragraph B2.4)
> The early detection of faults through simulation testing with formal V&V also serves to reduce project risks earlier in the development process.
57 AREVA NP Inc. >Meeting with NRC
>Meeting with April 29, on April NRC on 2008 29, 2008 57 I
Testing V&V TXS Approach to Acceptance Testing Layers of V&V are used to ensure FAT quality to demonstrate proper integrated system performance.
- 1. Generic TXS platform software and hardware integration is generically qualified, as described in the TXS topical report.
< This approach provides a very high degree of V&V independence commensurate with the importance of generic system qualification.
- 2. FAT is performed by a test group (comprised of hardware and software personnel from the design organization).
" This testing method ensures that the proper hardware and software personnel are used in an integrated fashion to develop and conduct the FAT.
" The FAT plans, procedures, and results are prepared in accordance with 10 CFR Part 50 Appendix B quality assurance requirements.
o This approach enables the hardware and software engineers to compare the test results to the design and customer specifications.
58
>Meeting with NRC
>Meeting with on April NRC on 29, 2008 April29, 2008 58 I AREVA NP Inc. IL
Testing V&V TXS Approach to Acceptance Testing
- 3. V&V defines criteria and performs independent verification (including requirements tracing) and Appendix B design review of FAT procedures and results to ensure system functionality.
"> V&V performs verification work in accordance with Software Verification and Validation Plan.
"> Independent V&V group has authority to perform independent acceptance testing or require additional test cases and analysis, as deemed necessary.
The TXS approach to testing V&V has the benefit of two diverse groups addressing testing methods and results: two heads are better than one!
59
>Meeting with
>Meeting NRC on with NRC April 29, on April 2008 29, 2008 59 i AREVA NP Inc. IL
V& V Methodology Requirements TraCeability P FAT is a formal project milestone that will be attended by both AREVA NP Quality Assurance and Duke Energy personnel.
o FAT fulfills requirement for validation.
P During FAT, V&V engineers observe testing and verify that testing follows approved FAT procedures.
0 V&V team uses software requirements traceability matrix to ensure that original requirements have been tested.
o V&V engineers independently verify that software versions being tested match those in Software Configuration Management list.
60 AREVA NP Inc. >Meeting with NRC
>Meeting with Apr11 29, on April NRC on 2008 29, 2008 60 I
Software ProgramManual Testing Option 2 Oconee Units 2 and 3 Tracing and Testing Scope of the Design -L-
-I--
Scope of the V&V System part
(= HW + SW)
Software part I
61
>Meeting wfth NRC
>Meeting with April29, on April NRC on 2008 29, 2008 61
Review & Verification Activities General Process AREVA ýp I., >Meeting with NRC on April 29, 2008 62
Testing V&V Methods
-4 m
co m
Cl) z-<
CA) 63
>Meeting with NRC
>Meeting with on April NRC on 29, 2008 April29, 2008 63
A Testing V&V Methods
.cut mn 64
>Meeting with
>Meeting NRC on with NRC on Apfil 29, 2008 April29, 2008 64
A 0* -
Testing V&V Conclusions
> The V&V approach to testing is equivalent or better than methods identified in IEEE Std 1012-1998.
< Use of two diverse groups to assess testing method and results provides a stronger test than a single test perspective.
" No manual code generation for the safety system software.
< Software is automatically generated from the network diagrams and function diagrams by the qualified SPACE tool.
" SPACE generates diagrams that can be readily checked by an independent team to verify that requirements are met and that validation testing is correct.
L >Meeting with NRC on April 29, 2008 65
Testing V&V Availability of Oconee Tests V& V Reports P The following Oconee Unit 1 software V&V reports will address testing activities:
Oconee Unit 1 Software V&V Report Target Availability Design V&V Activity Summary Report
- SIVAT Test Plan Verification June 2008
- Acceptance Test Plan Verification Implementation V&V Activity Summary Report
- SIVAT Test Report and Test Incident Report August 2008 Verification Test V&V Activity Summary Report
" Acceptance Test Design Specification Verification
" Acceptance Test Case Specification Verification March 2009
- Acceptance Test Procedure Verification
- Acceptance Test Verification 66 IP Inc. >Meeting with
>Meeting NRC on with NRC April 29, on April 2008 29, 2008 66 I
Closing Closing mRV PIc >Meeting with NRC on April 29, 2008 67
Backup Slides 68 AREVA >Meeting with
>Meeting April 29, on April NRC on with NRC 2008 29, 2008 68
TELEPERM XSTM System Platform Architecture Layered Software Structure on a ProcessingModule System software Function block library ITELEPERM XSTm runtime environment I
- plant-independent U
- pre-developed
- qualified for safety applications Operating system software and services I (MICROS, MicroNET)
I U
I Hardware-specific software II I 69
>Meeting with NRC
>Meetlng with April29, on April NRC on 2008 29, 2008 69