aerospace engineering - ulisboa€¦ · iii acknowledgements firstly, i would like to thank my...

Availability Simulation Model of a Complex System:

A Contribution to the RAMI analysis of the ITER LFS CTS System

Inês Margarida Dias Martins Fragoso

Thesis to obtain the Master of Science Degree in

Aerospace Engineering

Supervisors: Prof. Elsa Maria Pires Henriques

Prof. Virgínia Isabel Monteiro Nabais Infante

Examination Committee

Chairperson: Prof. Filipe Szolnoky Ramos Pinto Cunha

Supervisor: Prof. Virgínia Isabel Monteiro Nabais Infante

Member of the Committee: Dr. Alberto Manuel Martinho Vale

November 2017

iii

Acknowledgements

Firstly, I would like to thank my supervisors, Professor Elsa Henriques and Professor Virginia Infante,

for all their dedication and guidance during my master thesis. Their invaluable advice and, of course,

the intense yet prolific discussions.

I would like to thank IPFN - Instituto de Plasmas e Fusão Nuclear from Técnico for the continued support,

especially, Professor Bruno Gonçalves, for all the opportunities and vital learning experiences.

To all my colleagues with whom I shared this journey, to their relentless efforts in keeping spirits high.

A special thanks to Joana Fidalgo and Pedro Pinto, without whom this work would not have been

possible. To all the moments shared over jasmine tea.

Lastly to my family, my parents and sister for their unconditional support and love even during the most

trying times. To my aunt for instilling in me a passion for science. To my grandmother for her caring

heart. Finally, to my grandfather whose life efforts came to fruition.

This work was partially supported by FCT – Fundação para a Ciência e a Tecnologia, under project F4E-

FPA-393.

iv

Resumo

Esta dissertação enquadrou-se numa parceria entre o Técnico e a Universidade Técnica da Dinamarca

(DTU) sendo um dos objetivos aplicar um procedimento de RAMI, ao Collective Thomson Scattering

(CTS). Trata-se de um sistema de diagnóstico do ITER, um projeto internacional de investigação e

engenharia cujo o objetivo é produzir eletricidade através de fusão nuclear controlada.

O enfoque é a modelação de diagramas de blocos adequados ao último design do CTS, recorrendo às

bases de dados de fiabilidade e manutibilidade disponíveis e a análise da fiabilidade e disponibilidade

do sistema.

Foram desenvolvidas três abordagens. A primeira é um modelo analítico capaz de oferecer estimativas

da fiabilidade e disponibilidade médias.

Com o intuito de obter dados de disponibilidade mais pormenorizados, partiu-se para uma segunda

abordagem, uma simulação de eventos discretos em que os componentes funcionam de modo

independente, gerando falhas aleatórias e as subsequentes reparações. Esta simulação ofereceu um

conjunto alargado de dados relativos à performance do CTS onde se incluem a média, percentis,

intervalos de confiança e casos de disponibilidade máxima e mínima.

Contudo, dado o conservadorismo dos resultados obtidos nesta segunda abordagem foi desenvolvido

um terceiro modelo de simulação com componentes dependentes, cujos relógios internos individuais

param sempre que há uma falha crítica de outros componentes, funcionando assim assincronamente,

na prática é o equivalente a desligar o sistema quando há falhas críticas, aproximando-se mais da

realidade. O trabalho desenvolvido poderá impactar estudos futuros relativos ao CTS e ao ITER,

nomeadamente, no que respeita ao funcionamento do reator e manutenção do mesmo.

Palavras-chave:

Simulação de Eventos Discretos;

RAMI;

Disponibilidade;

Fiabilidade;

Collective Thomson Scattering;

ITER.

v

Abstract

This thesis is based on a partnership between Técnico and the Technical University of Denmark, where

one of its objectives is the application of a RAMI procedure to the Collective Thomson Scattering (CTS).

The CTS is a diagnostics system for ITER, an international nuclear fusion research and engineering

project with the purpose of producing electricity.

The focus of this thesis is the modulation of Reliability Block Diagrams adapted to the last design of the

CTS and grounded on existing reliability and maintainability databases and the analyses of the reliability

and availability of the system.

There are three approaches. The first one is an analytical model capable of offering estimations of the

average reliability and availability.

The second approach developed is a discrete event simulation, due to its potential to provide more

detailed information about the availability. For each component, an operation-failure-maintenance cycle

is simulated. These cycles work independently from each other. It is possible to get a wide range of

information such as averages, confidence intervals and percentiles through this type of approach.

In order to get finer results a third approach was developed, now considering that components influence

each other. The simulation now includes delays, becoming – operation/delay-failure-maintenance

cycles. To achieve this behaviour, the components were considered to be dependent on each other and

their internal clocks work asynchronously, meaning that whenever a critical failure occurs, the internal

clocks of non-failing components is stopped, the equivalent of turning off the system, as in a real-life

setting. This work has the potential to influence future studies on the CTS and ITER, especially regarding

behaviour and maintenance of the nuclear fusion reactor.

Keywords:

Discrete Event Simulation;

RAMI;

Availability;

Reliability;

Collective Thomson Scattering;

ITER.

vi

Contents

Acknowledgements .............................................................................................................................. iii

Resumo.................................................................................................................................................. iv

Abstract .................................................................................................................................................. v

List of Figures ..................................................................................................................................... viii

List of Tables ........................................................................................................................................ xii

Symbols ............................................................................................................................................... xiii

Nomenclature ...................................................................................................................................... xiv

1. Introduction .................................................................................................................................... 1

1.1. Framework ............................................................................................................................. 1

1.2. Objectives .............................................................................................................................. 1

1.3. Thesis Structure .................................................................................................................... 2

2. Related Background ...................................................................................................................... 4

2.1. RAMI analysis ........................................................................................................................ 4

2.1.1. Reliability .................................................................................................................. 4

2.1.2. Availability ................................................................................................................. 8

2.1.3. Maintainability ........................................................................................................... 9

2.1.4. Inspectability ............................................................................................................. 9

2.2. RAMI in ITER ......................................................................................................................... 9

2.3. Discrete Event Simulation ................................................................................................... 14

3. ITER CTS ....................................................................................................................................... 18

3.1. Introduction to the ITER Collective Thomson Scattering .................................................... 18

3.1.1. Previous Functional Analysis of the ITER Collective Thomson Scattering ............ 18

3.1.2. Description of the ITER Collective Thomson Scattering ........................................ 23

3.2. Reliability Block Diagram ..................................................................................................... 24

3.3. Failure Modes Effects and Critical Analysis ........................................................................ 27

3.4. RAMI requirements .............................................................................................................. 29

4. Simulation Model ......................................................................................................................... 31

4.1. Reliability Block Diagrams ................................................................................................... 31

4.2. Analytical Approach ............................................................................................................. 35

vii

4.2.1. Reliability ................................................................................................................ 35

4.2.2. Availability ............................................................................................................... 38

4.3. Discrete Event Simulation Models ....................................................................................... 40

4.3.1. Synchronous Model ................................................................................................ 43

4.3.2. Asynchronous Model .............................................................................................. 46

5. Results .......................................................................................................................................... 55

5.1. Analytical Model .................................................................................................................. 55

5.1.1. Availability ............................................................................................................... 55

5.1.2. Reliability ................................................................................................................ 58

5.2. Simulations’ Validation ......................................................................................................... 60

5.3. Synchronous Model ............................................................................................................. 63

5.4. Asynchronous Model ........................................................................................................... 68

6. Conclusions and Studies ............................................................................................................ 75

References ........................................................................................................................................... 77

APPENDIX A ........................................................................................................................................... A

viii

List of Figures

Figure 1-1: Thesis Structure, chapters and subchapters. ....................................................................... 2

Figure 2-1 Reliability bathtub curve model. [15] ...................................................................................... 5

Figure 2-2: Network of components in Series, P stands for Reliability and Availability. .......................... 6

Figure 2-3: Network of components in Parallel, P stands for Reliability and Availability. ........................ 7

Figure 2-4: Network of components in parallel with an m-out-of-n configuration. ................................... 8

Figure 2-5: Information flow: Inputs and Outputs expected from a Functional Analysis. ...................... 10

Figure 2-6: Schematic representing the functional breakdown where a top-to-bottom description of the

system and subsystems, from the main functions to the elementary functions performed by the

components [34]. .................................................................................................................................... 11

Figure 2-7: Information flow: Inputs and Outputs expected from a Reliability Block Diagram. .............. 11

Figure 2-8: Information flow: Inputs and Outputs expected from FMECA. ........................................... 12

Figure 2-9: Information flow: Inputs and Outputs expected from Risk Mitigation Actions. .................... 12

Figure 2-10: Information flow: Inputs and Outputs expected for Availability and Reliability. ................. 13

Figure 2-11: Working procedure for an ITER’s system, adapted from [2]. ............................................ 14

Figure 2-12: Description of the process development of a Discrete Event Simulation Approach [42] .. 15

Figure 2-13: Examples of Models of DES from [45] .............................................................................. 15

Figure 2-14: Flowchart exemplifying one DES trial. .............................................................................. 17

Figure 3-1: IDEFØ Sample Block. ......................................................................................................... 19

Figure 3-2: Functional breakdown model of the ITER CTS. [4] ............................................................ 21

Figure 3-3: Functional modelling of ITER CTS system based on IDEFØ technique at the first

decomposition level.[4] .......................................................................................................................... 22

Figure 3-4: Functional modelling of the ITER CTS system based on IDEF technique at the second

decomposition (sub-functions of function 55-CTS-1, 55-CTS-2 and 55-CTS-3).[4].............................. 22

Figure 3-5: Schematic of ITER CTS system. [56] ................................................................................. 23

Figure 3-6: RBD used to evaluate the reliability and availability of the ITER CTS system. .................. 25

Figure 3-7: RBD with the reliability architecture of the subsystem Launcher and numbered components.

............................................................................................................................................................... 25

Figure 3-8: RBD with the reliability architecture of the subsystem Receiver ........................................ 26

Figure 3-9: RBD with the transmission lines expanded. ....................................................................... 26

ix

Figure 3-10: RBD of three Transmission Lines sharing one Fused Silica Window. .............................. 27

Figure 3-11: RBD of the special transmission line Passive View. ......................................................... 27

Figure 3-12: RBD of the subsystem Data Acquisition System .............................................................. 27

Figure 4-1: RBD used to assess the reliability and availability of the ITER CTS system – Whole system

including in-vessel and ex-vessel subsystems, as well as the passive view (in more detail in appendix

A1). ........................................................................................................................................................ 33

Figure 4-2: RBD used to evaluate the reliability and availability of the ITER CTS system – In-vessel

Subsystem including the passive view (ex-vessel IO scope components are excluded) (in more detail in

appendix A2). ......................................................................................................................................... 33

Figure 4-3: RBD used to evaluate the reliability and availability of the ITER CTS system – Whole system

including in-vessel and ex-vessel subsystems, excluding the passive view (in more detail in appendix

A3). ........................................................................................................................................................ 34

Figure 4-4: RBD used to evaluate the reliability and availability of the ITER CTS system – In-vessel

Subsystem excluding the passive view (ex-vessel) IO scope components are excluded (in more detail

in appendix A4). ..................................................................................................................................... 34

Figure 4-5: Launcher subsystem with numbered components. ............................................................ 35

Figure 4-6: Receiver subsystem with numbered components. ............................................................. 36

Figure 4-7: Data Acquisition System with numbered components. ....................................................... 36

Figure 4-8: Generation of pseudorandom Times To Failure of each component k (TTF Generator). ... 41

Figure 4-9: MATLAB Simulink- an example of the application of the algorithm developed to generate

pseudorandom times to failure for any component. .............................................................................. 41

Figure 4-10: Flowchart for the treatment of the threshold pertaining to the m-out-of-n network. .......... 42

Figure 4-11: Overview of the implementation of the threshold for the m-out-of-n network. .................. 42

Figure 4-12: Sequence of Events in the Synchronous Simulation, until the TTF is reached the systems

is operational during the MTTR the system is not-operational. ............................................................. 43

Figure 4-13: Schematic of the state changes in the signal of one component, as a result of reaching the

time of the next event. ........................................................................................................................... 44

Figure 4-14: Schematic showing the cumulative nature of the 𝑇𝑜𝑅𝑖, for the synchronous system. ..... 45

Figure 4-15: Flowchart of the algorithm representing the generation of the Boolean signal of one

component for the synchronous system. ............................................................................................... 45

Figure 4-16: MATLAB Simulink -- example of application of the algorithm developed to generate the

Boolean signal of a single component ................................................................................................... 46

Figure 4-17: Sequence of Events in the Asynchronous Simulation with a delay in the Time to failure

𝑇𝑇𝐹2. ..................................................................................................................................................... 48

x

Figure 4-18: Schematic of the state changes in the signal of one component, as a result of the interaction

between reaching the time of the next event and the Global Final Signal. ........................................... 49

Figure 4-19: Schematic showing the cumulative nature of the 𝑇𝑜𝑅𝑖, for the asynchronous system. ... 49

Figure 4-20: Flowchart of the algorithm representing the generation of the Boolean signal of one

component for the asynchronous system. ............................................................................................. 50

Figure 4-21: MATLAB Simulink - signal generation of the asynchronous ............................................. 51

Figure 4-22: High-level representation of the feedback system used to govern the components' internal

clock. ...................................................................................................................................................... 52

Figure 4-23: Block Processing the Global Final Signal for the Whole System including the Passive View.

............................................................................................................................................................... 52

Figure 4-24: Transmission Line controller and the inside view of the controller. ................................... 53

Figure 4-25: Fused Silica Window controller and the inside view of the controller. .............................. 53

Figure 4-26: Overview of the complete Asynchronous Model for the Whole System with Passive View,

attesting to its complexity. ...................................................................................................................... 54

Figure 5-1: High-level RBD and subsystems analytical availability. ...................................................... 57

Figure 5-2: Reliability and failure probability functions for the different assumptions (whole system and

in-vessel components, with and without passive view). It assumes all components in series. ............. 60

Figure 5-3: Behaviour of ITER CTS system (whole system and passive view) with the number of

transmission lines required for the system to be in operational conditions (one simulation run). ......... 61

Figure 5-4: Behaviour of transmission lines (whole system and passive view) (one simulation run). .. 62

Figure 5-5: Behaviour of fused silica windows (whole system and passive view) (one simulation run).

............................................................................................................................................................... 62

Figure 5-6: Behaviour of launcher, passive view, receiver mirror M2 and data acquisition system (whole

system and passive view) (one simulation run)..................................................................................... 63

Figure 5-7: Evolution of the synchronous simulation results and statistical analysis of availability for the

whole system with passive view. CI stands for a confidence interval of the mean. .............................. 64


in-vessel components with passive view. CI stands for a confidence interval of the mean. ................. 64


whole system without passive view. CI stands for a confidence interval of the mean. ......................... 65


in-vessel components without passive view. CI stands for a confidence interval of the mean. ............ 65

Figure 5-11: Evolution of the ITER CTS system availability with m-out-of-7 receiver transmission lines,

synchronous simulation. ........................................................................................................................ 67

xi

Figure 5-12: High-level RBD and subsystems availability synchronous system. .................................. 68

Figure 5-13: Evolution of the asynchronous simulation results and statistical analysis of availability for

the whole system with passive view. CI stands for a confidence interval of the mean. ........................ 69


the in-vessel components with passive view. CI stands for confidence interval of the mean. .............. 69


the whole system without passive view. CI stands for a confidence interval of the mean. ................... 70


the in-vessel components without passive view. CI stands for a confidence interval of the mean. ...... 70

Figure 5-17: Evolution of the ITER CTS system availability with m-out-of-7 receiver transmission lines

for the asynchronous system. ............................................................................................................... 71

Figure 5-18: High-level RBD and subsystems availability for the asynchronous system, the whole system

with passive view was used to get this data. ......................................................................................... 72

Figure 5-19: Results for the synchronous and asynchronous simulations - Whole System with Passive

View and In-Vessel Components with Passive View ............................................................................. 73

Figure 5-20: Results for the synchronous and asynchronous simulations - Whole System without

Passive View and In-Vessel Components without Passive View ......................................................... 73

Figure 5-21 Relative difference between the availabilities obtained from synchronous and asynchronous

simulations. ............................................................................................................................................ 74

xii

List of Tables

Table 2-1: ITER rating scale for severity S and occurrence O. [2] ........................................................ 12

Table 2-2: Risk Mitigation actions. [2] .................................................................................................... 12

Table 3-1: Critical components of the ITER CTS separated in In-vessel (exclusive responsibility of the

ITER CTS) and Ex-vessel components (exclusive responsibility of IO). .............................................. 23

Table 3-2:Failure Modes Effects and Causes of ITER CTS components.[56] ...................................... 28

Table 3-3: Initial severity, occurrence frequency and criticality level for each function failure mode.[56]

............................................................................................................................................................... 29

Table 4-1: Components reliability and maintainability input data for ITER CTS system availability

estimation (adapted from [56])............................................................................................................... 31

