# Selection of Production Reliability Indicators for Project Simulation Model
## 4 Results
### Implementation of the Selected Indicators to a Process Simulation Model  
As it can be inferred from the result of the QFD method, there are two outstanding indicators, which are advised to be built in the process simulation. These indicators can be treated at the same time in the process simulation model.  
The MTBF indicator can be interpreted in two different ways:  
1. Based on experimental data or professional estimation, an exact value can be assigned to trigger the failure in the activity. This is done by accumulating total process times and examining the value by mod operator.  
\begin{table}
\begin{tabular}{c c c c c c c c c} \hline \hline
**Citeria** & **CR1** & **CR2** & **CR3** & **CR4** & **CR5** & **CR6** & **CR7** & **Importance** \\ \hline CR1 & 0.241 & 0.199 & 0.200 & 0.462 & 0.272 & 0.227 & 0.176 & 0.254 \\ CR2 & 0.241 & 0.199 & 0.200 & 0.103 & 0.136 & 0.227 & 0.176 & 0.183 \\ CR3 & 0.048 & 0.040 & 0.040 & 0.051 & 0.019 & 0.045 & 0.059 & 0.043 \\ CR4 & 0.027 & 0.099 & 0.040 & 0.051 & 0.136 & 0.045 & 0.118 & 0.074 \\ CR5 & 0.121 & 0.199 & 0.280 & 0.051 & 0.136 & 0.114 & 0.294 & 0.171 \\ CR6 & 0.241 & 0.199 & 0.200 & 0.256 & 0.272 & 0.227 & 0.118 & 0.216 \\ CR7 & 0.080 & 0.066 & 0.040 & 0.022. The other approach is providing information about the failure in cycle format. This can be very useful when a production process is described in network format (e.g., CPM) and stochastic methodology is applied. The stochastic CPM can also be applied when a high volume production is modeled and the activities should wait for the end of the process. A decision-maker can have an estimate about how frequently a certain failure repeats itself, e.g., every 5 th run is affected by that particular problem. The aforementioned are considered easier ways to implement this idea in coding. This variation is described in the following table in the Pseudocode (Algorithm 1): ```
```
1:set\(i\)to 1,
2:setsetShift\(to\) 2,//2 shifts per day
3:setsetMinutes to 480,//8 h in a shift
4:settotalProcessTime to 0,
5:set\(\_\)cumulatedTPT to 0,
6:set\(\_\)mvDays to 0,
7:set\(\_\)mvShifts to 0,
8:set\(\_\)activityDuration, //array
9:set\(\_\)problemList //problemCount, activityAffected, MTBFCycle, meanDownTime
10:for\(i\)to n
11:randomizeactivityDuration
12:for eachproblem\(n\)
13:if\(i\)%problemList[MTBFCycle] == 0 then
14:activityDuration[n] = activityDuration[n] + problemList[meanDownTime]
15:endif
16:elseactivityDuration[n] = activityDuration[n]
17:endfor
18:solvetotalProcessTime \(\rightarrow\)min!
19:createsensitivityReport
20:cumulatedTPT = cumulatedTPT + totalProcessTime,
21:nrDays = cumulatedTPT / (setShift * setMinutes)
22:nrShifts = cumulatedTPT / setMinutes
23:copy i,activityDuration, totalProcessTime, cumulatedTPT, sensitivityReport, nrDays,
24:endfor
```  
**Algorithm 1** ReliabilitySimulation.  
The result of the modified process simulation shows how many times a certain problem occurred and how much time the machine spends out of production (downtime). In this case, downtime is not further categorized, but it can also be done by breaking down the process into smaller activities. Additionally, cost calculations can be fit to the model, but this was out of scope in this research.