Qualification of safety-critical systems in TVO nuclear power plants

SOFTWARE PROCESS IMPROVEMENT AND PRACTICESoftw. Process Improve. Pract. 2007; 12: 559–567

Published online 4 July 2007 in Wiley InterScience(www.interscience.wiley.com) DOI: 10.1002/spip.349

Qualificationof Safety-critical Systemsin TVO Nuclear PowerPlants

Practice SectionJuha Halminen1 and Risto Nevalainen2,*,†

1 Teollisuuden Voima Oy, Olkiluoto, Finland2 Finnish Software Measurement Association ry FiSMA, Espoo, Finland

Teollisuuden Voima Oy (TVO) operates two nuclear power plant units in Finland and hasstarted to build a third one. The current nuclear power units have to continuously maintain andupdate existing instrumentation and control systems (I&C). Each new device will have to beclassified and qualified according to its safety requirements. Using modern technology meansin practice that more and more components have programmable features. The reliability ofsuch components has proved to be difficult to demonstrate because of the nature of flaws in thesoftware. Standards and rules given by authorities set the acceptance criteria for the componentsused in the safety systems of nuclear power plants. As a result of this trend, there is a clear needfor an integrated and effective method to qualify software-intensive I&C systems in nuclearpower plant units. The integration has three major areas: (i) definition and harmonization ofrequirements for software-intensive systems at different safety classes, (ii) integration of severalapproaches such as Software Process Improvement and Capability dEtermination (SPICE)and Failure Mode, Effects and Criticality Analysis method (FMECA) to improve confidencein qualification and (iii) integration of the system acquisition and qualification processes toimprove the total effectiveness of the acquisition, delivery and deployment processes. Theintegrated qualification method is called the TVO SoftWare Evaluation Procedure (SWEP). Itconsists of a detailed qualification process and related methods for safety category B and C(IEC 61226) and Finnish safety class 3 qualifications. TVO will use the TVO SWEP method toevaluate suppliers and the conformance of their products/systems against requirements. It hasbeen used in several cases, and it seems to save a lot of qualification resources compared totraditional methods. Copyright 2007 John Wiley & Sons, Ltd.

KEY WORDS: safety-critical systems; instrumentation and control; qualification; SPICE; FMECA

∗ Correspondence to: Risto Nevalainen, Finnish Software Mea-surement Association ry FiSMA, Espoo, Finland†E-mail: [email protected]

Copyright 2007 John Wiley & Sons, Ltd.

1. INTRODUCTION

When the first versions of nuclear-specific sys-tem and software standards were written some20–25 years ago, no generic software and qualitystandards such as ISO 15 504 or IEC/EN ISO 61 508existed or were not at least commonly known.

Practice Section J. Halminen and R. Nevalainen

So, each party developed their own criteria andterminology for their own needs.

Quite typically, nuclear power instrumentationand control (I&C) systems are industrial productsand are not designed and manufactured uniquelyfor each application. At least their platform is basedon standard solutions and may be developed formany different purposes. Some subsystems maybe old and not able to qualify during the systemdelivery. The only evidence may be their histor-ical development process and current operationalhistory. They may have many versions and vari-ants and new changes to come. Only some minorpart of the whole delivered system may consist ofcustomer-specific application. When the system isdelivered to the nuclear power unit, it may requireplatform-oriented prequalification and application-oriented qualification during the delivery process.As a whole, complete qualification can be very timeconsuming and expensive.

As a result of the described development, thereis clear need for an integrated and effective methodto qualify software-intensive systems in nuclearpower units. The integration has three major areas:(i) definition and harmonization of requirements forsoftware-intensive systems at their different safetylevels, (ii) integration of several approaches suchas Software Process Improvement and CapabilitydEtermination (SPICE) and failure mode effects andcriticality analysis method (FMECA) to improveconfidence of qualification and (iii) integration ofthe system acquisition and qualification processesto improve total effectiveness of the acquisition,delivery and deployment processes.

