1 / 27

EDF (Electricité de France)

betty_james
Download Presentation

EDF (Electricité de France)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

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

More Related