Table 4-2: Analytical Approach for the Reliability .................................................................................. 37

Table 4-3: Analytical Results for the four RBDs .................................................................................... 38

Table 4-4: Analytical Approach for the Availability. ................................................................................ 39

Table 4-5: Analytical Results for the Availability. .................................................................................... 40

Table 5-1 Average availability of ITER CTS system’s components. ...................................................... 56

Table 5-2: Availability values gathered from the analytical approximation. ........................................... 58

Table 5-3: Analytical results for the reliability. ........................................................................................ 58

Table 5-4: Analytical results for the Failure Function ............................................................................. 59

Table 5-5: Availability values gathered from the stochastic synchronous simulation. ........................... 66

Table 5-6: Availability values gathered from the stochastic asynchronous simulation. ......................... 71

xiii

Symbols

𝐴𝑇𝐿𝑚7⁄ (𝑖𝑛−𝑣𝑒𝑠𝑠𝑒𝑙)

Availability of m-out-of-7 Transmission Line’s in-vessel components

𝑅𝑇𝐿𝑘(𝑖𝑛−𝑣𝑒𝑠𝑠𝑒𝑙) Reliability of Transmission Line k’s in-vessel components

𝐴𝑇𝐿𝑘(𝑖𝑛−𝑣𝑒𝑠𝑠𝑒𝑙) Availability of Transmission Line k’s in-vessel components

𝐴𝐿(𝑖𝑛−𝑣𝑒𝑠𝑠𝑒𝑙) Availability of the Launcher’s in-vessel components

𝐴𝑇𝐿(𝑖𝑛−𝑣𝑒𝑠𝑠𝑒𝑙) Availability of the Transmission Lines’ in-vessel components

𝐴𝑇𝐿𝑚7⁄ Availability of m-out-of-7 Transmission Lines

𝑅𝐿(𝑖𝑛−𝑣𝑒𝑠𝑠𝑒𝑙) Reliability of the Launcher’s in-vessel components

𝑅𝑃𝑉(𝑖𝑛−𝑣𝑒𝑠𝑠𝑒𝑙) Reliability of the Passive View’s in-vessel components

𝑅𝑇𝐿(𝑖𝑛−𝑣𝑒𝑠𝑠𝑒𝑙) Reliability of the Transmission Lines’ in-vessel components

𝑅𝑇𝐿𝑘 Reliability of Transmission Line k

𝐴𝑇𝐿𝑘 Availability of Transmission Line k

𝐴𝐹𝑆𝑊 Availability of the Fused Silica Windows

𝐴𝐿 Availability of the Launcher

𝐴𝑇𝐿 Availability of the Receiver with m-out-of-7 Transmission Lines

𝑃𝑃 Probability for Components in Parallel

𝑃𝑠 Probability for Components in Series

𝑅𝑚𝑛⁄ Binomial Probability Distribution

𝑅𝐷𝐴𝑄 Reliability of the Data Acquisition System

𝑅𝐹𝑆𝑊 Reliability of the three Fused Silica Window

𝑅𝐿 Reliability of the Launcher

𝑅𝑃𝑉 Reliability of the Passive View

𝑅𝑇𝐿 Reliability of the seven Transmission Lines combined

xiv

𝑇𝑇𝐹𝑖 Time to Failure of Component i

𝑇𝑜𝑅𝑖 Time of Reset

C Criticality

i Component’s number

k Component’s number

MTBF Mean Time Between Failure

MTTR Mean Time To Repair

O Occurrence

S Severity

t time

T time

λ Failure rate

𝐴 Availability

𝐹(𝑡) Probability of Failure

𝑅(𝑡) Reliability

𝑓(𝑡) Failure Density Function

Nomenclature

A Availability

C Criticality

DAQ Data Acquisition System

DES Discrete Event Simulation

FA Functional Analysis

FMECA Failure Modes, Effects & Criticality Analysis

GFS Global Final Signal

I Inspectability

xv

IO ITER Organisation

ITER CTS ITER Collective Thomson Scattering

ITER International Thermonuclear Experimental Reactor

M Maintainability

MOU Matching Optics Unit

MTBF Mean Time Between Failure

MTTR Mean Time To Repair

O Occurrence

R Reliability

RAMI Reliability, Availability, Maintainability and Inspectability

S Severity

TL Transmission Lines

ToR Time of Return

TTF Time to Failure

WG Waveguide

1

1. Introduction

1.1. Framework

Aerospace engineering has an exploratory quality to it, breaching scientific barriers with each

technological advancement. Its cutting-edge nature demands creativity and relies on a wide range of

scientific fields to accomplish its endeavours. This thesis was developed in an adjacent area that has

the same inquisitive demeanour as space exploration and enough versatility to be applied in such an

enterprise.

ITER is intended to be the most ambitious experimental nuclear fusion reactor, aiming at producing 500

MW. It is the result of the joint efforts from seven world powers: China, Europe, Japan, India, South

Korea, Russia and the United States of America, in a total of thirty-five countries. Portugal has been,

and continues to be, an active and productive member of the European Consortium for the Development

of Fusion Energy. It has been awarded with several projects by the ITER Organisation (IO), as well as

the European domestic agency – Fusion For Energy (F4E).

Técnico, in particular Instituto de Plasma e Fusão Nuclear (IPFN) takes part of this Consortium, not only

providing expertise on the diagnostic, but also development and design for the Radial Neutron Camera

and the Radial Gamma-Ray. Additionally, Técnico is also collaborating in the elaboration of a Collective

Thomson Scattering (CTS) system, offering expertise in a wide range of areas such as robotics,

materials engineering, RAMI analysis during the design process, among others. [1]

RAMI is an acronym that stands for reliability, availability, maintainability and inspectability, which are

performance characteristics of an engineering system. Plainly, the reliability is a system’s ability of

correct continuous operation; the availability is a system’s readiness to operate correctly at a given point

in time; maintainability is the ease with which a system can be repaired or modified; and inspectability

which is a system’s ability to be visited and controlled. Evaluating these features during the development

of an engineering project allows for the implementation of design measures that can improve desirable

characteristics. Maximum availability is advantageous, consequently, it is a project requirement.

Furthermore, cultivating the synergy between reliability, maintainability and inspectability, augments

availability. It is then essential to prioritise the quantification of the availability during the design phase

of the project. There are myriad of tools and strategies available for this purpose.[2], [3]

1.2. Objectives

The scope of the collaboration of Técnico is, in part, the maturation of the ITER CTS by providing

expertise in the RAMI area. The primary goal of a RAMI analysis is to guarantee that a system meets

the requirements regarding reliability, availability, maintainability and inspectability. Evaluating these

2

characteristics requires an understanding of the ITER CTS’ global function basic functions and sub-

functions, the components involved and their interactions. Furthermore, it calls for the development of a

flexible model of the equipment’s behaviour, permitting the identification of subsystems and components

that profoundly impact the ITER CTS reliability and availability. The tasks, mentioned ahead, have

significant input from the Preliminary RAMI analysis[4]:

• Functional Analysis of the ITER CTS;

• Construction of Reliability Block Diagrams (RBD);

• Identification of the Failures Modes Effects and Criticality Analysis (FMECA);

• Development of an Analytical Model for the availability and reliability of the ITER CTS;

• Development of a Discrete Event Simulation (DES) fitted to the reliability architecture of the

ITER CTS system allowing a comprehensive stochastic quantification of the availability of the

system; programmed on MathWorks Simulink, the MATLAB extension that allows modelling of

continuous processes using block diagrams.

• Presentation and analysis of the results through graphs, tables and sketches;

• Ensuring RAMI requirements are satisfied.

1.3. Thesis Structure

The thesis is divided into six chapters following the structure of Figure 1-1.

Figure 1-1: Thesis Structure, chapters and subchapters.

Chapter One – Introduction is a short introduction to the motivation and objectives of the work that was

developed and is presented in this thesis.

3

Chapter Two - Related Background is a description of the concepts included in a RAMI analysis:

definition of reliability, availability, maintenance and inspectability; definition of strategies to evaluate

these characteristics when applied to a system with an intricate configuration; influence that these

features exert on each other; contextualization of RAMI analysis when applied to ITER; approaches and

tools to quantify RAMI such as a Discrete Event Simulation (DES).

Chapter Three – ITER CTS comprises: an introduction and description of the ITER CTS; its Functional

Analysis (FA); the reliability structure based on Reliability Block Diagrams (RBD)s based on which the

reliability and availability simulation model was developed ; the Failure Modes and the, Effects and

Criticality Analysis (FMECA) of each failure.

Chapter Four – Simulation Model begins by an analytic modelling of the ITER CTS systems which

provides some approximate boundaries of its reliability and availability, followed by the description of a

second availability model based on a synchronous DES. Finally, a third model is presented based on

asynchronous DES. All these models and algorithms developed are presented and explained, as well

as, their implementation.

Chapter Five – Results comprises the: presentation of the results obtained from the three developed

models and a discussion of the results and comparison between the two DES developed.

Chapter Six – Conclusions and studies’ pointing to further analysis and improvements that deserve to

be developed.

4

2. Related Background

The work developed is a part of a Reliability, Availability, Maintainability and Inspectability (RAMI)

procedure. This specific process was developed by the ITER Organisation (IO). However, efforts to

maximise reliability and availability of a system have been a part of engineering ventures for decades.

Consequently, the techniques applied have grown in number and complexity.[5]–[12]

This chapter is organised in three subchapters, broaching several RAMI concepts and techniques:

2.1 The first subchapter regards a RAMI analysis, RAMI is an acronym from Reliability

Engineering. It borrows concepts that can be applied to a broad range of systems. Here,

these concepts (Reliability, Availability, Maintainability and Inspectability) will be briefly

described, as well as some mathematical tools used to quantify them;

2.2 The second subchapter regards RAMI in ITER. It is a complete description, step by

step, of the procedure, develop for ITER, comprising: Functional Analysis (FA),

Reliability Block Diagram (RBD), Failure Modes and Criticality Analysis (FMECA), Risk

Mitigating Actions and RAMI requirements;

2.3 The third subchapter regards Discrete Event Simulations (DES). It is a brief description

of what a DES is, how it works and where it can be applied.

2.1. RAMI analysis

The RAMI (reliability, availability, maintainability and inspectability) analysis process involves analytical

methods and integrative concepts that should be used to guide the system’s design into meeting the

project requirements. The analysis of these characteristics requires the identification of the system’s

global function, basic functions, sub-functions, components and the hierarchical relationships between

them. This analysis starts with the early design conceptions and influences further designs iterations

until the project requirements are fulfilled[2][13].

2.1.1. Reliability

Reliability (R) is the ability of a system to maintain correct operation forgoing any kind of intervention.

When designing for reliability, the objective is to achieve a solution with the highest reliability possible

accommodating any other functional, economical or safety requirement. When designing for reliability

it’s necessary to define the system’s components the way they interact and the function they perform,

and in case of failure, the impact said failure would have on the system.

From a mathematical point of view reliability, denoted as 𝑅(𝑡), is the probability of a system having a

successful operation at a given time t.

𝑅(𝑡) = 𝑃(𝑇 > 𝑡), 𝑡 ≥ 0 (2.1)

5

In the equation above T is a random variable that represents the time to failure. For the system to be

operational at time t, T must be greater than t. Consequently, the probability of failure, 𝐹(𝑡), is defined

as the probability that a system has failed by the time T.

𝐹(𝑡) = 𝑃(𝑇 ≤ 𝑡), 𝑡 ≥ 0 (2.2)

The failure distribution function, 𝐹(𝑡) which can also be called cumulative failure distribution function is

the opposite of the survival function 𝑅(𝑡), hence:

𝐹(𝑡) = 1 − 𝑅(𝑡) (2.3)

and the failure density function associated is:

𝑓(𝑡) = −𝑑𝑅(𝑡)

𝑑𝑡(2.4)

Among the probability distributions used to evaluate systems reliability, beta, binomial, lognormal,

exponential and Weibull distributions are the most common. Choosing the appropriate estimation

technique depends on the system configuration and the properties of the components. The pattern of

failures is vital in determining the type of probability distribution to be used. [14]

Over the lifetime of a system, there are three distinct failure phases often presented in a bathtub curve,

see Figure 2-1. The first phase is related to infant mortality here the failure rate decreases in time. Infant

mortality is connected to design and manufacturing problems and errors that are not caught in quality

control. The second phase is the useful life or steady-state phase, where the failure rate stabilises and

becomes more or less constant. Here, failures are mostly due to the normal physical behaviour of the

system or other random fluctuations. The third phase is the wear-out phase which means the failure rate

is increasing; these failures are due to corrosion, oxidation, the breakdown of insulation, fatigue among

others. Random failures and wear-out failures are a product of design; it could be related to an excessive

load or/and inappropriate material. When analysing a system the reliability data used is, generally, the

one gathered during the steady-state phase, where the failure rate (λ) is constant.[15], [16]

Figure 2-1 Reliability bathtub curve model. [15]

6

In a RAMI analysis, the random failure phase is the one being studied since it is influenced mostly by

design.[17] The exponential distribution (equation 2.6) is, thus, the most commonly used in

Reliability, 𝑅(𝑡, 𝜆), as it is simple and describes components through a single constant parameter the

failure rate (𝜆). The failure rate is calculated using the component’s Mean Time Between Failure (MTBF)

(equation 2.5).The failure density function associated to the exponential distribution can be seen in

equation 2.7. [18]

𝜆 =1

𝑀𝑇𝐵𝐹(2.5)

𝑅(𝑡, 𝜆) = 𝑒−𝜆𝑡 (2.6)

𝑓(𝑡) = 𝜆𝑒−𝜆𝑡 𝑡 > 0 (2.7)

The formulae presented until now are used in the analysis of a single component or a system with a

single parameter. Engineering systems are complex networks of components, often with non-linear

interdependencies and multifaceted hierarchical relations. Reliability calculations for these systems,

frequently, involve networks of components with unique configurations, combining components in series,

parallel or even m-out-of-n networks. These connections can be defined mathematically accordingly to

their relationships.

Systems in series (see Figure 2-2); its components rely on each other to be operational if any component

fails that network becomes not-operational. Evaluating networks of components in series implies

multiplying the probabilities associated with each component, see equation 2.8.

Figure 2-2: Network of components in Series, P stands for Reliability and Availability.

𝑃𝑠 = 𝑃1𝑃2𝑃3𝑃(… )…𝑃𝑛 (2.8)

Systems in Parallel, see Figure 2-3, components work independently from each other if one component

fails the others may continue their normal operation. They can be used to introduce redundancies in a

system. Evaluating networks of components in parallel implies combining the probabilities of each

component as seen in equation 2.9.

7

Figure 2-3: Network of components in Parallel, P stands for Reliability and Availability.

𝑃𝑃 = 1 − (1 − 𝑃1)(1 − 𝑃2)(1 − 𝑃3)(1 − 𝑃(… ))… (1 − 𝑃𝑛) (2.9)

System, merely, in parallel and series are often inadequate to emulate real systems.

A system that cannot be portrayed by either parallel of series architectures is the m-out-of-n network,

see Figure 2-4. The probability of having m components working out of an n set can be calculated using

a binomial distribution – the probability is is given by equations 2.10 and 2.11. It can be used in cases

where the components are independent of each other, every component has the same properties, there

are no replacements, and the analysis is finite.[7], [8], [16], [19]–[30]

8

Figure 2-4: Network of components in parallel with an m-out-of-n configuration.

𝑅𝑚𝑛⁄= ∑ (

𝑛𝑗)

𝑛

𝑗=𝑚

𝑃𝑗(1 − 𝑃)𝑛−𝑗 (2.10)

(𝑛𝑗) =

𝑛!

(𝑛 − 𝑗)! 𝑗!(2.11)

2.1.2. Availability

Availability (A) can be described as a system’s readiness to operate in a particular time interval taking

into consideration the effects of singular or multiple component failures. Planning for availability requires

the assessment of the consequences of an unsuccessful operation: maintenance. Hence, it makes

sense to include maintainability and inspectability alongside with reliability as aspects of availability. The

ratio presented in equation 2.12, is the availability.

𝐴 =𝑈𝑝 𝑇𝑖𝑚𝑒

𝐷𝑜𝑤𝑛 𝑇𝑖𝑚𝑒 + 𝑈𝑝 𝑇𝑖𝑚𝑒(2.12)

Uptime is a measure of time a system has been operational (available). The term downtime is used to

refer to periods where the system is not-operational (unavailable). Improving availability can be done by

enhancing uptime and diminishing downtime, this can be achieved through design changes such as the

addition of redundancies, spares, facilitation of maintenance and inspection operations. [18]

9

2.1.3. Maintainability

In broad strokes, maintainability is a system’s ability to undergo maintenance. Systems should have a

high reliability and availability, by design. Failures are unavoidable; systems will stop meeting their

objectives and must undergo maintenance be it preventive or corrective.

The criteria that define if a system has failed is highly dependent on the expectations one has for said

system. It can be described as the absence of a regular operation, that can be restored through

corrective intervention. Any interventions, corrective or scheduled, should be executed quickly and

efficiently.