The objective of SPICE method is to evaluate theprocess capability. SPICE is a brand name for ISO15504 Process Assessment standard. The capabilitymeasurement system is based on ordinal 5-pointcapability level scale. Basically any process can beevaluated using the measurement system. In mostcases, some predefined process reference model isused. Most known models are defined by ISO itself.ISO 12207 is the standard for software life-cycleprocesses. ISO 15288 is a similar model for systemsengineering. In most cases I&C systems for nuclearpower plants are developed using a combination ofsoftware and systems engineering processes.

FMECA has been used in some cases in Finland tobring evidence to the qualification process of safety-critical system. FMECA is effective to focus on themost critical parts of the system that have the highest

potential to cause failures. In hardware components,many well-defined methods can be used to showevidence about reliability and potential to failures.Redundancy can be used to reach the requiredreliability and failure prevention level. For software-intensive components standard FMECA is lessapplicable, because software failure statistics istypically incomplete. Software reliability and theprobability of failures to occur may be difficult topredict, or even to calculate. Software failures can becommon failures, making them even more criticalthan separately occurring hardware failures.

Teollisuuden Voima Oy (TVO) SoftWare Eval-uation Procedure (SWEP) has been developed asa joint effort of TVO, Technical Research CentreVTT and Finnish Software Measurement Associa-tion FiSMA. TVO had the project management role,and it validated the method in real-life pilot studies.VTT is the primary research party and is responsibleof the safety analysis method refinements. FiSMA isthe national body responsible for software and sys-tems engineering standards, including ISO 12 207,ISO 15 288 and ISO 15 504. FiSMA is responsible formodification and extension of SPICE to fulfill thequalification requirements of safety-critical systems.

Sateilyturvallisuuskeskus (STUK), The FinnishRadiation and Nuclear Safety Authority, hasdefined four safety class levels for nuclear powerunits (SC1–SC4, SC1 being the highest). IEC/EN61 508 defines four safety integrity levels (SIL1–SIL4, SIL4 being the highest). Some other standardshave defined, for example, safety classes 1, 2 and3 for systems, and safety categories A, B and Cfor functions. There is no clear mutual compatibil-ity between various nuclear-specific standards andtheir safety classifications. Also, criteria and require-ments to validate achievement of the defined safetyclass can be different. National regulators as STUKwant to and even must define their own require-ments for the qualification process, to be able tocarry out their monitoring and regulatory role. Alsoseveral international standards and specificationinclude requirements for qualification, for exampleCommon Position by EV and Safety Guide fromIAEA.

2. OVERVIEW OF THE QUALIFICATIONPROCESS BY SPICE AND FMECA

The main phases of the qualification are prequal-ification and application qualification. SPICE is

Copyright 2007 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2007; 12: 559–567

560 DOI: 10.1002/spip

Practice Section Qualification of Safety-critical Systems

Acquisition and Qualification - Integrated Process Diagram

Inte

grat

ed A

cqui

sitio

n an

d Q

ualif

icat

ion

Qualification Planning Process

System Acquisition and Development Processes

Qualification Performance Process

Acceptanceof ConceptualDesign Plan

Link

s

Offering

ConceptualDesign Plan

Systemdevelopmentand delivery

ContractSystemdelivery

Preliminary/Final offers

Offerrequest(s)

ConceptualDesign

Identificationof alternative

solutions

Negotiationswith

Suppliers

SupplierSelection

InvestmentDecision

OperationTechnical and

Cost Estimation

QualificationPlanning

Definition ofQualification

Method

DetailedQualification

Planning

Pre-Qualification

Application/Delivery

Qualification

Acceptanceof

QualificationResults

AcquisitionNeed

PreliminaryQualification

PlanPHA


Plan

ApplicationQualification

Results

Acceptanceto use

Permission tooperate

