1 JRC – IE Petten Benchmark Exercise of Safety Evaluation of Computer Based Systems V.Kopustinskas 1, C.Kirchsteiger 1, B.Soubies 2, F.Daumas 2, J.Gassino.

Slides:



Advertisements
Similar presentations
Ossi Taipale, Lappeenranta University of Technology
Advertisements

Auditing Concepts.
International Energy Agency Hydrogen Implementing Agreement Proposed Task on Hydrogen Safety.
RISK INFORMED APPROACHES FOR PLANT LIFE MANAGEMENT: REGULATORY AND INDUSTRY PERSPECTIVES Björn Wahlström.
Validation, Verification, Qualification : Which is right and does it really matter?
5 december 2011 Living Probabilistic Asset Management Dr.ir. J.A. van den Bogaard.
Off-The-Shelf Software Components in systems important to safety (EPR - European Pressurized water Reactor) Nguyen N.Q. THUY RESEARCH AND DEVELOPMENT DIVISION.
Westinghouse Atom Atom- 1 Design of Digital Safety Systems in NPP Improvements regarding: System Requirements, Engineering, Argumentation for a Safety.
MSIS 110: Introduction to Computers; Instructor: S. Mathiyalakan1 Systems Design, Implementation, Maintenance, and Review Chapter 13.
IS Audit Function Knowledge
Lecture 7 Model Development and Model Verification.
PURPOSE OF DFMEA (DESIGN FAILURE MODE EFFECTS ANALYSIS)
UGDIE PROJECT MEETING Bled September WP6 – Assessment and Evaluation Evaluation Planning  Draft Evaluation plan.
DITSCAP Phase 2 - Verification Pramod Jampala Christopher Swenson.
1 CMPT 275 Software Engineering Requirements Analysis Process Janice Regan,
EVALUATION AND QUALITY ASSURANCE STRATEGY PRESENTED BY DR SHYAM PATIAR.
Software Verification and Validation (V&V) By Roger U. Fujii Presented by Donovan Faustino.
Software Configuration Management
SÄTEILYTURVAKESKUS STRÅLSÄKERHETSCENTRALEN RADIATION AND NUCLEAR SAFETY AUTHORITY Protection of the environment from ionising radiation - views of a regulator.
Codex Guidelines for the Application of HACCP
Formal Methods 1. Software Engineering and Formal Methods  Every software engineering methodology is based on a recommended development process  proceeding.
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 19Slide 1 Verification and Validation l Assuring that a software system meets a user's.
S/W Project Management
No: 1 CEMSIS wp6_beg010_v0_1_fisa slides.ppt CEMSIS FIKS-CT Cost-Effective Modernisation of Systems Important to Safety Deryk Pavey, Deryk Pavey,
Commercial Database Applications Testing. Test Plan Testing Strategy Testing Planning Testing Design (covered in other modules) Unit Testing (covered.
System Implementation. System Implementation and Seven major activities Coding Testing Installation Documentation Training Support Purpose To convert.
Managing the development and purchase of information systems (Part 1)
Institut für Sicherheitstechnologie (ISTec) GmbH BE-SECBS Benchmark Exercise of Safety Evaluation of Computer Based Systems Safety Assessment of MADTEB-Limitation.
Balancing Practices: Inspections, Testing, and Others JAXA scenario (formal method) Masa Katahira Japanese Space Agency.
M.Ellis 17th August MICE Software School Aims Course content –Management –Specifications –Design –Production –Testing –Use Information –Operation.
VTT-STUK assessment method for safety evaluation of safety-critical computer based systems - application in BE-SECBS project.
ITEC224 Database Programming
NIST Special Publication Revision 1
SENG521 (Fall SENG 521 Software Reliability & Testing Software Product & process Improvement using ISO (Part 3d) Department.
Principles of Information Systems, Sixth Edition Systems Design, Implementation, Maintenance, and Review Chapter 13.
Creating a Shared Vision Model. What is a Shared Vision Model? A “Shared Vision” model is a collective view of a water resources system developed by managers.
JRC-IE – Fuel Cell TEsting, Safety and Quality Assurance FCTES QA SUSTDEV Fuel Cells and their applications Research Topic: Generic tools.
© Copyright 2011 John Wiley & Sons, Inc.
> AREVA NP GmbH NRPP-G, AREVA NP All rights are reserved, see liability notice.
BE-SECBS FISA 2003 November 13th 2003 page 1 DSR/SAMS/BASP IRSN BE SECBS – IRSN assessment Context application of IRSN methodology to the reference case.
Principles of Information Systems, Sixth Edition Systems Design, Implementation, Maintenance, and Review Chapter 13.
Quality Evaluation methodologies for e-Learning systems (in the frame of the EC Project UNITE) Tatiana Rikure Researcher, Riga Technical University (RTU),
Bank Audit. Internal Audit Internal audit is an independent, objective assurance activity and can give valuable insight in providing assurance that major.
SmartNets Results Overview SmartNets SmartNets Methods.
NCHRP Project Development of Verification and Validation Procedures for Computer Simulation use in Roadside Safety Applications SURVEY OF PRACTITIONERS.
Over View of CENELC Standards for Signalling Applications
International Atomic Energy Agency Roles and responsibilities for development of disposal facilities Phil Metcalf Workshop on Strategy and Methodologies.
Principles of Information Systems, Sixth Edition 1 Systems Design, Implementation, Maintenance, and Review Chapter 13.
Chapter 1: Fundamental of Testing Systems Testing & Evaluation (MNN1063)
Requirement Engineering. Recap Elaboration Behavioral Modeling State Diagram Sequence Diagram Negotiation.
IAEA International Atomic Energy Agency Methodology and Responsibilities for Periodic Safety Review for Research Reactors William Kennedy Research Reactor.
Software Engineering1  Verification: The software should conform to its specification  Validation: The software should do what the user really requires.
United Nations Oslo City Group on Energy Statistics OG7, Helsinki, Finland October 2012 ESCM Chapter 8: Data Quality and Meta Data 1.
Assoc. Prof. Dr. Ahmet Turan ÖZCERİT.  System and Software  System Engineering  Software Engineering  Software Engineering Standards  Software Development.
Software Testing Mehwish Shafiq. Testing Testing is carried out to validate and verify the piece developed in order to give user a confidence to use reliable.
Software Requirements Specification Document (SRS)
Software Quality Assurance and Testing Fazal Rehman Shamil.
SwCDR (Peer) Review 1 UCB MAVEN Particles and Fields Flight Software Critical Design Review Peter R. Harvey.
What is a software? Computer Software, or just Software, is the collection of computer programs and related data that provide the instructions telling.
Failure Modes, Effects and Criticality Analysis
CRITICAL INFRASTRUCTURE RISK ASSESSMENT SUPPORT CIRAS PROJECT OVERVIEW 2nd Stakeholders’ Workshop Aschaffenburg, November, 26th, 2015 Jaime Martín, Project.
Auditing Concepts.
SOFTWARE TESTING Date: 29-Dec-2016 By: Ram Karthick.
Flooding Walkdown Guidance
Chapter 10 Verification and Validation of Simulation Models
BU IS GIG Chemical, Oil & Gas
Engineering Processes
Verification and Validation Unit Testing
Regulatory Oversight of HOF in Finland
PSS verification and validation
Presentation transcript:

1 JRC – IE Petten Benchmark Exercise of Safety Evaluation of Computer Based Systems V.Kopustinskas 1, C.Kirchsteiger 1, B.Soubies 2, F.Daumas 2, J.Gassino 2, JC. Péron 2, P. Régnier 2, J. Märtz 3, M. Baleanu 3, H. Miedl 3, M. Kersken 3, U. Pulkkinen 4, M. Koskela 4, P. Haapanen 4, M-L.Järvinen 5, H-W.Bock 6, W.Dreves 6, 1) EC DG-JRC, IE (NL);2) IRSN (FR) 3) ISTec (D)4) VTT (FIN) 5) STUK (FIN)6) Framatome ANP (D) To be presented at post -FISA’2003 workshop