Preventive maintenance is a scheduled activity, and its purpose is to assure the system is operating

correctly and prevent future failures. It can be clock based, age-based or condition based. Clock-based

maintenance is based on calendar times: repairs and replacements are made periodically. Condition-

based maintenance is done when individual or groups of parameters pass a predefined threshold.

Corrective maintenance takes place when there is a failure of a component, and it’s necessary to repair

it, its purpose is to restore the system to normal functioning as soon as possible. [31], [32]

2.1.4. Inspectability

Inspectability is the ability to undergo visits and controls. It can be defined as one of the characteristics

of Maintainability but with a preventive outlook. This feature is set in the design phase and aims at

facilitating monitoring of the equipment: testing and failure diagnostics.

Failure-finding maintenance is a particular type of corrective maintenance that relies on the ability of a

system to undergo an inspection: operational checks or tests to assure backup systems, protective

devices, among others. It is carried out at specified intervals between failure-finding tasks.

These concepts are lumped together since designing for reliability and availability, which are desirable

characteristics, implies optimising inspection and maintenance times. A system that spends shorter

periods down to undergo maintenance or inspection will have a higher availability. The same relationship

can be drawn between availability and reliability, a system that hardly ever fails will experience an

improvement in availability. [7], [8], [16], [19]–[30], [33]

2.2. RAMI in ITER

ITER is an ambitious scientific and technological endeavour to generate energy through nuclear fusion.

To ensure its success the ITER Organisation (IO) developed a RAMI procedure, meant to be applied to

every ITER system. Deriving from the more conventionally used approach RAMS (reliability, availability,

maintainability and safety) that integrates the analysis of the safety aspects of a system. The nature of

the project, nuclear fusion, imposes a particular approach to safety, so it is treated as an independent

matter.[1], [2]

10

ITER is an ambitious scientific and technological program, given its importance the inherent risk of

nuclear fusion, a different RAMS approach was developed for ITER. It consists of four steps; functional

analysis, failure modes analysis, effects and criticality (FMECA), risk mitigation actions and finally

integration of requirements. In nuclear fusion, Safety is treated separately, given the impact that a

hypothetical accident might have. Since this is a highly innovative project, the reliability of the

components is uncertain. As such additionally to the previous steps there is a particular concern that the

components can undergo scheduled inspections, which originates RAMI, the I for Inspectability.

The RAMI process, for ITER, accompanies the entire design phase of the system. During this period it

is still possible to implement corrective design measures that will impact reliability, maintainability,

availability and inspectability. Before quantitative values can be assigned to measure the performance

of a system, it is necessary to analyse the functions and sub-functions performed, and to identify the

components involved.

Figure 2-5: Information flow: Inputs and Outputs expected from a Functional Analysis.

The first stage is a Functional Analysis (FA) of the system (see Figure 2-5). It comprises a complete

functional breakdown with top-down descriptions of the system and subsystems, from the primary

functions to elementary functions performed by the components. It is crucial to identify every core

function that the system performs to meet the requirements; it is also essential to identify critical

components associated with the elementary functions. Figure 2-6 represents the functional breakdown

of a system, from upper-level functions to lower level sub-functions and finally the lowest level –

components.

11

Figure 2-6: Schematic representing the functional breakdown where a top-to-bottom description of the system and

subsystems, from the main functions to the elementary functions performed by the components [34].

The second stage, of a RAMI process, is the construction of a Reliability Block Diagram (RBD), where

the system’s structure is presented, with the analysis made in the functional breakdown and focusing

on the reliability relationships between each function’s components, as seen in Figure 2-7. The RBDs

also show reliability and maintenance parameters of the components such as the Mean Time to Repair

(MTTR) and Mean Time Between Failure (MTBF). Through this data and the hierarchical relationships,

it’s possible to compute the reliability and availability of the system. The parameters used in the RBDs

originate from databases from industries, previous experiences, assumptions made by RAMI experts.

Figure 2-7: Information flow: Inputs and Outputs expected from a Reliability Block Diagram.

Blocks can be seen as switches, when closed the block is operational otherwise the block has failed. As

the complexity of the system augments, different strategies to calculate the reliability and availability

have to be applied, since there can be components, in series, parallel, n-out-m networks, redundancies,

among others.

The third stage failure modes, effects and criticality analysis (FMECA) is based on the functional analysis

and the RBD. It establishes a list with every possible function failures for the system and subsystems; it

also defines their causes and impacts, as seen in Figure 2-8. The causes and consequences are

reviewed accordingly with a severity and occurrence scale (Table 2-1), that is used for every ITER

system to maintain coherence and consistency throughout the design phase.

12

Figure 2-8: Information flow: Inputs and Outputs expected from FMECA.

Table 2-1: ITER rating scale for severity S and occurrence O. [2]

After the qualitative analysis that provides the level of the occurrences and their severity, it’s possible to

calculate the criticality, which is the product of both. The criticality is calculated using the equation 2.13.

𝐶𝑟𝑖𝑡𝑖𝑐𝑎𝑙𝑖𝑡𝑦 = 𝑆𝑒𝑣𝑒𝑟𝑖𝑡𝑦 × 𝑂𝑐𝑐𝑢𝑟𝑒𝑛𝑐𝑒 (2.13)

The fourth stage is risk mitigation actions that are meant to lessen the hazards associated with the

failure modes, that were identified in the previous step, see Figure 2-9. The measures have distinct

names according to what they aim to reduce. The occurrence is mitigated using prevention and severity

is treated with protection, which will ideally result in a decrease on criticality. Some risk mitigation actions

are implementing redundancies, preventive maintenance and other design activities. Examples can be

seen in Table 2-2.

Figure 2-9: Information flow: Inputs and Outputs expected from Risk Mitigation Actions.

Table 2-2: Risk Mitigation actions. [2]

13

After the mitigation actions are implemented a new RBD with the improvements must be done, and the

new tests must be performed to evaluate the impact on RAMI and see if they are beneficial, specifically

reliability and availability (see Figure 2-10) must be revaluated. If the desired objectives aren’t reached

then more actions need to be taken towards improving the system.

Figure 2-10: Information flow: Inputs and Outputs expected for Availability and Reliability.

The RAMI requirements are the integration of the risk mitigation actions and evaluation of their success

and coherence with the requirements. In this case, there are called ITER RAMI process:

• Meeting targets of availability and reliability for the different systems and subsystems;

• Design changes that are made to improve the current system availability and reliability;

• Tests to be performed on the components or systems;

• Operation procedures and specific training to lower the risks;

• Maintenance requirements: spares, intervals between inspections, preventive maintenance;

• Proposals for standardisation of common parts used in significant number in the project,

ensuring inter-changeability of spares in the design of the systems allows for better reliability

parameters.

The ITER RAMI approach aims at lowering technical risks, through a RAMI processes that involve

functional analysis and FMECA. This procedure should be applied to any system present in ITER.

Examples of applications of the RAMI procedure in ITER are ITER central interlock system, Cryostat

system, Tritium Storage and Delivery System, Hot Cell Facility, Detritiation Systems, Blanket Remote

Handling System, Central Safety System, Fuel Cycle System, Helium Cooled Ceramic Breeder test

blanket system, among others.[35]–[44]

14

Figure 2-11: Working procedure for an ITER’s system, adapted from [2].

The RAMI cycle presented in Figure 2-11 was developed exclusively for ITER. It should be applied by

every team involved in the development of ITER systems to ensure coherency.

Phase A (definition), it starts by setting reliability and availability targets for a system from ITER, then

comes the general design concept followed by the functional analysis of the failure modes effects and

critical analysis (FMECA) which leads to an early design.

Phase B is the focus of this thesis. It involves conceptual, and engineering design and has an iterative

structure; after FA/FMECA the reliability and availability are evaluated and the results obtained are

compared with the project targets set in phase A, if they are not met, design improvements are made,

and another FA/FMECA are required.

Phase C (manufacturing) it is the construction phase with the definition of Quality Assurance and

Operation.[2]

2.3. Discrete Event Simulation

A Discrete Event Simulation (DES) replicates the operation of a system as a series of discrete events,

it can be used to predict the behaviour of production lines, queues at a bank, model the influx of patients

in an emergency room. In a RAMI analysis a DES is of particular interest, since it can emulate the

undercurrents of a system and quickly determine a range of values where the availability and reliability

lies, as well as, identify critical sets of components that significantly impact the system’s performance.

Developing a DES is a complex task that requires balancing of every aspect of the simulation to achieve

reliable results. The process is started by defining the problem and the choosing a mathematical model

15

with affinity to the problem; the information gathered during the definition of the problem is critical to this

step as there are many kinds of models. Among the many modelling techniques, there are, time driven-

simulations, where all states changes are synchronised by the system’s internal clock, event-driven

simulations, where events occur asynchronously and possibly concurrently, such as hybrid systems, as

shown in Figure 2-13. After choosing the model, it is time to implement it, compute and interpret results.

Accordingly, to the results obtained the model should be adapted and changed to ensure its accuracy,

see Figure 2-12.

Figure 2-12: Description of the process development of a Discrete Event Simulation Approach [42]

Figure 2-13: Examples of Models of DES from [45]

16

Stochastic event-based simulations are a sequence of processes where sample paths are created under

a particular set of parameters. Events are instantaneous state changes that result from a group of tasks

organised chronologically, and the system’s state is updated at each discrete point in time and changed

if an event occurs. It is based on stochastic processes hence it is memoryless. Sets of independent

events are executed through each sample-path.

Different simulation models can share a few processes among them. These processes are represented

as activity-blocks, some examples are:

• Generators – that generate random variables;

• Queues – where entities can be temporarily stored while waiting for access to a resource

• Attributes – that control activity according to data being fed;

• Subsystems – that allow a combination of blocks to be executed upon occurrence of the

particular events

• Timer and Counters - that measure event occurrence times or time elapsing between events.

There are many software tools to analyse the availability and reliability of engineering systems, including

MATLAB SimEvents and MATLAB & Simulink. SimEvent is a DES engine with a library, able to emulate

the activity blocks mentioned previously, that can be used to model event-driven and time-driven

simulations. These simulations can move entities and respective resources through a system. It is

possible to create a DES in a MATLAB & Simulink environment without resorting to the SimEvent’s

library. Simulink can be used to develop workflows and generate random events, while a script in

MATLAB can make the statistical analysis. Figure 2-14 is a Flowchart that shows a possible approach

to implementing a DES in a MATLAB environment.[19], [46]–[54]

17

Figure 2-14: Flowchart exemplifying one DES trial.

The script initialises the simulation and gives the entities that are moved through the workflow attributes

(reliability and maintainability parameters). The simulation then generates stochastic events and

accordingly to those events enables state changes as time goes by. Data is then stored and analysed.

To produce data with statistical meaning, it is necessary to run multiple trials with different outcomes.

The number of trials should be chosen accordingly with the confidence interval desired. [46], [55]

18

3. ITER CTS

The ITER Collective Thomson Scattering (ITER CTS) is a plasma diagnostics system operation in the

ITER organisation (IO). ITER has developed a Reliability, Availability, Maintainability and Inspectability

(RAMI) procedure that has to be applied to every system in it. Even though reliability and availability

optimisation operations are not new, it was necessary to make a standardised approach to ITER’s

systems.

This chapter is divided into five subchapters and it is an update to the RAMI analysis performed for the

first design of the ITER CTS system.

3.1 The first chapter is an introduction and contextualization of the Collective Thomson Scattering.

It starts with the previous functional analysis of the ITER CTS. This step was started with the

first RAMI procedure the ITER CTS went through, and further analyses were based on it. Then

the new schematic provided by the Technical University of Denmark (DTU) team responsible

for the coordination of the design of the ITER CTS. Here the components of the system are

identified as well as their placement in the ITER Organisation;

3.2 the second subchapter corresponds to the new Reliability Block Diagrams (RBD) made for the

new design presented in subchapter 3.1; it also includes a detailed explanation regarding the

subsystems and blocks as well as the hierarchical relationships between them;

3.3 The third subchapter are the Failure Modes Effects and Critical Analysis (FMECA). This

chapter is mostly based on the information gathered in the first RAMI procedure;

3.4 the fourth subchapter is the RAMI requirements that were also defined in the previous RAMI

procedure.

3.1. Introduction to the ITER Collective Thomson

Scattering

The RAMI analysis of the ITER Collective Thomson Scattering (ITER CTS) had already begun when

this thesis was initiated. Given the iterative nature of the RAMI procedure, the objective was to revaluate

the availability and reliability, since the initial design had been improved. The information gathered in

the previous analysis was vital to understand the ITER CTS and most of the functional analysis is still

valid, as well as, some of the information gathered about the components.

3.1.1. Previous Functional Analysis of the ITER Collective

Thomson Scattering

The functional analysis performed during the last iteration of the RAMI process [4] was the basis of the

new analysis. Hence, to provide context, it is necessary to review the information gathered then. The

functions performed by the system must be identified, as well as, all the critical components associated

19

with these functions. Consequently, a complete top-down description of the system and its subsystems

was done. The main functions were identified and broken into basic functions and, subsequently, into

critical components, which can be seen in Figure 3-2. The hierarchical relations were well-defined and

afterwards modelled using the language IDEFØ.

IDEFØ is a function modelling methodology used to describe a wide array of engineering systems. As

seen in Figure 3-1, blocks work with:

• Function inputs that enter the block coming from the left;

• Function outputs come out from the right side of the block;

• Function control directions come from, the function or sub-function code name is in the bottom

right corner of the block;

• Mechanisms involved in the function, usually, described below the block.

Figure 3-1: IDEFØ Sample Block.

Through an IDEFØ model, it is possible to identify functions being performed the interactions between

them and the connections. Figure 3-2 is a description of the global function, sub-functions and basic

functions of the ITER CTS, including the components involved in those functions. The critical

components associated with basic functions, identified in the first Functional Analysis from the previous

RAMI analysis[4] Figure 3-2 are:

• 55-CTS-1.1, 55-CTS-1.2, 55-CTS-1.3, 55-CTS-1.4 – Cooling system;

• 55-CTS-1.1 To generate high power microwaves – Gyrotron;

• 55-CTS-1.2 To route high-power microwaves from 60 GHz gyrotron(s) to launcher - Polarizer

unit;

• 55-CTS-1.2 To route high-power microwaves from 60 GHz gyrotron(s) to launcher - Waveguide;

• 55-CTS-1.2 To route high-power microwaves from 60 GHz gyrotron(s) to launcher - Diamond

windows;

• 55-CTS-1.2 To route high-power microwaves from 60 GHz gyrotron(s) to launcher - Waveguide

in primary Vacuum;

20

• 55-CTS-1.2 To route high-power microwaves from 60 GHz gyrotron(s) to launcher- Evacuated

waveguide in primary Vacuum;

• 55-CTS-1.3 To launch high-power microwaves into the plasma - Launcher mirror (fixed);

• 55-CTS-1.3 To launch high-power microwaves into the plasma - Launcher mirror (movable);

• 55-CTS-1.3 To launch high-power microwaves into the plasma - Moving unit of the mirror;

• 55-CTS-1.4 To receive scattered low power microwaves emission from plasma - Receiver mirror

M3;

• 55-CTS-1.4 To receive scattered low power microwaves emission from plasma - Receiver mirror

M4 (7 mirrors);

• 55-CTS-1.5 To route/direct low power microwaves from antenna to receivers - Waveguide;

• 55-CTS-1.5 To route/direct low power microwaves from antenna to receivers - Passive view

waveguide;

• 55-CTS-1.5 To route/direct low power microwaves from antenna to receivers - Fused silica

windows unit;


fused silica windows unit;

• 55-CTS-1.5 To route/direct low power microwaves from antenna to receivers - Waveguide;


waveguide;

• 55-CTS-1.5 To route/direct low power microwaves from antenna to receivers - Polarizer unit;


polarizer unit;

• 55-CTS-1.6 To detect and digitize signals - Acquisition system;

• 55-CTS-1.6 To detect and digitize signals - Passive view acquisition system;

• 55-CTS-1.7 To analyse signals (subtract background noise etc.) - Processing software;

• 55-CTS-1.8 To generate measurements - Processing software.

21

Figure 3-2: Functional breakdown model of the ITER CTS. [4]

After identifying the main functions and the main components involved in each function, the relationships

between functions and afterwards sub-functions were defined and represented using IDEFØ.

In Figure 3-3 is a high-level schematic of the functions performed by the ITER CTS each function is

represented by a distinct colour code. There are three main functions:

1. 55-CTS-1: Diagnostic system functions – Generation of signals;

2. 55-CTS-2: Diagnostic service functions – Providing services and features to support the main

functions

3. 55-CTS-3: Diagnostic measurement functions – Providing parameter measurements

22

Figure 3-3: Functional modelling of ITER CTS system based on IDEFØ technique at the first decomposition

level.[4]

The primary schematic in Figure 3-3 is a high-level representation of the sub-functions performed by

ITER CTS. Sub-functions that belong to the same function are represented by the same colour. The

code name for each function is Figure 3-2.

