-
Notifications
You must be signed in to change notification settings - Fork 2
/
answer-to-reviewers.tex
718 lines (533 loc) · 36.5 KB
/
answer-to-reviewers.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
\documentclass[authoryear]{elsarticle}
% ------------ packages -------------
\usepackage[utf8]{inputenc}
\usepackage[OT1]{fontenc}
\usepackage{graphicx}
\usepackage[english]{babel}
\usepackage{amsmath}
\usepackage{amsfonts}
\usepackage{amssymb}
\usepackage{amsthm}
\usepackage{bm}
\usepackage[usenames,dvipsnames]{xcolor}
\usepackage{booktabs}
\usepackage{tikz}
\usepackage{sidecap}
\usepackage{url}
\usepackage[bookmarks]{hyperref}
%\usetikzlibrary{shapes.misc,fit}
\usetikzlibrary{%
arrows,%
calc,%
fit,%
patterns,%
plotmarks,%
shapes.geometric,%
shapes.misc,%
shapes.symbols,%
shapes.arrows,%
shapes.callouts,%
shapes.multipart,%
shapes.gates.logic.US,%
shapes.gates.logic.IEC,%
er,%
automata,%
backgrounds,%
chains,%
topaths,%
trees,%
petri,%
mindmap,%
matrix,%
calendar,%
folding,%
fadings,%
through,%
patterns,%
positioning,%
scopes,%
decorations.fractals,%
decorations.shapes,%
decorations.text,%
decorations.pathmorphing,%
decorations.pathreplacing,%
decorations.footprints,%
decorations.markings,%
shadows}
%\usepackage{hyperref}
%\usepackage[bookmarks]{hyperref}
%\usepackage[colorlinks=true,citecolor=red,linkcolor=black]{hyperref}
% ------------ custom defs -------------
\newcommand{\reals}{\mathbb{R}}
\newcommand{\posreals}{\reals_{>0}}
\newcommand{\posrealszero}{\reals_{\ge 0}}
\newcommand{\naturals}{\mathbb{N}}
\newcommand{\dd}{\,\mathrm{d}}
\newcommand{\mbf}[1]{\mathbf{#1}}
\newcommand{\bs}[1]{\boldsymbol{#1}}
\renewcommand{\vec}[1]{{\bm#1}}
\newcommand{\uz}{^{(0)}} % upper zero
\newcommand{\un}{^{(n)}} % upper n
\newcommand{\ui}{^{(i)}} % upper i
\newcommand{\ul}[1]{\underline{#1}}
\newcommand{\ol}[1]{\overline{#1}}
\newcommand{\Tsys}{T_\text{sys}}
\newcommand{\Rsys}{R_\text{sys}}
\newcommand{\lRsys}{\ul{R}_\text{sys}}
\newcommand{\uRsys}{\ol{R}_\text{sys}}
\newcommand{\fsys}{f_\text{sys}}
\newcommand{\Fsys}{F_\text{sys}}
\newcommand{\lFsys}{\ul{F}_\text{sys}}
\newcommand{\uFsys}{\ol{F}_\text{sys}}
\newcommand{\lgt}{\ul{g}}
\newcommand{\ugt}{\ol{g}}
\newcommand{\E}{\operatorname{E}}
\newcommand{\V}{\operatorname{Var}}
\newcommand{\wei}{\operatorname{Wei}} % Weibull Distribution
\newcommand{\ig}{\operatorname{IG}} % Inverse Gamma Distribution
\newcommand{\El}{\ul{\operatorname{E}}}
\newcommand{\Eu}{\ol{\operatorname{E}}}
\def\yz{y\uz}
\def\yn{y\un}
%\def\yi{y\ui}
\newcommand{\yfun}[1]{y^{({#1})}}
\newcommand{\yfunl}[1]{\ul{y}^{({#1})}}
\newcommand{\yfunu}[1]{\ol{y}^{({#1})}}
\def\ykz{y\uz_k}
\def\ykn{y\un_k}
\def\yzl{\ul{y}\uz}
\def\yzu{\ol{y}\uz}
\def\ynl{\ul{y}\un}
\def\ynu{\ol{y}\un}
\def\yil{\ul{y}\ui}
\def\yiu{\ol{y}\ui}
\def\ykzl{\ul{y}\uz_k}
\def\ykzu{\ol{y}\uz_k}
\def\yknl{\ul{y}\un_k}
\def\yknu{\ol{y}\un_k}
\newcommand{\ykzfun}[1]{y\uz_{#1}}
\newcommand{\ykzlfun}[1]{\ul{y}\uz_{#1}}
\newcommand{\ykzufun}[1]{\ol{y}\uz_{#1}}
\def\nz{n\uz}
\def\nn{n\un}
%\def\ni{n\ui}
\newcommand{\nfun}[1]{n^{({#1})}}
\newcommand{\nfunl}[1]{\ul{n}^{({#1})}}
\newcommand{\nfunu}[1]{\ol{n}^{({#1})}}
\def\nkz{n\uz_k}
\def\nkn{n\un_k}
\newcommand{\nkzfun}[1]{n\uz_{#1}}
\newcommand{\nkzlfun}[1]{\ul{n}\uz_{#1}}
\newcommand{\nkzufun}[1]{\ol{n}\uz_{#1}}
\def\nzl{\ul{n}\uz}
\def\nzu{\ol{n}\uz}
\def\nnl{\ul{n}\un}
\def\nnu{\ol{n}\un}
\def\nil{\ul{n}\ui}
\def\niu{\ol{n}\ui}
\def\nkzl{\ul{n}\uz_k}
\def\nkzu{\ol{n}\uz_k}
\def\nknl{\ul{n}\un_k}
\def\nknu{\ol{n}\un_k}
\def\yknow{y_k^{(\tnow)}}
\def\nknow{n_k^{(\tnow)}}
\newcommand{\nk}{n_k}
\newcommand{\nkp}{n_k'}
\newcommand{\yk}{y_k}
\newcommand{\ykp}{y_k'}
\def\taut{\tau(\vec{t})}
\def\ttau{\tilde{\tau}}
\def\ttaut{\ttau(\vec{t})}
\def\tautk{\tau(\vec{t}_k)}
\def\MZ{\mathcal{M}\uz}
\def\MN{\mathcal{M}\un}
\def\MkZ{\mathcal{M}\uz_k}
\def\MkN{\mathcal{M}\un_k}
\def\PkZ{\Pi\uz_k}
\def\PkN{\Pi\un_k}
\newcommand{\PZi}[1]{\Pi\uz_{#1}}
\def\tnow{t_\text{now}}
\def\tpnow{t^+_\text{now}}
\newcommand{\Rsysnow}{R^{(t_\text{now})}_\text{sys}}
\newcommand{\Tsysnow}{T^{(t_\text{now})}_\text{sys}}
\newcommand{\tsysnow}{t^{(t_\text{now})}_\text{sys}}
\newcommand{\fsysnow}{f^{(t_\text{now})}_\text{sys}}
\def\eknow{e_k^{(\tnow)}}
\def\cknow{c_k^{(\tnow)}}
\def\vectknow{\vec{t}_k^{(\tnow)}}
\def\Phinow{\Phi^{(\tnow)}}
\newcommand{\gnow}{g^{(\tnow)}}
\newcommand{\tausnow}{\tau_*^{(\tnow)}}
\newcommand{\tprep}{\tau_{\text{prep}}}
\newcommand{\tthresh}{\tau_{\text{thresh}}}
\newcommand{\tstarnow}{t_*^{(\tnow)}}
\newcommand{\gstarnow}{g_*^{(\tnow)}}
\newcommand{\gtotalnow}{g_\text{total}^{(\tnow)}}
\newcommand{\esys}{e_\text{sys}}
\newcommand{\mrsys}{\bar{r}_\text{sys}}
% ------------ options -------------
\allowdisplaybreaks
\journal{RESS}
\begin{document}
% ------------ frontmatter -------------
\begin{frontmatter}
\title{Answer to Reviewers' Comments on our Manuscript
``Condition-Based Maintenance for Complex Systems\\ based on Current Component Status\\ and Bayesian Updating of Component Reliability''}
\author[tue]{Gero Walter}
\ead{[email protected]}
\author[tue]{Simme Douwe Flapper}
\ead{[email protected]}
\address[tue]{School of Industrial Engineering, Eindhoven University of Technology,\\ Eindhoven, The Netherlands}
\begin{abstract}
We would like to thank the three anonymous reviewers for their detailed and constructive comments,
and their overall positive votum.
We reproduce their comments here verbatim,
and have numbered the reviewers' comments and questions to allow for easy referencing.
Our answers are interlaced and typeset in \emph{italic}.
\end{abstract}
\end{frontmatter}
% ------------ comments & answers -------------
\section*{Reviewer 1}
This paper proposes a condition-based maintenance (CBM) policy under a Bayesian framework. The key technique is to use the Bayesian method to update the reliability of each component based on the failure and censoring times observed so far. The probability distribution of each component type is assumed to be Weibull. For convenience, a conjugate prior distribution (inverse Gamma in the paper) is utilized for the Weibull scale parameter while assuming the shape parameter is known. Upon updating the posterior distribution for each component type, the conditional reliability of the system is updated based on the status of working/failed components, and the reliability diagram and signature of system. The object considered in the CBM policy is to minimize the expected cost rate of operational (inspection) cycle by determining the moment of replacement for the system.
The paper is well-written and the idea is clearly presented and demonstrated.
The problem is that it might have a significant overlap with the other paper the leading author submitted to another journal.
\smallskip
\emph{The other paper Reviewer 1 refers to is:}
\nocite{2016:walter-coolen}
\bibliographystyle{elsarticle-harv}
\bibliography{refs}
\smallskip
\emph{We cite this paper in our manuscript in Section~4,
clearly stating, in the last paragraph before Section~4.1,
that our manuscript and the cited paper share the same basic approach, namely
Weibull component models with conjugate inverse Gamma priors
combined with a survival signature approach to calculate the system remaining life distribution (RLD).
As mentioned there, however, the focus of these two works is entirely different.
The cited paper develops an approach to use \textbf{sets} of inverse Gamma priors,
to allow for a sophisticated modeling of uncertainties in the component models,
resulting in \textbf{sets} of RLDs which are the ultimate result of the paper.
Instead, the present manuscript uses the basic approach to develop a \textbf{maintenance policy},
using \textbf{a single} RLD as input for an optimization of the mean cost rate to find the cost-optimal moment of system maintenance.
Sections~4.1 to 4.3 describe the approach used for RLD calculation
in a similar way as in the cited paper,
but with notation adapted to the present manuscript's objective, i.e., defining a maintenance policy.
For readers to be able to understand our approach,
we considered it necessary to include a detailed description of the RLD calculation,
and not just refering to the paper.
}
\medskip
I have the following questions that I hope the authors can answer.\\
Questions:
\begin{enumerate}
\item In cases of pessimistic and optimistic priors, should we continually update or do not update component reliability in terms of minimizing the overall cos[t]?
\smallskip
\emph{In both cases, it is optimal to continuously update the component model parameters.
This is exemplarily shown in the case study in Section~6, with more systematic evidence given in Section~7.
Section~6.2 covers the case of failures happening later than expected, i.e., a pessimistic prior is considered,
and the last paragraph before Section~6.3 (beginning with ``The effect of the continuous parameter update \ldots'')
gives a detailed explanation.
Section~6.3 studies a case with failure times earlier than expected, i.e., with a too optimistic prior.
Here, as described in the text, both the approach with and without continuous parameter update
trigger maintenance at the same time, leading to the same costs.
However, Figure~8 shows that without continuous parameter update, the system RLD is overestimated,
which may lead to an excess risk of system failure.
This is confirmed in the simulation study in Section~7.2, Figure~11 (previously Figure~10),
where the continuous update approach (CBM-cpu) can be seen to lead to slightly lower mean cost rates
than the approach without continuous parameter update (CBM-epu and CBM-npu).
Citing the last sentence of Section~7,
``[o]verall, it seems that CBM-cpu can exert its adaptive strengths most effectively
when prior assumptions are too pessimistic,
while also performing well when prior assumptions are correct or too optimistic.''
It is almost alway impossible to know beforehand if priors are too optimistic or too pessimistic.}
\item For the example system, I think we can simply use the key stone method (use H as the key stone) to calculate the system reliability when the components are independent. Is it necessary to use system signature?
\smallskip
\emph{The example system was deliberately chosen to be very simple,
and for such a system, indeed a simpler methodology like the keystone method can very well suffice.
However, our survival signature based method is also applicable to much larger systems with complex structures,
for which the keystone method is not practical.
We now emphasize this more explicitely,
and refer to a recent paper on survival signature computations for large and complex systems (Reed 2017).
Furthermore, the \textsf{R} package \texttt{ReliabilityTheory} allows to automatically calculate the
survival signature from any given system graph,
thus avoiding manual computations as necessary in the keystone method.}
%no one component can be singled out as the reliability-limiting force.\\
%***add a note on simplicity (to understand what's going on) at example intro in Section~3?***}
\end{enumerate}
\section*{Reviewer 2}
The manuscript proposes a condition-based preventive maintenance policy for multi-component systems. The objective is to minimise certain cost rate by means of scheduling preventive maintenance interventions. The failure probabilities and the residual life distribution are updated in a Bayesian fashion as new information of the system’s evolution is gathered. The components are assumed to fail independently, but they are interrelated and the failure of a single component may have an effect in other surrogate elements.
The problem addressed is important and the methodology well-grounded. However, the manuscript requires some important work before it can be accepted.
The English writing is good. However, the paper needs to be reviewed as some sections lack a proper structure and the argument is hard to follow. In particular Section~5 must be completely rewritten.
\smallskip
\emph{Yes, we rewrote Section~5 according to the reviewer's suggestions,
as detailed below in relation to the reviewer's technical and general comments.}
\smallskip
More specific comments are summarised in the two following sections:
\subsection*{\emph{Technical comments}}
\begin{enumerate}
\item The notational choice does not seem to be the most appropriate. The use of $\tnow$ is confusing and makes the reading of the paper cumbersome. I will suggest to use something more direct, as $t_j$, where $j=1,\ldots$ represents the $j$th scheduled intervention. With that choice, the notation $\tau^{\tnow}_*$ can be simplified to $\tau^*_j$ without any loss of generality of information. Moreover, with this notational choice (or a similar one) the expression $t_j=j \delta$ becomes natural and. [sic!]
\smallskip
\emph{Our approach evaluates the RLD and $\tausnow$ not only at a regular grid,
but also at the exact times of component failures.
The reviewer's suggestion would thus have us describe the set of re-evaluation times as
$\big\{ t_j: (t_j = m\delta, m \in \naturals_0) \,\cup\, (t_j = t_{k,i}, k \in \{1,\ldots,K\}, i \in \{1,\ldots, N_k\}) \big\}$.
We think this adds unnecessary complexity at the early parts of the manuscript,
and thus prefer to denote $\tnow$ as a generic evaluation point.}
\item The claim in the first paragraph of Section 5 is a strong one and should be properly proved or, at least, a reference must be provided.
\smallskip
\emph{We were not sure which claim exactly the reviewer refered to, maybe to
``Close to system startup, $\tausnow$ will be large;
but as components in the system age and some indeed fail over time, $\tausnow$ will typically decrease.''
In the rewrite of Section~5, this sentence was dropped.}
%(It will be hard to prove this formally, as $\tausnow$ is a result of an optimization over the re-estimated RLD.
%But informally, this is clear: when a component fails, this is taken up by the RLD calculation,
%such the probability mass of the RLD is moving closer to $\tnow$,
%which leads to $\tausnow$ being closer to $\tnow$ as well.)***}
\item In Section 5.1, the authors indicate that if, for a given time $\tnow$, $\tau_*^{\tnow}<\delta$, then a preventive maintenance is triggered. I wonder if it will not be better to wait until $\tau_*^{\tnow}$? Given that $\tau_*^{\tnow}$ is---by definition---the optimal intervention time, it seems that the best action is to intervene precisely at that time.
\smallskip
\emph{Our reasoning, now better explained in the Introduction and in the rewritten Section~5,
is that $\delta$ gives the shortest inter-evaluation time period that can be realized from a hardware point of view,
and preventive maintenance is initiated only when $\tausnow < \delta$.
Therefore, initiating maintenance at $\tnow$ or $\tnow + \tausnow$ is practically equivalent.}
%Hmmm, yes, currently we have that the system is repaired at $\tnow$ when $\tausnow < \delta$.
%I could change the simulations to execute repair at time $\tnow + \tausnow$,
%but then one needs to check whether there is a component failure (and with it, a system failure)
%between time $\tnow$ and $\tnow + \tausnow$, making the policy flow chart even more complex.
%If we keep it as it is, we need to explain $\delta$ better as being very small such that repair at $\tnow$ or $\tnow + \tausnow$
%do not make a big difference and that without $\delta$, we get a situation like in the paradox of Achilles and the tortoise.}
\item It seems that the authors assume constant preventive and corrective maintenance costs. However, in practice one finds that maintenance costs are often state dependent. Is their model suitable for this? Is it robust to different cost structures? How will their results be affected?
\smallskip
\emph{Yes, we indeed assume constant cost parameters in our manuscript.
We now comment on this in the Conclusion, where we now briefly explain how our model could be extended to allow
for costs depending on time and on system state.
Such dependencies will lead to a more variable $\tausnow$.}
\item Throughout the manuscript it is assumed that the survival signature, $\Phi$, is a given parameter of the problem and no further details are given. Even though this may be correct for any real life application of their methodology, for the sake of completeness I will suggest to either include the complete version of Table 1 (maybe as an appendix) or to provide a closed form of the corresponding survival signature for their toy example.
\smallskip
\emph{Upon re-inspection of Table~1, we have found some errors that we have now corrected,
and would like to apologize for the confusion that these errors may have caused.
(We did all calculations with the correct survival signature though.)
We now exemplarily show how $\Phi$ is obtained for the case of $l_M = 0, l_H = 1, l_C = 0, l_P = 1$,
and give an explanation on how the omitted rows in Table~1 can be easily determined by the reader.}
%{\scriptsize
%(1) Take a row, decrease $l_k$ for one $k \in \{M, H, C, P\}$ by 1.
%If the resulting row is not in Table~1, then the corresponding $\Phi$ is $0$.\\
%(2) Take a row, increase $l_k$ for one $k \in \{M, H, C, P\}$ by 1.
%If the resulting row is not in Table~1, then the corresponding $\Phi$ is $1$.}\\
%Also add complete table in Appendix, or formula for $\Phi$ based on structure function???
%Also note here that there is software to calculate $\Phi$?***}
\item Five subsequent operation cycles seems to be a rather short simulation horizon. I will suggest the authors to extend their analysis to, at least, 20-25 cycles.
\smallskip
\emph{We agree that the simulation study in our submitted manuscript is rather small,
but we think it is still sufficiently large to give general impressions on the performance of our method
and to identify the factors contributing to its performance.}
%Time restrictions (the first author is no longer employed at TU Eindhoven)
%unfortunately prevented us from extending the simulation study.}
\item Beside the didactical advantages of the small example, the authors should consider a more realistic framework for testing their model. Results should be provided for a larger scale simulation exercise.
\smallskip
\emph{We decided to use the simple example also in the simulation study to provide clear insights
that could get lost with a more complex example.
Generally, more complex systems are possible, only increasing computation times,
and we now comment on the scalability of our approach when introducing the running example in Section~3.}
\end{enumerate}
\subsection*{General Comments}
\begin{enumerate}
\item The authors claim that no degradation signal is used for monitoring the system’s state. However, they mention that the status of the components can be monitored continuously. How can this be done? This question becomes more important when the authors mention that certain inspections (which reveal the status of the systems) can be conducted periodically. This seems to be in contradiction with the continuous monitoring mentioned above. Could the authors be so kind to clarify this?
\smallskip
\emph{We would like to apologize to Reviewer 2,
and agree that our manuscript was indeed very confusing in this point.
We completely rewrote the introduction and other relevant parts,
hopefully making more clear now that
we do not use a \textbf{usual} domain-continuous degradation signal, like, e.g., vibration measurements.
Instead, we assume a time-continuous signal from the components of the system, telling us only whether they work or not.
We also previously denoted our frequent re-evaluation of the system RLD by ``inspections'',
which was indeed not adequate, and we have changed our wording and explanations.}
\item The fourth paragraph in Section 1, starting with “In this paper…” must be rewritten. Their argument is not clear and it may seem contradictory; e.g. “no degradation signal for the system is available” and later “each component sends a binary signal”. At the end, it is not clear how information is collected.
\smallskip
\emph{Agreed, this is one of the paragraphs that we changed substantially as mentioned in the answer to the previous question,
and we hope that our argument is now more clear.}
%Again, we need to clarify that we do not use a \textbf{usual} degradation signal for the \textbf{system as a whole},
%but that the component status information (working or not) can be seen as a special kind of multivariate system degradation signal.
%I would also do not call our approach ``inspection-based'', as we now do in that paragraph.
\item The definition of an operational cycle in the first paragraph of page 3 seems to be in conflict with the one provided elsewhere in the manuscript, in particular page 11, Section 5.
\smallskip
\emph{We previously wrote on p.~3: ``where an operational cycle starts with a new system,
and ends after this system has been replaced by an as good as new system'',
and in Section~5 we wrote: ``An operational cycle begins with system start-up,
and ends when either preventive maintenance is carried out, or a failure of the system occurs,
with subsequent corrective maintenance.''
Since we assume that both preventive and corrective maintenance result in an (as good as) new system state,
we don't quite see the conflict here.
In our rewriting of the Introduction and Section~5,
we now make more clear that in our approach, maintenance means replacing the whole system,
indicating in Section~5.2 when this is a reasonable assumption.
Furthermore, in the Introduction, we now write
``An operational cycle spans the time between two consecutive system maintenance actions.
We assume that in both preventive and corrective maintenance, the entire system is replaced or brought to an as good as new state,
and thus optimize the unit cost rate calculated over the time since the last system replacement.''}
\item I suggest the authors to define all the acronyms on their first use. For example, CBM is used throughout the text, but never defined; and RDL is used from page 2, but not defined until page 3 (in Section 2).
\smallskip
\emph{CBM was defined in the first line of Section~1, where we wrote ``CBM (condition-based maintenance)''.
We now write ``condition-based maintenance (CBM)'' instead.
We are sorry that we indeed defined RLD too late, and now define it at the first use on page~2.}
\item The assumption of independence of the components, that appears for the first time in page 5, must be mentioned earlier in the paper.
\smallskip
\emph{Yes, we now mention this early in the Introduction, in a separate paragraph on page~2.}
\item Some variables are not properly defined, e.g. $\Rsys$ or $\Tsys$. The meaning of $C^k_l$ can be guessed from the context, but for completeness should be clearly stated.
\smallskip
\emph{We wrote $\Rsys(t) = P(\Tsys > t)$ on p.~5 above Equation~1,
but indeed did not introduce $\Tsys$ as the random failure time of the system.
We do so now at the start of Section~3.
$C^k_t$ is now properly defined in the text below Equation~1.}
\item As it seems, some of the results in section 4 have been developed elsewhere by one of the authors of this paper. Given that Section 4.1 does not add to the understanding of the problem under discussion, I will suggest to omit it or to include it as an appendix to the manuscript. This is only an opinion and I will understand if the authors decide to ignore my comment.
\smallskip
\emph{Section~4.1 introduces the Weibull component models
and the conjugate inverse Gamma prior distribution in our non-standard parametrization,
explaining the Bayesian parameter update step for right-censored lifetimes.
We think that Section~4.1 is crucial to the understanding of our method,
especially for readers not familiar with Bayesian approaches.
As mentioned in our answer to Reviewer~1's main comment,
Sections~4.1 to 4.3 combine results from several parts of the cited manuscript
in a form that is adapted to the purpose of the present manuscript.
We thus think that it is preferable to keep Section~4.1 within the main part of the manuscript.}
\item I suggest to place Figure 2 somewhere after parameters $m$ and $\delta$ are defined and the maintenance policy is described in Section 5.1 (for example at the end of the section). Otherwise, it is hard to follow.
\smallskip
\emph{We had placed Figure~2 (depicting the flowchart for the policy, now Figure~3) directly before Section~5.1 which explains the policy.
We agree that it should appear during or after the detailed description of the policy to avoid confusion,
and now have placed it within Section~5.2.}
\item A timeline sketch depicting the evolution of the policy on time, where the different elements of a time grid are illustrated, will be welcome.
\smallskip
\emph{We agree with Reviewer~2 that such a sketch is helpful, and now provide two such sketches in Figure~2.}
\item Even though the use of the zero sub-indexed double struck capital N is correct for positive naturals and zero, I think that the simpler double struck capital N is enough. The context makes evident the inclusion of zero.
\smallskip
\emph{By using $\naturals_0$ and not $\naturals$ as suggested by Reviewer 2,
we intended to emphasize that the system RLD is evaluated for the first time directly at system startup time 0,
and thus prefer to keep using $\naturals_0$.}
\item In page 13, paragraph 2, line 7, please remove “is” from the sentence “is for the current off-grid time”.
\smallskip
\emph{Thanks for pointing this out, done.}
\item Frequent references to function $g$, which is only defined later in Section 5.2, make the lecture of the manuscript difficult. I suggest to rewrite the section seeking for all elements to be introduced in a more orderly fashion.
\smallskip
\emph{Our intention was to establish the cost rate function $g^{(\tnow)}(\cdot)$ as a generic function first
and to explain the details of its calculation later.
In the rewritten Section~5, we now mention this more explicitely.}
\item As Section 8 concludes the manuscript, I will suggest to refer to it as “the conclusion” rather than Section 8; e.g. at the end of sections 5.1 and 5.2.
\smallskip
\emph{Agreed, we now write ``the conclusion (Section~8)''.}
\end{enumerate}
\section*{Reviewer 3}
The paper is well structured, well written and technically accurate. The numerical experiments are particularly interesting. I recommend the acceptation of the paper after a revision.
The weak point of the work is related to the different hypothesis which significantly simplify the modeling framework. More precisely:
\smallskip
\emph{In the revision of our manuscript, we have aimed to emphasize the pilot character of our approach,
which should be seen as a first step towards a completely new class of CBM policies.
We now discuss these and other restricting assumptions more prominently in the Introduction, Section~5, and in the conclusion (Section~8).}
\begin{enumerate}
\item All the components have the same lifetime model (namely the Weibull distribution) with a known fixed shape parameter which is not discussed. Only the scale parameter is updated and directly associated with the mean lifetime if the shape parameter is known.
\smallskip
\emph{Yes, each component type has an individual Weibull model assigned,
where the (component type specific) shape parameter is assumed to be fixed and known.
We agree that the assumption of a fixed known shape parameter is a serious limitation of our approach.
We have added a comment on this in the conclusion,
repeating a comment from the beginning of Section~4, where we wrote:
``The model could be extended to learn also the shape parameter in a later step,
using, e.g., the discretized approach by Soland (1969).''
We now also emphasize in the introduction and the conclusion that the method as described in the manuscript is deliberately kept simple
to allow for a clear and straight-forward demonstration of the general approach.
For a practical application, one should indeed update the shape parameter as well,
but in our view, adding this conceptually simple but notationally cumbersome feature would obstruct the goal of this manuscript.}
\item In the introduction the authors claim that ``the system RLD does not require a physical inspection’’ because the failure time of each component is detected online via continuous monitoring. This hypothesis seems to be very strong as it requires a costly related instrumentation. Most of the time, systems with redundancies are not monitored in a such way. if a specific application field is inferred, please give it explicitly. It could be interesting to discuss shortly the sensitivity of the proposed maintenance policy to non-detection of some components failures.
\smallskip
\emph{We have added a short discussion related to the non-detection of component failures in the conclusion.
We were mostly thinking of systems where a failure of a component is immediately eminent,
but the measurement of the component's health degree is very difficult or too costly.
This is, e.g., the case for components in power systems, where failure of a certain component
is usually reflected in a loss of current (detectable from the control centre),
but proper health monitoring (going beyond working yes/no) is cumbersome and costly.}
\item The maintenance of the system is always a replacement of the whole system by an as good as new one. This hypothesis is hard to accept especially if all the components are continuously monitored.
\smallskip
\emph{In the rewritten Section~5, we discuss this point now extensively in Section~5.2:
``At first sight, replacing a complete system when only some parts of it are defective may seem strange.
However, there are many real life examples, including from daily life.
So called complete clustering (Olde Keizer et al, 2017)
may be optimal in case of a very strong economic dependence between the different parts of a system,
e.g., due to a very high fixed set-up cost independent of the maintenance activities to be done,
as is the case of installations used in the generation and distribution of oil and gas.
Note that often for safety reasons, the latter installations are monitored continuously.
There may be also technical dependencies between parts of a system that may require combined replacement:
replacing the cassette of a bike often also requires to replace the chain,
and the tires of an airplane are required to have the same thickness.
But also complete systems are replaced because replacing one or more of its parts may take much longer,
which may result in big production losses.
Another reason can be that there may be a high probability that when individual parts are replaced,
other parts will be damaged, requiring their replacement as well.''}
\end{enumerate}
Some additional comments or remarks are given hereafter to help improving the paper.
\begin{enumerate}
\item The literature review has a strong focus on papers that are very close to the proposed one. There are some ambiguities about what the authors call ``papers having some relation to their approach’’. For example the paper by Si et al. (2013) is referred first as a paper where the inspection of the system condition lead to the choice of the moment for the next inspection. There are a lot of (older) papers with that specificity. The reason why Si et al.~(2013) has been chosen is probably the RUL update in a Bayesian framework. It is not clear at this stage.
\smallskip
\emph{We did mention right in the first paragraph of the discussion of Si et al.~(2013)
that they use an empirical Bayesian framework,
but we now also state explicitely that the use of a Bayesian approach is a main reason why we consider this paper relevant for the discussion.}
\item Page 1, last line: Maintaining systems or components at the right time is the central idea of all the maintenance policies, not only for CBM. The specificity of CBM is to take the decision about maintenance on the basis of the on-line system condition.
\smallskip
\emph{Agreed. We now give a better definition of CBM, as
``using information about the actual condition of the systems or components''.}
\item Page 2, line 18 from top: The phrase ``a kind of inspection-based CBM policy’’ is maladjusted. The paper does not deal with inspection. The system is supposed to be continuously monitored (and re-evaluated from times to times). It would also be interesting to give in details the specific points which make the proposed policy a ``kind of’’ CBM policy.
\smallskip
\emph{Agreed, we deleted that notion, and hope to be more clear now here.}
\item Page 2, line 15 from bottom: Please explain the acronym ``RLD’’ the first time it is used.
\smallskip
\emph{We are sorry that we defined RLD too late, and now define it at first use.}
\item Page 4, line 5 from top: Please explain more precisely the meaning of ``this approximate calculation method’’.
\smallskip
\emph{We replaced ``this approximate calculation method’’ with ``the renewal-reward theory based calculation method''
in the hope to make this more clear.}
\item Page 6, line 11 from bottom: It would be interesting for the reader to know explicitly which sections of the paper follow closely ``Walter and Coolen (2016)’’ to help identifying precisely the original part of the work.
\smallskip
\emph{Agreed, the respective sections are now added.}
\item Page 7: The choice of the inverse Gamma distribution as a prior is interesting for mathematical reasons. Are there some possible tests to justify this choice from data?
\smallskip
\emph{It is not possible to use data for testing the adequacy of the parametric family of the prior,
as it is supposed to reflect the expert's opinion.
So the crucial question is rather whether inverse Gamma distributions can adequately reflect the expert's opinions.
A tool to help answering that question are prior predictive distributions.
They give a distribution for the failure times that can be expected according to the expert's choice of prior
(here: inverse Gamma with specific parameters)
\textbf{in combination with the assumed sample model} (here: Weibull).
Figure~6 (previously Figure~5) depicts prior predictive reliability functions for the priors in the case study of Section~6,
as a way to visualize the choice of prior parameters given in Table~2 in the context of the Weibull model.
When an expert feels that these prior predictive reliability functions do not correspond to the failure time distribution (s)he postulates,
and no change of prior parameters can approximate the postulated failure time distribution,
then the prior family would seem inappropriate,
under the condition that the sample model is indeed correct.
We now briefly discuss this issue in Section~6.1,
also giving a reference to methods for checking the correctness of the sampling model.}
\item Page 13, section 5.1: The grid of planned evaluation time points is defined with a ``sufficiently small’’ time increment. What does it mean quantitatively? It seems that if $\delta$ is very small the maintenance time will be almost given by $\tau_*^{(\tnow)}$.
\smallskip
\emph{We have completely rewritten Section~5 and now address the role of $\delta$ in more detail there, as well as in the Introduction.}
\item Page 14, first paragraph: Is it possible to determine the number of operational cycles which is necessary to improve significantly the values of the parameters? It seems that after a certain amount of time the updates will have a negligible effect.
\smallskip
\emph{Indeed, due to the weigthed average update in Equation (7),
it is possible that the parameter $y_k$ (the expected value of the Weibull scale parameter $\lambda_k$)
will not change by much once it has approached the 'true' value.
However, the strength parameter $n_k$ will continue to increase,
since the other part of (7) reads $n'_k = n_k + e_k$, i.e.,
$n_k$ is incremented by 1 for each observed failure.
The consequence is that the posterior distribution over $\lambda_k$ becomes ever more pointed
(the variance of the posterior approaches zero),
such that the posterior predictive distribution approaches the Weibull distribution with $\lambda_k$ equal to $y_k$.
Stopping to update would make only sense when the posterior is practically equal to a point mass on $y_k$.
However, this holds only if a component's failure behaviour does not change.
Updating allows to automatically adapt to any changes in the failure behaviour.}
\item Page 14, Equation (14): Is it possible to have some elements about the variance of the unit cost rate?
\smallskip
\emph{In Equation~(15), the unit cost rate $\gnow(\tau)$ is defined as
$\gnow(\tau) = \E[g(\tau \mid \Tsysnow)]$,
i.e., as expectation of the conditioned unit cost rate $g(\tau \mid \Tsysnow)$ from Equation~(14).
We do not think the variance of the conditioned unit cost rate,
$\text{V}[g(\tau \mid \Tsysnow)]$ is instructive for the purposes of our manuscript.}
\item Page 15, line 12 from bottom: Please replace ``the costs rate’’ [sic!] by ``the mean cost rate’’.
\smallskip
\emph{We wrote ``$\gnow(\tau)$ gives the cost rate that we expect to incur [...]'',
which includes the notion of mean via ``expect'', and we hope this is clear enough.}
\end{enumerate}
\end{document}