2 JRC – IE Petten Project partners Project duration: 01/2001 – 12/2003 Project coordinator: EC-JRC-Inst. for Energy, Petten (Netherlands) Project started by:EC-JRC-IPSC, Ispra (Italy) Industrial partner: Framatome ANP (Germany, form. Siemens) Assessment teams:IRSN (France) ISTec (Germany) STUK and VTT (Finland)

3 JRC – IE Petten Project objectives The project primary target is a comparative evaluation of existing safety assessment methodologies of safety critical computer based systems in use in the nuclear field among EU regulators and technical support organizations.

4 JRC – IE Petten Work packages WP1: High-level specification of the Benchmark Exercise WP2: Reference software study case definition and design WP3: Final specification of the assessment methodologies WP4: Application of the assessment methodologies WP5: Comparison of the assessment methodologies WP6: Project coordination and financial coordination

5 JRC – IE Petten Project implementation Framatome ANP provided a reference case study of a hypothetical reactor protection system, including the requirements and functional specification of a limited number of safety functions that were selected by the project partners. The proprietary documentation was made available to the assessor partners, namely IRSN, ISTec, STUK and VTT. Each assessor applied their assessment methodology to the reference case study. The comparison study was performed to highlight the current practices and methods used in the field by major research and regulatory support organizations.

