Download
slide1 n.
Skip this Video
Loading SlideShow in 5 Seconds..
EDF (Electricité de France) PowerPoint Presentation
Download Presentation
EDF (Electricité de France)

EDF (Electricité de France)

253 Vues Download Presentation
Télécharger la présentation

EDF (Electricité de France)

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Off-The-Shelf Software Components in systems important to safety (EPR - European Pressurized water Reactor)Nguyen N.Q. THUYRESEARCH AND DEVELOPMENT DIVISION Power Plant Control Branch 6, quai Watier, BP 49 CEDEX, 78401 Chatou, France Tel: +33 1 30 87 72 49, Fax: +33 1 30 87 82 84e-mail: thuy.nguyen@edfgdf.frFrançoise FICHEUX-VAPNEENGINEERING AND CONSTRUCTION DIVISION Computer Systems Quality Group Immeuble Lorraine, Boulevard de France, BP 128 CEDEX, 91004 Evry, FRANCE Tel: +33 1 60 87 46 49, Fax: +33 1 60 87 46 70e-mail: francoise.ficheux-vapne@edfgdf.fr

  2. Penly Gravelines Paluel Chooz Cattenom Flamanville Nogent Fessemheim Chinon St-Laurent Civaux Belleville Bugey Le Blayais Creys-Malville Golfech St-Alban Cruas Tricastin Marcoule EDF (Electricité de France) • French electric power utility • 56 nuclear power plants in activity • 75% of French electricity from nuclear power plants Dampierre

  3. 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

  4. Classification of systems in nuclear power plants • 3 classes of systems important to safety: • IEC 61226 • IEC 61513 (draft) • N4 series • EUR (European Utilities Requirements) • EPR • Defense in depth

  5. 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)

  6. 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

  7. 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

  8. 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)

  9. 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

  10. 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

  11. 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

  12. Quality and reliability of OTS-SCs • Direct demonstrations: • Testing • Analysis • Certification • Operating experience • Indirect demonstrations: • Quality of development processes • Supplier ’s proficiency

  13. 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)

  14. 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

  15. 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

  16. 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)

  17. 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)

  18. 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

  19. 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

  20. 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

  21. 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

  22. 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

  23. 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

  24. 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

  25. 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

  26. 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

  27. Conclusion • OTS-SCs unavoidable, even in systems important to safety • No simple magic formula for assessing OTS-SCs • Engineering judgement still needed