Figure 3-4: Functional modelling of the ITER CTS system based on IDEF technique at the second

decomposition (sub-functions of function 55-CTS-1, 55-CTS-2 and 55-CTS-3).[4]

In the updated version of the ITER CTS the global function, sub-functions and basic functions are the

same. However, there are a few design alterations that affected the type and number of components

involved, the connections between them and the hierarchy among them. Since there is a new design

the previous reliability and availability RBDs and calculations have to be redone to see if the RAMI

requirements are met.

23

3.1.2. Description of the ITER Collective Thomson Scattering

The schematic in Figure 3-5 is a representation of the ITER CTS system’s last design. Components are

separated into two groups, ex-vessel components and in-vessel components. The design of the ex-

vessel components, presented with a grey background, are outside the ITER CTS design team

responsibility and belong to the ITER Organisation (IO). They are connected to the in-vessel

components of the ITER CTS. In-vessel components are sole responsibility of ITER CTS team. The

system’s waveguides (WG) are highlighted in blue.

Figure 3-5: Schematic of ITER CTS system. [56]

For this RAMI iteration, the critical components associated with the ITER CTS system functions that

were considered for the RAMI analysis are listed in Table 3-1:

Table 3-1: Critical components of the ITER CTS separated in In-vessel (exclusive responsibility of the ITER CTS)

and Ex-vessel components (exclusive responsibility of IO).

ITER CTS ITER Organisation

In-Vessel Components Ex-Vessel Components

Split-biased WG (electrically biased) Gyrotron

24

(introduced after mitigation actions proposal for

the launcher in-vessel TL)

Launcher in-vessel Transmission Line (TL)

(cooled)

MOU Polarizer Unit

Launcher Mirror M1 (cooled) Launcher ex-vessel Transmission Line (TL)

Receiver Mirror M2 Diamond Window

Receiver Mirror M3 Fused Silica Window

Receiver in-vessel Transmission Line (TL) Receiver ex-vessel Transmission Line (TL)

Receiver Electronics

Data Acquisition System (DAQ)

3.2. Reliability Block Diagram

The RBD relies on the information gathered in the functional breakdown phase. It is a graphical

representation of the relationship and hierarchy between functions and their components. Each block

accounts for a component, and it includes reliability and availability parameters such as the Mean Time

To Repair (MTTR) and the Mean Time Between Failure (MTBF). The sources to gather these parameters

are reliability databases available and knowledge of RAMI experts. The diagrams show several levels

of the hierarchy between components, sub-functions and functions, that were established in the

functional breakdown. The data of the lower-level blocks can be computed into reliability and availability

analysis of upper-levels.[2], [15], [21], [57]

The RBD to develop the reliability and availability of the ITER CTS system is described and shown in

Figure 3-6.

25

Figure 3-6: RBD used to evaluate the reliability and availability of the ITER CTS system.

The ITER CTS is divided into three subsystems in series: the Launcher, the Receiver and the Data

Acquisition System.

The Launcher, seen in Figure 3-7, is composed of seven components in series, the first four are ex-

vessel components: Gyrotron, MOU Polarizer Unit, Launcher ex-vessel TL and Diamond Window; while

the remaining three are in-vessel components: Spilt-biased Waveguide, Launcher in-vessel TL and

Launcher Mirror.

Figure 3-7: RBD with the reliability architecture of the subsystem Launcher and numbered components.

The Receiver, seen in Figure 3-8, is composed of one Receiver Mirror in series, seven Transmission

Lines that are a part of a m-out-of-n network and a special transmission line the Passive View (see

Figure 3-11) that shares a Fused Silica Window with one of the Transmission Lines. The need for the

Passive View depends on the quality of the microwaves being received and the level of noise present.

To describe the RBD, it will be considered critical and will be represented in series. Its components are

all in series, the first two in-vessel components are the Receiver Mirror and the Receiver in-vessel TL;

the remaining three ex-vessel components are a shared Fused Silica Window, Receiver ex-vessel TL,

Receiver Electronics.

26

Figure 3-8: RBD with the reliability architecture of the subsystem Receiver

The Transmission Lines, seen in Figure 3-9, are seven identical lines. These transmission lines are not

independent: they have all their components in series, but two sets of three lines share the same fused

silica window, see Figure 3-10. The identical receiver transmissions lines are considered in parallel, and

the ITER CTS is declared available if at least m-out-of-7 transmission lines (of the m-out-of-n network)

are available.

Figure 3-9: RBD with the transmission lines expanded.

27

Figure 3-10: RBD of three Transmission Lines sharing one Fused Silica Window.

Figure 3-11: RBD of the special transmission line Passive View.

The Data Acquisition System, seen in Figure 3-12, is in series with the rest of the subsystems, it is made

by one component, and it is critical for the operation of the ITER CTS.

Figure 3-12: RBD of the subsystem Data Acquisition System

3.3. Failure Modes Effects and Critical Analysis

The Failure Modes, Effects and Criticality Analysis (FMECA) used both the Functional breakdown and

the RBDs data as input and pursued the same steps followed in the previous RAMI analysis reported in

[4].

Previously to the analysis of the failure modes of the components, a list of all the possible component

failure modes was established. The failure modes of each component were then identified based on that

list, followed by the identification of their causes and effects regarding the basic functions (Table 3-2).

28

Table 3-2:Failure Modes Effects and Causes of ITER CTS components.[56]

Component Failure

Mode

Effect

(Impact on

operation)

Cause

(Root cause of the

failure mode, failure

mechanism)

Gyrotron all modes Inoperative system Failure of gyrotron

MOU Polarizer

unit all modes

Microwave

transmitted without

the right

polarization

Failure of polarizer

Launcher ex-

vessel

Transmission

Line

all modes Secondary vacuum

lost Failure of TL

Diamond

window all modes

Loss of

confinement barrier Failure of barrier

Launcher in-

vessel TL

(cooled)

all modes

Plasma breakdown

and arcing resulting

in destruction of

components

Failure of WG

Launcher mirror

M1 (cooled)

Thermo-

mechanical

failure

Deformation of the

beam profile

Thermomechanical

stress

Receiver mirror

M2

Thermo-

mechanical

failure

Deformation of the

beam profile

Thermomechanical

stress

Receiver mirror

M3

Thermo-

mechanical

failure

Deformation of the

beam profile

Thermomechanical

stress

Receiver in-

vessel TL all modes

ITER CTS

transmission signal

lost

Failure of TL

Fused silica

window all modes

Loss of

confinement barrier Failure of barrier

Receiver ex-

vessel TL all modes

Secondary vacuum

lost Failure of TL

Receiver

electronics all modes

Deterioration of the

capability of

measurement

Failure of electronics

components

Data

Acquisition

System

all modes Partial loss of

function

Failure of acquisition

system

The ITER RAMI defines the severity (effect on the availability of ITER machine), the occurrence

(frequency of failure) rating criteria and major, medium, and minor failure risks [4]

29

Table 3-3 aggregates the inputs and the criticality calculation for all the failure modes identified for the

ITER CTS system. Each register in the table contains the following elements:

• The failure mode associated with the basic function/component;

• The impact on ITER operation (Yes/No).

• The pre-mitigation occurrence value;

• The pre-mitigation severity value;

• The level of criticality (automatically determined using the expression criticality = occurrence x

severity).

According to the RAMI procedure from ITER, a criticality level (= O x S) over 13 is considered to be a

major risk, and mitigation provisions must be implemented. A criticality between 7 and 13 is categorised

as a medium risk and mitigation is recommended. Mitigation actions for a criticality less than 7 are

optional.

Table 3-3: Initial severity, occurrence frequency and criticality level for each function failure mode.[56]

Component Failure Mode Impact on ITER

operation O S

Level

O x S

Gyrotron all modes N 4 1 4

MOU Polarizer unit all modes N 4 1 4

Launcher ex-vessel

Transmission Line all modes N 4 1 4

Diamond window all modes Y 4 5 20

Launcher in-vessel TL

(cooled) all modes Y 4 5 20

Launcher mirror M1

(cooled)

Thermomechanical

failure Y 4 5 20

Receiver mirror M2 Thermomechanical

failure N 4 1 4

Receiver mirror M3 Thermomechanical

failure N 4 1 4

Receiver in-vessel TL all modes N 4 1 4

Fused silica window all modes Y 4 5 20

Receiver ex-vessel TL all modes N 4 1 4

Receiver electronics all modes N 4 1 4

Data Acquisition System all modes N 4 1 4

3.4. RAMI requirements

The outputs of the ITER RAMI process will be the RAMI requirements that must be integrated as system

and subsystems design requirements of the ITER CTS:

30

• Availability and reliability targets for the system and main functions according to the project

requirements;

• Required design changes that need to be integrated to improve the current design in order to

meet availability and reliability requirements;

• Specific tests to be performed on the components or systems;

• Operation procedures and specific training to lower the risks when operating the machine;

• Maintenance requirements in terms of list of spares, intervals of inspection and preventive

maintenance, procedures and training;

• Proposals for standardisation of common parts used in great number in the project, as ensuring

inter-changeability of spares in the design of the systems allows for shorter maintenance

operation (procurement, replacement of consumables, repairs of failed components). As far as

it reduces the downtime of the system and the severity ratings of the failure (in the FMECA),

standardisation of common parts will reduce the failures risk levels and will contribute to a higher

availability of ITER CTS system and the ITER machine.[4]

31

4. Simulation Model

This chapter describes the simulation model that was developed to deal with the stochastic behaviour

of the different components of the system as regards the occurrence of failures and their impact on the

system availability. It is divided into four subchapters where the system’s structure and the simulation

models are described:

4.1 The first subchapter presents the structure of the ITER Collective Thomson Scattering (ITER

CTS) system regarding its blocks of reliability, and the analyses that are going to be done, four

models were developed to evaluate the impact of subsystems and the special transmission

line, the Passive View;

4.2 The second subchapter is an analytical approximation based on the reliability blocks presented

previously; this analytical analysis was performed for the availability and the reliability of the

system;

4.3 The third subchapter is a description of the synchronous, and asynchronous Discrete Event

Simulations (DES) developed to evaluate the systems’ availability. It starts by describing

common elements used in both simulations and then explains the particularities of the models

separately.

4.1. Reliability Block Diagrams

The Reliability Block Diagrams (RBD) approach uses the functional breakdown as a basis but

concentrates on the reliability-wise relationships linking the function-blocks (components that perform

the function). Diagrams describing the multiple levels in a hierarchy consistently with the functional

breakdown, together with the input data fed to the lowest level blocks, allow to compute the resulting

reliability and availability for the upper levels, up to the main functions of the system or to the whole

system itself. These input data (Table 4-1) consist in the reliability parameter, Mean Time Between

Failures (MTBF), and maintenance parameter, Mean Time To Repair (MTTR), which were obtained from

reliability databases, previous experience, tacit knowledge compiled on other scientific

devices/environments, and assumptions made following the personal experience of the RAMI analysis.

Table 4-1: Components reliability and maintainability input data for ITER CTS system availability estimation

(adapted from [56])

Components # of

Components

Failure

rate

(/h)

Failure

distribution MTBF

(years)

MTTR

(h)

Impact on

ITER

operation

Gyrotron 1 2.85E-05 Exponential 4 2160 N

MOU Polarizer unit 1 1.14E-05 Exponential 10 2160 N

Launcher ex-vessel

Transmission Line 1 5.71E-06 Exponential 20 2160 N

Diamond window 1 1.14E-05 Exponential 10 2160 Y

32

Split-biased WG 1 5.71E-06 Exponential 20 2160 N


(cooled) 1 1.14E-05 Exponential 10 2160 Y

Launcher Mirror M1

(cooled) 1 5.71E-06 Exponential 20 2160 Y

Receiver mirror M2 1 5.71E-06 Exponential 20 2160 N

Receiver mirror M3 7+1 5.71E-06 Exponential 20 2160 N

Receiver in-vessel TL 7+1 5.71E-06 Exponential 20 2160 N

Fused Silica Window 3 1.14E-05 Exponential 10 2160 Y

Receiver ex-vessel TL 7+1 5.71E-06 Exponential 20 2160 N

Receiver electronics 7+1 3.00E-06 Exponential 38 24 N

Data Acquisition

System 1 1.71E-05 Exponential 6.68 24 N

Considering the system is composed of three distinct subsystems: the Launcher, the Receiver and the

Data Acquisition System; that these subsystems are partly composed of in-vessel and ex-vessel

components, seven identical transmission lines. These transmission lines are not independent: they

have all their components in series, but sets of 3 lines share the same fused silica window (Figure 3-10).

The identical receiver transmissions lines are considered in parallel and the ITER CTS is declared

available if at least m-out-of-7 transmission lines are available (the m-out-of-n case). Then there is a

special transmission line the Passive View, whose criticality is dependent on the quality of the

microwaves received, meaning that it is necessary for diagnosis purposes when the signal presents a

high noise level.

Four reliability block diagrams were built. These four models aim at exploring the impact of the in-vessel

and ex-vessel components and the passive view on the availability and reliability of the system. The

following four situations were analysed:

1. Complete ITER CTS system including the Passive View Figure 4-1;

2. In-vessel subsystems including the Passive View (excludes IO scope components)Figure 4-2;

3. Complete ITER CTS system excluding the Passive View Figure 4-3;

4. In-vessel subsystems excluding the Passive View (excludes IO scope components) Figure 4-4.

33

Figure 4-1: RBD used to assess the reliability and availability of the ITER CTS system – Whole system including

in-vessel and ex-vessel subsystems, as well as the passive view (in more detail in appendix A1).

Figure 4-2: RBD used to evaluate the reliability and availability of the ITER CTS system – In-vessel Subsystem

including the passive view (ex-vessel IO scope components are excluded) (in more detail in appendix A2).

34

Figure 4-3: RBD used to evaluate the reliability and availability of the ITER CTS system – Whole system including

in-vessel and ex-vessel subsystems, excluding the passive view (in more detail in appendix A3).

Figure 4-4: RBD used to evaluate the reliability and availability of the ITER CTS system – In-vessel Subsystem

excluding the passive view (ex-vessel) IO scope components are excluded (in more detail in appendix A4).

35

4.2. Analytical Approach

The analysis of the reliability and availability of the ITER CTS was started with an analytical approach.

It is the quicker way of getting a first sense of the systems’ availability and reliability, with the possibility

of identifying more impacting components or subsystems.

The system’s Reliability and Availability were calculated for the four models presented in subchapter

4.1; those four RBDs are different arrangements that divide the system into “in-vessel components vs

the whole system” and “system with passive view vs system without passive view”. The analyses were

also tailored to provide information regarding the subsystems (Launcher, Receiver and DAQ), as well

as, the other differentiating characteristics in the RBDs.

4.2.1. Reliability

Table 4-2 shows the reliability calculation for each subsystem: the Launcher (Figure 4-5), the Receiver

(Figure 4-6), the Data Acquisition System (Figure 4-7), the special transmission line called Passive View.

Since there are seven identical transmission lines their components are only represented once; the

index (i) accounts for all of the components of each subsystem. In-vessel and ex-vessel components

are also identified by a vertical column on the left of the components’ names. It was assumed that 7-

out-of-7 transmission lines are necessary to be working for the system to be available. The reliability

calculations were made for the Launcher (𝑅𝐿), the Launcher’s in-vessel components ( 𝑅𝐿(𝑖𝑛−𝑣𝑒𝑠𝑠𝑒𝑙)), each

Transmission Line (𝑅𝑇𝐿𝑘), the Transmission Line’s in-vessel components (𝑅𝑇𝐿𝑘(𝑖𝑛−𝑣𝑒𝑠𝑠𝑒𝑙)), 7-out-of-7

Transmission Lines (𝑅𝑇𝐿), the Passive View (𝑅𝑃𝑉), the Fused Silica Widows (𝑅𝐹𝑆𝑊), the Passive View’s

in-vessel components (𝑅𝑃𝑉(𝑖𝑛−𝑣𝑒𝑠𝑠𝑒𝑙)) and the Data Acquisition System (𝑅𝐷𝐴𝑄).

Figure 4-5: Launcher subsystem with numbered components.

36

Figure 4-6: Receiver subsystem with numbered components.

Figure 4-7: Data Acquisition System with numbered components.

37

Table 4-2: Analytical Approach for the Reliability

Subsystem Component i Reliability (R)

𝑹 = 𝒆−𝝀𝒕

Lau

nch

er

(L)

ex-v

essel

Gyrotron (i=1)

𝑖=1,…,7

𝑅𝐿 = 𝑒−𝜆1𝑡 × …× 𝑒−𝜆7𝑡

𝑅𝐿(𝑖𝑛−𝑣𝑒𝑠𝑠𝑒𝑙) = 𝑒−𝜆5𝑡 × …× 𝑒−𝜆7𝑡

Polarizer Unit (i=2)

Launcher ex-vessel TL (i=3)

Diamond Window (i=4)

in-v

ess

el

Split-biased Waveguide

(i=5)


(mitre bendx3) (i=6)

Launcher mirror (cooled)

(m1) (i=7)

Receiv

er

Tra

nsm

issio

