overview of deterministic safety analysis: input data, verification & validation,...

Overview of Deterministic Safety Analysis:Overview of Deterministic Safety Analysis:Input Data, Verification & Validation, Input Data, Verification & Validation,

Conservative/BE ApproachesConservative/BE Approaches (Part. 2) (Part. 2)

IAEA Training Course on Safety Assessment of NPPs to Assist Decision Making

Workshop InformationWorkshop InformationIAEA WorkshopIAEA Workshop

LecturerLesson IV 2_2

City , CountryXX - XX Month, Year

IAEA Training Course on Safety Assessment of NPPs to assist Decision Making

2

Input Data PreparationInput Data Preparation

– The construction of the input data to a Safety Analysis must be subject of an adequate Quality Assurance programme. All sources of data must be referenced and documented. The whole process must be recorded and archived to allow independent checking.


3

Input Data PreparationInput Data Preparation– Input data to a conservative DSA:

• Conservative initial values of the plant variables.• Conservative boundary conditions through the transient (e.g.

systems and operator performances).• Conservative physical models in the code.

– Different degrees of conservatism:

• Most variables are set to “high” values (taking account of their probability distribution functions). E.g.: average value plus “two sigma”, or 95 percentile…

• Some variables can be set to extremely high values. E.g.: values established in Appendix K to 10 CFR 50, for LOCA analysis.


4

Input Data PreparationInput Data Preparation– Conservative assumptions made for DB analysis:

• Initiating event occurs at an unfavourable time.• Control systems operate only if their functioning would

aggravate the effects of the initiating event. No credit for mitigation.

• All plant systems and equipment no designed as safety grade (full QA, seismic and equipment qualification) should be assumed to fail causing the most severe effects for the PIE

• Worst single failure assumed in the operation of the safety groups required for the initiating event. For redundant systems it is often assumed running of minimum number of trains.


5


• Safety systems assumed to operate at their minimum performance levels.

• Structures, systems or components that do not have proven full operability during the accident should be assumed unavailable.

• Actions of the plant staff to prevent or mitigate the accident are only modelled when it is shown that there is sufficient time to perform them, and that procedures and training are adequate.


6


– DB analysis should include any failures which could occur as a consequence of the IE, including:

• If the IE is part of an electrical distribution system, all the equipment powered from that part will be unavailable.

• If the IE is an “energetic event” (failure of pressurised system), failure of the equipment that could be affected.

• Fire, floods or external events: failure of the equipment neither designed nor protected against the effects.


7


– For AOOs, the deterministic SA should include many of the conservative assumption of the DBA analysis, especially those related to the systems for maintaining critical safety functions. But it’s not necessary to assume unavailability of all non-safety systems and equipment or no credit to mitigation by control systems, unless the PIE impose it.


8

Input Data PreparationInput Data Preparation– Input data to a best-estimate DSA:

• Plant and model parameters and variables that will participate in the uncertainty analysis: set to realistic values. But the input is not a single value, rather a probability density function (pdf).

• Variables and parameters that will not intervene in the uncertainty analysis will be set to conservative values.

– Both conservative and BE analysis need to know the probability distribution of the uncertain variables and parameters. But the knowledge must be finer for the BE approach, coarser for the conservative one.


9

Verification and ValidationVerification and Validation

– Verification and Validation (V&V) of computer codes for safety analysis:

• Systematic approach for improving reliability of computer codes and reduce risk of incorrect application.

• Activities that can be performed in parallel with the code development process, or a posteriori.

• The project sponsor should determine the level and modality of V&V efforts.

– ANSI/ANS-10.4-1987


10


– Verification: process of evaluating the products of a software development phase to provide assurance that they meet the requirements defined for them by the previous phases.

– Validation: process of testing a code and evaluating the results to ensure compliance with specified requirements.

• Testing is carried out by the code developer. Must be evaluated, supplemented or independently performed by a separate V&V team.


11


VALIDACIÓN

VERIFICATION

REALITY MATH MODEL CODE DESIGN CODE


12


• The code is validated when tests results are shown to meet criteria previously stated.

– V&V activities are performed by the code developer or by an independent V&V team.

– Model/user qualification is considerably simplified if the codes involved have been adequately V&V.


13


“PARALLEL” V&V– Software development phases (orientative):

• Initiation• Requirements definitions• Design• Coding• Integration and testing• Installation• Operation and maintenance


14


– Details of the V&V process: in each phase:• Results should be documented and reported. Each V&V