6 JRC – IE Petten Reference study case The case study comprised a limited part of a complete safety I&C modernization project, using the tools of the TELEPERM XS system platform. 8 MADTEB group functions were selected from the safety functions of the KWU Konvoi plants and which were intended to be applied for the Finland 1400 MW PWR plant (status of 1993 year). The MADTEB functions are part of the reactor limitation system and limit the allowed range of process variables (mainly coolant pressure and pressurizer level) of the primary coolant loop of the reactor.

7 JRC – IE Petten Reference study case MADTEB functions - A33 Reduction of leakage in case of steam generator tube rupture - A34Ensure effectiveness of extra borating system spraying - C31Prevent violation of maximum allowable working pressure - D01 Prevent inadvertent opening of 1st pressurizer safety valve - D02Prevent response of 2nd and 3rd pressurizer safety valve - D32Pressurizer overfeed protection - D33Prevent loss of coolant via stuck open 1st pressurizer safety valve - J34Prevent emptying of pressurizer

8 JRC – IE Petten Reference study case design process Provision of typical documents to be developed in a safety I&C modernization project; Specification of the requirements to be met by the system; Specification of the safety system on the basis of the TELEPERM XS system platform; Detailed design of the functions; Verification of the design using the SPACE-engineering tools of TELEPERM XS; Production of code which is able to run on an existing test system; Demonstration of operation of the code in the test system; Validation tests of the software.

9 JRC – IE Petten Reference study case documentation All the benchmark study related and generic Teleperm XS system documentation was available to the assessors; Software source code was available upon request; A number of technical meetings were organised to provide clarifications and discuss technical questions; FANP made available simulation testing of the benchmarked software

10 JRC – IE Petten Reference study case limitations As a consequence of the limited scope essential parts of a real project were not performed, e. g. - Validation of the functional requirements - Design of interfaces to other systems - Hardware procurement and manufacture - Validation of the hardware

11 JRC – IE Petten Assessment studies and results To be presented by each partner: IRSN ISTec VTT/STUK

12 JRC – IE Petten Comparison procedure The comparison is based for the following main items: - technical basis of different approaches, - depth of analysis allowed to perform by the methodologies; - availability of various methods and analysis tools used for assessment; - assessment phases; - assessment results and findings.

13 JRC – IE Petten Comparison procedure The comparison procedure will not target to - identify any possible deficiencies in the methodologies; - decide which methodology is better or worse; - conclude anything about safety of study case software.

14 JRC – IE Petten Comparison procedure The comparison procedure resulted in a descriptive study of the following main items: - Comparison of the methodological approaches; - Comparison of the assessment studies; - Comparison of the assessment results and findings.