n L

ine

(TL

)

in-v

ess

el

Receiver Mirror (cooled)

(m2) (i=8)

𝑖=8,…,39

{

𝑅𝑇𝐿𝑘(𝑖𝑛−𝑣𝑒𝑠𝑠𝑒𝑙)

= 𝑒−𝜆9𝑡 × 𝑒−𝜆10𝑡

𝑅𝑇𝐿𝑘(𝑖𝑛−𝑣𝑒𝑠𝑠𝑒𝑙)= 𝑅𝑇𝐿1 = ⋯ = 𝑅𝑇𝐿7

𝑅𝑇𝐿(𝑖𝑛−𝑣𝑒𝑠𝑠𝑒𝑙) ∗= 𝑒−𝜆8𝑡 × 𝑅𝑇𝐿1 × …× 𝑅𝑇𝐿7

𝑅𝐹𝑆𝑊 = 𝑒−𝜆11𝑡 × 𝑒−𝜆24𝑡 × 𝑒−𝜆37𝑡

{

𝑅𝑇𝐿𝑘 = 𝑒−𝜆9𝑡 × 𝑒−𝜆10𝑡 × 𝑒−𝜆12𝑡 × 𝑒−𝜆13𝑡

𝑅𝑇𝐿𝑘 = 𝑅𝑇𝐿1 = ⋯ = 𝑅𝑇𝐿7𝑅𝐹𝑆𝑊 = 𝑒−𝜆11𝑡 × 𝑒−𝜆24𝑡 × 𝑒−𝜆37𝑡

𝑅𝑇𝐿 ∗= 𝑒−𝜆8𝑡 × 𝑅𝑇𝐿1 × …× 𝑅𝑇𝐿7 × 𝑅𝐹𝑆𝑊

*the reliability 𝑅𝑇𝐿 and 𝑅𝑇𝐿(𝑖𝑛−𝑣𝑒𝑠𝑠𝑒𝑙) includes

de first receiver mirror of the Receiver

Receiver Mirror (m3)

(i=9,14,18,22,27,31,35)

Receiver in-vessel TL

(i=10,15,19,23,28,32,36)

ex-v

essel

Fused Silica Window

(i=11,24,37)

Receiver ex-vessel TL

(i=12,16,20,25,29,33,38)

Receiver electronics

(i=13,17,21,26,30,34,39)

Pas

siv

e V

iew

(PV

)

in-v

ess

el

Passive View Receiver

(i=40)

𝑖=39,…,43

𝑅𝑃𝑉 = 𝑒−𝜆40𝑡 × 𝑒−𝜆41𝑡 × 𝑒−𝜆42𝑡 × 𝑒−𝜆43𝑡

𝑅𝑃𝑉(𝑖𝑛−𝑣𝑒𝑠𝑠𝑒𝑙) = 𝑒−𝜆40𝑡 × 𝑒−𝜆41𝑡

Passive View in-vessel TL

(i=41)

ex-v

essel

Fused Silica Window (i=37)

Passive View ex-vessel

(i=42)

Receiver electronics (i=43)

DAQ DAQ (i=44)

𝑖=44

𝑅𝐷𝐴𝑄 = 𝑒−𝜆44𝑡

38

After getting the partial results for the subsystem and in-vessel components, the formulae were

combined, as seen in Table 4-3, to give the values of the whole system with passive view, in-vessel

components with passive view, whole system without passive view and in-vessel system without passive

view. The Reliability of each of these cases is presented as a function of time.

Table 4-3: Analytical Results for the four RBDs

RBD Total Reliability

Whole system with

Passive View 𝑅 = 𝑅𝐿 × 𝑅𝑇𝐿 × 𝑅𝑃𝑉 × 𝑅𝐷𝐴𝑄

In-vessel system with

Passive View 𝑅 = 𝑅𝐿(𝑖𝑛−𝑣𝑒𝑠𝑠𝑒𝑙) × 𝑅𝑇𝐿(𝑖𝑛−𝑣𝑒𝑠𝑠𝑒𝑙) × 𝑅𝑃𝑉(𝑖𝑛−𝑣𝑒𝑠𝑠𝑒𝑙) × 𝑅𝐷𝐴𝑄

Whole system without

Passive View 𝑅 = 𝑅𝐿 × 𝑅𝑇𝐿 × 𝑅𝐷𝐴𝑄

In-vessel system without

Passive View 𝑅 = 𝑅𝐿(𝑖𝑛−𝑣𝑒𝑠𝑠𝑒𝑙) × 𝑅𝑇𝐿(𝑖𝑛−𝑣𝑒𝑠𝑠𝑒𝑙) × 𝑅𝐷𝐴𝑄

4.2.2. Availability

Table 4-4 shows the availability calculation for each subsystem: the Launcher, the Receiver, the Data

Acquisition System, the special transmission line called Passive View. Since there are seven identical

transmission lines their components are only represented once; the index (i) accounts for all of the

components of each subsystem. In-vessel and ex-vessel components are also identified by a vertical

column on the left of the components’ names. Given the system’s complex reliability-wise relationships,

the calculation of the availability concerning the m-out-of-n network was done with the project

assumption that at least 5-out-of-n Transmission Lines would have to be working for the system to be

considered operational. With regards to the RBD of the Whole System with Passive, this condition turned

the Fused Silica Windows into critical components, since if one fails three Transmission Lines stop

working as Figure 3-10 shows.

The availability calculations were made for the Launcher (𝐴𝐿), the Launcher’s in-vessel components

( 𝐴𝐿(𝑖𝑛−𝑣𝑒𝑠𝑠𝑒𝑙)), each Transmission Line (𝐴𝑇𝐿𝑘), the Transmission Line’s in-vessel components

(𝐴𝑇𝐿𝑘(𝑖𝑛−𝑣𝑒𝑠𝑠𝑒𝑙), Receiver with m-out-of-7 Transmission Lines (𝐴𝑇𝐿), the three Fused Silica Windows

(𝐴𝐹𝑆𝑊), the Passive View (𝐴𝑃𝑉), the Passive View’s in-vessel components (𝐴𝑃𝑉(𝑖𝑛−𝑣𝑒𝑠𝑠𝑒𝑙)) and the Data

Acquisition System (𝐴𝐷𝐴𝑄).

39

Table 4-4: Analytical Approach for the Availability.

Subsystem Component i Availability (A)

𝑨 =𝑼𝒑 𝑻𝒊𝒎𝒆

𝑼𝒑 𝑻𝒊𝒎𝒆 +𝑫𝒐𝒘𝒏 𝑻𝒊𝒎𝒆=

𝑴𝑻𝑩𝑭

𝑴𝑻𝑩𝑭 +𝑴𝑻𝑻

La

un

ch

er

(L)

ex

-ve

ss

el

Gyrotron (i=1)

𝑖=1,…,7

𝐴𝐿 = 𝐴1 ×…× 𝐴7

𝐴𝐿(𝑖𝑛−𝑣𝑒𝑠𝑠𝑒𝑙) = 𝐴5 ×…× 𝐴7

Polarizer Unit (i=2)

Launcher ex-vessel TL (i=3)

Diamond Window (i=4)

in-v

ess

el

Split-biased Waveguide (i=5)

Launcher in-vessel TL (mitre

bendx3) (i=6)

Launcher mirror (cooled) (m1)

(i=7)

Rec

eiv

er

Tra

ns

mis

sio

n L

ine

(TL

)

in-v

ess

el

Receiver Mirror (cooled) (m2)

(i=8)

𝑖=8,…,39

{

𝐴𝑇𝐿𝑘(𝑖𝑛−𝑣𝑒𝑠𝑠𝑒𝑙)

= 𝐴9 × 𝐴10

𝐴𝑇𝐿𝑘(𝑖𝑛−𝑣𝑒𝑠𝑠𝑒𝑙= 𝐴𝑇𝐿1 = ⋯ = 𝐴𝑇𝐿7

𝐴𝑇𝐿(𝑖𝑛−𝑣𝑒𝑠𝑠𝑒𝑙) = 𝐴𝑇𝐿𝑚 7⁄ (𝑖𝑛−𝑣𝑒𝑠𝑠𝑒𝑙)× 𝐴8

𝐴𝐹𝑆𝑊 = 𝐴11 × 𝐴24 × 𝐴37

{

𝐴𝑇𝐿𝑘 = 𝐴9 × 𝐴10 × 𝐴12 × 𝐴13𝐴𝑇𝐿𝑘 = 𝐴𝑇𝐿1 = ⋯ = 𝐴𝑇𝐿7𝐴𝑇𝐿 = 𝐴𝑇𝐿𝑚

7⁄× 𝐴8 × 𝐴𝐹𝑆𝑊

𝐴𝑇𝐿𝑚7⁄∗ = ∑ (

7𝑗)

7

𝑗=𝑚

𝐴𝑇𝐿𝑘𝑗(1 − 𝐴𝑇𝐿𝑘)

7−𝑗

(7𝑗) =

7!

(7 − 𝑗)! 𝑗!

*for the Availability, 𝐴𝑇𝐿𝑚7⁄ (𝑖𝑛−𝑣𝑒𝑠𝑠𝑒𝑙)

, of the

in-vessel system use 𝐴𝑇𝐿𝑘(𝑖𝑛−𝑣𝑒𝑠𝑠𝑒𝑙) instead of

𝐴𝑇𝐿𝑘.

Receiver Mirror (m3)

(i=9,14,18,22,27,31,35)

Receiver in-vessel TL

(i=10,15,19,23,28,32,36)

ex

-ve

ss

el

Fused Silica Window

(i=11,24,37)

Receiver ex-vessel TL

(i=12,16,20,25,29,33,38)

Receiver electronics

(i=13,17,21,26,30,34,39)

Pa

ss

ive

Vie

w

(PV

)

in-v

ess

el Passive View Receiver (i=40)

𝑖=39,…,43

𝐴𝑃𝑉 = 𝐴40 × 𝐴41 × 𝐴42 × 𝐴43

𝐴𝑃𝑉(𝑖𝑛−𝑣𝑒𝑠𝑠𝑒𝑙) = 𝐴40 × 𝐴41

Passive View in-vessel TL

(i=41)

ex

-ve

ss

el

Fused Silica Window (i=37)

Passive View ex-vessel (i=42)

Receiver electronics (i=43)

DAQ DAQ (i=44)

𝑖=44

𝐴𝐷𝐴𝑄 = 𝐴44

40

After getting the partial results for the subsystem and in-vessel components, the formulae were

combined, as seen in Table 4-5, to give the values of the whole system with passive view, in-vessel

components with passive view, whole system without passive view and in-vessel system without passive

view. The Availability regarding the four RBDs was determined for at least 5, 6 and 7-out-of-7

Transmission Lines working.

Table 4-5: Analytical Results for the Availability.

RBD Total Availability

Whole system with

Passive View 𝐴 = 𝐴𝐿 × 𝐴𝑇𝐿 × 𝐴𝑃𝑉 × 𝐴𝐷𝐴𝑄

In-vessel system with

Passive View 𝐴 = 𝐴𝐿(𝑖𝑛−𝑣𝑒𝑠𝑠𝑒𝑙) × 𝐴𝑇𝐿(𝑖𝑛−𝑣𝑒𝑠𝑠𝑒𝑙) × 𝐴𝑃𝑉(𝑖𝑛−𝑣𝑒𝑠𝑠𝑒𝑙) × 𝐴𝐷𝐴𝑄

Whole system without

Passive View 𝐴 = 𝐴𝐿 × 𝐴𝑇𝐿 × 𝐴𝐷𝐴𝑄

In-vessel system without

Passive View 𝐴 = 𝐴𝐿(𝑖𝑛−𝑣𝑒𝑠𝑠𝑒𝑙) × 𝐴𝑇𝐿(𝑖𝑛−𝑣𝑒𝑠𝑠𝑒𝑙) × 𝐴𝐷𝐴𝑄

4.3. Discrete Event Simulation Models

Simulation models are structured in the time domain, where the flow of events can be observed and

evaluated. When a discrete event model is built for reliability, availability, maintainability and

inspectability analysis, tasks and operations are modelled as discrete, chronologically ordered steps.

The model was programmed with the support of an appropriate simulation package namely the Simulink

package of MATLAB environment. Simulations runs are made to assess the impact of time-dependent

equipment operations (failures and repairs) on the performance of the system. The simulator’s input

includes RAMI information, e.g., time to failure and repair times distributions, the duration of the mission

and other elements that affect equipment reliability.

The simulation considers the system in its operational status until a failure occurs in some system

component. After the failure is repaired, the simulation continues until the next failure. Performance

measures, e.g., a number of failures and total downtime are collected during the simulation run allowing

the estimation of the system’s availability. Because the model uses random variables to describe the

times to failure according to their specific statistical distributions; any simulation model must be

previously setup with (1) a duration time for a simulation that allows retrieving statistically significant

conclusions on the mean availability-relevant parameters; and (2) a number of simulation runs

(independent experiments) that allows drawing significant conclusions on the randomness and spread

of these parameters.

41

This subchapter presents two different simulation models with different characteristics. However, since

these are both based on DES, some activity-block are shared. Before embarking on a more in-depth

description of those models, it is advisable to introduce them now. The shared activity blocks are:

Pseudorandom Failure Generators:

The first stage of the development of the algorithm requires the random generation of Times to Failure

(TTF) for each component. All components have an exponential failure distribution. So, by using a

random number belonging to [0,1] with a uniform distribution to generate the cumulative failure

distribution at time t and reversing equation 2.6, each time to failure can be simulated. The process is

described in Figure 4-8, which requires the failure rate of the simulated component and the generation

of a set of random numbers to generate its sequence of failures.

Figure 4-8: Generation of pseudorandom Times To Failure of each component k (TTF Generator).

The implementation of this process can be seen in Figure 4-9, where the logarithm of the pseudorandom

number generated is divided by the failure rate. As can be seen, the failure rate is the inverse of the

MTBF (mean time between failure). The unit delay is used to break internal loops created during the

simulation development.

Figure 4-9: MATLAB Simulink- an example of the application of the algorithm developed to generate

pseudorandom times to failure for any component.

42

After generating the stochastic failures and corresponding signals, the status of the components must

be combined accordingly to their hierarchical relationships. Components in series are connected by

logic gates “and”, which means that if any component fails the– ITER CTS system will go down.

For the transmission lines that belong to an m-out-of-n architecture, the flowchart in Figure 4-10 shows

how the signal from every transmission line is added and depending on the threshold chosen (number

of Transmission Lines working for the ITER CTS system be considered available) the signal will be

changed.

Figure 4-10: Flowchart for the treatment of the threshold pertaining to the m-out-of-n network.

Figure 4-11 shows the Simulink block resulting from the implementation of the flowchart in Figure 4-10.

The Boolean signal is converted, then added. Finally, the outputs of this block are seven Boolean signals

corresponding to the seven different possible thresholds that can be chosen, from one line working to 7

lines working simultaneously.

Figure 4-11: Overview of the implementation of the threshold for the m-out-of-n network.

43

4.3.1. Synchronous Model

The analytical approach gave a first useful yet rough sense of the system’s strengths and frailties. To

further explore the system’s behaviour there was the need to develop a DES. Stochastic Discrete Event

Simulations could provide a broader range of statistical information regarding the system’s performance.

Assumptions:

• At the start of the simulation all components are operational and with a null past operative time;

• The components work independently and do not influence the behaviour of other components;

• The components work in operation-failure-maintenance cycles;

• After a repair process all components are as good as new;

• Each component has its own, independent, activity-block that produces a Boolean signal:

o 1 means operational,

o 0 means not-operational;

• Each component has its own unique reliability and maintainability characteristics;

o Time Failure (TTF) is simulated based on a pseudorandom number, according to an

exponential distribution,

o Mean Time to Repair (MTTR) is a constant;

• Each component has its own Pseudorandom Time of Failure Generator;

• Failures correspond to state change and occur instantaneously;

• Whenever a failure occurs, maintenance starts immediately, and its duration is MTTR;

• Whenever maintenance ends, a new TTF is attributed to that component as the operation-

failure-maintenance cycle renews itself.

• The simulation is event-based (Figure 4-12);

• The simulation will end at a predetermined time.

Figure 4-12: Sequence of Events in the Synchronous Simulation, until the TTF is reached the systems is

operational during the MTTR the system is not-operational.

Figure 4-13 shows the operation-failure-maintenance cycle, which implies state alternations between

one (operational) and zero (not-operational). The clock used to evaluate if the component is operational

44

or not-operational is the same for every component. The management of the “failure” condition is made

cumulatively, meaning prior events (maintenance and operational time) are added to a pseudorandom

failure time, once reached a state change will be triggered.

Figure 4-13: Schematic of the state changes in the signal of one component, as a result of reaching the time of

the next event.

Figure 4-15 shows the Boolean signal generated by an activity-block explicitly developed for the

synchronous simulation. This block receives as input the clock, the pseudorandom numbers from the

TTF Generator and the MTTR of the component. With this input it then manages to produce the

component’s signal, similar to the one seen in Figure 4-13, with operational times, followed by random

failures (TTF) and then maintenance periods (MTTR). The algorithm used to produce this signal can be

seen in Figure 4-15, one of its key elements, the Time of Return (ToR), see Figure 4-14.

45

Figure 4-14: Schematic showing the cumulative nature of the 𝑇𝑜𝑅𝑖, for the synchronous system.

Time of Return refers to the point in time where maintenance (MTTR) is over and instantaneously a new

Failure is loaded. ToR is cumulative and represents the sum of every operational (before TTF) period

and every not-operational period (MTTR) activity the system has ever undergone up to the point where

the last maintenance ended.

Figure 4-15: Flowchart of the algorithm representing the generation of the Boolean signal of one component for

the synchronous system.

1. Assumptions: At the beginning of the simulation the component is available, as such, the starting

signal is 1, and a newly generated TTF (time of failure) is loaded.

2. The sum of Time of Failure with the previous time at which the signal of the component was set to

1 (ToR) is then continuously compared to the clock to see if the clock reached the TTF:

a) If NO the clock is incremented without further action

b) If YES the signal of the component is changed to 0 (meaning a failure has occurred, the impact

of this failure will be evaluated further on)

The MTTR (mean time to repair) is loaded, and the sum of TTF with ToR and MTTR is compared

to the clock to see if it has been reached:

46

c) If NO the clock is incremented without further action

d) If YES the signal of the component is changed to 1 (meaning the component has been

repaired, the impact of this action will be evaluated further on)

3. Lastly, the operation goes back to point 2), a new time of failure is loaded, and the process is

repeated until the predefined “time of simulation” is over.

The implementation of the algorithm that generates the Boolean signal can be seen in Figure 4-16.

Since TTF are being generated at all discrete points in time, it’s necessary to hold on and save the TTF

of the component each time its signal changes from 0 to 1, as it is the representative TTF for its next

failure. To do this a “Sample and Hold” block that stores the sum of the representative TTF together with

the time at which it was generated (ToR) is used.

Figure 4-16: MATLAB Simulink -- example of application of the algorithm developed to generate the Boolean

signal of a single component

The output of this model is seven arrays that store the systems’ states throughout the simulation

timeframe. The seven arrays are a combination of the availability of the critical components and the m-

out-of-n network. Hence the need for seven different signals.

A MATLAB script controls the simulation, runs it multiple times and changes seeds at every run so that

various scenarios are tested. Given that all components are independent of each other, only one

Simulink file can generate data for all of the four models. It also processes arrays into the availability of

the system and stores the data obtained in excel files, where the analysis and post-processing of the

results are made.

4.3.2. Asynchronous Model

The synchronous system provides a respectable though conservative measurement of the availability

of the system. It is a more straightforward analysis, so it demands less computational capability. Its chief

handicap is that since the components work independently from each other, when a failure occurs in a

component and it undergoes through a repair period, the others are kept running even if the system is

down. Whenever a critical component becomes not-operational due to a failure and subsequent

maintenance, the whole system should stop, and the other components should be put on a waiting

47

status that would delay predicted. By not having inter-dependencies between components the

availability projected is lower than it should, components are considered to be operational even when

they shouldn’t so the number of failures is higher, and they can also occur concomitantly. This

characteristic of the synchronous system can be overlooked when the order of magnitude of the MTTR

is small enough when compared to the MTBF. However, when that is not the case, so, to get finer

availability projections, an asynchronous model was developed, bypassing the availability constraints

caused by the order of magnitude of the MTTR and the MTBF, while also better emulating the real

situation.

In this context being asynchronous means that in parallel with the system’s clock, each component has

its own clock, measuring its operational working time. This is achieved by creating a feedback loop that

governs every component the Global Final Signal (GFS), see Figure 4-18. When the GFS is one,

meaning the system is operational, and the expected sequence of events happens normally, see Figure

4-12. When the GFS is zero the expected sequence of events suffers delays, see Figure 4-17; failures

are postponed by the same amount of time the system is not-operational. However, there is a safeguard

if the failure in GFS is caused by the component itself, the internal clock doesn’t stop and the

maintenance operation goes on as planned.

Assumptions for each block:

• The components start the simulation operational;

• The components are not independent, failure-wise, from each other:

o Failures of critical components for the system, delay the internal clocks of components

not involved in the failure itself;

o Failures of non-critical components for the system, but critical for a particular set of

components, given the reliability connections, will delay the internal clock of that set of

particular components;

o Components will receive the appropriate feedback as to delay their internal clocks

accordingly to the reliability-wise relationships

• The components work in operation-failure-maintenance and delay cycles;

• Each component has its own, albeit dependent, activity-block that produces a Boolean signal:

o 1 means operational or being delayed,

o 0 means not-operational;

• Each component has its own unique reliability and maintainability characteristics;

o Time of Failure (TTF) is a pseudorandom number,

o Mean Time to Repair (MTTR) is a constant;

• Each component has its own Pseudorandom Time of Failure Generator;

• Failures correspond to state change and occur instantaneously;

• Failures of foreign critical components delay the internal clocks of other non-failing components

by the same amount time the system is not-operational;

• Whenever a failure occurs, maintenance starts immediately, and its duration is MTTR;

48

• Whenever maintenance ends, a new TTF is attributed to that component as the operation-

failure-maintenance and delay cycle renews itself.

• The simulation is event-based (Figure 4-17);

• The simulation will end at a predetermined time.

Figure 4-17: Sequence of Events in the Asynchronous Simulation with a delay in the Time to failure 𝑇𝑇𝐹2.

Figure 4-18 shows the operation-failure-maintenance and delay cycle, which implies state alternations

between one (operational) and zero (not-operational). The clock used to evaluate if the component is

operational or not-operational is unique to every component (internal clock), it suffers delays whenever

the critical components fail and affect the GFS but also in non-critical components that due to reliability

connections affect sections of the system. An example is when the Fused Silica Window in Figure 3-10

fails three Transmission Lines will go down and their non-failing components internal clock will be delay

by the same amount of time it takes to recuperate the Fused Silica Window. As in the synchronous

system, the management of the “failure” condition is made cumulatively, meaning prior events

(maintenance and operational time) are added to a pseudorandom failure time, once reached a state

change will be triggered.

49

Figure 4-18: Schematic of the state changes in the signal of one component, as a result of the interaction

between reaching the time of the next event and the Global Final Signal.

In Figure 4-19 it is possible to see the evolution of the ToR for a single component, the progression is

still cumulative, chunks of time corresponding to the MTTR and the TTF are continuously added with

the exception of the delays. Delays happen when the activity-block that generated the asynchronous

Boolean signal receives a zero signal in its control port. The progression of time in that component stops,

thus postponing the next Time to failure.

Figure 4-19: Schematic showing the cumulative nature of the 𝑇𝑜𝑅𝑖, for the asynchronous system.

50

Figure 4-20: Flowchart of the algorithm representing the generation of the Boolean signal of one component for

the asynchronous system.

1. Assumptions: At the beginning of the simulation every component is available, GFS is 1, and the

internal signal of the component is 1, and a TTF is generated and loaded;

2. Since a GFS is commanding the inner clock of every component, this test is repeated at every

discrete moment in time. There are three possible outcomes, there are no failures (I), there is a

failure, but it is in another component (II), there is a failure in this component (III):

a) If GFS=0: the system is available;

