Off-The-Shelf Software Components in systems important to safety (EPR - European Pressurized water Reactor) Nguyen N.Q. THUY RESEARCH AND DEVELOPMENT DIVISION.

Slides:



Advertisements
Similar presentations
Chapter 12 Prototyping and Testing Design of Biomedical Devices and Systems By Paul H. King Richard C. Fries.
Advertisements

Design of Experiments Lecture I
What is Software Design?. Systems Development Life- Cycle Planning Analysis Design Implementation Design.
RISK INFORMED APPROACHES FOR PLANT LIFE MANAGEMENT: REGULATORY AND INDUSTRY PERSPECTIVES Björn Wahlström.
No: 1 CEMSIS 1 Potential for influencing standards and broadening collaboration N. Thuy EDF R&D.
1 Software Testing and Quality Assurance Lecture 33 – Software Quality Assurance.
1 Verification, validation and testing Chapter 12, Storey.
1 Certification Chapter 14, Storey. 2 Topics  What is certification?  Various forms of certification  The process of system certification (the planning.
Soft. Eng. II, Spr. 02Dr Driss Kettani, from I. Sommerville1 CSC-3325: Chapter 6 Title : The Software Quality Reading: I. Sommerville, Chap: 24.
Westinghouse Atom Atom- 1 Design of Digital Safety Systems in NPP Improvements regarding: System Requirements, Engineering, Argumentation for a Safety.
School of Computing, Dublin Institute of Technology.
Software Issues Derived from Dr. Fawcett’s Slides Phil Pratt-Szeliga Fall 2009.
The Modular Structure of Complex Systems D.L. Parnas, P.C. Clement, and D.M. Weiss Published in IEEE Transactions on Software Engineering, March 1985 Presented.
Purpose of the Standards
©Ian Sommerville 2006Critical Systems Slide 1 Critical Systems Engineering l Processes and techniques for developing critical systems.
BS EN ISO 14001:2004 Madlen King BSc MSc MIEMA EMS Lead Assessor Lloyd’s Register Quality Assurance Ltd BS EN ISO 14001:2004.
Chapter 24 - Quality Management
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 1 Software testing.
CS 4310: Software Engineering
Expert System Presentation On…. Software Certification for Industry - Verification and Validation Issues in Expert Systems By Anca I. Vermesan Presented.
Database System Development Lifecycle © Pearson Education Limited 1995, 2005.
1 Software Process Lecture Outline Nature of software projects Engineering approaches Software process A process step Characteristics of a good.
University of Palestine software engineering department Testing of Software Systems Fundamentals of testing instructor: Tasneem Darwish.
No: 1 CEMSIS 1 WP3 - Use of pre-developed products Key issues N. Thuy EDF R&D.
Lec#3 Project Quality Management Ghazala Amin. 2 Quality Specialist-Job responsibility Responsibilities Reports monitoring and measurement of processes.
1 Assessment Topics, Part 1 Thuy Nguyen and Ray Torok Joint IAEA - EPRI Workshop on Modernization of Instrumentation and Control Systems in NPPs
المحاضرة الثالثة. Software Requirements Topics covered Functional and non-functional requirements User requirements System requirements Interface specification.
IRSN STRATEGY TO ASSESS A NEW MAINTENANCE POLICY / Nesebar, Bulgaria Presented by Naoëlle MATAHRI, IRSN.
Software Engineering Chapter 23 Software Testing Ku-Yaw Chang Assistant Professor Department of Computer Science and Information.
© Grant Thornton | | | | | Guidance on Monitoring Internal Control Systems COSO Monitoring Project Update FEI - CFIT Meeting September 25, 2008.
1 Software Quality CIS 375 Bruce R. Maxim UM-Dearborn.
Chapter 2: Software Process Omar Meqdadi SE 2730 Lecture 2 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
1 Software Testing and Quality Assurance Lecture 33 – Software Quality Assurance.
1 Software testing. 2 Testing Objectives Testing is a process of executing a program with the intent of finding an error. A good test case is in that.
© GMV, 2010 Propiedad de GMV Todos los derechos reservados EUROPEAN GNSS EGNOS AND GALILEO. CHARACTERISTICS AND ADVANTAGES OF BRUSSELS. OCTOBER 1 st, 2010.
Ranga Rodrigo. The purpose of software engineering is to find ways of building quality software.
Overview of Formal Methods. Topics Introduction and terminology FM and Software Engineering Applications of FM Propositional and Predicate Logic Program.
This chapter is extracted from Sommerville’s slides. Text book chapter
No: 1 CEMSIS wp6_beg037_v0_2_fisa 2003 slides.ppt CEMSIS FIKS-CT Cost-Effective Modernisation of Systems Important to Safety Deryk Pavey, Deryk.
1 PED: equivalent overall level of safety PED Annex 1, clause 7: The following provision apply as a general rule. However, where they are not applied,
Lach1MAPLD 2005/241 Accessible Formal Verification for Safety-Critical FPGA Design John Lach, Scott Bingham, Carl Elks, Travis Lenhart Charles L. Brown.
Dtsi/Sol CEA System Software Activities 125/02/2005VD R&D topics Designing tools and system software for:  The management of parallelism Mono-processor.
Main Requirements on Different Stages of the Licensing Process for New Nuclear Facilities Module 4.5/1 Design Geoff Vaughan University of Central Lancashire,
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 9 Slide 1 Critical Systems Specification 1.
Use of Fieldbus in safety related systems, an evaluation study of WorldFIP according to proven-in-use concept of IEC Jean Pierre Froidevaux WorldFIP.
1 The Good, the Bad, and the Ugly: Collecting and Reporting Quality Performance Data.
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.
Static WCET Analysis vs. Measurement: What is the Right Way to Assess Real-Time Task Timing? Worst Case Execution Time Prediction by Static Program Analysis.
Topic 4 - Database Design Unit 1 – Database Analysis and Design Advanced Higher Information Systems St Kentigern’s Academy.
Winter 2011SEG Chapter 11 Chapter 1 (Part 1) Review from previous courses Subject 1: The Software Development Process.
International Atomic Energy Agency Regulatory Review of Safety Cases for Radioactive Waste Disposal Facilities David G Bennett 7 April 2014.
CORROSION FORUM Industry Perspective Sheldon W. Dean 20 May 2003.
High Assurance Products in IT Security Rayford B. Vaughn, Mississippi State University Presented by: Nithin Premachandran.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 1 Software testing.
Lach1MAPLD 2005/241-W Accessible Formal Verification for Safety-Critical FPGA Design BOF-W Presentation John Lach, Scott Bingham, Carl Elks, Travis Lenhart.
Lecturer: Eng. Mohamed Adam Isak PH.D Researcher in CS M.Sc. and B.Sc. of Information Technology Engineering, Lecturer in University of Somalia and Mogadishu.
Toward a New ATM Software Safety Assessment Methodology dott. Francesca Matarese.
About Us! Rob StockhamBA IEng MIEE General Manager Moore Industries-Europe, Inc MemberIEE Honorary Secretary ISA England Institute of Directors DirectorThe.
Software Engineering Process - II 7.1 Unit 7: Quality Management Software Engineering Process - II.
SENG521 (Fall SENG 521 Software Reliability & Testing Preparing for Test (Part 6a) Department of Electrical & Computer Engineering,
Software Testing. SE, Testing, Hans van Vliet, © Nasty question  Suppose you are being asked to lead the team to test the software that controls.
Formalizing standards and regulations variability in longlife projects. A challenge for Model-Driven Engineering Nicolas Sannier* **, Benoît Baudry** and.
Analysis of Current Maturity Models and Standards
Classifications of Software Requirements
BASIC PROFESSIONAL TRAINING COURSE Module V Safety classification of structures, systems and components Case Studies Version 1.0, May 2015.
Software Design Methodology
Regulatory Oversight of HOF in Finland
Chapter 13 Quality Management
Considerations on the Reference Plant Concept
Presentation transcript:

Off-The-Shelf Software Components in systems important to safety (EPR - European Pressurized water Reactor) Nguyen N.Q. THUY RESEARCH AND DEVELOPMENT DIVISION Power Plant Control Branch 6, quai Watier, BP 49 CEDEX, Chatou, France Tel: , Fax: Françoise FICHEUX-VAPNE ENGINEERING AND CONSTRUCTION DIVISION Computer Systems Quality Group Immeuble Lorraine, Boulevard de France, BP 128 CEDEX, Evry, FRANCE Tel: , Fax:

Research and Development Division / Power Plant Control Branch Off-The-Shelf Software Components in systems important to safety Page 2 / 27, SES’98, Monterey EDF (Electricité de France) French electric power utility 56 nuclear power plants in activity 75% of French electricity from nuclear power plants Dampierre

Research and Development Division / Power Plant Control Branch Off-The-Shelf Software Components in systems important to safety Page 3 / 27, SES’98, Monterey EPR - European Pressurized water Reactor Design of future French and German nuclear power plants: EDF, 9 German Utilities Siemens, Framatome French and German licencing authorities Experience from N4 and Konvoï series Extensive use of Off-The-Shelf computer-based systems Work still in progress

Research and Development Division / Power Plant Control Branch Off-The-Shelf Software Components in systems important to safety Page 4 / 27, SES’98, Monterey Classification of systems in nuclear power plants 3 classes of systems important to safety: IEC IEC (draft) N4 series EUR (European Utilities Requirements) EPR Defense in depth

Research and Development Division / Power Plant Control Branch Off-The-Shelf Software Components in systems important to safety Page 5 / 27, SES’98, Monterey Overall gradation of requirements - Class 1 Low complexity Deterministic behavior for computer-based systems: cyclic behavior preferably stateless behavior load independent of external conditions static resource allocation guaranteed response times single (random) failure criterion robustness with respect to errors Software developed according to stringent nuclear industry standards (e.g., IEC 60880)

Research and Development Division / Power Plant Control Branch Off-The-Shelf Software Components in systems important to safety Page 6 / 27, SES’98, Monterey Overall gradation of requirements - Class 2 Controlled complexity Confidence based in particular on analysis of system design High quality software, not necessarily developed according to nuclear industry standards

Research and Development Division / Power Plant Control Branch Off-The-Shelf Software Components in systems important to safety Page 7 / 27, SES’98, Monterey Overall gradation of requirements - Class 3 No specific limit for complexity Confidence mainly based on: proven application of quality standards global demonstration of fitness Specific demonstrations may be required on identified topics

Research and Development Division / Power Plant Control Branch Off-The-Shelf Software Components in systems important to safety Page 8 / 27, SES’98, Monterey Assessment of components Objective: contribute to confidence that system conforms to safety requirements Stringency of assessment depends on: safety class of system how component is used consequences of component errors and failures intrinsic component properties (e.g., complexity)

Research and Development Division / Power Plant Control Branch Off-The-Shelf Software Components in systems important to safety Page 9 / 27, SES’98, Monterey Off-The-Shelf Software Components (OTS-SCs) OTS-SCs usually assessed as « black-boxes »: Specification is available No information on design and implementation No detailed information on development processes « Clear-box » assessment necessary only in some cases: Class 1: normal practice, with exceptions Class 2: required only when black-box assessment not sufficient Class 3: not required Black-box hardware components may contain software

Research and Development Division / Power Plant Control Branch Off-The-Shelf Software Components in systems important to safety Page 10 / 27, SES’98, Monterey Main requirements for assessment of OTS-SCs Precise and complete specification Quality and reliability demonstrated as appropriate Component functionally suitable Use consistent with specification Component and use consistent with system level constraints

Research and Development Division / Power Plant Control Branch Off-The-Shelf Software Components in systems important to safety Page 11 / 27, SES’98, Monterey Component specification Precision and completeness sufficient for: functional assessment of component reliability assessment (e.g., testing) correct use, integration and maintenance Mandatory for all Classes Mainly provided by component supplier may be completed after tests, measurements, operating experience

Research and Development Division / Power Plant Control Branch Off-The-Shelf Software Components in systems important to safety Page 12 / 27, SES’98, Monterey Quality and reliability of OTS-SCs Direct demonstrations: Testing Analysis Certification Operating experience Indirect demonstrations: Quality of development processes Supplier ’s proficiency

Research and Development Division / Power Plant Control Branch Off-The-Shelf Software Components in systems important to safety Page 13 / 27, SES’98, Monterey Testing Development tests (Class 1, clear-box components): coverage of component specification, design & coding documented tests or documented processes Type testing (Class 1, black-box components): based on complete component specification independently of component supplier Testing in conditions of use (Classes 1 & 2)

Research and Development Division / Power Plant Control Branch Off-The-Shelf Software Components in systems important to safety Page 14 / 27, SES’98, Monterey Analysis Applicable to clear-box components only (Class 1) Analysis of: structural complexity quality of design and coding quality of development documentation conformance to applicable software standards behavioral complexity

Research and Development Division / Power Plant Control Branch Off-The-Shelf Software Components in systems important to safety Page 15 / 27, SES’98, Monterey Certification Independent certification may be taken into account if: certifying authority is identified, competent and independent component certified is the one used in the system properties and values certified are identified and appropriate methods, tools and results are documented and appropriate Properties and values required but not certified still need to be demonstrated

Research and Development Division / Power Plant Control Branch Off-The-Shelf Software Components in systems important to safety Page 16 / 27, SES’98, Monterey Operating experience Conditions: components fully identified and similar to the one used conditions of use documented and similar to those in system failures during operating experience are detected and reported Also to be taken into account: functional complexity of the component likely consequences of component failures volume of operating experience (number of components, duration)

Research and Development Division / Power Plant Control Branch Off-The-Shelf Software Components in systems important to safety Page 17 / 27, SES’98, Monterey Quality standards, Proficiency of component supplier Conformance to AIEA 50 CQ-A (Class 1) Level equivalent to ISO 9000 series (All Classes) Certification of supplier may be taken into account if: certifying authority is identified, competent and independent reference for certification is identified and appropriate Proven experience of supplier in developing successfully similar products (Classes 1 & 2)

Research and Development Division / Power Plant Control Branch Off-The-Shelf Software Components in systems important to safety Page 18 / 27, SES’98, Monterey Functional suitability, Complexity Functional suitability of component (Classes 1 & 2): component satisfies documented needs and constraints complexity not out of proportion with needs and constraints Complexity of component and of « binding » code: functional complexity structural complexity behavioral complexity

Research and Development Division / Power Plant Control Branch Off-The-Shelf Software Components in systems important to safety Page 19 / 27, SES’98, Monterey Use in the system Conditions of use proven to remain within component specification (Classes 1 & 2) Restricted use may ease demonstration of reliability Caution recommended (Classes 1 & 2): stable conditions of use possible errors and failures of component detected as early as reasonable reasonable defense against unacceptable consequences

Research and Development Division / Power Plant Control Branch Off-The-Shelf Software Components in systems important to safety Page 20 / 27, SES’98, Monterey Consistency with system level constraints Predictable behavior (Classes 1 & 2): precise specification of component behavior documented conditions of use in system Deterministic behavior (Class 1): static resource allocation static parameterization preferably stateless behavior clear-box (with limited exceptions) proven maximum response time proven robustness against consequences of errors

Research and Development Division / Power Plant Control Branch Off-The-Shelf Software Components in systems important to safety Page 21 / 27, SES’98, Monterey Black-box OTS-SCs in Class 1 systems Very large operating experience Low functional complexity Stable conditions of use System protected as appropriate against propagation and consequences of errors

Research and Development Division / Power Plant Control Branch Off-The-Shelf Software Components in systems important to safety Page 22 / 27, SES’98, Monterey Example: OTS-SCs in a Class 2 Supervision system Typical OTS-SCs Real Time Operating System (RT-OS) Graphic-HMI libraries Basic communication software Software buried in dedicated OTS hardware components Black-boxes

Research and Development Division / Power Plant Control Branch Off-The-Shelf Software Components in systems important to safety Page 23 / 27, SES’98, Monterey RT-OS Main characteristics: ` functionally complex ` errors & failures may be subtle + some already in use in systems important to safety Operating experience necessary, but not sufficient Confidence mainly based on: pre-existing certification, if any very cautious use extensive testing in conditions of use

Research and Development Division / Power Plant Control Branch Off-The-Shelf Software Components in systems important to safety Page 24 / 27, SES’98, Monterey Graphic-HMI libraries Main characteristics: ` functionally complex ` not developed specifically for safety applications + modular + very wide market + in some cases, source code is public Operating experience necessary, but not sufficient Confidence mainly based on: supplier ’s proficiency quality of development processes very cautious use extensive testing in conditions of use

Research and Development Division / Power Plant Control Branch Off-The-Shelf Software Components in systems important to safety Page 25 / 27, SES’98, Monterey Basic communication software Main characteristics: + functional complexity reasonably low + very wide market + some already in use in systems important to safety + failures unlikely to go unnoticed Confidence mainly based on: low functional complexity large operating experience pre-existing certification, if any testing in conditions of use

Research and Development Division / Power Plant Control Branch Off-The-Shelf Software Components in systems important to safety Page 26 / 27, SES’98, Monterey OTS-HC embedding software Main characteristics: + functional complexity reasonably low + wide market Confidence mainly based on: low functional complexity very large operating experience very cautious use testing in conditions of use

Research and Development Division / Power Plant Control Branch Off-The-Shelf Software Components in systems important to safety Page 27 / 27, SES’98, Monterey Conclusion OTS-SCs unavoidable, even in systems important to safety No simple magic formula for assessing OTS-SCs Engineering judgement still needed