18.4.2005 61508-työryhmä

Automaatiojärjestelmien kelpoistaminen – ohjelmistot.(Turvallisuuskriittisten ohjelmoitavien automaatiosovellustenkelpoistamisesta)

Pentti Haapanen

18.4.2005 61508-työryhmä

http://www.stuk.fi/julkaisut_maaraykset/fi_FI/tutkimusjulkaisut/

STUK-YTO-TR 202 Haapanen P, Helminen A, Pulkkinen U. Quantitative reliability assessment in the safety case of computer-based automation systems. STUK, Helsinki 2004.

STUK-YTO-TR 198 Helminen A, Pulkkinen U. Reliability assessment using Bayesian network. Case study on quantative estimation of a software-based motor protection relay. STUK, Helsinki 2003.

STUK-YTO-TR 171 Haapanen P, Korhonen J, Pulkkinen U. Licensing process for safety-critical software-based systems. STUK, Helsinki 2000.

STUK-YTO-TR 119 Korhonen J, Pulkkinen U, Haapanen P. Statistical reliablity assessment of software-based systems. STUK, Helsinki 1997

18.4.2005 61508-työryhmä

IEC TC 45 Nuclear Instrumentation SC 45A Instrumentation and control of nuclear facilities

IEC 60880 (1986-09) Software for computers in the safety systems of nuclear power stations

IEC 60880-2 (2000-12) Software for computers important to safety for nuclear power plants - Part 2: Software aspects of defence against common cause failures, use of software tools and of pre-developed software

IEC 61513 (2001-03) Nuclear power plants - Instrumentation and control for systems important to safety - General requirements for systems

IEC 60880 Ed. 2.0 (CDV, 2004-09) I&C systems important to safety - Software aspects for computer based systems performing category A functions

IEC 61226 (2005-02) Nuclear power plants - Instrumentation and control systems important to safety - Classification of instrumentation and control functions

18.4.2005 61508-työryhmä

Process

Sensors Actuators

Control room, operation automation

Protection logic

PT

(PT) (PT)

PT ~ Programmable technology

Alustat/laitteet

• Kiinteästi ohjelmoidut

• Parametroitavat

• Konfiguroitavat

• Vapaasti ohjelmoitavat

18.4.2005 61508-työryhmä

Modules

HardwareSoftware

Systems

HardwareSoftware

Tools

DesignV&V

Standard platform

Application

Specifications- functions- performance- integrity

18.4.2005 61508-työryhmä

C5) Suppliers are quoting that their products conform to IEC 61508 for a specific safety integrity level. Does this mean that using these products is sufficient for me to comply with IEC 61508?

No. A safety integrity level is not directly applicable to individual subsystems or components. It applies to a safety function carried out by the E/E/PE safety-related system.

IEC 61508 covers all components of the E/E/PE safety-related system, including field equipment and specific project application logic. All these subsystems and components, when combined to implement the safety function (or functions), are required to meet the safety integrity level target of the relevant functions. Any design using supplied subsystems and components that are all quoted as suitable for the required safety integrity level target of the relevant functions will not necessarily comply with the requirements for that safety integrity level target. A simple example is when the subsystem or component is incorrectly installed.

Important factors to be quoted by the supplier are the rate of unrevealed (i.e. not detected by the on-line diagnostic tests) dangerous failures and the diagnostic test interval (needed to ensure that a safe reaction

to revealed dangerous failures can be achieved quickly enough).

IEC 61508: Frequently Asked Questionshttp://www.iee.org/oncomms/pn/functionalsafety/61508faq_index.cfm

18.4.2005 61508-työryhmä

18.4.2005 61508-työryhmä

Laws

Regulations

Safetyimportance

Safetyclassification-1, 2, 3 & EYT

Acceptance criteria - deterministic - reliability

Developmentprocess - procedures - depth

Assessmenttprocess - procedures - depthSafety

analyses

18.4.2005 61508-työryhmä

Licensingauthority

Otherexperts

Utility

PlantVendor

Systemvendor(s)

Designteam

Independentassessor(s)

E = evidenceA = assessmentL = license