I. The sum of Time of Failure with the time at which the TTF was generated (ToR) is compared

to the clock to see if the clock has reached the TTF:

A. If NO the clock is incremented without further action

B. If YES the signal of the component is changed to 0 (meaning a failure has occurred,

and if the component is critical GFS=0)

The MTTR (mean time to repair) is loaded, and the sum of ToF with ToR and MTTR

is compared to the clock to see if it has been reached:

C. If NO the clock is incremented without further action;

D. If YES the signal of the component is changed to 1 (meaning the

component has been repaired, the impact of this action will be evaluated

further on);

b) If GFS=ZERO, there has been a failure and it is necessary to compare the component’s Internal

Signal (IS) to the GFS:

51

II. If the Internal Signal is ONE the internal clock (IClock) remains unchanged and the

component’s TTF is therefore delayed in time;

III. If the Internal Signal is ZERO, the failure is coming from the component, and the IC must

not be stopped. Go back to point C.

3. Lastly, the operation goes back to point a), the GFS continues to be tested, the process is repeated

until the predefined “time of simulation” is over.

The implementation of the algorithm in Figure 4-20 was done resorting to MATLAB Simulink and can be

seen in Figure 4-21. The principle is the same used in the synchronous model. However, if there are

external failures, the TTF of the component will be delayed while the system is down.

Figure 4-21: MATLAB Simulink - signal generation of the asynchronous

Conditions for the entire system:

• At the beginning the system is operational;

• Failures from any critical component will make the system not-operational, and delay further

failures from other components;

• A failure of a component belonging to a parallel line, such as the transmission lines, will only

affect components in that line, delaying further failures from those components;

• The system will remain operational unless all the Transmission Lines in the-m-out-of-n network

fail at the same time,

• A failure in a Fused Silica Window will cause the three Transmission Lines connected to it to

become not-operational;

• If the three Transmission Lines connected to one Fused Silica Window fail at the same time,

because other components than the Fused Silica Window failed the Fused Silica Window will

be delayed

52

• Components in series are critical, combining their signals is made by using a logic gate AND, if

any input is zero the output will be zero;

• The Global Final Signal (GFS) is calculated by an activity-block and fed (Figure 4-22) to every

component, components that are not in series require the combination of GFS with other

components;

Figure 4-22: High-level representation of the feedback system used to govern the components' internal clock.

• Activity-blocks built to implement the, previously, mentioned conditions and determine whether

a component should be put on hold (meaning its failures should be delayed) are:

o Global Final Signal (see Figure 4-23) – that processes the operational signal from the

whole system, considering all its subsystems.

Figure 4-23: Block Processing the Global Final Signal for the Whole System including the Passive View.

53

o Transmission Lines (see Figure 4-24) - tests to see if any component of the transmission

line in question has failed, combines it with the GFS and delays the internal clock of

each component accordingly;

Figure 4-24: Transmission Line controller and the inside view of the controller.

o Fused Silica Windows (see Figure 4-25) – The Transmission Lines operation signals

and the GFS signal are the input signals of this activity-block. Its purpose is to delay the

Fused Silica Windows’ internal clock by testing for GFS=0 (complete system not-

operational) and for at least one line connected to the Transmission Line is operational.

Figure 4-25: Fused Silica Window controller and the inside view of the controller.

54

Figure 4-26: Overview of the complete Asynchronous Model for the Whole System with Passive View, attesting to

its complexity.

Figure 4-26 is an overview of the Simulink file, showing the whole system with passive view, the

subsystems and the signal processing and controlling activity-blocks.

The output of this model, as in the synchronous simulation, are seven arrays that store the systems

states throughout the simulation timeframe. The seven arrays are a combination of the availability of the

critical components and the m-out-of-n network. Hence the need for seven different signals.

A MATLAB script controls the number of trials required for statistical relevancy. It was necessary to

develop four different Simulink files to model each simulation, given the dependencies among

components. Every Pseudorandom Failure Generator has one Simulink block called Uniform Random

Number, these blocks are programmed to supply random probabilities and every one of them has a

different seed. These seeds are changed at the beginning of every trial to ensure that the sample of

scenarios is diverse. At each trial, arrays with system’s state are processed into the availability of the

system and then stored in excel files, where the probabilistic analysis is made.

55

5. Results

The results presented in this chapter concern not only singular components, but also the four models

presented in chapter 4:

• Whole system with passive view (Figure 4-1);

• Only in-vessel components with passive view (Figure 4-2);

• Whole system without passive view (Figure 4-3);

• Only in-vessel components without passive view (Figure 4-4).

This chapter is divided into subchapters, three of which present numerical results obtained from the

different models, these results are presented in tables, graphics and high-level Reliability Block

Diagrams (RBD).

5.1 The first subchapter the analytical results obtained for the availability and the reliability are

presented and discussed

5.2. The second subchapter is about the validation of the asynchronous model. It shows that

the criteria for operational components, not-operational components and delays of the

times to failure are met;

5.3. The third subchapter are the results of the synchronous simulation;

5.4 The fourth subchapter are the results of the asynchronous simulation and a comparison

between the two Simulink models.

5.1. Analytical Model

The analytical model was previously described in chapter 4, and it was developed to get a first estimation

of the availability and reliability of the ITER CTS.

5.1.1. Availability

The analytical evaluation was done for individual components and for the RBDs mentioned at the

beginning of this chapter.

Table 5-1 and Table 4-1 present the reliability and maintainability parameters and the resulting

availability of the ITER CTS components. As regards the individual components, its high reliability can

be noticed, which results in an availability always higher than 95% even if most of them present a long

repair time. However, the ITER CTS system, has a high number of components in series, which makes

their failures impact the whole system, besides its intricate reliability-wise relationships is expected to

damage its overall availability significantly.

56

Table 5-1 Average availability of ITER CTS system’s components.

Component MTBF MTTR Availability (A)

A =MTBF

MTBF + MTTR (h) (h)

Gyrotron 35040 2160 94.2%

MOU Polarizer unit 87600 2160 97.6%

Launcher ex-vessel Transmission Line

175200 2160 98.8%

Diamond window 87600 2160 97.6%

Split-biased WG 175200 2160 98.8%

Launcher in-vessel TL (cooled) 87600 2160 97.6%

Launcher Mirror M1(cooled) 175200 2160 98.8%

Receiver mirror M2 175200 2160 98.8%

Receiver mirror M3 175200 2160 98.8%

Receiver in-vessel TL 175200 2160 98.8%

Fused Silica Window 87600 2160 97.6%

Receiver ex-vessel TL 175200 2160 98.8%

Receiver electronics 332880 24 100.0%

Data Acquisition System 58516.8 24 100.0%

One should note that the classical analytical methods can only be applied here to obtain an initial

estimation on the availability. This is due to the intricate reliability wise relationships on the transmission

lines and, particularly, to the long time to repair. In fact, the MTTR order of magnitude of is close to the

MTBF one, which means that the probability of having failures in one component when the system is

down cannot be neglected. These issues together with the ability to deal with the stochastic nature of

the availability demanded the development of simulation models to understand the failures of the ITER

CTS system and its dynamic behaviour.

57

Figure 5-1: High-level RBD and subsystems analytical availability.

By combining the availability of every component accordingly to the reliability-wise relationships

presented in Figure 3-6, it was possible to calculate the availability of the subsystems: Launcher,

Receiver and Data Acquisition System, see Table 4-4.

The Launcher has an availability of 81%. The Receiver is divided into four components in series, the

Receiver Mirror (M2) with and availability of 99%, three Fused Silica Windows (FSW) considered to be

in series in this approximation, and thus were represented together in a higher-level block, their

combined availability is 93.0%. Then there are Seven transmission lines in parallel and another special

transmission line in series, the “Passive View”, these transmission lines have the same components,

their availability excluding the Fused Silica Windows is 96%. Finally, there is the Data Acquisition system

with an availability of 100%.

The transmission lines presented in Figure 5-1 are a part of an m-out-of-n network, and as an

approximation a binomial distribution was used to calculate the availability of the four RBD models

(Figure 4-1, Figure 4-2, Figure 4-3, Figure 4-4) for at least 7, 6 and 5 out 7 lines working, see Table 5-2.

As expected, the availability is higher when fewer components are included in series. The most relevant

values are the ones related to the projects demands “at least 5-out-of-7 lines working”. For the Whole

System with Passive view, the availability is 71.3%, when the passive view is excluded the availability

increases by more than 2 points to 73.9%. As for the In-vessel subsystems with Passive View, the

availability is 87.5% when the Passive View is excluded the availability increases to 89.7%. From the

analytical analysis, the most impacting components seem to be the ex-vessel components. However,

the Passive View in relative terms can provide increases on the availability of almost 4%, when excluded

from the whole system.

58

Table 5-2: Availability values gathered from the analytical approximation.

m-out-of-n

Whole System In-Vessel subsystems

With Passive

View

Without Passive

View

With Passive

View

Without Passive

View

7-out-of-7 55.1% 57.2% 73.8% 75.6%

6-out-of-7 69.6% 72.2% 86.6% 88.7%

5-out-of-7 71.2% 73.9% 87.5% 89.7%

5.1.2. Reliability

The Reliability (R) of the system was calculated for the RBD presented in chapter 4 (Figure 4-1, Figure

4-2, Figure 4-3, Figure 4-4). Assuming all components, see Table 4-2, had a constant failure rate (𝜆𝑖)

(see equation 2.5), their failure probability was modelled by an exponential probability function.

A first analytical estimation of the reliability of the ITER CTS system was performed assuming that for

the system to be considered in operational conditions all its components must be operational. Since all

components must be operational, a reliability-wise series relationship linking the function-blocks on

RBD. Table 5-3 and Table 5-4 show the analytical results obtained for the reliability and failure function.

These functions mirror each other (see equation 2.3), as time passes, and the reliability decreases the

failure functions increases in the same measure.

Table 5-3: Analytical results for the reliability.

Time (hours)