ProcessAssessment

SafetyEvaluation

Pre-Qualification

Results

PreliminaryHazard

Analysis

User ReqsSpec

User Req′sSpecification& Analysis

AuthorityAcceptance

AuthorityAcceptance

ApplicationQualification

Overallrequirementsspecification

Figure 1. The qualification process, integrated with I&C system acquisition

used mainly in the prequalification phase, togetherwith relevant nuclear-specific standards. If needed,also application qualification is done, partly withthe same methods. As a starting point, a prelimi-nary hazard analysis (PHA) is done as part of theuser requirements definition step. FMECA or theHAZOP method is used after PHA, and is main-tained and completed during all qualification steps.Figure 1 shows the main steps of the qualificationand how it is integrated to the main steps of systemacquisition and development.

As Figure 1 illustrates, qualification is based on adetailed qualification plan. A typical input is a PHAbased on user requirements. It is very importantto define the safety requirements early in theacquisition process for each safety-related function.When that is defined, the detailed qualificationplan and tailoring of questionnaires can be doneaccording to the requirements.

Typically, the qualification needs a lot of tech-nical data from system suppliers. Therefore, theprequalification phase and necessary negotiationswith system suppliers run in parallel with qualifi-cation planning. The suppliers are informed aboutthe qualification, and are prepared to participate ifneeded.

Prequalification is meaningful to perform infull scale, if the system platform and the appli-cation are quite large systems and have typi-cally several safety-related functions. For smallsystems, some less effort-intensive methods areused if possible. The prequalification is mainly acombination of detailed and evolved PHA, pro-cess assessment and conformance checks againstnecessary nuclear-specific standards. Necessarydocuments are reviewed as part of the assess-ment. Also, verification and validation of tech-nical documents and their safety functions are


DOI: 10.1002/spip 561


Detailed Pre-Qualification Process with Roles

Sup

plie

rLi

nks

TV

OQ

ualif

ier

Aut

horit

y

InitialQualification

Plan

Contracting withthe selected

supplier

ProcessAssessment

Verificationsand

Validations

Acceptable?


Planning

SystemTechnical

Data

PHA

User ReqSpec


Method


Plan

TechnicalData Review

QualificationInterviews Validation of

QualificationData

PreliminaryReport andFindings

DataRequests(optional)

AdditionalData

Collection(optional)

QualificationReporting

and Findings

QualificationReport

Acceptable?Qualification

Report

Yes

Yes

Conformancewith nuclearstandards

No, feedbackprovided

No, Feedbackprovided

Figure 2. A typical work flow of prequalification

an essential part of the prequalification. Figure 2shows the typical work flow of prequalifica-tions.

Qualification during application and systemdevelopment is done when needed. As a process, itis quite similar to the prequalification. In most casesit includes further checks of system and applicationdetails. Also, some additional requirements mayevolve from selected normative standards. Theymay be identified during prequalification, but needmore attention and evidences. Some typical top-ics are control of tests and their coverage duringapplication development, and handling of systemchanges for each application.

3. PROCESS ASSESSMENT ELEMENTSOF THE METHOD

ISO 15 504 Part 5 (known as the SPICE model) isused in as the main source of process assessment.The latest published ISO standard version ISO

Table 1. Main normative sources for safety class 3 requirements

YVL 5.5 Instrumentation systems and components atnuclear facilities. STUK 2002.

IEC 61 513 Nuclear power plants – Instrumentation andcontrol for systems important tosafety – General requirements for systems.2001.

IEC 62 138 Nuclear power plants instrumentation andcontrol computer-based systems important forsafety software for I&C systems of safetyclasses 2 and 3. 2001.

ISO 15 504Part 5

An exemplar process assessment model.Published as an ISO/IEC standard in 2006.

IAEA SafetyGuideNS-G-1.1

Software for computer-based systemsimportant to safety in nuclear power plants.2000.