activity should produce a report describing both the positive and negative results of the analysis or testing performed.

• If V&V findings require revisions to the documents and products that are being verified, the modified ones should be reverified before the next phase begins.

• Checklists (containing questions that must be answered) should be used in the verification process.


15

Verification and ValidationVerification and Validation– Example of checklist for verification


16

Verification and ValidationVerification and ValidationINITIATION PHASE

– The products generated:

• Statement of the problem

• Management Plan, that form the basis of the development and V&V efforts of the project. Includes V&V planning:

Who will perform itLevel of effortActivitiesResponsibilitiesProducts, schedule, reporting...


17

Verification and ValidationVerification and ValidationDEFINITION PHASE:

– Preparation of the V&V plan, according with the Management Plan. Topics included:

• V&V plan description• V&V approach: activities, tools, documents…• V&V project organization an management

– Verification of requirements :

• A document of “Requirements Specification” (RS) is produced, that form the foundation both for code development and V&V

• RS identifies inputs, outputs, interfaces, models to be used, acceptance criteria for the code, basis for verifying the code...


18


• RS must be verified: this has a positive impact in the improvement of software quality

– Development of preliminary test plans: A Test Plan specifies all activities required for program validation, including descriptions of all test cases. The software testing is carried out by:

• Only the developer.• Developer, then evaluated by IV&V team.• Developer, evaluated by IV&V team, who in addition performs

a full, independent test effort.• Both developer and IV&V team perform full, independent test

efforts.


19

Verification and ValidationVerification and Validation– Verification of preliminary Test Plans, conforming to RS and

V&V and Management Plans.

DESIGN PHASE:

– Verification of design.– Verification of the preliminary program documentation, to

ensure that code input descriptions are sufficient to permit test planning.

– Update of Test Plans: additional tests may be needed.– Verification of the updated Tests Plans: consistency with

previous documents.


20

Verification and ValidationVerification and ValidationCODING PHASE:

– Verification of source code:

• Source code (list of machine-readable statements, usually in a high level language) should be a clear and correct representation of the design specification.

• Includes manual code inspection.

– Verification of the updated code documentation.– Completion of final Test Plans and building of Test Data Bases:

input data for each test case is generated.– Verification of final Test Plans and Test Data Bases.


21

Verification and ValidationVerification and ValidationINTEGRATION AND TESTING PHASE:

– Verification of code integration:• The source code together with all necessary components form an

operational package.• Compilation and loading generates the integrate code, which is the final

product, on which Test Plans will be executed.

– Execution of the Test Plans - Validation:• Test cases are executed, and results evaluated and compared to their

expected values stated in RS.• This is used to produce a “total performance envelope” for the code, that

must meet acceptance criteria.• A test report is prepared.


22

Verification and ValidationVerification and Validation– Verification of test results, with evaluation of the Test Report

and test outputs.

INSTALLATION PHASE:

– Verification of the installation package:

• The package includes installation procedures, files that must be installed, selected test case data for verifying installation.

• The package, once verified, may be used for backup and distribution.

– Verification of the final code documentation, including user manual, mathematical background, programmer manual, etc.

– Preparation of final V&V report, summarizing all activities.


23

Verification and ValidationVerification and ValidationOPERATION AND MAINTENANCE PHASE:

– Modifications in the operating environment, to accommodate upgrades in system software or hardware. Some test cases could be rerun.

– Code modifications, if errors are discovered during operation, or operating environment has changed, or requirements have been changed. When the code is modified:

• Test Plans should be reviewed.• Selected cases rerun. • Maybe new cases introduced.


24



25

Verification and ValidationVerification and ValidationV&V OF EXISTING CODES:

– Sometimes parallel V&V may be inappropriate. (e.g.: research project whose end product is the code). Then a posteriori V&V review (or “Design Review”) is used.

– Purpose: determine whether the code produces valid response when applied to problems in some domain.

– Results in document “V&V Review Report”– Phases:

• Preparation of V&V Review Plan• Determination of Code Requirements (applications, models,

numerics, valid responses,etc), which must be verified• Review of code design, even verification


26

Verification and ValidationVerification and Validation• Review of source code, code integration and documentation

• Review of code testing: adequacy of test coverage

• Review or test results - validation : Range of validity: determined on the basis of physical

observations, analytic means, comparison with validated programs

In many cases, the code being reviewed is the only tool capable of analyzing the problems of interest. Physical observations may be available only for simplified, distorted conditions, and analytic results only for trivialized cases. The validation becomes a more subjective process, dependent of judgement of V&V team