Whole System In-Vessel Components

with Passive View

without Passive View

with Passive View without Passive View

0 100.0% 100.0% 100.0% 100.0%

250 91.3% 92.0% 95.1% 95.3%

500 83.3% 84.7% 90.4% 90.9%

1000 69.4% 71.8% 81.7% 82.6%

1500 57.8% 60.8% 73.8% 75.1%

2000 48.1% 51.5% 66.7% 68.3%

59

Table 5-4: Analytical results for the Failure Function

Figure 5-2 presents the results achieved, graphically, for the system reliability and failure probability for

the four situations (all components with and without passive view, only in-vessel components with and

without passive view). As expected, reliability increases when the ex-vessel components (IO scope) are

excluded from the analysis when compared with the reliability of the whole system. For instance, at t =

4000 working hours, a success probability (reliability) of 23.1% is expected for the whole system (with

passive view), and a success probability of 44.5% is estimated when the ex-vessel components (with

passive view) are excluded. Figure 5-2 also shows that the effect of the passive view can be considered

4000 23.2% 26.6% 44.5% 46.6%

6000 11.1% 13.7% 29.7% 31.8%

8000 5.4% 7.1% 19.8% 21.7%

10000 2.6% 3.6% 13.2% 14.8%

12000 1.2% 1.9% 8.8% 10.1%

Time (horas)

Whole System In-Vessel Components

with Passive View

without Passive View

with Passive View without Passive View

0 0.0% 0.0% 0.0% 0.0%

250 8.7% 8.0% 4.9% 4.7%

500 16.7% 15.3% 9.6% 9.1%

1000 30.6% 28.2% 18.3% 17.4%

1500 42.2% 39.2% 26.2% 24.9%

2000 51.9% 48.5% 33.3% 31.7%

4000 76.8% 73.4% 55.5% 53.4%

6000 88.9% 86.3% 70.3% 68.2%

8000 94.6% 92.9% 80.2% 78.3%

10000 97.4% 96.4% 86.8% 85.2%

12000 98.8% 98.1% 91.2% 89.9%

60

as small in absolute terms in both cases (all and only in-vessel components): the effect is smaller than

3 percentage points at t=4000h. However, in relative terms, the effect of the exclusion of the passive

view cannot be neglected. At t=4000h its elimination in the case of the whole system means an increase

of 6%. The analysis considering all components in series shows that the probability that the ITER CTS

system performs a complete run of 16 months without a failure is less than 2%. Excluding the ex-vessel

components in the IO scope and considering only the in-vessel ones the reliability for a complete run of

16 months increases to 8.8% and 10.1%, with and without the passive view components respectively.

Figure 5-2: Reliability and failure probability functions for the different assumptions (whole system and in-vessel

components, with and without passive view). It assumes all components in series.

5.2. Simulations’ Validation

This section provides an overview of the results of one simulation run. The simulation time span was

200 000 hours, however, for visualisation purposes, only a window on that time horizon is presented.

The outputs of the model for the whole system with the passive view are presented in Figure 5-3. Over

100 000 hours the graphs show the evolution of the ITER CTS system as regards its up and down

(available, not available) status for different criteria of the down status: launcher, passive view and data

acquisition system available and m-out-of-7 (m= 4 to 7) transmission lines available. As shown the

number of failures and the system downtime increases with the number of required transmission lines

(higher m values). Having more transmission lines operational requires more components to be

0%

20%

40%

60%

80%

100%

0 2000 4000 6000 8000 10000 12000

Rel

iab

ility

& F

ailu

re a

ccu

mu

late

d p

rob

abili

ty

Operating Time (hours)

Whole System with Passive View(Reliability)

Whole System without Passive View(Reliability)

In Vessel Components with Passive View(Reliability)

In Vessel Components without PassiveView (Reliability)

Whole System with Passive View (FailureFunction)

Whole System without Passive View(Failure Function)

In Vessel Components with Passive View(Failure Function)

In Vessel Components without PassiveView (Failure Function)

61

operational, as the number of components increases the chances of failure increases as well, thus

impacting the availability negatively.

Figure 5-3: Behaviour of ITER CTS system (whole system and passive view) with the number of transmission

lines required for the system to be in operational conditions (one simulation run).

Besides looking at the ITER CTS system behaviour, the analysis of its subsystems can also be

performed. Figure 5-4 shows the failures of the 7 transmission lines. One can notice that simultaneous

failures seem to happen. This is because sets of three transmission lines share the same Fused Silica

Window. The failure of one Fused Silica Window immediately triggers the down-status of three

transmission lines Figure 5-4: it’s possible to see Transmission Lines 1,2 and 3 have become not-

operational at the same time, while the others have not, later on Transmission Lines 4, 5 and 6 go offline

at the same time which doesn’t happen for the other transmission lines at that point in time.

Figure 5-5 shows the operation of the three Fused Silica Windows, this particular trial was chosen to

demonstrate that the failures between Fused Silica Windows are independent and can occur at any

point in time. Finally, Figure 5-4 and Figure 5-5 a part of the same trial and the failures of the Fused

Silica Windows match the concomitant failures described previously, thus proving that the concomitant

failures are a consequence of the failures of the Fused Silica Windows.

62

Figure 5-4: Behaviour of transmission lines (whole system and passive view) (one simulation run).

Figure 5-5: Behaviour of fused silica windows (whole system and passive view) (one simulation run).

Figure 5-6 presents the failures generated on the remaining subsystems, namely the launcher, passive

view, data acquisition system and receiver mirror M2. It should be noticed that the subsystems fail

independently and never at the same time. This sample of subsystems and components were chosen

to show that failures do not occur at the same time. Proving that the delays programmed so that every

component would halt their internal clocks and thus postpone their Time to Failure is working as

intended.

63

Figure 5-6: Behaviour of launcher, passive view, receiver mirror M2 and data acquisition system (whole system

and passive view) (one simulation run).

5.3. Synchronous Model

The following graphs present the results achieved for the availability considering that the ITER CTS is

available if at least 5-out-of-7 transmission lines are in operational conditions. Here the 50 independent

simulation runs were always considered each involving a temporal horizon of 200 000 hours. The

different cases are considered. It shows the availability of each trial, the average that for every trial

completed, the confidence intervals (95%) and the percentile (95%).

The results show significant differences in the availability of the different cases:

1. The average availability for the whole system with passive view (Figure 5-7) is 71.7%, and its

95% confidence interval is [69.9%; 73.6%]. Within the 50 runs, the availability ranges from