IAEA 384 Verification and validation of software relatedto nuclear power plant instrumentation andcontrol. IAEA 1999.

IEC/EN61 508

Functional safety ofelectrical/electronic/programmable electronicsafety-related systems. 1998.

CommonPosition

European nuclear regulators guideline for thelicensing of safety critical software for nuclearreactors, EUR 19 265, 2000.


562 DOI: 10.1002/spip


Table 2. List of SPICE processes used in qualification

Process Name Main areas of integration with nuclear-specificstandards

ENG.1 Requirements elicitation Detailed specification of safety functions and their SIL typeaccording to PHA analysis results. Requirements for systemtesting.

ENG.2 System requirements analysis Validation of each requirement, separate handling of safetyrequirements. Traceability.

ENG.3 System Architecture design Allocation of each safety function. Overall architecture of thesystem. System validation planning.

ENG.4 Software requirements analysis Specification and independent validation of each softwarefunction related to safety

ENG.5 Software design Similarly as ENG.4. Planning of software verification tests.ENG.6 Software construction Module testing and documentation. Avoidance of

unnecessary code.ENG.7 Software integration Test records. Validation of integration test results.ENG.8 Software testing Test records. Validation of software testing results.ENG.9 System integration Test records. Validation of system integration test results.ENG.10 System testing Test records. Validation of system test results.ENG.11 Software installation Installation test. Correct technical environment.SUP:1 Quality assurance Quality planning. Reviews and inspections at project level.SUP.2 Verification Independent tests and technical reviews.SUP.3 Validation Independent FAT and SAT tests.SUP.7 Documentation Done according to supplier’s process and safety

requirements.SUP:8 Configuration management Full traceability. Change control.SUP:9 Problem resolution management Full audit trail. Analysis of each defect and it’s impacts.

Common causes of failures.SUP.10 Change request management Full change records. Analysis of each change.MAN.3 Project management Quality planning. Verification and validation planning.MAN.4 Quality management Quality management activities according to supplier’s

process.MAN.5 Risk management Avoidance of product related risks.MAN.6 Measurement Measurement-based testing and validation, if possible.

15 504 Part 5 is used as the baseline. Part 5 hasall ISO 12 207 processes and not all of them arerelevant for qualification purposes. Many nuclear-specific standards include quite similar concepts ofprocesses such as ISO 15 504 Part 5, and they are alsoused as normative sources. The primary sources arelisted in Table 1.

The list of relevant SPICE processes selected forqualification is presented in Table 2. Not all SPICEprocesses are as relevant as others, and also the cost-effectiveness of process assessment indicates a shortrather than complete list. The criterion for processselection has been alignment and integration of ISO12 207 processes and the related nuclear-specificstandards in Table 2.

Each process is assessed up to capability level 3,if possible. Level 3 is considered as the highestrequired capability level because only standardprocesses and an organization-wide quality system

is required for safety class 3 systems. Some processesneed a lot of refinements and elaborations to complywith the safety-critical system context, and that isdone as part of integration of SPICE and nuclear-specific standards. In most cases, an interpretationof each SPICE element is not enough, and anextension of the processes with additional practicesor alternative checklists is also needed.

The result of SPICE assessment is a capabilitylevel for each process and a number of evidences.They can be used as ‘load evidence’ for moredetailed safety analysis. SPICE capability level is notalways the best way to express the real capabilityof each process. Therefore, a ‘capability index’ isalso calculated as a ratio of the evaluated practicesand their sum compared to the target level of theprocess.

Conformance against nuclear-specific standardsand their safety requirements is carried out mainly


DOI: 10.1002/spip 563


Severity of safety effect

SOD-tables for safety class 313.3.2004

SeverityOccurrenceDetection

Occurrence and detection table for a I&C system

Probability of failure SIL Occ DetReduct.

Det%

RankTargetContinuous Low demand

