Department of Science and Technology
Institutionen för teknik och naturvetenskap
Linköping University
Linköpings universitet
g
n
i
p
ö
k
r
r
o
N
4
7
1
0
6
n
e
d
e
w
S
,
g
n
i
p
ö
k
r
r
o
N
4
7
1
0
6
-E
S
Konstandseffektiv optimering
av systemsäkerhet och
tillförlitlighet
Joakim Bergström
Hampus Nilsson-Sundén
2015-06-02
Konstandseffektiv optimering
av systemsäkerhet och
tillförlitlighet
Examensarbete utfört i Elektroteknik
vid Tekniska högskolan vid
Linköpings universitet
Joakim Bergström
Hampus Nilsson-Sundén
Handledare Kjell Karlsson
Examinator Anna Lombardi
Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare –
under en längre tid från publiceringsdatum under förutsättning att inga
extra-ordinära omständigheter uppstår.
Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner,
skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för
ickekommersiell forskning och för undervisning. Överföring av upphovsrätten
vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av
dokumentet kräver upphovsmannens medgivande. För att garantera äktheten,
säkerheten och tillgängligheten finns det lösningar av teknisk och administrativ
art.
Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i
den omfattning som god sed kräver vid användning av dokumentet på ovan
beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan
form eller i sådant sammanhang som är kränkande för upphovsmannens litterära
eller konstnärliga anseende eller egenart.
För ytterligare information om Linköping University Electronic Press se
förlagets hemsida
http://www.ep.liu.se/
Copyright
The publishers will keep this document online on the Internet - or its possible
replacement - for a considerable time from the date of publication barring
exceptional circumstances.
The online availability of the document implies a permanent permission for
anyone to read, to download, to print out single copies for your own use and to
use it unchanged for any non-commercial research and educational purpose.
Subsequent transfers of copyright cannot revoke this permission. All other uses
of the document are conditional on the consent of the copyright owner. The
publisher has taken technical and administrative measures to assure authenticity,
security and accessibility.
According to intellectual property law the author has the right to be
mentioned when his/her work is accessed as described above and to be protected
against infringement.
For additional information about the Linköping University Electronic Press
and its procedures for publication and for assurance of document integrity,
please refer to its WWW home page:
http://www.ep.liu.se/
This master thesis was performed at Saab Aeronautics in Linköping, Sweden, as part of a project in the Swedish National Aeronautics Research Programme
(Na-tionella Flygtekniska Forskningsprogrammet - NFFP), initialized to find a method
able to optimize the choice of devices in aircraft subsystems with respect to safety, reliability, cost and weight in early design phases.
A method able to analyze and optimize subsystems could be useful to reduce project cost, increase subsystem reliability, improve overall aircraft safety and reduce subsystem weight. The earlier the optimization of development of an aircraft in the design phase can be performed, the better the yield of the opti-mization becomes. However, optiopti-mization of this magnitude is a time-consuming process. Thus, a method utilizing a script that could decrease the amount of work-hours in the analysis stage of a project was sought-after. Being true for aircraft industries, this is also true for most processes of various industries - the earlier the construction line is optimized, the better the yield. Hence, in addition to aircraft subsystems, the method should be compatible with systems of various industries with minor modifications of the script.
A research study to obtain previously mentioned optimization method was ini-tiated by Saab Aeronautics and conducted by a PhD student. This PhD student designed a script with predetermined parameters and hard-coded values of men-tioned parameters; able to optimize one given subsystem. But the PhD student wanted a time-saving and more trustworthy method capable of optimizing sub-systems with varying numbers of dynamic parameters - therefore, this master thesis was formed in order to improve and automate the optimization method designed by the PhD student.
Based on a literature study, the research began by evaluating the optimization method constructed by the PhD student. A simple script containing the very basics to allow automatic information transfer between software tools was cre-ated. The script was then integrated with a Genetic Algorithm in order to be able to optimize subsystems by changing the combination of system parameters in a gradual, system-performance increasing manner. A new optimization method utilizing the script designed in this thesis work was constructed and, in order to test if this method can be used to optimize various systems, an attempt to opti-mize the design of a small system on component level was conducted.
Inspired by the optimization method constructed by the PhD student, a semi-automatic analysis script capable of optimizing aircraft subsystems with respect to safety, reliability, cost and weight in an early design stage was designed. The script was implemented in an optimization method handling varying numbers of dynamic parameters. The method constructed in this thesis work calculates data faster and in a more trustworthy way than the method constructed by the PhD student. Additionally, the implemented script is designed to be easily expanded and altered to allow functionality in various industries. Thus, the optimization method constructed in this thesis work meets the demands of the PhD student.
The authors would like to thank the employees at Saab Aeronautics department OTTDIF and especially the people involved in the NFFP6 project - Cristina Jo-hansson, PhD student, for letting us be a part of her research study; Per Persson, for excellent guidance as supervisor at Saab - and Karl-Gustav Fransson, for a more educational oriented input. We would also like to thank our examiner Anna Lombardi and supervisor Kjell Karlsson at Linköping University, ITN, for their time, input and help throughout the master thesis process.
Norrköping, May 2015 Joakim Bergström Hampus Nilsson-Sundén
List of Figures ix List of Tables xi List of Software xiii Abbreviations xv 1 Introduction 1 1.1 Background . . . 1 1.2 Purpose . . . 1 1.3 Delimitation . . . 2 1.4 Secrecy . . . 2 1.5 Approach . . . 2 1.6 Outline . . . 4
1.7 Saab AB, Aeronautics . . . 4
1.8 Problem Description . . . 5
1.8.1 Combinations . . . 5
1.8.2 Comparison Factors to Optimize . . . 5
1.8.3 Analysis Methods . . . 5
1.8.4 Software . . . 5
1.8.5 Failure Models and Equations . . . 5
1.8.6 Optimization using Genetic Algorithm . . . 6
1.8.7 Workflow . . . 6
2 Theory 7 2.1 Combinations . . . 7
2.2 Comparison Factors to Optimize . . . 8
2.2.1 Safety . . . 8 2.2.2 Reliability . . . 8 2.2.3 Cost . . . 9 2.2.4 Weight . . . 9 2.3 Analysis Methods . . . 10 v
2.3.1 Fault Tree Analysis . . . 10
2.3.2 Reliability Block Diagram . . . 16
2.3.3 Life-Cycle Cost . . . 18 2.4 Software . . . 19 2.4.1 Reliability Workbench . . . 19 2.4.2 Matlab . . . 19 2.4.3 Microsoft Excel . . . 19 2.4.4 CATLOC . . . 20
2.5 Failure Models and Equations . . . 21
2.5.1 Truth Tables . . . 22
2.6 Optimization using Genetic Algorithm . . . 24
2.7 Workflow . . . 27
3 Method Constructed by the PhD 29 3.1 Method . . . 29 3.2 Script . . . 30 4 Implementations 31 4.1 Model 1 . . . 32 4.2 Model 2 . . . 33 4.3 Description of Script . . . 37 5 Evaluation of System 45 5.1 Test of Method on Component Level . . . 45
5.2 Problem Description . . . 45
5.3 FTA and RBD on Component Level . . . 49
5.4 Results . . . 52
6 Conclusion and Discussion 55 Bibliography 59 A LED Datasheet 63 B WP Schematic 65 B.0.1 Circuit parameters . . . 67 C Risk Analysis 69 C.0.1 Resistors . . . 69 C.0.2 Capacitors . . . 70 C.0.3 Transistors . . . 70
C.0.4 Diode and LED . . . 70
C.0.5 Cold filament . . . 71
D Graphs 73
F GUI Windows 85 G Compare Time and Output 89 H Compare Executions 97 I Flowcharts of Models 101
1.1 Product development process . . . 3
1.2 Workflow . . . 6
2.1 Fault Tree, OR-gate . . . 11
2.2 Fault Tree, AND-gate . . . 12
2.3 Fault Tree, gate symbols . . . 13
2.4 Fault Tree, event symbols . . . 14
2.5 Fault-Tree example . . . 15
2.6 Reliability Block Diagram, failure-oriented . . . 16
2.7 Parallel connection of blocks . . . 17
2.8 Series connection of blocks . . . 17
2.9 Life-Cycle Cost . . . 18
2.10 Overview Genetic Algorithms . . . 25
2.11 Crossover . . . 26
2.12 Workflow . . . 27
4.1 Example of comparison factor influence-selection . . . 33
4.2 Device data input comparison . . . 35
4.3 Example of device data input . . . 35
4.4 Flowchart of the designed script. . . 37
4.5 Example input of GUI functions of read_excel . . . 38
4.6 Function calls of calculate_normalization . . . 39
4.7 Comparison between function calls of safety and cost functions . . 40
4.8 Matrix transformation . . . 42
4.9 Output example, worksheet names . . . 43
4.10 Output example, parameters worksheet . . . 43
4.11 Output example, design vector worksheet . . . 43
4.12 Output example, cost values worksheet . . . 44
5.1 Original WP-Schematic . . . 46
5.2 WP-schematic . . . 48
5.3 Simplified schematic . . . 49
5.4 Fault Tree of the simplified schematic . . . 50
5.5 RBD series . . . 51
5.6 RBD parallel . . . 51
5.8 Failure Models . . . 52
5.9 Unavailability . . . 52
5.10 FTA Design vector . . . 53
A.1 Datasheet LED . . . 64
B.1 Evaluation schematic WP . . . 66
D.1 Currentleakage without R4 . . . 73
D.2 No currentleakage with R4 . . . 74
D.3 No currentleakage without filter R4 . . . 75
D.4 Current over LED if two of R1, R2 and R3 is shorted . . . 76
D.5 Current in point A and over LED if two of R1, R2 and R3 is shorted 77 D.6 Current and voltage over LED if R1, R2 and R3 is shorted . . . 78
D.7 Current In point A red and over LED green R1, R2 and R3 shorted 79 D.8 Schematic over suggested circuit . . . 80
D.9 Graph over suggested circuit . . . 81
E.1 Time-comparison between rng(’shuffle’) and Random.org . . . 84
F.1 GUI_comparison_factors_selection . . . 86
F.2 GUI_ga_settings . . . 87
F.3 Vendor question . . . 87
F.4 GUI_number_of_vendors . . . 87
G.1 Matlab output of script designed by the PhD student . . . 90
G.2 Graph output of script designed by the PhD student . . . 91
G.3 Matlab output of script designed in this work . . . 92
G.4 Design vector and list of device names . . . 92
G.5 Design vector graph . . . 93
G.6 Time taken for the script designed by the PhD student . . . 94
G.7 Time taken for the script designed in this work . . . 95
H.1 First-time execution number 1 . . . 98
H.2 First-time execution number 2 . . . 99
I.1 Workflow of PhD student script . . . 101
I.2 Workflow of Model 1 . . . 102
I.3 Workflow of Model 2 . . . 103
List of Tables
2.1 An example of device purchase . . . 7
2.2 Truth table of OR-gate . . . 22
2.3 Truth table of XOR-gate . . . 22
2.4 Truth table of AND-gate . . . 22
• Reliability Workbench incorporating Fault Tree+, versions 11.0.32 and 12.1 • Microsoft Office Excel, version 14.0.07140.5002 (32-bit)
• MATLAB R2013b (8.2.0.701, 64-bit), August 13, 2013 • CATLOC, version 7.0b (64-bit)
• LT Spice, version 4.22x
Abbreviation Full Meaning
COM Component Object Model FT Fault Tree
FTA Fault Tree Analysis GA Genetic Algorithm GUI Graphical User Interface LED Light Emitting Diod LCC Life-Cycle Cost
RBD Reliability Block Diagram RNG Random Number Generator RWB Reliability Workbench
WP Warning Panel
1
Introduction
This chapter aims to describe the thesis. The base of the thesis is divided into subsections and this is described in section 1.8.
1.1
Background
Previously, safety and reliability has not been prioritized as highly as cost within Saab Aeronautics. Cristina Johansson, a PhD student, brought this to attention in her research study that was initialized in order to find an optimization method of aircraft subsystems focusing on safety, reliability, cost and weight together. This method would be capable of selecting devices to form optimal subsystems for air-craft in an early design phase focusing on the parameters mentioned. This master thesis was formed to improve and automate the optimization method constructed by the PhD student.
1.2
Purpose
The work of the thesis aims to semi-automate an optimization method of aircraft subsystems based on system devices with respect to the factors: safety, reliabil-ity, cost and weight. These factors are here referred to as comparison factors since they are mutually compared. Another aim of the work is that the method is compatible with different systems of various number of parameters and various industries. The method should also allow additional comparison-factors in addi-tion to those previously menaddi-tioned to be taken into consideraaddi-tion in the method if needed.
1.3
Delimitation
The work is limited to the software originally used by the PhD student and does not evaluate options to replace these software since the software with associated licenses was already accepted and well-established at Saab. Furthermore, the work with the optimization study was already in progress once the master the-sis was formed. Thus, the PhD student had already designed a non-automatic subsystem-optimization script that served as inspiration for the semi-automated optimization script designed in the thesis work.
In the work, two analysis methods are used to calculate safety and reliability
-Fault Tree Analysis (FTA) and Reliability Block Diagram (RBD) respectively. No
alternative analyzes are evaluated in this thesis since the work with the opti-mization study was already in progress once the master thesis was formed and the PhD student had already decided the initial analyzes suited in early design phases. Additionally, an algorithm called Genetic Algorithm (GA), used to com-pare possible combinations in order to find the optimal one, was requested by the PhD student to be implemented in the work.
The script has been limited to work on Windows systems only.
1.4
Secrecy
Any classified material made available to the PhD student has been declassified by her and authorized personnel prior to its publishing. Since the published material is the base of the thesis, the thesis is also approved to be published. Additionally, limitations were set by internal standards regarding master thesis students in what material was made available. Any new inventions resulting in patent belongs to Saab.
1.5
Approach
Firstly, a literature study was conducted - accompanied by testing and evaluation of the optimization method constructed bu the PhD student. Next, the design and evaluation of a script containing the very basics of automatic information transfer between various software. This script was integrated with the optimiza-tion algorithm, a GA, in order to be able to optimize subsystems by changing the combination of system parameters in a gradual, system-performance increas-ing matter. The scrpit was so far managincreas-ing only one of the comparison factors - safety - and chosen to be called Model 1. The script was expanded to include the comparison factors: reliability, cost and weight. A new optimization method utilizing this script was constructed. This new optimization method relied on handling varying numbers of dynamic parameters, while having the names of all parameters being exported from analysis software and imported into calcu-lation software. Additionally, the method was having the various values of the parameters being imported into the calculation software all at once.
For the script to fit the approach of the method, the script was tested, evaluated and revised until functioning according to the master thesis instructions - the script was now given the name Model 2. Model 2 was later used in the develop-ment of an electrical system on component level to test if this method can be used to optimize various systems of various industries.
The two analysis methods FTA and RBD are suitable for system evaluation in early design phases, and both part of the system safety method in the product de-velopment process [18]. See Figure 1.1. Combining these analysis methods with the GA allowed an optimization method capable of evaluating device combina-tions in early design phases to form.
1.6
Outline
This thesis is written with the typesetting language LATEX [27, 6]. The style sheet
rtthesis, written by Hedenby and Tidefelt [11], has been used and modified.
A word that is to be abbreviated is written in its full content the first time it is written, and followed by the abbreviation in parenthesis “()”. If the word recurs, only the abbreviation is used. Abbreviations are not used at the beginning of sentences for better readability. See the list of abbreviations, on the page prior to the start of Chapter 1.
The thesis is divided into chapters consisting of sections where relevant back-ground theory is briefly presented followed by a more thorough description of the subject if needed. Chapter 1 describes this thesis and its purpose. General information regarding the work - such as delimitation, secrecy, approach and structure of the thesis - is followed by a brief introduction of the company where the work presented in this thesis was performed. Chapter 2 treats the underly-ing theory in relation to the work performed. Chapter 3 discusses the method constructed by the PhD student and the script designed by the PhD student. Chapter 4 explains the script that was designed, its implementation and how it is integrated within the semi-automated method that was constructed. Chap-ter 5 evaluates a system on component level and a test conducted to show that the method works for various systems of various industries. Chapter 6 is dedicated to the conclusion and discussion.
1.7
Saab AB, Aeronautics
“Saab serves the global market with world-leading products, services and solu-tions from military defence to civil security. With operasolu-tions on every continent, Saab continuously develops, adapts and improves new technology to meet cus-tomers’ changing needs. Its most important markets today are Europe, South Africa, Australia and North America. Saab has around 14,700 employees. An-nual sales amount to around SEK 24 billion, of which research and development account for about 25 per cent of sales.” [30]
“Saab has divided operations into six business areas: Aeronautics, Dynamics, Elec-tronic Defence Systems, Security and Defence Solutions, Support and Services, and Industrial Products and Services.” [30]
"Aeronautics engages in advanced development of military and civil aviation tech-nology. it also conducts long-term future studies of manned and unmanned air-craft as preparation for new systems and further development of existing prod-ucts." [31]
1.8
Problem Description
The problem to solve is to find the optimal combination of devices with respect to cost, reliability, safety and weight, and what vendor to buy these devices from. This means solving and dealing with a number of problems described in the fol-lowing subsections with associated solutions described in chapter 2.
1.8.1
Combinations
The number of possible combinations increases rapidly with the increase of pos-sible vendors and devices. And if finding the optimal combination of devices means to try every possible combination, that would be a time consuming task. Therefore this task should be evaluated and automated to save time.
1.8.2
Comparison Factors to Optimize
Depending on the context, the word optimize can have various meanings. The meaning of optimization in this work is to obtain a system as reliable and safe as possible, while keeping weight and cost of this system at a minimum. This means to optimize the combinations of devices within the system. Knowledge of these so called comparison factors is needed; as well as how they relate to the objective.
1.8.3
Analysis Methods
To analyze safety and reliability, FTA and RBD - two reliability methods - were chosen as analyzing tools since they are best suited in early design phases from the aspects objectives and system characteristics. These methods were chosen after the evaluation of several methods performed by the PhD student [18]. These methods are so called top-down methods; where the analysis starts at the top with an unwanted event to be evaluated, and end in the cause of the event at the bottom.
1.8.4
Software
In order to automate the optimization process various software tools are needed. These tools are used for e.g. building analysis diagrams, calculation, acting as a link between other software via import and export of data, visualizing results, etc.
1.8.5
Failure Models and Equations
Equations are needed to mathematically describe the Failure Models - mathemati-cal representations of component unavailability - to be analyzed.
1.8.6
Optimization using Genetic Algorithm
An algorithm, which is the base of the analysis, is a self-contained step-by-step set of operations to be performed [36]. In this project a well-known algorithm called Genetic Algorithm is used to optimize device-combinations and select which ven-dors to purchase these devices from.
1.8.7
Workflow
The workflow described in Section 1.8.1 to 1.8.6 can be visualized as in Figure 1.2 below.
Figure 1.2:Workflow
The goal is a script that handles combinations, takes the comparison factors into account, analyzes the comparison factors accordingly by using software of vary-ing kinds and dependvary-ing on the type of Failure Model, optimizes the answer using a GA, and finally, presents the answer numerically and graphically.
2
Theory
Based on the problematics explained in section 1.8, this chapter discusses the underlying theory in relation to the work performed. The descriptions are gener-alized and narrowed down in order to fit the approach of the thesis.
2.1
Combinations
If two different devices can be purchased from three different vendors it results in 32 = 9 different combinations of possible purchases, given by Equation 2.1 below:
possible purchase combinations = (number of vendors)number of devices (2.1) Table 2.1 display an example where two devices are obtainable at three vendors. For this example, the selection of purchasing Device 1 from Vendor 1 and Device 2 from Vendor 3 is displayed. These purchases would be represented in vector format as [1 3] in the script. In the work performed, such a result vector is called a Design Vector and is further discussed in Chapter 4.
Vendor 1 Vendor 2 Vendor 3 Device 1 *
Device 2 *
Table 2.1: An example of device purchase. * marks a device-vendor combi-nation indicating a purchase.
Equation 2.1 is true while all vendors sell all devices. A non-allowed device-vendor combination is produced if a device is not obtainable at a certain device-vendor - removing a combination from the result of the equation. Aircraft systems usu-ally consist of many devices that can be purchased from several vendors, making the possible purchase combinations increase exponentially. Normally a company tries to have as few vendors as possible to ensure quality and price. However, widely spread components that require widely spread knowledge is hard to find within one company. Meaning, all devices may not be obtainable at all vendors and several non-allowed combinations may occur - something the script will need to handle. This is discussed in section 4.2.
2.2
Comparison Factors to Optimize
Optimization is performed regarding specific variables called comparison factors - in the case of this work these factors are safety, reliability, cost, and weight.
2.2.1
Safety
"Safety, in a general sense the result of actions or characteristics that reduce the likeli-hood of accidents or other adverse events to occur." [25]
Saab wanted more focus on: pilot safety, maintenance personnel safety, civilian safety and construction personnel safety and safety generally. In order to achieve this, the risks have to be identified. Managing risks is a prime responsibility of managing a project or managing a company. This could be done by a Risk Analysis process. Risk Analysis, in simple terms, implies analyzing the potential for loss. It’s the systematic use of available information to identify hazards and to estimate the risk to individuals or populations, to property, or to the environment.
Once the risks have been identified a FTA can be performed, which is a graph-ical representation used to analyze safety - discussed in section 2.3.1. The FTA method was developed initially for the nuclear industry, and it underpins the Probabilistic Risk Assessment method required to be applied in the U.S. nuclear industry after the Three Mile Island accident in 1979 [19].
Using FTA, the safety value implies the risk of failures to occur. In the case of optimizing, the safety value of a system is preferred low.
2.2.2
Reliability
"Reliability, quality dimension of a system that reflects its ability to function in a satisfactory manner with a minimum of interference, faults and repairs." [24]
There are three main branches of reliability: hardware, software and human [20]. It is hard to rule out human errors, and since human errors in terms affect hardware and software, accurate measures have to be taken.
In order to evaluate reliability a RBD can be used, which is a graphical represen-tation of reliability - discussed in section 2.3.2.
The difference between safety and reliability lies within the definition when a system is being designed. The constructor of the RBD selects the reliability defi-nition.
Using RBD, the reliability value implies the chance of the system working satis-factory. In the case of optimizing, the reliability value of a system is preferred high.
2.2.3
Cost
In terms of optimization, perhaps the most self-explanatory parameter. However, it can be hard to tell if low purchase price implies better long-term price - and all subsystems need to be summed to get a total cost of the system. Furthermore, some subsystems can be more expensive aside from purchase price. For instance, maintenance, operating cost and cost for personnel such as engineers, specialist, and hourly wage to install a system. This implies that in order to evaluate the cost of a subsystem, lifetime cost of each device of the system will have to be evaluated.
The authors suggests that a so called Life-Cycle Cost (LCC) analysis - discussed in section 2.3.3 - performed using CATLOC should be implemented with the script by Saab in the future. This would allow the script to obtain data describing the system in economical terms - similar to how RWB is currently used to obtain safety and reliability data. Saab is already using CATLOC in other projects, hence the recommendation of this specific software. However, allowing the script to obtain LCC data is still for the future, and for now the user will have to provide the script with desired cost data.
High cost implies an expensive system. In the case of optimizing, the cost value of a system is preferred low.
2.2.4
Weight
Flight characteristics are affected negatively by overweight. However, increasing the weight in retrospect, if needed, is never a problem. Weight is more com-plex than it might seem at first - devices weigh; cables weigh; shielding material weighs; every single nut and bolt weighs. When adding a new device to a system from a selection of devices - or when replacing an existing device - it will affect the weight of the system. Not only because the devices themselves weigh differ-ently. In order to interact with surrounding devices, they might require different types of cables; or, in order to attach those devices to the flight body, one of the de-vices might require more brackets than the other. Total weight added to a system by purchasing a device could be calculated by summing the weight of the device, its brackets and attachment on flight body, various connection and cables needed for the device, etc. However, in this work per request from the PhD student, only the weight of the device itself is considered due to practical reasons.
In this work, total weight of the system evaluated is considered optimal when low. In the case of optimizing, the weight value of a system is preferred low.
2.3
Analysis Methods
Two analysis methods - one for safety, one for reliability - are used to evaluate risks. They are described in the following sections. Additionally, a LCC analysis is discussed. A LCC is used in order to calculate long-term device cost.
2.3.1
Fault Tree Analysis
Fault Tree is a logical event-chart that illustrates the connection between un-wanted events of a system and the cause of these events. The causes can be human or technical errors. Fault Tree Analysis is a top-down technique where a possible event is analyzed from system level to component level. The event-chart often gives an increased understanding of how and why a system is built in a certain way in terms of safety. Fault Tree also gives opportunity to detect critical errors and weak spots, even when component data is missing [3].
The design of a FT begins by specifying the non-wanted top-event - usually a crit-ical or catastrophic failure - and the events that directly causes the top-event fail-ure. The top-event and events are then connected using suitable logic gates. This is repeated down to the base-event and component level or subsystem level [3]. The mathematical representation of the FT (or RBD, section 2.3.2) is called Cut Sets (Gate Cut Set for FT and Block Cut Set for RBD) - which resembles the de-rived Boolean expression. Similarly, Minimal Cut Set which are used in the script, resembles the derived simplest form of a Boolean expression. The result of the FTA shows the probability that the non-wanted top-event occurs, therefore this quantity is desired low (close to the minimum value, 0).
Another important aspect is that the events described in the FT used for this work are time independent, meaning that the top-event occurs only depending on what events that have previously occurred but not the order they occurred in. Such FT consists only of AND-gates and OR-gates and are considered non-repairable. This should not be confused with independent events - events that does not share the same input-event [3].
As the script designed in this work relies on Cut Sets rather than gate types, it can handle systems containing other gates than AND-gates and OR-gates. When an-alyzing a FT using RWB, the Cut Sets are automatically derived - independently of what gates the FT is consisting of. Thus, the designed script in combination with RWB allow safety analyses to be performed on time dependent FT as well. Fault Tree Analysis is widely used at NASA. The two FT shown in Figure 2.1 and Figure 2.2 - representing the probability of inadvertent jet firing investigated at NASA - explain the use and difference of OR-gates and AND-gates [17]. OR-gates should be read as the possibility that one of the events occur, requiring at least one of them to occur in order for the top-event to occur. AND-gates should be read as the possibility that all events occur, requiring all of them to occur in order for the top-event to occur.
Figure 2.1:Fault Tree, OR-gate. P = probability, A = first event (Navigation software error), B = second event (G&C software error). [34]
Figure 2.2:Fault Tree, AND-gate. P(A) = probability of inadvertent jet firing (top-event), P(B) = probability of navigation software error, P(C) = probabil-ity of crew error, P(D) probabilprobabil-ity if G&C software error. [34]
Reliability Workbench use internationally recognized gate and event symbols shown in Figure 2.3 and Figure 2.4 respectively, and provides the option of us-ing additional symbols that conform to the British 5760 (Part 7) and IEC 61025 standards. These gate and event symbols are used to link the events of a FT.
Event symbols are used to graphically represent the underlying purpose of pri-mary events. The BASIC symbol shown in Figure 2.4 is used as the standard event.
An example of event symbols and gates combined to form a FT is shown in Fig-ure 2.5, where the unwanted event "Total loss of cooling" is analyzed.
2.3.2
Reliability Block Diagram
Reliability Block Diagram models how devices and subsystem failures combine to cause system failure, and can be used to analyze and predict the availability of a system and determine the critical devices from a reliability viewpoint. The RBD module automatically evaluate the system Minimal Cut Sets and use these Cut Sets to determine system performance parameters [15].
The result of a RBD analysis shows the probability that the top-event occurs. If the top-event represents a desired outcome - success-oriented - the RBD is used to calculate availability of the system and the quantity is wanted high (close to the maximum value, 1). If the top-event represents a non-wanted outcome - failure-oriented - the RBD is used to calculate unavailability of the system and the quan-tity is wanted low (close to the minimum value, 0).
Figure 2.6 displays a RBD example of the braking system of a car, and the topevent that loss of braking commands has occurred; a nonwanted outcome -is seen in the bottom right of the figure. Note that the Cut Sets of th-is RBD -is denoted Block Cut Sets to inform that the diagram is failure-oriented. Meaning, when analyzed using RWB, unavailability will be calculated.
Figure 2.6: Reliability Block Diagram, failure-oriented. Failures of each block can add up to form the top-event ’Loss of braking commands’. This diagram serves as an example - the inexperienced reader is suggested against trying to understand the details.
The blocks of a RBD can be connected either in parallel or in series. Blocks con-nected in parallel allows several paths between the two points of each side of the parallel connection, while blocks connected in series only allows one path between the two points of each side of the series connection.
Figure 2.7 and Figure 2.8 show and explain the difference between parallel con-nection and series concon-nection of blocks in a RBD.
Figure 2.7:Parallel connection of blocks. In order for point 1 and point 2 to connect, at least one of the failures of block A, B or C must be fulfilled.
Figure 2.8: Series connection of blocks. In order for point 1 and point 2 to connect, the failures of block A, B and C must all be fulfilled.
The functionality of parallel connection of blocks could be compared to that of an OR-gate for events, as the one shown in Figure 2.1. The functionality of series connection of blocks could be compared to that of an AND-gate for events, as the on shown in Figure 2.2.
2.3.3
Life-Cycle Cost
While this thesis work was being performed, comprehensive work was being done at Saab collecting data of device-cost and cost-impacts of environmental choices, recyclable components and more using a software called CATLOC (dis-cussed in Section 2.4.4). This was done in order to have a LCC that displays the individual LCC of each device per flight hour. A suggestion by the authors was to import this data to the designed script.
However, at the final date of this thesis work, CATLOC could not export data on Saab computers due to non-compliant software - CATLOC being in 64-bit version while Excel (Office package) being in 32-bit version.
The LCC is divided into three main groups: Life Acqustion Cost, Life Support Cost & Life Operation Cost and Life Termination Cost, as shown in Figure 2.9.
2.4
Software
Various software programs are used in the optimization process, and the follow-ing section describe them. Minimal Cut Sets are exported from RWB via Excel, and imported into Matlab.
2.4.1
Reliability Workbench
Isograph “is now one of the world’s leading companies in the development and provision of integrated Reliability, Availability, Maintainability and Safety soft-ware products”. [13]
“Reliability Workbench (RWB) is Isograph’s flagship suite of reliability, safety and maintainability software. The software has been in continuous development since the 1980s. It is easy to use and is a great tool for all reliability and mainte-nance professionals.” [14]
Reliability Workbench was used to create and export FT and RBD files, including information such as: event names, block names, Failure Models and Cut Sets. This information was imported to Matlab and used during the analyzing phase.
2.4.2
Matlab
When designing an automated evaluation script, a lot of calculation is to be ex-pected. Seeing how the calculations will most likely be a major part of the evalua-tion itself, the software tool to handle said calculaevalua-tions should be fast and power-ful. In addition to being a powerful tool in handling heavy calculations - used by millions of engineers and scientists worldwide [23] - Matlab by Mathworks was already installed on Saabs’ servers and used by the PhD student. Thus, Matlab was chosen to perform the majority of the work of this project.
2.4.3
Microsoft Excel
Since it was found to be one of the export options of RWB that provided a clean, easy-to-use output that works well with Matlab, the spreadsheet program Excel was used to form a link between software; allowing exported data from RWB to be imported into Matlab. Saab already had Excel licenses and the software itself installed on their servers, additionally adding odds to Excels’ favor.
2.4.4
CATLOC
CATLOC is a software with analysis capability that gives knowledge and control over costs. It is a tool that is well suited for LCC analysis. Common dimensions of interest include:
• Materials (systems, equipment, items, spare parts...) • Stations (stores, workshops, sites of operations...) • Tasks (maintenance tasks, PM / CM ...)
• Resources (personnel, maintenance equipment...) • Time
Any combination of cost-dimensions can be studied and analyzed using CATLOC. It can also be used for modeling revenues, enabling cost/profit analysis. [32] A suggestion from the authors of this thesis is that Saab should implement CAT-LOC with the designed script in the future in order to allow for a more thorough cost analysis.
2.5
Failure Models and Equations
Failure Models are mathematical equations or representations of component-una-vailability (explained below), usually based on exponential distribution. Failure Model equations representing worst case scenario - maximum risk of unavailable component - is often used in this project in order to ensure safety and reliability. Variables to be used in the Failure Models are presented below.
t - Flight Time. The time during which errors could occur. In this work t is usually set to 8 hours, implying that safety and reliability is ensured during 8 hours of flight.
Lambda,λ - Failure Rate. The probability of failure per unit time given that the
component is as good as new at time zero and has survived time t.
Mu, µ - Repair Rate. In this work, set to zero since all errors are seen as
non-repairable during flight.
Tau,τ - Inspection Interval. The interval at which inspections are performed.
Q - unavailability. The probability that an event, a block, a component or a sys-tem is unavailable (broken).
Cut Sets - Mathematical representations of groups of events or blocks which will cause system failure when occurring together.
Using these variables, the following Failure Models can be obtained with respec-tive equation.
Dormant Failure - A failure which will remain unrevealed until an inspection takes place. Using the Maximum Risk Dormant Model, this can be expressed as Equation 2.2. [1]
Q = 1 − e−λτ (2.2)
Rate Model - Represents non-repairable components if Repair Rate is set to zero, and can be expressed as Equation 2.3. [1]
Q(t) = λ λ + µ(1 − e
−(λ+µ)τ) → 1 − e−λτ (2.3)
Fixed Model - Represents event unavailability values and failure frequencies that do not vary with time. Can be expressed as Equation 2.4. [1]
Q = q (2.4)
Quantitative calculation method Q usually means unavailability, which is the probability that the component or a system is "broken" or unavailable at any given time.
2.5.1
Truth Tables
A truth table is a mathematical table used in logic — specifically in connection with Boolean Algebra. Truth tables of gates used in this work can be seen below where A, B, C and D denotes inputs. These can be expanded to desired num-ber of inputs in the conventional way. The underlying mathematics are based on Boolean Algebra and varies depending on what gate that is used - the inexperi-enced reader is suggested to see [37] for further explanations.
OR-gate The output of an OR-gate can be expressed mathematically as the sum of the inputs. If the result is greater than or equal to 1 (if the inputs are active), the output is 1. See Table 2.2. In the case of FT, this implies that if at least one input occur, it will cause the gate failure to occur.
A B A OR B 0 0 0 1 0 1 0 1 1 1 1 1
Table 2.2:Truth table of OR-gate.
Exclusive OR-gate The Exclusive gate (XOR) is just a special case of an OR-gate where the output OR-gate failure does not occur if all inputs occur. See Table 2.3.
A B A XOR B 0 0 0 1 0 1 0 1 1 1 1 0
Table 2.3:Truth table of XOR-gate.
AND-gate The output of an AND-gate can be expressed mathematically as the product of the inputs. If at least one input is zero, the output is zero. See Table 2.4. In the case of FT, this implies that if one of the inputs does not occur, the output gate failure will not occur.
A B A AND B 0 0 0 1 0 0 0 1 0 1 1 1
Majority Vote The vote number indicates how many of the inputs of a gate that need to occur to cause the gate failure to occur. [1] Table 2.5 shows an example where at least three out of four inputs would have to occur in order to cause a gate failure. That is, the vote number of the example is three.
A B C D Vote 3 0 0 0 0 0 0 0 0 1 0 0 0 1 0 0 0 0 1 1 0 0 1 0 0 0 0 1 0 1 0 0 1 1 0 0 0 1 1 1 1 1 0 0 0 0 1 0 0 1 0 1 0 1 0 0 1 0 1 1 1 1 1 0 0 0 1 1 0 1 1 1 1 1 0 1 1 1 1 1 1
2.6
Optimization using Genetic Algorithm
The term Genetic Algorithm is used to describe a search heuristic where devices of a system over time gradually change to form a superior system compared to the previous one. This algorithm is often used to find local optimums.
Genetic Algorithm is a concept that builds on evolution and natural selection according to Darwinism [7], meaning that the functions are inspired of functions found in nature. Solutions gets better and better based on previous generations, until a wanted result is fulfilled [16].
The Genetic part of GA is, as mentioned, inspired by evolution. Evolution among a population or a species occurs according to a specific order of variations and if those variations exist [10]. Species evolve in 4 steps, performed over and over:
• Reproduction • Genetic variation
• Competition and selection • Adaptation
The Algorithm part of GA is a plan or method that stepwise describes the imple-mentation of an operation or assignment. An algorithm can thus be seen as a solution-method to a specific problem. [4]
Genetic Algorithms use parameters that correspond to individuals with varying properties called genotype (genotype-population). When a genotype decodes to a programmable format, a phenotype is created (phenotype-population). The decoding consists of the individuals being tested in an evaluation function (ob-jective function) and given a fitness value. This value forms the base on which selection is performed, which in turn is the base on which reproduction is per-formed. [10] Furthermore, the GA can be described in six steps as in Figure 2.10 on the next page. [7]
Figure 2.10:Overview Genetic Algorithms.
1. Create initial population of individuals (genotypes) 2. Evaluate every individual and assign it a fitness value
3. Create new individuals, by preparing the chosen individuals and apply mu-tations and crossover
4. Remove the old generation (generation N) to give room to the new one (gen-eration N+1)
5. Evaluate the new individuals and assign a fitness value to them
6. If a stop script is fulfilled, stop and present the best solution, otherwise repeat from step 3
To evolve and produce new generations, genetic operators are used. The most common ones are: selection, crossover and mutation [33], which are used in this work.
Selection means selecting a vector of combination that gives the best fitness value. Crossover is based on two individuals exchanging chromosomes and producing a new individual [2]. In a two-point crossover, pairs of individuals are assigned two random crossover points X2 (X2 to denote two-point crossover). The
infor-mation of the two individuals between these two points changes place as shown in Figure 2.11 [10]. This builds a new generation and is called reproduction.
Figure 2.11:Crossover.
The example above shows the individuals named 2 and 8, “the parents” to the the left, in which the numbers between points limited by X2 is to be changed. The
result shown to the right is two new individuals where the integers between the points limited by X2of individual 2 and 8 has changed place. [10]
Mutation randomly changes a part of an individual with certain probability, cri-teria and restriction. In this case depending on the number of devices. If more devices is added, the probability of mutations must be decreased. That is because every part of the individual has a probability of mutation, and if a device is added it will cause the total probability of mutation to increase [2].
2.7
Workflow
The workflow described in Sections 2.1 to 2.6 can be visualized as in Figure 2.12 below.
Figure 2.12:Workflow.
The goal is a script that handles combinations which increase rapidly according to Equation 2.1 and take into account the comparison factors - safety, reliability, cost and weight - analyzes these accordingly using RWB and depending on type of failure (such as Fixed, Rate or Dormant) and finally optimize the answer using a GA.
3
Method Constructed by the PhD
This chapter briefly discusses the optimization method constructed by the PhD student and the script designed by the PhD student. The chapter aims to aid the reader in understanding the differences between the method constructed by the PhD student and that constructed by the authors as well as the differences between the respectively designed scripts.
Within this chapter, the optimization method constructed by the PhD student will be referred to as ’the method’ - discussed in Section 3.1, and the script de-signed by the PhD student will be referred to as ’the script’ - discussed in Sec-tion 3.2.
3.1
Method
The method heavily relies on the user being able to express the system mathemati-cally, using Cut Sets and Failure Models representations. The PhD student found these representations of a selected FT by hand-calculations, without any assis-tance from the script. Using these representations, the PhD designed a script to work for one system with a set number of parameters, hard-coded to be executed for three runs with predetermined values of each compare factors’ influence on the end result. See Appendix I for a flowchart over the workflow of the method. The result of the method is presented in the Matlab command window as a vector filled with integers representing device-vendor combinations, and in one plot for each of run of the script displaying each objective value for said run. These values serve to graphically show the user the difference between each generation of the GA - but each time a generation is produced the method plots all generations produced so far, making this step very time consuming. See Appendix G.
3.2
Script
The PhD did not design one script to perform the analysis - she designed several, hard-coded scripts to evaluate various compare factors at the time. This makes it hard for the user to know what file to use, and forces the user to change start file in Matlab each time a new analysis is to be performed. The workflow is similar in all scripts, and hence they will be discussed as if they were one.
The script utilizes a GA which is hard-coded to analyze a system with a set num-ber of parameters and that relies on all vendors selling all devices (can not handle non-allowed device-vendor combinations). Along with this hard-coded GA, the PhD student created various functions to evaluate the comparison factors. Each function being hard-coded for the chosen system and with predetermined values of each parameter (device-vendor combination), to be called from different ver-sions of the script in order to calculate safety, reliability, cost and weight using different equations. Having found the mathematical equations by hand, the PhD student used several different equations in various files and compared the result of each file in order to find a suitable one for her selected analysis.
The script is hard-coded to execute three runs and to use specific evaluations of the system each run, and it contain no randomizing element. Thus, between each time Matlab is re-started, the script produce the same start-generation and hence end result for the first three runs. Likewise, the 4th, 5th and 6th runs always produce the same start-generation and end result, as do the 7th, 8thand 9th, etc. See Appendix H.
Not being optimized, the three predetermined, hard-coded runs take a long time to finish in comparison to the script designed in the work. [Appendix G]
4
Implementations
The designed semi-automated analysis script is based on the optimization method constructed by the PhD student in the research study. It was developed in two phases - named Model 1 respectively Model 2.
Model 1 was the first phase of the development of the script- for the authors, this was a learning phase used to find the basis to build the script on. Based on close communication with the PhD student, the base of the script was formed and delimitations of this first phase were set. Following up, Model 2 was to continue the development of the script - to revise what had been made so far and to complete the script as described in section 4.2. Both models use similar workflow - discussed in section 4.3 - and allow the user to import several sets of parameters at once; informed by the analysis script when to enter all parameter values.
However, prior to starting up the analysis script in Matlab, the system to be ana-lyzed will need to be designed using RWB - if the user wishes to perform a FTA, a FT of said system is required; and if the user wishes to perform a RBD analysis, a RBD of said system is required. Templates to export FT respectively RBD files from RWB were set up as a part of the master thesis, and by using these the user creates data files to be imported to Matlab via the script.
Once the data is exported from RWB and imported to Matlab, the user will be requested to input failure rates, cost and weight in matrix form - as this data represent the data of various devices for the system being analyzed which can not be exported for all devices at once from RWB. The results of the script is pre-sented as a vector filled with integers - named design vector - where each position represents one device in the system and each integer represents a vendor selling the associated device. See Appendix G. It is emphasized that the same integer
occurring in various positions in the design vector implies the same vendor. An in-depth description of the script discussing both the functionality of the script and the user-required input will be presented in section 4.3, but first a description of each phase - explicating their differences - will be given.
4.1
Model 1
The optimization analysis designed by the PhD student used safety, reliability, cost and weight as comparison factors. All four with their respective parameters being hard-coded into the analysis - thus, making the analysis viable for only one system with only one set of parameters at a time. The goal of Model 1 was to allow the user to take basically any system - in FT form - and input several sets of parameters at once, and have the script handle the replacing of param-eters between each run of the analysis. In order to be able to quickly evaluate functionality of the script, only safety was used as comparison factor for Model 1. Additionally, in order to establish easy and fast information transaction between Matlab and RWB, a .xls-file (file format of Excel 97-2003) was used to create a file with relevant data for the analysis.
Using the previously mentioned FT template, RWB is configured to export the name of events, the name of Failure Models and the system equations called Gate
Cut Sets - data which the designed script use to re-build the system
mathemat-ically in order to analyze it. Combining the data from the .xls-file with the equations implemented by the authors that form the Failure Models as well as user-provided input of possible failure values, the script have obtained all infor-mation needed in order to evaluate the impact on the system of each available device. Using a GA, the script tries to find an optimum scenario of the system being evaluated by randomly selecting start values of the system parameters and then allowing these parameters to change in a gradual performance-increasing matter; where the parameters are representing the devices available.
The results are presented in vector-form, displaying integers representing ven-dors selling the devices of the system currently being analyzed. The final results display the vendors providing the best device-combination found based on sys-tem safety - this result vector is the design vector previously explained in sec-tion 4. Similar to Figure G.4 of Appendix G, but with no colors.
Mainly depending on number of generations, generation gap and number of
individ-uals per sub-population used in the GA - and in some cases the randomized values
of the first generation - the final results can vary between runs. Reason being that a GA requires a varying amount of generations based on the initial conditions in order to find an optimal solution.
The following list describe the workflow of Model 1 [Appendix I]: 1. The user creates the FT to be analyzed, using RWB
2. The user exports the FT to be analyzed, using the RWB template 3. The user initializes the analysis using Matlab and imports the .xls-file 4. In the .xls-file, the user enter all possible failure rate values of the events 5. From the .xls-file, Matlab find events, Failure Models and their mutual
rela-tions
6. Matlab performs the analysis and display the results in the Matlab com-mand window presented as a design vector, i.e., only showcasing what ven-dor to buy the devices from - in vector form
The user of the script based on Model 1 was not able to alter any settings while running the script - meaning, the user had no control of e.g. improving the result by increasing the number of generations in the GA. Just as the script designed by the PhD student, Model 1 requires all vendors to sell all devices. Additionally, Model 1 was unable to handle optimization based on any parameter other than safety values, and the results was presented in the Matlab command window.
4.2
Model 2
Once the functionality of the safety-factor comparison - Model 1 - reached a satis-fying level of completeness and functionality, the script was further developed in order to include the reliability-, cost- and weight-factor comparisons. Addition-ally, it was now chosen to be named Model 2.
Having Model 2 being capable of calculating the individual results of safety, re-liability, cost and weight and compare these to one another, the user is required to decide the relationship and proportions of the comparison factors. In other words, the user is capable to set the individual influence on the system being an-alyzed for each comparison factor. See Figure 4.1, which shows an example of influence-selection during the usage of Model 2.
Figure 4.1:Example of comparison factor influence-selection, with cost hav-ing 50 % influence on the end result while safety (FTA), reliability (RBD) and weight together make up the remaining 50 %.
Prior to importing system-describing data, the user is now presented with the option to select GA settings and include total number of vendors of the devices. Being able to change the settings of the GA, the user is able to e.g. shorten the time-consumption of the analysis stage of the script or improve the analysis result by e.g. setting a higher number of generations. By including the number of vendors, the files used to import safety-, reliability-, cost- and weight-data will be presented in a more user-friendly and pedagogical way.
Having the basis already formed from Model 1, cost and weight was chosen to be entered in the same way as the failure rates - via input directly into a .xlsx-file (file format of Excel versions newer than 2003); similar to that as in step 4 for Model 1. However, the values for the reliability analysis requires a new set of data acquired from the RBD project of RWB. Using the previously mentioned RBD template, RWB is configured to export the name of blocks, the name of Failure Models and the system equations called Minimal Cut Sets - data which the automated script use to re-build the system mathematically in order to analyze it.
The results are presented in a similar way as to those of Model 1 - as a design vector. The difference being that for Model 2 the result take into account the ratio between safety, reliability, cost and weight; and, the result will be exported to a .xlsx-file instead of being printed in the Matlab command window. Further more, in addition to one worksheet dedicated to the design vector, the .xlsx-file contain one worksheet for each of the individual analyses displaying the result of said analysis in numbers and in graphical format as well as one worksheet displaying the system parameters and selected influence of each comparison factor for each run. Similar to Model 1, depending on number of generations, generation gap and number of individuals per sub-population used in the GA, the final results of Model 2 can vary between runs. However, the most significant factor of the final result is the decided relationship and proportions of the comparison factors. The following list describes the workflow of Model 2 [Appendix I]:
1. The user creates the FT and/or RBD to be analyzed, using RWB 2. The user exports FT/RBD data to be analyzed in .xlsx-format 3. The user initializes the analysis using Matlab
4. The user select analyses to perform along with budgets and influences on end-result
5. The user imports the .xlsx-file(s) needed
6. In the .xlsx-file(s) the user enter failure rate, cost and weight values of the events and blocks
7. From the .xlsx-file(s), Matlab find events, blocks, Failure Models and their mutual relations
8. Matlab performs the analysis and extract results to a .xlsx-file - showcas-ing data, for each run, regardshowcas-ing comparison factor values, influences and budgets in text and graphs; design vector displaying found optimal device-combination and what vendors to buy all devices from; a table displaying what device each position in the design vector represent
The eagle-eyed reader might have noticed that Model 1 handles .xls-files while Model 2 handles .xlsx-files. The reasoning behind this is that Model 1 was de-veloped for RWB version 11 which has .xls as the default Excel extension, while Model 2 was developed for RWB version 12 which has .xlsx as the default Excel extension. In fact, however, Model 2 can handle both .xls- and .xlsx-files - thus, Model 2 is compatible with multiple RWB versions.
The advantage of importing .xlsx-files, instead of .xls-files, is that it allows the script to add colors and borders, in addition to informationtext, in the .xlsxfile -thus, making the input of data more user-friendly and pedagogical as mentioned previously. See Figure 4.2, displaying a comparison between data input in .xls-file of Model 1 and .xlsx-.xls-file of Model 2. Furthermore, if the user have selected to import a .xls-file during step 5 in the list above, the script will create a .xlsx-file copy between steps 5 and 6 in order to make use of the advantage.
Figure 4.2:Device data input comparison between .xls-file of Model 1 (left) and .xlsx-file of Model 2 (right), where the number of vendors is known in the Model 2 data input file.
Additionally, contrary to Model 1, Model 2 can handle situations when all ven-dors do not sell all the desired devices. If a device is nonexistent at a vendor the user is asked to type “-1” on the specific location denoting said vendor and de-vice. This is then handled by the script as a forbidden combination and will not be further evaluated. See Figure 4.3, displaying device data input with vendors row-wise and devices column-wise.
Figure 4.3: Example of device data input. Devices are indicated row-wise starting at row 2, vendor data is indicated column-wise starting at column D (lambda values), G (cost values) and J (weight values) respectively. Note that device two (EV2) is nonexistent at the second vendor, that device three (EV3) is nonexistent at the third vendor, and that device four (EV4) is nonexistent at the first vendor.
Model 2 also include various error checks - something that Model 1 completely lack. Error checks included in Model 2 are described in the list below:
• The script is heavily reliant on Excel. Thus, in order to run the script, Excel is required to be installed on the computer attempting to run the script. When the script is started, in order to avoid errors, a check to make sure Excel is installed is performed.
• If invalid input is performed by the user (e.g., letter instead of integer), the script will either a) display an error message informing the user on how to perform current input, or b) automatically switch to an allowed input (e.g., any letter input would generate ‘0’).
• Files used to import FT or RBD data to Matlab undergoes several checks: a) During file-handling, if a file can not be read the script will - up to two times for each file-selection - inform the user of the error and provide one possible solution. If the user can not select an accepted file on the second try the script will inform the user of this and then terminate.
b) If a file contain incorrect data (e.g., a FT file was selected when a RBD file was requested), the user will be informed of the error and a possible solution will be suggested.
c) If a file have been used previously to import data to Matlab but the script terminated the file incorrectly or lost contact with the file, there might be information-text remaining in the file. Prior to reading data from the file, the script checks if any old information-text is present in the file - if so, the information-text is removed from the file.
d) If a file have been used previously to import data to Matlab but the script terminated the file incorrectly or lost contact with the file, there might be colors and borders used to inform the user of what data to input and at what location remaining in the file. Prior to reading data from the file, the script checks if any old colors or borders are present in the file - if so, they are removed from the file.
e) Prior to closing a file, in order to prevent old information-text to remain in the file, the script removes the information-text from the file.
f) While performing data input, if the file do not contain matched data matrices the user will be informed and requested to try again. If the user fail to enter accepted data matrices on the second try the script will inform the user of this and then terminate.
• Would the user chose to end data input prior to providing accepted data input, the script will inform the user the analysis have been terminated and terminate.
• When looking to save the results file, if there is already an existing file with the wanted name the script will add extra information to the end of the wanted name until a string that does not match any existing file is created (this is discussed further in section 4.3).
• If the user chooses to import a .xls-file as data input file, the script will create a file copy in order to retain features accessible only for .xlsx-files.
4.3
Description of Script
This section describes the functionality and workflow of the script designed in this work. The description is based on Model 2 as it represents the final re-sults. Note that in order to achieve some level of randomization of population for the initialization steps of the analysis, the Matlab command rng(’shuffle’) [22] is called during the start-up of the designed script. This approach - rather than using a scientific Random Number Generator (RNG) such as that provided by e.g. Random.org [28] - was chosen mainly to allow the script to work without an Internet connection. Furthermore, this approach proves to be faster than using a scientific RNG when clocked with the time-measure function tic-toc in Matlab [Appendix E].
Using start_analysis, the script is started. Containing no calculations, start_analysis consists of start-up conditions and function calls that form the analysis. The script is relying on two software programs to be installed on the current com-puter - Matlab and Excel - thus, starting of by performing a simple prerequisite-check to see if Excel is installed on the current computer, the script can make sure it will be able to run properly. If the prerequisite-check pass, the start-up settings are performed. Initiation of global constants, calling of rng(’shuffle’) and selection of file to use for comparison between factors (this file will be used in the GA discussed later in this section).
Calling read_excel, the script requests and acquire data needed to mathematically re-build the system(s) to be analyzed as well as the data needed in order to cal-culate, analyze and evaluate the comparison factors. See step A of Figure 4.4, where each uppercase letter represent a function call and each sentence represent a function, while arrows indicate direction of data transfer.