59.1% to 83.8% (90% of experiments with an availability within the interval [61.0%; 80.5%].

2. The average availability when only the in-vessel components with passive view are considered

(Figure 5-8) is 85.0%, and its 95% confidence interval is [83.5%; 86.5%]. Within the 50 runs,

the availability ranges from 73.1% to 93.5% (90% of experiments with an availability within the

interval [76.5%; 92.4%].

3. The average availability for the whole system without passive view (Figure 5-9) is 76.1%, and

its 95% confidence interval is [74.6%; 77.6%]. Within the 50 runs, the availability ranges from


4. The average availability when only the in-vessel components without passive view are

considered (Figure 5-10) is 90.4%, and its 95% confidence interval is [89.3%; 91.4%]. Within

the 50 runs, the availability ranges from 80.7% to 96.8% (90% of experiments with an availability

within the interval [81.9%; 95.7%].

64

Figure 5-7: Evolution of the synchronous simulation results and statistical analysis of availability for the whole

system with passive view. CI stands for a confidence interval of the mean.

Figure 5-8: Evolution of the synchronous simulation results and statistical analysis of availability for the in-vessel

components with passive view. CI stands for a confidence interval of the mean.

40%

50%

60%

70%

80%

90%

100%

1 3 5 7 9 1 1 1 3 1 5 1 7 1 9 2 1 2 3 2 5 2 7 2 9 3 1 3 3 3 5 3 7 3 9 4 1 4 3 4 5 4 7 4 9

Number of trials (i=1,...,50)

WHOLE SYSTEM WITH PASSIVE VIEW

Availability Average Percentile 5 Percentile 95 CI high 95 CI low 95

40%

50%

60%

70%

80%

90%

100%

1 3 5 7 9 1 1 1 3 1 5 1 7 1 9 2 1 2 3 2 5 2 7 2 9 3 1 3 3 3 5 3 7 3 9 4 1 4 3 4 5 4 7 4 9


IN VESSEL COMPONENTS WITH PASSIVE VIEW


65

Figure 5-9: Evolution of the synchronous simulation results and statistical analysis of availability for the whole

system without passive view. CI stands for a confidence interval of the mean.

Figure 5-10: Evolution of the synchronous simulation results and statistical analysis of availability for the in-vessel

components without passive view. CI stands for a confidence interval of the mean.

40%

50%

60%

70%

80%

90%

100%

1 3 5 7 9 1 1 1 3 1 5 1 7 1 9 2 1 2 3 2 5 2 7 2 9 3 1 3 3 3 5 3 7 3 9 4 1 4 3 4 5 4 7 4 9


WHOLE SYSTEM WITHOUT PASSIVE VIEW


40%

50%

60%

70%

80%

90%

100%

1 3 5 7 9 1 1 1 3 1 5 1 7 1 9 2 1 2 3 2 5 2 7 2 9 3 1 3 3 3 5 3 7 3 9 4 1 4 3 4 5 4 7 4 9


IN VESSEL COMPONENTS WITHOUT PASSIVE VIEW


66

The simulation model was also run for different m-out-of-7 conditions (Table 5-5 and

Figure 5-11). These simulations were performed from m=1 to 7 to understand the behaviour of the

system outside the margins decided by the design team.

The first noticeable characteristic is that regardless of the simulation, when all the transmission lines

have to be working (7-out-of-7 case) there is a significant decline on the availability of the system, which

is expected since it is the most demanding scenario every simulation. Another point, is that when the 4-

out-of-7 case is reached the availability for less than 4 transmission lines operational has an asymptotic

behaviour. One can draw the conclusion that it is unlikely that more than 4 transmission lines will fail at

the same time.

Table 5-5: Availability values gathered from the stochastic synchronous simulation.

m-out-of-n


with Passive

View

without

Passive View

with Passive

View

without

Passive View

7-out-of-7 47.3% 50.3% 70.0% 74.9%

6-out-of-7 69.8% 73.8% 84.5% 89.8%

5-out-of-7 71.7% 76.1% 85.0% 90.4%

4-out-of-7 74.8% 79.3% 85.0% 90.4%

3-out-of-7 75.2% 79.8% 85.0% 90.4%

2-out-of-7 75.2% 79.8% 85.0% 90.4%

1-out-of-7 75.3% 79.9% 85.0% 90.4%

40%

50%

60%

70%

80%

90%

100%

7 out of 7 6 out of 7 5 out of 7 4 out of 7 3 out of 7 2 out of 7 1 out of 7

Availa

bili

ty

Whole System with Passive View

In Vessel Components with Passive View

Whole System without Passive View

In Vessel Components without Passive View

67

Figure 5-11: Evolution of the ITER CTS system availability with m-out-of-7 receiver transmission lines,

synchronous simulation.

The simulations performed by the different system models (whole system and in-vessel components,

with and without passive view) allow a deeper comprehension of the impact and criticality of certain

subsystems. In the whole system including the passive view the availability, as expected is the lowest.

It can reach 75.3%, but it can decrease to 47.3% as the number of functioning transmission lines

increases to 7. Excluding the passive view from the simulation marginally improves the availability, as it

now reaches almost 80% with its minimum in 50% when all transmission lines are assumed to be needed

(Table 5-5).

By excluding the ex-vessel components, the availability gains are superior to those of the passive view.

The availability reaches almost 84%. However, for 7-out-of-7 transmission lines, it lowers to 69%. Finally,

if the in-vessel subsystems are simulated without the passive view, again the availability increased

marginally to almost 90%, albeit lowering to 74.5% when 7-out-of-7 transmission lines are required to

be functioning (Table 5-5).

To better understand the relative availability of the different subsystems of the ITER CTS, Figure 5-12

presents a higher-level representation RBD of the ITER CTS system with the availability results for the

launcher, receiver mirror M2, transmission lines, passive view and data analysis subsystems. These

subsystems’ availability was estimated by the simulation developed. One can understand that the

launcher (ex-vessel components in the IO scope) is the most critical subsystem to the availability of the

ITER CTS.

40%

50%

60%

70%

80%

90%

100%


Availa

bili

ty


In Vessel Components with Passive View


In Vessel Components without Passive View

68

Figure 5-12: High-level RBD and subsystems availability synchronous system.

5.4. Asynchronous Model

The following graphs present the results achieved for the availability of the asynchronous model

considering that the ITER CTS is available if at least 5-out-of-7 transmission lines are in operational

conditions. Here the 50 independent simulation runs were always considered each involving a temporal

horizon of 200 000 hours. The different cases are considered:


1. The average availability for the whole system with passive view (Figure 5-13) is 74.1%, and its

95% confidence interval is [71.8%; 75.6%]. Within the 50 runs, the availability ranges from


2. The average availability when only the in-vessel components with passive view are considered

(Figure 5-14) is 88.6%, and its 95% confidence interval is [87.3%; 90.0%]. Within the 50 runs,

the availability ranges from 77.3% to 98.9% (90% of experiments with an availability within the

interval [81.6%; 95.9%].

3. The average availability for the whole system without passive view (Figure 5-15) is 88.6%, and

its 95% confidence interval is [87.3%; 90.0%]. Within the 50 runs, the availability ranges from


4. The average availability when only the in-vessel components without passive view are

considered (Figure 5-16) is 90.3%, and its 95% confidence interval is [89.2%; 91.4%]. Within

the 50 runs, the availability ranges from 80.5% to 98.9% (90% of experiments with an availability

within the interval [84.2%; 96.7%].

69

Figure 5-13: Evolution of the asynchronous simulation results and statistical analysis of availability for the whole

system with passive view. CI stands for a confidence interval of the mean.

Figure 5-14: Evolution of the asynchronous simulation results and statistical analysis of availability for the in-

vessel components with passive view. CI stands for confidence interval of the mean.

55%

60%

65%

70%

75%

80%

85%

90%

95%

100%

1 3 5 7 9 1 1 1 3 1 5 1 7 1 9 2 1 2 3 2 5 2 7 2 9 3 1 3 3 3 5 3 7 3 9 4 1 4 3 4 5 4 7 4 9

AV

AIL

AB

ILIT

Y

Number of Trials (i=1,...,50)

WHOLE SYSTEM WITH PASSIVE VIEW


55%

60%

65%

70%

75%

80%

85%

90%

95%

100%

1 3 5 7 9 1 1 1 3 1 5 1 7 1 9 2 1 2 3 2 5 2 7 2 9 3 1 3 3 3 5 3 7 3 9 4 1 4 3 4 5 4 7 4 9


IN VESSEL COMPONENTS WITH PASSIVE VIEW


70

Figure 5-15: Evolution of the asynchronous simulation results and statistical analysis of availability for the whole

system without passive view. CI stands for a confidence interval of the mean.

Figure 5-16: Evolution of the asynchronous simulation results and statistical analysis of availability for the in-

vessel components without passive view. CI stands for a confidence interval of the mean.

55%

60%

65%

70%

75%

80%

85%

90%

95%

100%

1 3 5 7 9 1 1 1 3 1 5 1 7 1 9 2 1 2 3 2 5 2 7 2 9 3 1 3 3 3 5 3 7 3 9 4 1 4 3 4 5 4 7 4 9

AV

AIL

AB

ILIT

Y


WHOLE SYSTEM WITHOUT PASSIVE VIEW


55%

60%

65%

70%

75%

80%

85%

90%

95%

100%

1 3 5 7 9 1 1 1 3 1 5 1 7 1 9 2 1 2 3 2 5 2 7 2 9 3 1 3 3 3 5 3 7 3 9 4 1 4 3 4 5 4 7 4 9

AV

AIL

AB

ILIT

Y


IN VESSEL COMPONENTS WITHOUT PASSIVE VIEW


71

The previous results were achieved considering that at least 5 transmission lines must be operational

for the system to be available. The simulation model was also run for the same m-out-of-7 (Table 5-6

and Figure 5-17). One can note that there are shared behavioural characteristics such as the

degradation of the availability for 7-out-of-7 lines and the asymptotic behaviour of the availability when

the requirement is less than 4 transmission lines working. However, because simultaneous failures on

the transmission lines are only probable when a fused silica window breaks down, an increase in the

availability only occurs from the 7-out-of-7 to the 4-out-of-7 case.

Table 5-6: Availability values gathered from the stochastic asynchronous simulation.

m-out-of-n


With Passive

View

Without Passive

View

With Passive

View

Without Passive

View

7-out-of-7 58.0% 60.0% 75.1% 76.2%

6-out-of-7 73.3% 76.7% 88.3% 90.0%

5-out-of-7 74.1% 77.9% 88.6% 90.3%

4-out-of-7 76.9% 80.6% 88.6% 90.3%

3-out-of-7 77.0% 81.0% 88.6% 90.3%

2-out-of-7 77.0% 81.0% 88.6% 90.3%

1-out-of-7 77.1% 81.1% 88.6% 90.3%

Figure 5-17: Evolution of the ITER CTS system availability with m-out-of-7 receiver transmission lines for the

asynchronous system.

55%

60%

65%

70%

75%

80%

85%

90%

95%

100%


Availa

bili

ty


In Vessel Subsystems with Passive View


In Vessel Subsystems without Passive View

72

The simulations performed by the different system models (whole system and in-vessel components,

with and without passive view) allow a deeper comprehension of the impact and criticality of certain

subsystems. In the whole system including the passive view the availability, as expected is the lowest.

It can reach 77.1%, but it can decrease to 58.0% as the number of functioning transmission lines

increases to 7. Excluding the passive view from the simulation marginally improves the availability, as it

now reaches 81.1% with its minimum in 60.0% when all transmission lines are assumed to be needed.

By excluding the ex-vessel components, the availability gains are superior to those of the passive view.

The availability reaches 88.6%. However, for 7-out-of-7 transmission lines, it lowers to 75.1%. Finally, if

the in-vessel subsystems are simulated without the passive view, again the availability increased

marginally to 90.3%, albeit lowering to 76.2% when 7-out-of-7 transmission lines are required to be

functioning.

To better understand the relative availability of the different subsystems of the ITER CTS, Figure 5-18

presents a higher-level representation RBD of the ITER CTS system with the availability results for the

launcher, receiver mirror M2, transmission lines, passive view and data acquisition subsystems. These

subsystems’ availability was estimated by the simulation developed. One can understand that the

launcher (ex-vessel components in the IO scope) is the most critical subsystem to the availability of the

ITER CTS.

Figure 5-18: High-level RBD and subsystems availability for the asynchronous system, the whole system with

passive view was used to get this data.

Figure 5-19 and Figure 5-20 show the results of the synchronous and asynchronous simulations the

former includes the Passive View and the latter excludes it. The most obvious trend is that for the

availability of the asynchronous simulations is overall higher than the synchronous simulations, as it was

expected. This difference is accentuated by the number of components present in each case. When

more components are considered in the system analysis there are more failure-maintenance events that

73

further postpone the cascade of events. More components imply a widening of the gap between the

synchronous and asynchronous simulations, when considering the same models.

Figure 5-19: Results for the synchronous and asynchronous simulations - Whole System with Passive View and In-Vessel Components with Passive View

Figure 5-20: Results for the synchronous and asynchronous simulations - Whole System without Passive View

and In-Vessel Components without Passive View

40%

50%

60%

70%

80%

90%

100%


Whole System with Passive View (synchronous)

Whole System with Passive View (asynchronous)

In-Vessel Components with Passive View (synchronous)

In-Vessel Components with Passive View (asynchronous)

40%

50%

60%

70%

80%

90%

100%


Whole System without Passive View (synchronous)

Whole System without Passive View (asynchronous)

In-Vessel Components without Passive View (synchronous)

In-Vessel Components without Passive View (asynchronous)

74

Figure 5-21 Relative difference between the availabilities obtained from synchronous and asynchronous

simulations.

In Figure 5-21 it is possible to see, percentage-wise, the relative differences between synchronous and

asynchronous simulations. There a few general trends present in every model; the difference is superior

when 7-out-of-7 transmission lines and it decreases with the number of transmission lines that must be

operational. For the cases where less than 5-out-of-7 transmission lines are operational the behaviour

becomes asymptotic for every model.


1. For the whole system with passive view and considering 7-out-of-7 transmission lines the

availability difference is of 22%, declining and converging to 2%.

2. For the in-vessel components with passive view and considering 7-out-of-7 transmission lines

the availability difference is of 7%, declining and converging to 4%.

3. For the whole system without passive view and considering 7-out-of-7 transmission lines the

availability difference is of 18%, declining and converging to 1%.

4. For the in-vessel components without passive view are and considering 7-out-of-7 transmission

lines the availability difference is of 2%, declining and converging to 0%.

0%

5%

10%

15%

20%

25%



In-Vessel Components with Passive View


In-Vessel Components without Passive View

75

6. Conclusions and Studies

After a careful analysis of the previous iteration of the ITER Collective Thomson Scattering (ITER CTS)

and contacts with the design team from the Technical University of Denmark (DTU) it was possible to

construct Reliability Block Diagrams that modelled the analyses meant to be made.

The stipulated operational conditions created the need to analyse four different cases: the whole system

with and without the passive view, and only the in-vessel components also with and without the passive

view ones.

With the four models defined, the next step was to make an analytical evaluation of them. It was a quick

way to understand the behaviour of the system, its subsystems and estimate some of the impact of the

transmission lines.

Then a synchronous Discrete Event Simulation (DES) was developed, allowing a deep understanding

of the ITER CTS. The intricacies of the system that weighted on the analytical approach were overcome

by the DES. This simulation model used random variables to describe the times to failure of each critical

component. However, given that the order magnitude of the MTTR is not sufficiently small when

compared to that of the MTBF, the results obtained were too conservative, the best solution was to

develop an asynchronous DES.

This last simulation allowed for a realistic representation of the ITER CTS, taking into consideration real-

life cycles of failure-maintenance-delay. It was achieved by giving each component its own clock and

measuring its operational working time. To generate significant results each simulation was run for a

time span of 200 000 hours (about 20 years) and was replicated 50 times (50 independent runs). When

the simulation model was run for different m-out-of-7 conditions, it was verified a significant degradation

on the availability of the system when all the transmission lines have to be working for the system to be

considered available. In the complete simulation including the passive view the availability, as expected

is the lowest. Excluding the passive view from the simulation marginally improves the availability. By

excluding the ex-vessel components, the availability gains are superior to those of the passive view.

Finally, if the in-vessel subsystems are simulated without the passive view, again the availability

increased marginally. These subsystems’ availability was estimated by the simulation developed. One

can understand that the launcher (ex-vessel components in the IO scope) is the most critical subsystem

to the availability of the ITER CTS, see Figure 5-18.

The present RAMI analysis has provided a fundamental understanding of the ITER CTS system

availability, however, based on the knowledge gathered some issues were identified warranting further

investigation, namely:

• Find and use updated and reliable data values for the reliability and maintainability

parameters taking into account the detailed specifications of each critical component.

• Develop a new simulation considering the stochastic behaviour of the time to repair.

76

• Develop a new simulation model considering the fact that in-vessel maintenance of

components that are not critical for ITER operation will have a frequency of about 2 years,

i.e. if they fail, it could be 2 years until they are repaired.

• Develop a simulation model for the reliability of the system.

77

References

[1] J. Girard, P. Garin, N. Taylor, J. Uzan-elbez, L. Rodriguez-Rodrigo, and W. Gulden, “ITER, safety

and licensing,” Reliab. Eng. Syst. Saf., vol. 82, no. 2, pp. 619–622, 2011.

[2] D. Van Houtte, K. Okayama, and F. Sagot, “RAMI approach for ITER,” Fusion Eng. Des., vol. 85,

no. 7–9, pp. 1220–1224, 2010.

[3] R. Tiusanen, J. Jännes, and M. Reunanen, “RAMSI management – from single analyses to

systematic approach.”

[4] V. Infante and E. Henriques, “Framework Partnership Agreement for Diagnostics Developement

and Design : LFS Collective Thomson Scattering ( CTS ) Specific Grant 03 - System Level

Design RAMI analysis of the best placed option and mitigation plan for unacceptable risks ( D08

),” Lisbon, 2016.

[5] E. Human, “What is Reliability Engineering,” Asset Manag. Reliab. Eng., no. June, pp. 3–5, 2012.

[6] A. Goyal, W. C. Carter, E. de Souza e Silva, and S. S. Lavenberg, “The System Availability

Estimator.” IEEE, Durham, NC 27706, pp. 84–89, 1986.

[7] R. Billinton and R. Goel, “An Analytical Approach to Evaluate Probability Distributions Associated

with the Reliability Indices of Electric Distribution Systems,” Power Eng. Rev. IEEE, vol. PER-6,

no. 7, p. 59, 1986.

[8] M. Azarkhail, “The Evolution and History of Reliability Engineering,” Int. J. Performability Eng.,

vol. 8, no. 1, pp. 1–13, 2011.

[9] F. Di Maio et al., “The CODAC Software Distribution for the ITER Plant Systems,” Proc.

ICALEPCS 2011, pp. 227–230, 2011.

[10] J. B. Lister, J. W. Farthing, M. Greenwald, and I. Yonekawa, “The status of the ITER CODAC

conceptual design,” Fusion Eng. Des., vol. 83, no. 2–3, pp. 164–169, 2008.

[11] S. I. Kitazawa, K. Okayama, Y. Neyatani, F. Sagot, and D. Van Houtte, “RAMI analysis of the

ITER CIS,” Fusion Eng. Des., vol. 4, pp. 2–6, 2014.

[12] S. Qin et al., “RAMI analysis for ITER radial X-ray camera system,” Fusion Eng. Des., vol. 112,

pp. 169–176, 2016.

[13] D. Van Houtte, K. Okayama, and F. Sagot, “ITER operational availability and fluence objectives,”

Fusion Eng. Des., vol. 86, no. 6–8, pp. 680–683, 2011.

[14] B. S. Dhillon, Maintainability, Maintenance, and Reliability for Engineers. Boca Raton, Florida:

CRC Press, 2006.

[15] J. C. Whitaker, Design for Reliability. Morgan Hil, California: CRC Press, 2001.

78

[16] D. J. Smith, Reliability, Maintainability and Risk. Practical Methods for Engineers, vol. 72, no. 6.

2011.

[17] M. A. Durivage, Practical Engineering, Process, and Reliability Statistics. Milwaukee, Wisconsin:

ASQ Quality Press, 2015.

[18] R. Frederick Stapelberg, Handbook of Reliability, Availability, Maintainability and Safety in

Engineering Deign. Springer US, 2009.

[19] W. W. W. Wang, J. Loman, and P. Vassiliou, “Reliability importance of components in a complex

system,” Annu. Symp. Reliab. Maintainab., pp. 6–11, 2004.

[20] W. C. K. C. Kurien, “Reliability and Availability Analysis of Repairable Systems using Discrete

Event Simulation,” Indian Institute of Technology, Delhi, 1988.

[21] R. Jiang, Introduction to Quality and Reliability Engineering. Beijing: Springer US, 2015.

[22] Y. X. Zhao, “On preventive maintenance policy of a critical reliability level for system subject to

degradation,” Reliab. Eng. Syst. Saf., vol. 79, no. 3, pp. 301–308, 2003.

[23] H. Pham, Handbook of reliability engineering, no. January. 2003.

[24] M. Marseguerra, E. Zio, and L. Podofillini, “Optimal reliability/availability of uncertain systems via

multi-objective genetic algorithms,” IEEE Trans. Reliab., vol. 53, no. 3, pp. 424–434, 2004.

[25] E. Bauer, X. Zhang, and D. A. Kimber, Practical System Reliability. 2009.

[26] D. Ryu, Improving reliability and quality for product success. 2012.

[27] P. Weber and L. Jouffe, “Complex system reliability modelling with Dynamic Object Oriented

Bayesian Networks (DOOBN),” Reliab. Eng. Syst. Saf., vol. 91, no. 2, pp. 149–162, 2006.

[28] T. Nakagawa and S. Osaki, “Discrete Weibull Distribution.,” IEEE Trans. Reliab., vol. R-24, no.

5, pp. 300–301, 1975.

[29] W. Qingfeng, L. Wenbin, Z. Xin, Y. Jianfeng, and Y. Qingbin, “Development and application of

equipment maintenance and safety integrity management system,” J. Loss Prev. Process Ind.,

vol. 24, no. 4, pp. 321–332, 2011.

[30] M. A. Lundteigen, M. Rausand, and I. B. Utne, “Integrating RAMS engineering and management

with the safety life cycle of IEC 61508,” Reliab. Eng. Syst. Saf., vol. 94, no. 12, pp. 1894–1903,

2009.

[31] M. R. Spiegel, Probability and Statistics. 2009.

[32] A. Tesini and J. Palmer, “The ITER remote maintenance system,” Fusion Eng. Des., vol. 83, no.

7–9, pp. 810–816, 2008.

[33] H. Guerrero, Excel Data Analysis: Modeling and Simulation. 2010.

79

[34] A. Faisandier, “Systems Architecture and Design,” Eng. Archit. Multidiscip. Syst., vol. 3, pp. 379–

420, 2012.

[35] J. Reich et al., “ITER In-Cryostat inspection and repair feasibility studies,” Fusion Eng. Des., vol.

86, no. 9–11, pp. 1809–1811, 2011.

[36] S. H. Yun et al., “Risk-based multi-criteria design concept of the ITER SDS getter bed,” Fusion

Eng. Des., vol. 89, no. 7–8, pp. 1495–1499, 2014.

[37] A. Dammann et al., “Conceptual design of the hot cell facility universal docking station at ITER,”

Fusion Eng. Des., vol. 86, no. 9–11, pp. 1890–1893, 2011.

[38] I. Namgung, H. G. Kang, M. H. Chang, C. H. Kim, S. H. Yun, and K. J. Jung, “Reliability Analysis

Modeling of ITER Tritium Storage and Delivery System at Conceptual Design Stage,” pp. 17–18,

2012.

[39] S. Beloglazov, A. Perevezentsev, L. Lepetit, P. Camp, and M. Benchikhoune, “Preliminary Design

of the ITER Tokamak Complex and Hot Cell Facility Detritiation Systems S. Beloglazov*, A.

Perevezentsev, L. Lepetit, P. Camp, M. Benchikhoune,” ITER Organ., p. 90.

[40] A. Tarallo, R. Mozzillo, G. Di Gironimo, A. Aiello, M. Utili, and I. Ricapito, “Preliminary piping

layout and integration of European test blanket modules subsystems in ITER CVCS area,”

Fusion Eng. Des., vol. 93, pp. 24–29, 2015.

[41] T. Maruyama, Y. Noguchi, N. Takeda, and S. Kakudate, “Availability analysis of the iter blanket

remote handling system,” Plasma Fusion Res., vol. 10, no. SpecialIssue.2, pp. 1–4, 2015.

[42] S. I. Kitazawa, K. Okayama, Y. Neyatani, F. Sagot, and D. Van Houtte, “RAMI analysis of the

ITER Central Safety System,” Fusion Eng. Des., vol. 89, no. 6, pp. 800–805, 2014.

[43] K. Okayama, D. Van Houtte, F. Sagot, and S. Maruyama, “RAMI analysis for ITER fuel cycle

system,” Fusion Eng. Des., vol. 86, no. 6–8, pp. 598–601, 2011.

[44] D. Wang, J. Wang, R. Yuan, M. Nie, and F. Wang, “RAMI Analysis of HCCB TBS for ITER,” J.

Fusion Energy, vol. 34, no. 5, pp. 1094–1099, 2015.

[45] L. Leemis, “Input modeling techniques for discrete-event simulations,” Proceeding 2001 Winter

Simul. Conf., pp. 62–73, 2001.

[46] D. K. Chaturvedi, Modeling and Simulation of System Using Matlab and Simulink. 2010.

[47] R. A. Weller et al., “Monte Carlo simulation of single event effects,” IEEE Trans. Nucl. Sci., vol.

57, no. 4 PART 1, pp. 1726–1746, 2010.

[48] W. F. Ramirez, Computational Methods for Process Simulation, vol. XXXIII, no. 2. Boulder,

Colorado: Butterworth Heinemann, 2014.

[49] L. Warrington, J. A. Jones, and N. Davis, Modelling of maintenance, within discrete event

80

simulation. 2002.

[50] P. Brandimarte, Handbook in Monte Carlo Simulation: applications in financial engineering, risk

management, and economics, vol. 53, no. 9. 2013.

[51] P. Heidelberger, “Fast simulation of rare events in queueing and reliability models,” Tmcs, vol. 5,

no. 1, pp. 43–85, 1995.

[52] M. Bazargan and R. N. McGrath, “Discrete Event Simulation to Improve Aircraft Availability and

Maintainability,” 2003 Annu. Reliab. Maintainab. Symp. 27-30 Jan. 2003, pp. 63–67, 2003.

[53] J. Hodicky, Modelling and Simulation for Autonomous Systems, vol. 9991. 2016.

[54] I. A. Tall, J. Venkateswaran, and Y.-J. Son *, “Hybrid system dynamic—discrete event simulation-

based architecture for hierarchical production planning,” Int. J. Prod. Res., vol. 43, no. 6, pp.

4397–4429, 2005.

[55] B. Kyu Choi and D. Kang, Modeling and Simulation of Discrete-Event Systems. Hoboken, New

Jersey: John Wiley & Sons, Inc, 2013.

[56] V. Infante and E. Henriques, “SG04 Deliverable D14 Updated RAMI analysis,” Lisbon, 2017.

[57] A. Birolini, Reliability Engineering, Seventh Ed. Springer, 2010.

APPENDIX A

aerospace engineering - ulisboa€¦ · iii acknowledgements firstly, i would like to thank my...

Documents