*4.3. PHM Framework Design-Implementation and Verification Process*

The proposed PHM framework was implemented within a Matlab GUI running as a standalone executable file within the HMSM module of the iron bird. The application to an integrated technological demonstrator, of which PHM is a part but not the only objective, means that some limitations were introduced. For the application at hand, it was chosen to replicate a system operating a periodical download of the actuators signals to be analyzed. For each simulated flight (or series of simulated flights), the Health Management System Module receives the signals from both the "simulated" half-wing and the "real" half-wing through the optical ring operating with a data transmission rate of 800 Hz. This posed a significant issue for data analysis, since all the electric current signals associated with a motor angular frequency higher than such transmission rate divided by 10 times the number of the magnetic pole couples of the Brushless-AC were not properly reconstructed. As such, it was necessary to limit the data analysis for low-speed conditions only. Before testing the behavior of the PHM algorithm on board the iron bird, it was necessary to verify its behavior and expected performances offline to avoid the need to debug or rethink parts of the framework once that system was installed. Such a verification process was achieved through the approach proposed in Figure 20, thus stressing the PHM routines with datasets generated through the real-time version of the model of the actuator, which are offline versions of the simulation models employed on the iron bird for the "simulated" half-wing. The use of the RT models was chosen because of 2 main reasons. The first was the significant cut in computational effort required to generate data. The second was the need to remain as close as possible to the iron bird configuration, to test possible issues with data exchange, labels, computational effort, and memory leaks. The test was performed again considering 10 different aircraft—different from those used during the design phase—subjected to several degradation patterns while using the same scenario generator described in Section 4.1. Data were then sent to the PHM GUI prepared for iron bird deployment. Data were analyzed, subjected through the fault-detection and classification routine, and then sent to the prognostic algorithm, which performed 10 RUL predictions at equally spaced time instants ranging from the time-at-detection (the time instant corresponding to the fault detection) to the end-of-life of the component (failure conditions).

**Figure 20.** Procedure for the preliminary performance assessment.

Results were then analyzed by checking the percentage of false alarm and misclassification rates and the convergence of the RUL estimate to the ground truth provided by the simulations.
