## 4 Data Description  
The data we have worked with are related to the RT2 plant belonging to the SARAS group and consist of \"Notices\" and \"ODM\" (maintenance orders):  
* The first one contains the chronology of all the anomaly notices that occurred for each component of the RT2 system from 2000 to 2021; we will refer to these also as alerts or notices;
* The second contains the maintenance orders for the same components, that is, the order of the materials needed for maintenance activities. We use \"ODM\" to understand whether a certain notice corresponds to a breakdown or a simple malfunction (a breakdown is related to a piece of equipment that has broken, whereas a malfunction corresponds to a piece of equipment or machinery that fails to function normally but has not broken yet). Both \"Notices\" and \"ODM\" have a similar structure: each sample (row) corresponds to a notice with different features (columns) about the notice. The features of interest for our analysis are:  
* The identification number of the notice;
* The description;
* The date of the event;
* The technical office;
* The equipment. The identification number is a unique numeric code necessary to understand which notice is being referred to. It is used to link information about a certain notice from \"Notices\" to \"ODM\". The description includes a short sentence indicating what happened. The date of the event represents the moment of occurrence of the event, which may be a breakdown or malfunction. The technical office defines the place where a specific anomaly occurred. The purpose of the technical office is to indicate the component that has presented a malfunction or breakdown and is represented by abbreviations that can be composed of three or four elements in the form:  
\"Plant\" - \"class of the component\" - \"component-name of the component\" or:  
\"Plant\" - \"class of the component\" - \"name of the component\" - \"part of the component\"  
An example for the first case is represented by:  
RT2-FURNACES-RT2F1A  
where FURNACES corresponds to \"furnaces\" and RT2F1A is a component of the class \"furnaces\". An example for the second case is:  
RT2-PUMPS-RT2 MP4-RT2 MP4P  
where PUMPS represents the class of pumps, RT2 MP4 is the associated component and, finally, RT2 MP4P is a sub-part of the component RT2 MP4. The last feature of the \"Notices\" and \"ODM\" data, the equipment, if indicated, represents the part of the component as shown in the second form of the technical office just mentioned. The main problem with the \"Notices\" data lies in the \"technical office\" column, which is usually blank or partially filled. This generates an enormous amount of incomplete information that cannot be used in any way. As the technical offices are supposed to provide the information about the offices and the components that have presented a possible anomaly, without that, we cannot associate the corresponding failure data. Therefore, many components do not have information about their corresponding technical office, making them unsuitable for the use of machine learning techniques. This problem occurs because the compilation of the alerts has been performed manually under the responsibility of the operators. Sometimes the operators omitted text in this field, compromising the overall quality of the available data. Thus, one problem we had to face was the reconstruction of the missing data. This was performed with a pre-processing step with the goal of filling the missing technical office names and reorganizing the overall structure so that each component may be defined and associated with a chronological data set of its notices. To reconstruct the data, first we had to identify the columns from the \"Notices\" data that could be a source of information or that could indicate which component presented an anomaly. In particular, the column \"Description\" present only in \"Notices\" and \"Equipment\" present both in the \"Notices\" and in the \"ODM\" have been considered.