• V&V Review Report


27

Conservative vs. Best-estimate approachesConservative vs. Best-estimate approaches

– Deterministic Safety Analysis has been traditionally carried out with a conservative or pessimistic bias.

– As described in previous section, conservative DSA makes use of pessimistic assumptions everywhere, so that the results of the analyses are expected to be “worse” than realistic ones (“bounding”):

• Conservative initial and boundary conditions.

• Models in the computer codes are chosen as conservative.


28


– Conservative DSA have been very popular, because it is relatively “easy” to perform. But the convenience of such an approach does not “excuse” the analyzer from being aware of the accuracy of the models and assumptions.

– A very characteristic example of conservative analysis: LOCA analysis for LWR according to section 46 and appendix K to 10 CFR 50. The conservativeness imposed by the appendix K requirements is very large, because some parameters/models are given overwhelmingly pessimistic values.


29


– Conservatisms imposed by the Appendix K to 10 CFR 50:• Stored energy: initial steady temperatures chosen so as to

maximize the strored energy in the fuel.

• Decay heat: heat generation rate from radioactive decay are 1.2 times the 1971 ANS Standard (this is a overestimation of about five standard deviations !!!).

• Metal-water reaction: conservative Baker-Just model. If cladding ruptures, both inner and outer surfaces are assumed to react.


30

Conservative vs. Best-estimate approachesConservative vs. Best-estimate approaches• Discharge from break: critical flow is based on the conservative

Moody model multiplied by discharge coefficients (from 0.6 to 1.0) that lead to the worst results.

• ECCS bypass: during most of the blowdown period for a PWR cold leg break, the ECCS water is assumed to be ineffective in refilling the system.

• No return to nucleate or transition boiling: once CHF has occurred in the blowdown period, no return to nucleate or transition boiling is allowed during blowdown; it must be postponed until the reflood period.


31


• Film boiling correlations, chosen to underpredict data.

• Single failure: it is assumed that one of the ECCS components fails, and the failure leading to the highest damage is chosen.

– Acceptance criteria for a LOCA Analysis (after 10 CFR 50.46)• Peak cladding temperature (PCT) lower than 2200 ºF.

• Maximum cladding oxidation lower than 0.17 times the total cladding thickness before oxidation. If cladding rupture is predicted, the inside surfaces will participate in the oxidation.


32


• Maximum hydrogen generation resulting from the cladding oxidation: lower 0.01 times the amount that would be generated if all the cladding metal were to react.

• Core geometry will remain amenable to cooling.

• Long-term cooling.


33


– Best-estimate or realistic DSA:

• Starting to develop in recent years, when the capabilities for simulating the phenomenology originated by accidents has increased.

• Try to unbiasedly reproduce the real plant behaviour during an accident or transient.

• Realistic models and assumptions.

• Must include an uncertainty analysis for the important results, that must be given with an “error interval”.


34


– The advantages of a realistic DSA:

• In principle, being realistic is harder that being pessimistic. Conservative models can be simple.

• Robust demonstration that there are large safety margins.• In both approaches you must know the accuracy of your

models and assumptions. But in the BE approach you must quantify such accuracy (uncertainty study).

• Given an accident scenario in a plant, a conservative analysis can make use of only one or some few computer code runs. But in a BE analysis you need “many” computer runs, in order to carry out the uncertainty analysis.


35


– The advantages of a realistic DSA:

• You look for the “real” performance of your plant. Conservative methodologies use to be physically unrealistic (misleading sequences of events, unrealistic time scales, missing of physical phenomena). BE calculations can provide guidance in developing accident management plans.

• Lower margins : safety margins adopted for a plant with a conservative approach may be unnecessarily large. BE margins may permit augment reactor power.

• You have a precise idea about the sensitivity of the calculations to variables and parameters.


36

Conservative vs. Best-estimate approachesConservative vs. Best-estimate approaches– Best-estimate LOCA analysis:

• Recently developed methodologies.• Makes use of realistic assumptions and codes: TRAC-P,

TRAC-B, RELAP5, COBRA-TRAC,…that incorporate state-of-the-art models.

• Must include an uncertainty analysis.• Drops out the Appendix K requirements.• Regulatory door open:

SECY-83-472 1988 revision of 10 CFR 50 Regulatory Guide 1.157 (1989) CSAU Methodology (1989)

overview of deterministic safety analysis: input data, verification & validation,...

Documents