18.4.2005 61508-työryhmä Automaatiojärjestelmien kelpoistaminen – ohjelmistot. (...
-
Upload
kaylie-lambeth -
Category
Documents
-
view
216 -
download
2
Transcript of 18.4.2005 61508-työryhmä Automaatiojärjestelmien kelpoistaminen – ohjelmistot. (...
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