0 0 5SIL 1 -1 60 4SIL 2 -2 75 3SIL 3 -3 90 2

10-4 ... 10-5

10-5 ... 10-6

10-6 ... 10-7

10-7 ... 10-8

10-8 ... 10-9

... 10-1

10-1 ... 10-2

10-2 ... 10-3

10-3 ... 10-4

10-4 ... 10-5 SIL 4 -4 99 1Potential concequence of a Safety Function Rank 5 4 3 2 1Loss of main mission of a SF (latent faults, no fail safe) 5 5 1Minor loss of a SF 4 4Degraded performance of a SF 3 3Fail safe operation 2 2No appreciable effect 1 1

Sev

ere

radi

adio

nda

mag

e (s

ever

alpe

rson

s)

Rad

iatio

n da

mag

e(o

ne p

erso

n)

Rad

iatio

n ex

posi

on

5 3

Fue

l dam

age

No

impa

ct o

n sa

fety

2

4321

321

21

4 1

Figure 3. Integration of severity, occurrence and detection rate of each potential failure

in parallel with SPICE assessment. Most require-ments are used as interpretation rules of base andgeneric practices of each SPICE process. Also, com-plementary methods and evaluations are needed,especially in software and system validation.

4. SAFETY EVALUATION ELEMENTSOF THE METHOD

The starting point for safety analysis is PHA.It defines the need for evidences to achieve therequired detection level for potential failures. InFMECA, the three main components of eachpotential failure are severity, occurrence and detec-tion.

On the basis of original safety requirements, eachpotential failure is classified according to its severityon a 1–5 scale. Similarly, also the probability ofoccurrence and required detection rate are classified1–5. SIL levels from IEC/EN 61 508 are used asa reference to map each safety function and itsrequired detection rate. As a result, these factorsare multiplied into the Action Priority Number(APN). The calculated APN for each potentialfailure indicates how much evidence is needed toachieve acceptable level of failure detection andtherefore the APN as a whole. Figures 3 and 4

explain in more detail the most important featuresof the method.

The column ‘Det’ in Figure 3 shows the minimumvalues for detection rate reduction. For example,to achieve SIL 1 one has to achieve at least 60%detection rate. See Figure 5 for more details as tohow to count detection rate.

Figure 4 shows two selected failure modes as anexample. The system was in this case the gammawagon. It is used to lift fuel bars up and down inthe reactor pool, for example, to maintain the fuelbar position.

5. EVIDENCE COLLECTION TO THEDETECTION TABLE

Figure 5 is a sample from a so-called detectiontable of the TVO SWEP method. It summarizesqualification findings in a composite index called‘total detection number (DET)’. The idea is touse the DET index as load or backing evidencein the FMECA sheet (Column 10–16 in Figure 4).The table is separate for the prequalification andqualification phases. In most cases, it is also separatefor Platform and Application. Evidence in eachphase is gathered by process evaluation (SPICE)and product safety evaluation (FMECA). Also,


564 DOI: 10.1002/spip


She

etno

:1E

valu

atio

n of

Fun

ctio

nal D

escr

iptio

n of

the

Gam

ma

Wag

onId

entit

y: P

03-

044,

rev

.2E

xist

ing

cond

ition

sE

xist

ing

cond

ition

s

1R

ef.

2E

ntry

code

3P

oten

tial

failu

re m

ode

(FM

)

4E

ffect

on

5P

oten

tial

effe

ct (

E)

6P

oten

tial

caus

e (C

)

7R

isk

cont

rols

(R

C)

8 Sev

9O

cc10 Det

11 AP

N12

Rec

omm

ende

dac

tion

13A

ctio

n ta

ken

14 Sev

15 Occ

16 Det

17 AP

N

Gen

eral

0T

he ir

radi

ated

fuel

isto

o ne

ar th

e w

ater

surf

ace

of th

e po

ol

Saf

ety

Dan

ger

ofra

diat

ion

for

peop