15 JRC – IE Petten Comparison: Regulatory requirements All three assessment teams follow national regulatory requirements, which are mainly based on the international IEC guide. Although based on the same international standard, at the national level, the requirements are slightly different. For example, finnish regulatory guide YVL-5.5 requires quantitative reliability analysis for the safety critical class 1 computer based systems, while the French and German regulations do not. Also finnish regulation explicitly requires FMEA to be performed.

16 JRC – IE Petten Comparison: Life cycle All assessment teams follow basically the same assessment steps that correspond to life cycle phases. The typical assessment procedure starts with general assessment of the quality assurance and V&V plans and engineering process itself. Then each life cycle phase is evaluated. Although different in titles, the content of the life cycle phases is nearly the same. The following life cycle was used for the comparison purposes: - Requirements specification - System specification - Detailed Design - Code generation - Testing

17 JRC – IE Petten Comparison: Quality assurance and eng. process A number of deficiencies were identified by the assessors in this phase. It is important to note that most of them are related to limitations of the study case. This especially concerns FANP testing strategy, as all test were performed by simulation tool SIVAT, but not on a realistic system. In the frame of this benchmark study, testing on a real system would not justified due to limited resources of the project. However, some identified deficiencies, like lack of united life cycle model description or lack of rigorous V&V procedures could be useful to improve the software documentation.

18 JRC – IE Petten Comparison: Requirements specification The results of the assessment indicate the need for independent verification of each development step. As a validation of the specification of the requirements by a process engineer was out of the scope of BE-SECBS, a fault could be identified (incorrect operation of AA011 valve).

19 JRC – IE Petten Comparison: System specification As all previous ones, also this assessment step was performed by the assessors only by a critical review of the documentation. One assessor also used the SPACE-tool for navigating and tracing signal-paths. No critical faults were identified. The deficiencies mentioned by the assessors would be useful to improve the development process and documentation.

20 JRC – IE Petten Comparison: Detailed design Most of the deficiencies reported are related to limitations of the benchmark exercise. However, supported by the SPACE-tool during checking the detailed design, one assessor detected an inconsistency in the function diagram JEB00CS811. According to FANP, it has no impact on the functional behavior of the integrated system, but this unintended inconsistency passed developers verification process. This confirms that in addition to any manufacturer's internal verification process an external independent validation by an assessor is needed.

21 JRC – IE Petten Comparison: Source code No major errors were reported, but the source code analysis by static analysis tools (QAC, Polyspace Verifier, RETRANS) provided some interesting insights that would be hard to observe manually. In addition, a number of potential problem areas were reported that would require more detailed analysis, which was, however, not performed due to limited project resources.

22 JRC – IE Petten Comparison: Testing The assessment results of the testing life cycle phase revealed some differences in the approaches and depth of the analysis: One assessment team concluded that due to the normed structure of the TXS C-code, the definition of the amount of testing that is required is only based on the functionality of the system and not on code-coverage measuring. Within BE-SECBS, the amount of functional testing could be accepted as sufficient; Another assessment team identified the missing tests and other non-compliances with the regulatory requirements and suggested additional tests. These differences could come from the different approaches, analysis tools and different requirements applied.

23 JRC – IE Petten Comparison: Quantitative reliability analysis A Bayesian network (by VTT/STUK) was developed, consisting of the following variables: requirement specification, concept design, detailed design, application C-code, code compilation and linking, platform software and integrated system tests. The main information on which the Bayesian network is built is coming from the limited qualitative assessment, which is based mostly on a critical review of the documentation. No tools or other assessment methods were applied that could enhance the credibility of the quality rating. The quantitative reliability study could significantly be improved with the information that is now available from the qualitative analysis performed by IRSN and ISTec by using QAC, Polyspace Verifier, Claire, Gatel, RETRANS tools.

24 JRC – IE Petten Comparative assessment conclusions The actual findings (in requirements specification and detail design) were identified, this confirms the need for independent as well as internal verification and validation processes to be performed; Assessment tools (both own developed or standard) could enhance a lot the depth of the assessment and the credibility of the evaluation; Quantitative software reliability analysis represents a useful analysis item that could be used also in PSA studies. The credibility of the analysis could be enhanced by information from the qualitative analysis, performed by various analysis tools, used in the exercise.