# SOPRENE: Assessment of the Spanish Armada's Predictive Maintenance Tool for Naval Assets
## 4 Unified Architecture  
As defined in Section 2, a common approach was required in order to guarantee the scalability of the solution in terms of equipment and ship class. This approach had to deal with a variant number of features (from a few hundreds to thousands of inputs), acquisition frequencies (from mHz to Hz), algorithmic solutions and prediction horizons.  
According to that, a modular architecture was designed where each one of the blocks could be modified (or even substituted) according to the necessities without altering the flow. As illustrated in Figure 1, this design differentiates three main parts: on the left side, the data processing modules are meant to be adequate for the input data to deal with it in the following steps. It includes the preprocessing (PrePro Data module) tasks required to structure the data into tabular information and the actual processing (Process Data). This second task involves cleaning, imputation, resampling and operational filtering. All of these subprocesses make use of the historical information previously cleaned and consolidated. The storage for both the raw data and the cleansed ones is performed in HDFS and recovered by using Hive queries. The combination of both make it possible to guarantee the robustness of the system and the availability of the information.  
This information flows to the rest of the systemic parts (Training and Operation) through the subsequent Hive queries. These ones--depicted in the Filter Data module--retrieve and provide the required dataset (in terms of variables and time periods) for each one of the parts and blocks. The training and operation blocks are internally divided into three tasks, predicting the future state of the engine, detecting anomalies in that future state and diagnosing faults. The training block will train the models that carry out these tasks, while the operation block will apply these models to carry out predictive maintenance. In this sense, training modules require the longest historical possibilities for the equipment to be trained. This dataset is transformed, normalized and prepared (temporal aggregation and data split) so it can be ready for the prediction and anomaly detection algorithms (see Sections 4.1 and 4.2, respectively). This grouping has been defined according to the operational requirements, which determines a triple scope \(s\) (days, weeks and months), providing then a triple time frame input to these modules. Finally, as stated in Section 2,  
Figure 1: Architectural design. SOPRENE is composed by three big subsystems: processing, training and operation. Processing subsystem is common to training and operation.  
there is a lack of supervised data required to postprocess the historical data: Synthetic data are generated using the dataset as the baseline and simulating malfunctions according to the FMECA parameters and conditions. As presented in Section 4.3, this modified dataset is the one used to train the diagnose algorithmic.  
On the other hand, the operational block implements the predictive diagnosis. To this end, it repeats the data preparation and makes use of the training results--normalization, prediction, anomaly detection and diagnosing trained models--over the prepared incoming new data. In this sense, the system understands that any unconsolidated information segment is required to be processed. Thus, the operational modules are triggered either by batch processing (current data arrives periodically) or by the inclusion of relevant information from the past. In both cases, the resulting information is stored according to its time indexing.  
Table 1 shows an example of FMECA entry as used in SOPRENE. It identifies the failure mode with a number that only serves as a label (31 in the example); for each failure mode, it provides a collection of variables along with their nominal values, threshold and tendency. This table contains implicit expert knowledge and identifies the signals that will be predicted, as explained in the next section.