le a

t the

pool

1. O

pera

tor

driv

esth

e w

agon

too

near

the

surfa

ce2.

Ris

k C

ontr

ols

are

faile

d

1. F

ailu

re d

etec

tion

by o

pera

tor

at th

epo

ol, D

ET

-12.

Man

ual e

mer

genc

yst

op, O

CC

-½3.

Har

dwire

dem

erge

ncy

stop

,OC

C-1

4. M

echa

nica

l sto

p,O

CC

-15.

Pos

ition

ala

rm o

fth

e m

echa

nica

lst

op, D

ET

-½6.

Bra

kesy

stem

7. R

adia

tion

alar

m,

DE

T-½

8. L

ock

keys

52,

53

37,5

52,

53

37,5

1. P

ositi

on d

etec

tion

of th

e m

echa

nica

lst

op2.

Rad

iatio

npr

otec

tion

3. P

rogr

amm

able

safe

ty s

top

1-3:

OC

C-1

For

furt

her

SW

err

orde

tect

ion

eval

uatio

n,D

ET

-1

51,

52

15

51,

52

152.

1.1.

1

2.1.

2.2

1P

rogr

amm

able

saf

ety

stop

(E

ntry

Cod

e 1-

7/8)

func

tion

does

not

be

actu

ated

in m

odeA

Ent

ryco

de 0

-R

C8

The

mov

emen

tof

the

wag

on w

illco

ntin

ue r

isin

g

1. E

lect

ro m

ech-

anic

al li

mit

switc

hes

are

faile

d2.

Inpu

ts fa

il3.

Log

ic fa

ils4.

Out

puts

fail

5. C

ontr

ol u

nit f

ails

EC

0-7

RC

V&

V fo

r S

WF

or fu

rthe

r S

W e

rror

dete

ctio

n ev

alua

tion:

SW

cau

ses

2-4

Figu

re4.

Use

ofse

veri

ty,o

ccur

renc

ean

dd

etec

tion

toca

lcul

ate

APN

.An

exam

ple

wit

htw

opo

tent

ialf

ailu

rem

odes

ispr

esen

ted

just

for

illus

trat

ion


DOI: 10.1002/spip 565


Verification of SW change process 0.33 0.20SPICESPICE

Pre-Q of the process, CFG.3 Problem resolution management NA NA

Pre-Q of the process, CFG.4 Change request management NA NAr Review of impact of change analysis (Walk or Insp) 0.66 NAr Review of life cycle tasks (Walk or Insp) 1r Review of non-regression analysis (Walk or Insp) NA NAo Review of impact of change analysis (FMECA)o Review of impact of change analysis (FTA)

Configuration and quality 0.57 0.57SPICE Pre-Q of the process, CFG.1 Documentation 1SPICE Pre-Q of the process, CFG.2 Configuration management 0.67 0.67SPICE Pre-Q of the process, QUA.1 Quality assurance NA NASPICE Pre-Q of the process, QUA.2 Verification 0.61 0.61SPICE Pre-Q of the process, QUA.3 Validation 0.36 0.36Management 0.24 0.24SPICE Pre-Q of the process, MAN.3 Project management 0.94 0.94SPICE Pre-Q of the process, MAN.4 Quality management NA NASPICE Pre-Q of the process, MAN.5 Risk management NA NASPICE Pre-Q of the process, MAN.6 Measurement NA NAOperating experience 0.33 0.33

Collected with a well specified method NA NAOperational profiles NA NARepresentative for the application NA NAHW & SW versions NA NALong collection time 1

1 1Results of experience

DET index 0.689 0.68DET after SW requirements phase 0.64 0.59

DET after SW coding phase 0.73 0.62DET after I&C integration phase 0.772 0.679

DET after FAT 0.767 0.688DET after SAT 0.759 0.691

1

1

1

Figure 5. A sample from an Excel-based checklist to calculate detection index DET. An example is presented just forillustration