E

L

A

E

EE

E

E

18.4.2005 61508-työryhmä

1

2

3

4

5

6

7

8

1

2

3

4

Acceptable safety demonstration

Standars

Specification

Prototypes

Peer check

V&V

Testing

Commissioning

Pre-operational soak

Manual checks

Static analyses

Source codecomparison

Dynamic testing

Excellence ofmanufacturing

Independentconfidence building

18.4.2005 61508-työryhmä

Qualityof designprocess

Qualityofproduct

* Standards* Guidelines* Tools - production - testing - analysis* Skills* QC/QA

* Testing* Analyses* Operational experience

Applicant: - provides evidence - own - vendor - independent experts

Authority: - assesses provided evidence - aquires independent evidence - own assessments - independent assessments

Pool of evidences - qualitative - quantitative

Combination of evidence - authority - independent expert

Independence - free access to information - diverse tools & methods - freedom of expression

Reject Accept

Requirements Evidence

100 kg

18.4.2005 61508-työryhmä

Evidence

Evidence

Evidence Claim

Inference rule

Inference rule

Argument

18.4.2005 61508-työryhmä

PLATFORM

APPLICATION

DESIGN PROCESS PRODUCT

HIGH QUALITYDESIGN PROCESS

HIGH QUALITYDESIGN PROCESS

HARDWARESOFTWARE - SYSTEM - MODULESDESIGN TOOLSV&V TOOLS

TESTINGANALYSESOPERATIONAL EXPERIENCE

TYPE QUALIFICATIONOPERATIONAL EXPERIENCE

APPLICATION

TYPE QUALIFICATIONDOCUMENTATION

DOCUMENTATIONAUDITS

18.4.2005 61508-työryhmä

18.4.2005 61508-työryhmä

System reliability

Pro

bab

ility

Designprocess 1

Designprocess 2

Lowerconfidencebound

Acceptancelimit

18.4.2005 61508-työryhmä

designerror

manufacturingflaw

inherentsw fault

fault insystem

conditionalmalfunction

ageing

externalinfluences

randomhw failure

inherenthw fault

immediatemalfunction

triggeringinput

&

implementationflaw

productiondeficiencies

18.4.2005 61508-työryhmä

Input space Program internal states

Output space

Error!

Input distribution State distribution

18.4.2005 61508-työryhmä

Table I. Failure types and defences.Fault types Random component

faultsInherent design

faultsExternal events

Failure types Single failure Can lead to Common Cause Failures (CCF)Redundancy Diversity Separation/segregati

onDefence

1oo2 sufficient forsafety, but can causeinadvertentactuations. Theselower the plantavailability and canalso act as initiatingevents for accidentscenarios

2oo3 sufficient bothfor safety andavailability butreduces to 1oo2when one train isfailed/undermaintenance.

2oo4 manages all theprevious if nocommon causefailures present

Proper selection ofhardware, softwareand implementationdiversity can protectthe redundanciesagainst commoncause failures causedby inherent faults.

Functional diversityis considered a gooddefence againstcommon causefailures in diverseredundancies.

Physical separationand geographicalsegregation protectsthe redundancies tofail due externalevents.

Functionalseparation preventsthe spreading offailure effects fromthe failedredundancy toothers.

Total defence Diversity and separation/segregation between redundant trainsResidual problem Common cause failures in diverse redundancies?

Solution: Functional diversity (= Defence in Depth)?

18.4.2005 61508-työryhmä

Tilastollinen luotettavuustestaus

18.4.2005 61508-työryhmä

1,0E-05

1,0E-04

1,0E-03

1,0E-02

1,0E-01

100 1 000 10 000 100 000 1 000 000

Number of succesfull tests

Fai

lure

pro

bab

ility Confidence level 0.9

Confidence level 0.95

Confidence level 0.99

Confidence level 0.999

18.4.2005 61508-työryhmä

1,0E-05

1,0E-04

1,0E-03

1,0E-02

1,0E-01

100 1 000 10 000 100 000 1 000 000

Number of successfull tests

Upp

er p

oste

rior

90%

frac

tile