Off-The-Shelf Software Components in systems important to safety
Download
1 / 27

off-the-shelf software components in systems important to safety ... - PowerPoint PPT Presentation


  • 200 Views
  • Uploaded on

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'off-the-shelf software components in systems important to safety ...' - betty_james


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Slide1 l.jpg

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: [email protected]ç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: [email protected]


Edf electricit de france l.jpg

Penly safety

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


Epr european pressurized water reactor l.jpg
EPR - European Pressurized water Reactor safety

  • 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


Classification of systems in nuclear power plants l.jpg
Classification of systems in nuclear power plants safety

  • 3 classes of systems important to safety:

    • IEC 61226

    • IEC 61513 (draft)

    • N4 series

    • EUR (European Utilities Requirements)

    • EPR

  • Defense in depth


Overall gradation of requirements class 1 l.jpg
Overall gradation of requirements - Class 1 safety

  • 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)


Overall gradation of requirements class 2 l.jpg
Overall gradation of requirements - Class 2 safety

  • Controlled complexity

  • Confidence based in particular on analysis of system design

  • High quality software, not necessarily developed according to nuclear industry standards


Overall gradation of requirements class 3 l.jpg
Overall gradation of requirements - Class 3 safety

  • 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


Assessment of components l.jpg
Assessment of components safety

  • 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)


Off the shelf software components ots scs l.jpg
Off-The-Shelf Software Components (OTS-SCs) safety

  • 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


Main requirements for assessment of ots scs l.jpg
Main requirements for assessment of OTS-SCs safety

  • 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


Component specification l.jpg
Component specification safety

  • 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


Quality and reliability of ots scs l.jpg
Quality and reliability of OTS-SCs safety

  • Direct demonstrations:

    • Testing

    • Analysis

    • Certification

    • Operating experience

  • Indirect demonstrations:

    • Quality of development processes

    • Supplier ’s proficiency


Testing l.jpg
Testing safety

  • 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)


Analysis l.jpg
Analysis safety

  • 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


Certification l.jpg
Certification safety

  • 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


Operating experience l.jpg
Operating experience safety

  • 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)


Quality standards proficiency of component supplier l.jpg
Quality standards, Proficiency of component supplier safety

  • 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)


Functional suitability complexity l.jpg
Functional suitability, Complexity safety

  • 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


Use in the system l.jpg
Use in the system safety

  • 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


Consistency with system level constraints l.jpg
Consistency with system level constraints safety

  • 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


Black box ots scs in class 1 systems l.jpg
Black-box OTS-SCs in Class 1 systems safety

  • Very large operating experience

  • Low functional complexity

  • Stable conditions of use

  • System protected as appropriate against propagation and consequences of errors


Example ots scs in a class 2 supervision system l.jpg
Example: OTS-SCs in a Class 2 Supervision system safety

  • Typical OTS-SCs

    • Real Time Operating System (RT-OS)

    • Graphic-HMI libraries

    • Basic communication software

    • Software buried in dedicated OTS hardware components

  • Black-boxes


Rt os l.jpg
RT-OS safety

  • 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


Graphic hmi libraries l.jpg
Graphic-HMI libraries safety

  • 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


Basic communication software l.jpg
Basic communication software safety

  • 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


Ots hc embedding software l.jpg
OTS-HC embedding software safety

  • 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


Conclusion l.jpg
Conclusion safety

  • OTS-SCs unavoidable, even in systems important to safety

  • No simple magic formula for assessing OTS-SCs

  • Engineering judgement still needed


ad