compliance with nuclear-specific standards is takeninto account here.

SPICE capability level is converted to the so-called capability index, which summarizes detailedpractice ratings at levels 1–3 for each process. Itis normalized to get values between 0 and 1 foreach capability level. Other evidences are detailedrequirements from Verification and Validationprocesses, as defined in IAEA report no. 384.

In the example of Figure 5 we present twocolumns for DET and its inputs. The right columnis for the prequalification phase and the left columnfor the additional nuclear-specific verification of theapplication. The prequalified system was in this

case a radiation monitoring equipment. As seen inthe example, also the NA (Not Applicable) ratingis allowed and used if the relevant input data orrating result is not available.

In most cases, the Severity and Occurrenceparameters remain the same and only failuredetection rate can be improved. As a result, APNmay reach an acceptable level. In our example (seecolumns 11 and 17 in Figure 4) the goal was thateach potential failure has an APN value of 25 or less.This is the case in our example, and the qualificationhas been successful.

Finally, the aim is to determine the ReductionDetection Number (RDN). RDN is typically the


566 DOI: 10.1002/spip


difference between the DET numbers in the FMECAtable (see columns 10 and 16 in Figure 4 as anexample). RDN can get a value 0–4. The detectiontable calculates the value of RDN automatically, onthe basis of the SPICE and V&V evidences. Thecalculated RND value is used in the FMECA tableto reduce the detection rate.

6. CONCLUSIONS AND FUTUREDEVELOPMENTS

Methods and techniques in TVO SWEP consistof process safety evaluation and product safetyevaluation. These same methods and techniquesare used by the second- or third-party inspectors,who assess explicitly or/and implicitly the artifactsor processes.

Several real-life qualifications have already beencarried out using the TVO SWEP method. Thegoals of the method have been achieved well, andthe prequalification is effective. It is evident thatTVO SWEP still needs refinements and additionalvalidation. The main difficulty is to collect evidencesso systematically that the necessary calculationsand reports can be carried out as automatically aspossible. Then the main focus can be on professionaltopics, which may lead to useful win–win findingsbetween TVO and the supplier.

Other industries may have quite similar needs forqualification as nuclear power plants. For example,control of railway and metro networks and traffic,electro medical devices, such as patient controlsystems, and many military systems could be usersof our method. In fact, any business sector andcompany that has predefined safety requirementsand can express it by using SIL levels can be apotential user.

The method is implemented partially in theFiSMA Assessment System GNOSIS and in Excelsheets. Also a paper-based version is available. It isquite possible that the method will be implementedin several technical areas in the future.

REFERENCES

Common Position of European Nuclear regulators for thelicensing of safety critical software for nuclear reactors. 2000.EUR 19265.

Harju H. 2000. Ohjelmiston luotettavuuden kvalitatiivinenarviointi (The qualitative assessment of software dependability).VTT Technical Research Centre of Finland. VTT ResearchNotes 2066, (In Finnish).

IAEA 384. 1999. Verification and Validation of SoftwareRelated to Nuclear Power Plant Instrumentation and Control.

IEC 61 513. 2001. Nuclear power plants – Instrumentation andcontrol for systems important to safety – General Requirementsfor Systems.

IEC/EN 61 508. 1998. Functional safety of electri-cal/electronic/programmable electronic safety-related systems.

IEC 62 138. 2001. Nuclear Power Plants Instrumentation andControl Computer-based systems important for safety Softwarefor I&C systems of safety classes 2 and 3.

ISO15504 Part 5. 2006. An Exemplar Process AssessmentModel.

Safety Guide. 2000. Software for Computer Based SystemsImportant to Safety in Nuclear Power Plants.

YVL 5.5. 2002. Instrumentation systems and components atnuclear facilities, STUK.


DOI: 10.1002/spip 567

Documents

Qualification of safety-critical systems in TVO nuclear power plants