## 3 The Proposed Methodology  
The proposed methodology is described in this section. The objective is to provide a description of the steps that should be followed to implement, \"from scratch\", a procedure that:  
* identifies anomalous behaviours that could potentially represent faults;
* builds a training set for the identification of the corresponding degradation model; and,
* triggers the RUL prediction when most appropriate to anticipate the occurrence of the known fault. Figure 2 shows the steps included in the methodology, where two main blocks can be distinguished. The online part includes data collection and feature extraction, and aims to detect anomalous behaviours and assign each data sample to a cloud, in such a way that each cloud will correspond to a different HS. As feature vectors are available, for each k data sample, the online algorithm decides whether a change in the data structure has occurred in real time. When no anomaly is detected, the data sample  
is automatically assigned to the current data cloud. Otherwise, it could be assigned to an existing data cloud or become the prototype of a new cloud. In addition, in the case in which a data sample is considered to be anomalous, a warning message is generated, which signals to a worker to physically check for the presence of a fault. If no faults are effectively found, then the HI value at which the anomaly was detected can be set as the anomaly threshold (AT), i.e., the time to start the prediction; then, the next k observations are read to begin a new iteration. On the contrary, if a fault is detected, the failure threshold (FT) is identified as the HI value at that time instant; data that are collected until that moment are used as the training set for building the degradation model of the fault. After restoring the correct operating condition of the system, it is possible to use the degradation model that was built during the previous phase. The online part is always activated for detecting anomalies and updating/creating data clouds. However, an additional online part is introduced, which aims to anticipate the occurrence of the fault identified in the previous \"training\" step. as shown in Figure 3. Indeed, when an anomaly is detected and the FT is reached, then offline analysis is needed to update the degradation model. Otherwise, if the HI value that corresponds to the time instant at which the anomaly is detected is greater than or equal to the AT, and then the future values of the HI begin to be predicted based on the built degradation model and the RUL prediction is triggered. On the contrary, if the current HI value does not exceed the anomaly threshold, but it is nonetheless considered to be anomalous by the online algorithm, then a further offline investigation is needed. In any case, when the RUL prediction is triggered, what we expect is a warning message, showing how long it takes to reach the FT.  
Figure 2: The proposed methodology for the PHM implementation “from scratch”. For simplicity, consider the example that is shown in Figure 4, in which vibration data in the healthy and fault conditions are collected at a certain sample frequency \(f_{\mathrm{s}}\) through an accelerometer. Suppose that the vibration signature during a certain period of time is in a healthy condition; then, after a time \(T\), it enters a fault condition. The first step is to extract relevant features after \(t=f_{\mathrm{s}}\cdot k\), where \(k\) is the number of data samples read during the time window considered for one iteration. For example, for rotating machinery, the time window could correspond to the time of one revolution. At the time \(t_{1}\), the feature vector \(F(t_{1})\) corresponding to the first signal segment, made up of \(k\) data samples, can be memorized, while the \(k\) samples can be discarded, as shown in Figure 5.  
Figure 4: Example of vibration Signal. Figure 3: The proposed methodology for the prognostic health management (PHM) implementation after fault identification.