Improvements of a Failure Database for Marine Diesel Engines Using the RCM and Simulations

: Diesel engines are widely used in marine transportation as a direct connection to the propeller and as electrical principal or auxiliary generator sets. The engine is the most critical piece of equipment on a vessel platform; therefore, the engine’s reliability is paramount in order to optimize safety, life cycle costs, and energy of the boat, and hence, vessel availability. In this paper, the improvements of a failure database used for a four ‐ stroke high ‐ speed marine diesel engine are discussed. This type of engine is normally used in military and civil vessels as the main engine of small patrols and yachts and as an auxiliary generator set (GENSET) for larger vessels. This database was assembled by considering “failure modes, effects, and criticality analysis (FMECA),” as well as an analysis of the symptoms obtained in an engine failure simulator. The FMECA was performed following the methodology of reliability ‐ centered maintenance (RCM), while the engine response against failures was obtained from a failure simulator based on a thermodynamic one ‐ dimensional model created by the authors, which was adjusted and validated with experimental data. The novelty of this work is the methodology applied, which combines expert knowledge of the asset, the RCM methodology, and the failure simulation to obtain an accurate and reliable database for the prediction of failures, which serves as a key element of a diesel engine failure diagnosis system.


Introduction
The diesel engine is the most often used engine type in naval propulsion, as well as in electrical energy generation of the military vessels. While it is common in civil vessels to use large two-stroke engines, military vessels use four-stroke engines due fundamentally to size restrictions. Diesel engines have a high density of power, very good efficiency, high reliability, and better response to load changes than other solutions, such as a gas turbine [1,2].
Propulsion and power generation are the most critical systems on the vessel platform. Therefore, the optimization of its reliability has an important impact on vessel availability, safety, and life-cycle cost. In addition, the maintenance energy cost is estimated to be around 2% of the energy in the life occurring. The methodology RCM is the one used to make a failure modes, effects, and criticality analysis (FMECA) database, which is intended to be a systematic and effective procedure that has demonstrated great results in aeronautics, the military, and in industry in general.
Although the RCM [4] has proven to be an effective methodology for defining failure modes reliably if applied correctly and having ample knowledge about the asset, it is possible to improve the result with the proposed methodology. The proposed methodology consists of causing failures in a marine diesel engine simulator built in AVL Boost© and analyzing the model symptoms in terms of the parameters monitored on board. In addition, the main problems and worst effects of the relatively constrained experimental database are two-fold: first, obtaining a false positive failure, and second, not detecting little failures that could eventually become a fatal failure. To improve the database with modeling is possible because the precision of a well-adjusted physical model is able to reproduce the behavior of a situation that maybe an equipment expert can never imagine. In this way, there is a symbiosis between the experience and the objective information obtained by a reliable model.

RCM in Naval Platforms
Papers from Society of Automotive Engineering, SAE's Papers JA1011 [4] and JA1012 [5] standards specify what a maintenance plan must accomplish to be considered an RCM. The main RCM concept is that it maintains functions [9], not the asset. It could be defined as a process that is used to determine which maintenance actions should be performed such that the assets continue to perform the functions required of it.
The RCM procedure establishes seven steps in which to define the asset functions, functional failures, causes of failure, the effects of the failure, the consequences of the failure, and the maintenance task to prevent them from happening. The process involves answering questions in the first to fourth steps, resulting in a FMECA failure database, which is why the RCM is used in this paper. The fifth, sixth, and seventh steps correspond to the second phase, which determines the maintenance tasks to be performed on the asset. This methodology aims to define the most costeffective maintenance tasks. The cost-effective concept means the best relationship between the cost of the consequences of a failure and the cost of the maintenance task to prevent it from occurring. Among all types of maintenance tasks, this methodology prioritizes predictive or condition-based maintenance. As long as it is technically feasible and economically profitable with regard to the consequences of the failure, a predictive task will be carried out. In order to carry out a predictive maintenance task, the concept of the P-F curve [8] is important. The interval P-F, is the time that exists between the detection of the potential failure P and the failure F. The higher the P-F interval, the more time to plan the repair/replacement such that it has a lower impact on the operation and availability of the asset. Another important concept is the existence of six types of failure patterns [8]. Traditional preventive maintenance assumed that there is only one failure pattern, which considers that the probability of the failure of any element begins to increase exponentially at a given moment. However, the RCM indicates that there is not always a point where the probability of failure is rapidly increasing; as such, a useful life time period cannot be defined. Finally, a fundamental aspect is the operational context [8]. Two equal assets cannot have the same maintenance strategy if they have a different operational context. The operational context is made up of the environmental conditions, operating profile, different demanding functions on one asset from another of the same type, etc.
The RCM methodology has been adapted for naval platforms by the defense industry [7,8]. This specific industry defines operational and quite rigid dock maintenance periods, which are established at the warship design stage and are difficult to change during a vessel's life cycle. Another important adaptation of the RCM to the naval defense industry is the type of consequences, i.e., warship mission fulfilment is more important than economic savings. In addition, there is no single operational context, but several contexts ranging from the extremes of peace to war. A summary of the specific process for designing the maintenance plan for a military vessel is as follows: determination of the operational context, functional breakdown of the vessel, analysis and determination of critical systems/assets, performing the RCM analysis of critical platform systems, combat system and structures, definition of maintenance programs adapting to the maintenance cycle defined for the vessel, and determination and organization of spare parts that are on board and on shore. A risk matrix is defined [8], where a risk is considered a combination of the probability of occurrence and severity of the consequences in case a failure occurs. Selvik [29] shows the importance of risk assessment in complex platforms.

Construction of a Failure Database for Marine Diesel Engine Using RCM
The first steps toward creating a complete and reliable failure database of a marine diesel engine are to define the operational context and functions of the vessel. In this case study, the diesel engine is part of a Generator SET (GENSET), and a vessel power plant is composed of four identical GENSETs. Table 1 and Figure 1 show the general characteristics and a diagram of the points monitored, respectively, of the marine diesel engine simulator used in this study. Marine Diesel Oil F76 Figure 1. Layout of the diesel engine model [29,30]. Figure 1 identifies the monitored points of the engine with the symptom identification code of the failure database defined later. Both propulsion engines and GENSETs were always within the vessel RCM analysis since they are systems whose loss is critical. Subsequently, the limits of the asset in the analysis must be clearly defined; in this case, the entire diesel engine and its auxiliary services are included (sea water and hot water refrigeration systems, lubrication system, fuel supply system up to the daily service tank, and air inlet and gas exhaust system).
Once the limits of the analysis are defined, the construction of the failure database was started by defining the engine functions, then the failure modes of each function, and finally its effects/symptoms. It includes the probability, consequences, and criticality that corresponds to each one of the failure modes considered. The number of failures defined is limited by all those that have a realistic probability of occurring, as well as those that are critical, whose consequences are very serious even if the probability is scarce.
As for the symptoms, it should be considered how they can be detected in the real installation. For this purpose, it is vitally important to consider the available failure indicators, which in this study are: the operating parameters monitored in real-time on board, the fluid parameters obtained via periodic analyses, and visual inspections that the crew carries out daily.
Following the procedure indicated, a complete failure database was performed by the authors in References [28,30]. This database is composed of a total of 69 functions, 209 failure modes, and 54 potential symptoms, of which 154 failures have some operating parameter as a symptom. Among these last 154, 69 failures come from thermodynamic processes inside the engine. Furthermore, among the total amount of 209, 43 failure modes have some parameter from the analysis of fluids (oil, water cooling or fuel) as a symptom. Table 2 shows an example of information included for each failure mode in Pagan [28]. Hot water temperature high. There could be low hot water pressure. If there is communication between hot water and seawater, hot water goes to sea water circuit when the engine is running, so hot water level goes down. When the engine stops, seawater enter hot water circuit so level goes up. In this case, there could be engine corrosion in engine parts cooled by hot water and high chloride content in the water.
If hot water leakage goes outside the engine, it is visible in joints between cooler plates.
The failure database [28] codifies each function, functional failure, and failure mode according to the RCM methodology. Table 2 shows failure mode number 37A7 as an example. Condition-based parameters related to this failure are the "high" refrigerating hot water temperature TT11, "low" refrigerating hot water pressure PT10, and "high" chloride content in the refrigerating water AG-FQ-Clor. The value of criticality goes from "0" when it is negligible to "1" when it is critical.
Among the 69 failure modes with thermodynamic symptoms, the 15 most frequent were extracted in order to introduce them in a thermodynamic model of the diesel engine [28,30] to act as a failure simulator and accurately and quantifiably check the symptoms produced in terms of engine parameters. The analysis of the symptoms allows for optimizing the original FMECA failure database made using the RCM. The database size of the 15 selected failure modes was reduced from the total amount of 209 failure modes × 54 symptoms to 15 failure modes × 30 symptoms. Table 3 shows the simplified database that includes 15 thermodynamic failure modes. The failures are represented by the rows from F1 to F15. The potential symptoms are represented in columns from symptom S1 to S30 [30]. The failure modes were: excessive pressure drop in the air filter (F1), efficiency reduction in the air cooler (F2), excessive pressure drop in the air cooler (F3), air compressor failure (F4), air leak in the intake manifold (F5), inlet valve leakage (F6), partial misfiring (F7), cylinder compression ratio loss (F8), low clearance between the rocker arm and cylinder valves (F9), high clearance between the rocker arm and cylinder valves (F10), timing failure-injection advance (F11), timing failure-injection delay (F12), turbine failure (F13), exhaust manifold gas leakage (F14), and excessive gas pressure drop in exhaust ducts after turbine (F15).

Optimization of the FMECA Failure Database
The response of engine parameters, which are symptoms of the original FMECA failure database, as well as other potential symptoms were analyzed in the simulator under failure conditions. Following this simulation and analysis, an improved FMECA failure database was obtained.
The magnitude of a parameter's variation in failure condition with respect to its normal value is traditionally given by experience [6]. In this paper, it is proposed that the variation of engine parameters are objectively based on the results that produce the failure simulation to determine the symptoms. A minimum threshold of 5% was set as the parameter variation considered as a symptom. Although experience may be enough to propose approximate variations for each failure mode, having a failure simulator allows one to know the variation of each parameter for each failure with a much greater accuracy. This limit of 5% was established as an agreement between robustness and diagnostic capacity. It would be possible to slightly reduce the limit to a value equal to the accuracy of each sensor plus a small margin, but in that case, there would be a different limit for each parameter. Moreover, this reduction in the variation limit would not significantly improve the detection capacity; however, it would increase the risk of false positives.
All the symptoms were analyzed and are presented in Tables A1 and A2 showing when each parameter of interest was considered an indicator/symptom of a failure mode using the criterion indicated above. Appendix A offers a large important part of the data and the discussion for each symptom separately. From that analysis, new symptoms were obtained: the cooler inlet air temperature (S31 and S32), respectively; exhaust manifold gas pressure (S33); indicated main effective pressure (IMEP) (S34); turbocompressor speed (S35 and S36); and air mass flow (S37).
As an example, Table 4 shows the effect of each failure (F1 to F15) regarding the cooler inlet air temperature as symptoms S31 and S32.   Table 4, it can be seen that S31 and S32 are symptoms of failures F5-F8 and F13-F15 when it is lower than its normal value, while it is a symptom of failures F4, F6, and F12 if it is higher; therefore, S31 and S32 can be indicative of a large number of thermodynamic failures. The variation of these parameters was mainly due to these failures being involved in both the gas/air management and the energy balance of the engine. For example, if the turbine has a failure (F13), the energy available for the compressor will be reduced; therefore, it compresses less intake air, and consequently, S31 or S32 will be reduced. The response of several symptoms can be explained with energy balance that provokes each failure within the engine. For example, S31 and S32, combined with S33 (exhaust manifold gas pressure), can be a symptom for failures related with energy losses in the engine, such as fouling in the air filter (F1) and in the air cooler (F3), a reduction in the energy efficiency of the compressor (F4), the more difficult to detect failure of F6 (inlet valve leakage), etc. Table 5 shows the comparison between both databases, original (a) and after the optimization (b).

Results
Once the symptoms of each of the failures was determined via simulations, it was possible to update the original failure database to improve it. Table 5 shows the original failure database as Table  6a and the optimized failure database as Table 6.
In the same way as in Table 3, the "high" (H) and "low" (L) values that appear in Table 5 indicates whether the symptom value is high or low, respectively, for the failure mode. Table 5 is marked in green plus index "1" in the boxes of the symptoms that have changed relative to the original database, and in blue plus index "2" for the symptoms that have been added to the original database, which were not considered beforehand. All green-colored boxes were an improvement over the original database, either by correcting or by activating symptoms that were considered in the original database. The squares in green with the index "1" without any value indicate that there was a symptom, but the simulation has shown that the variation was not significant enough to be considered. Therefore, the parameter of the column corresponding to that box ceased to be a symptom for the row failure corresponding to that box.
Basically, the symptoms defined in the optimized database were similar to those of the original database. However, it was improved in two ways. First, by increasing the number of parameters that were used as potential symptoms (S31-S37), and second, existing parameters changed its condition to symptoms for some failures. All these changes can be seen in Table 5, where the F1 to F15 rows correspond to the simulated failures and the columns from S1 to S37 correspond to the potential symptoms.
The effect of including new parameters is that the optimized database Table 5 has seven more columns, which correspond to new parameters considered as symptoms. The new symptoms are: cooler inlet air temperature in banks A and B (S31 and S32, respectively), exhaust manifold gas pressure (S33), IMEP (S34), speed of the turbocompressor banks A and B (S35 and S36, respectively), and air mass flow (S37). The existence of new parameters made it possible to identify many of the failures more accurately. The most striking case was the set of failures F6, F9, F11, F12, and F15, which in the original database shared symptoms, while in the optimized database, they can be distinguished from each other.
The effect of the symptom condition change for the existing parameters was that the original symptoms have been updated, in particular, their activation or exclusion as symptoms. For example, the high air pressure in inlet manifold (S4) for the detection of the efficiency failure in the air cooler (F2), or on the other hand, deactivation of the gas output temperature of cylinders (S6 to S17) was added for the failures F1-F3, F5, F9-F12, F14, and F15. In the first case, the symptoms were dismissed by the experts, and in the second case, the symptoms estimated by the experts did not have enough variation according to the simulations.

Comparative Evaluation between the Original and Optimized Failure Databases
In this section, a comparison is made between the two failure databases, namely the original and optimized ones. The objective was to compare the results they offer when both are fed the same input data and their failure-diagnosis capabilities are compared.
There is no real historical data of the 15 most typical thermodynamic engine failures. This is due to two main reasons. First, the number of monitored engines to which the author has access to is limited. Second, we have only been monitoring engine behavior relatively recently, for less than five years. Among all the data monitored, we have data only of the failure F7, misfiring/failure in the fuel supply system. This failure has been identified and verified using historical maintenance reports.
Two evaluations were carried out. The first one was made of the complete failure database of the 15 failures studied using a thermodynamic model to simulate the diesel engine under a failure condition. In the second evaluation, a real historic engine data was used, which had the failure F7.
Both evaluations were carried out in a blind way, where active symptoms were fed into the databases without these databases having previous information of the real failure. For the evaluation, the two databases were placed in parallel and fed with the same input parameters from the simulator and the real engine.
As shown in Figure 2, the behavior with real or simulated failure produced active symptoms when the variation of parameters reached at least 5% of its normal value. The parameters that met this criterion were labelled with the high value "H" or low value "L" depending on whether the value was greater than or less than the normal value, respectively. The normal value was set by the parameter value running under normal conditions without failures for different operating points. The two failure databases that are compared were those that are shown in Table 6. The two evaluation processes and the results obtained from both the original and optimized databases are described below. Evaluation 1 was based on parameters monitored in an engine simulator and evaluation 2 was based on a real engine.

Evaluation 1-Entering Data from the Engine Simulator under Failure Conditions
The database will interpret the parameters as symptoms when the data variation coming from the simulator is higher enough. Then, the combination of symptoms provided by the databases that are active at each moment indicates the type of failure that is occurring. For this evaluation, a typical operating profile was simulated: engine starts, connects to the vessel power plant, increases its load (25%, 50%, 75%, and 100%), and finally reduces the load until it stops. It was assumed that the failure already existed before starting the engine or occurred before the first load step was taken. In this way, it was possible to check the diagnostic accuracy at each operating point of the simulated engine.
The results obtained in this study and the results of each failure simulation are shown in Tables A3 to A7 of Appendix A of this paper. These tables indicate the symptoms that identify the original failure database (a) and the optimized database (b) at each operating point and the corresponding diagnosis. In this part of the paper, only the detection of F4 (air compressor failure) was used as an example of the methodology used for this detection; Table 6 shows the comparison between both databases used. Highlighting in red was used when there was no diagnosis, in orange when the exact combination of symptoms was not fulfilled and a multiple diagnosis exists with several possible failures, and in green when the diagnosis was unmistakable because a unique combination of symptoms was fulfilled in the database.
It is important to remark that not just the number of symptoms that is important for detecting a type of failure; what is more important is the type of symptom and in what situations this symptom appears.
To perform a better comparative evaluation, the diagnosis was offered with two different premises: first, using only parameters that the diesel engine thermodynamic model can simulate: S4-S21 and S31-S37 (see Tables A1 and A2), and secondly, taking into account the rest of the potential symptoms included in the databases: S1-S4 (see Table 3). These other symptoms are the same in both databases.
As a summary of the failures detected between both databases, Figure 3 shows a comparison between the number of symptoms detected with the original and improved databases (columns correspond to the left axis) and the probability of failure detection (red and blue points correspond to the right axis). With the improved database, the number of detected symptoms was higher in almost all failure types, and therefore, it was possible to detect the type of failure in 13 of 15 failures types with a 100% probability. However, with the original database, it was possible to detect a failure, but it was not possible to detect the exact type of failure (as in the cases of F1, F3-F6, F9-F12, F14, and F15); with the improved database, only two failures were not detected (F9 and F10).
In addition, Table 6 shows a summary of the analysis between the original failure database and the optimized failure database.   This table shows that the optimized failure database using the methodology proposed in this paper offered a much more precise diagnosis in most of the failures. Nevertheless, the diagnostic capability was different depending on the operating point. This was mainly because of different sensitivity of engine parameters under failure depending on the load. Also, the values used for the diagnosis were relative to the normal operating value; this meant that when a value was high and the variation was small, it was sometimes below the threshold of the 5% variation taken to avoid false positives. In this way, the system offered a variable diagnosis in terms of possible failures that may be occurring until it reached the point of operation in which it was diagnosed unequivocally. Despite this, it is considered that this system significantly improves upon earlier systems. In short, in most of the cases, the original database was not able to differentiate between one failure or another by considering the symptoms; however, the optimized database uniquely managed to diagnose all the failure modes studied, as shown in the next section.
There was an exception to the above assertion, which was the valve clearance failures (F9 and F10), which share the symptoms of low S1, low S2, and high S3. The simulator indicated that the rest of the thermodynamic parameters suffered a variation of much less than 5%. For these two failures, it would not work to reduce the limit of detection to the precision of the instrumentation (approx. 3%) because these failures produce a variation of the symptoms of less than 1%. Therefore, it was not possible to detect using actual instrumentation.
Regarding the performance of the engine's efficiency and power, it is possible to say that all tested failures are going to produce a reduction of both engine energy and efficiency because a little failure means a deviation from the optimal operational adjustment for the engine. Since a predicted diagnosis can be detected before and corrected during normal maintenance control, this can improve the energy efficiency of the engine at the same time that it is possible to increase the life cycle of the engine, and to avoid a catastrophic failure of the engine.

Evaluation 2-Entering Data from a Real Engine under Failure Conditions
Historical data of a real diesel engine installed on board was used. There were 2 months of real operating data, January and February 2015, where data were recorded every 1 min, providing a total of 17,377 records after having applied a filter to eliminate the data in which GENSET was not working. These records are the same as those used to validate the artificial-intelligence-based anomaly detection system [31]. Among all operating records, the detection system identified 78 events that represented a potential anomaly, and among them, it automatically determined that 13 were records of real anomaly. Once the anomalous behaviors were identified, it was necessary to diagnose the anomaly. If no failure database is available, an expert must do it manually, observing the altered parameters in those records. In this case, the proposed diagnosis system has a failure database that can do that work automatically.
Analogous to the previous evaluation of the 15 most typical thermodynamic failures using data from the simulations, in this case, the active symptoms produced by real historical records and identified as anomalies were insert into the two databases. Table 7 shows the results. Table 7 shows the diagnoses offered by the original failure database and the optimized failure database for a real failure of partial misfiring (F7) that happened in an engine of the same model as the one studied. It was observed that both databases detected almost the same symptoms. However, there was a slight difference that made the original database offer three possible failures-F7, F8, or F10-while the optimized database unequivocally identified the actual failure as F7. The only symptom that the optimized database detected and the original did not was a low S4, which in this case made the difference in isolating the failure. This symptom was added in the optimized database thanks to the use of the engine model, which was able to detect that this symptom dropped more than 5% when failure F7 occurred. In the original failure database, this symptom was not considered by expert knowledge.
The result of this comparison under a real failure F7 was similar to the previous one using the simulation of the failure F7. However, there was a substantial difference between the simulated failure F7 and the real failure F7. In the simulated case, the partial misfiring failure occurred in a single cylinder, 1A, whereas in the real case, it occurred in all cylinders at the same time. The symptoms were the same, only that in the real case, the effect on the engine was much greater, as we would expect.

Conclusions
The main conclusion of this work was that the proposed optimized failure database significantly improved the detection of engine failures. The early detection of most typical failures was possible thanks to the methodology used, which combined expert knowledge, the RCM methodology, and engine modelling of failure conditions. The conclusions are organized into two different areas: construction of the original failure database using RCM and optimization of the failure database using a diesel engine simulator.

Conclusions Regarding the Preparation of the Failure Database Using RCM
A failure database of the diesel engine was made using the RCM methodology with a highly detailed list of possible symptoms and causes. The same level of detail reached in this work has not been found in the literature to date [30].
This database defined not only the effects of each failure mode, but also the inspection tasks to be performed in case there were several possible failure modes. This level of detail made this original failure database a very valuable product in itself. For its construction, it required knowledge of the methodology, experience in operation, maintenance of this type of diesel engine, and existing techniques of predictive maintenance.
The obtained result was a failure database that contained 209 failure modes. The methodology described by the RCM was valid and valuable for the realization of the FMECA databases, which allowed for a correct failure diagnosis of assets and systems, in this case of a marine diesel engine.
Almost 170 of the 209 failures were detectable using the failure database, so 39 could not be detected as there was no monitored indicator that could detect that type of failure and/or the evolution of it. Therefore, it was not possible to predict all failures of a diesel engine, unless the monitoring is combined with periodic inspections and engine dismantling.
The greater the number of failures covered, the greater the reliability and the lower the need for dismantling, which would also reduce the cost of maintenance.

Conclusions Concerning the Optimization of the Original Failure Database Using a Diesel Engine Simulator
One of the most important results derived from this work was the obtaining of an optimized failure database.
The failure simulation in the model allowed us to correct some symptoms associated with the failures in the original failure database, as well as to know what additional parameters would have to be monitored and included as symptoms in the database to obtain the best possible diagnosis ability.
A comparative evaluation between the two databases was obtained using a double evaluation: first, by inserting failures in the model and feeding the databases with the symptoms provided by the model, and second, by using data monitored from a vessel engine with a real known failure that was verified by the maintenance service.
The optimized failure database unequivocally identified failures and worked much better than the original failure database.
All failures were detected, except for the two valve clearance failures because the alterations in engine behavior were less than 3%, and therefore had not been included as symptoms in the improved database.
To take advantage of the full capacity of the new database, it is necessary to add new instrumentation not available in the actual installation. Due to the cost and difficulty of measuring the pressure inside the cylinder and the air mass flow, they can be replaced by measurements calculated in real time.
The IMEP may be calculated using the torque, engine speed, and the mass flow via the inlet air manifold temperature and pressure measurements. The greater the number of signals available among those listed above, the greater the diagnostic capability provided by the optimized failure database that is leveraged.
Another great advantage of the proposed diagnosis system is the avoidance of installing expensive real-time monitoring systems based on incorporating new pressure instrumentation inside the cylinder, such as accelerometers, which are an important barrier for ship-owners.
The proposed system takes advantage of all the variables that are usually monitored in marine engines and adds only a few signals that are easy to install, allowing for a great diagnostic capacity without having to make a great investment.
With the incorporation of direct real-time measurements of cylinder pressure, vibration, and others that can be made at an affordable cost, the proposed system will be able to be updated to take into account new indicators and cover even more failure modes.
This methodology offers an important reduction of the energy and time losses dedicated to maintenance tasks, and at the same time, it is possible to reduce the energy consumption of the engine through monitoring and modelling to improve the performance of the engine working in different situations. Acknowledgments: This work has been done thanks to Navantia and the cooperation of Universidad Politécnica de Cartagena, where authors have developed this methodology for the construction of the asset failure database.

Conflicts of Interest:
The authors declare no conflict of interest.

GENSET
Generator

F1
Excessive pressure drop in the air filter F2 Efficiency reduction in the air cooler F3 Excessive pressure drop in the air cooler F4 Air compressor failure F5 Air leak in the intake manifold F6 Inlet valve leakage F7 Partial misfiring F8 Cylinder compression ratio loss F9 Low clearance between the rocker arm and cylinder valves F10 High clearance between the rocker arm and cylinder valves F11 Timing failure (injection advance) F12 Timing failure (injection delay) F13 Turbine failure F14 Exhaust manifold gas leakage F15 Excessive gas pressure drop in the exhaust ducts after the turbine

S1
Engine speed S2 Electric active power S3 Fuel consumption S4 Intake manifold air pressure S5 Intake manifold air temperature S6 to S17 Outlet exhaust gas temperature in cylinders 1A to 6B S18 and S19 Inlet exhaust gas temperature in turbocharger banks A and B S20 and S21 Outlet exhaust gas temperature in turbocharger banks A and B S22 Cooling hot water pressure S23 Lubrication oil pressure S24 Chromium content in the lubrication oil S25 Copper content in the lubricaton oil S26 Iron content in the lubrication oil S27 Manganese content in the lubrication oil S28 Silicon content in the lubrication oil S29 Vanadium content of lubrication oil S30 Oil contamination by fuel S31 and S32 Cooler inlet air temperature banks A and B S33 Exhaust manifold gas pressure S34 Indicated mean effective pressure S35 and S36 Speed of turbocompressor banks A and B S37 Air mass flow

Appendix A
Appendix A shows the results obtained for the activated/deactivated symptoms from the modelled results and the results obtained after the improvements of the FMECA database for both the failures and loada tested with the model describe in this article. Appendix A1 shows the justification of activated/deactivated symptoms, while Appendix A2 shows the number and type of symptoms detected for each failure modelled with four different loads (25%, 50%, 75%, and 100%).

Appendix A1. Justification for Activation Symptoms for Optimization of the FMECA Failure Database
In this part of Appendix A, a huge important part of the data and the discussion for each symptom separately is offered as justification of improved database. Table A1 shows when the intake manifold air pressure (S4), intake manifold air temperature (S5), outlet exhaust gas temperature in cylinder 1A to 6B (S6-S17), inlet exhaust gas temperature in turbocharger (S18 and S19), and outlet exhaust gas temperature in turbocharger (S20 and S21) can be used as failure symptoms. It is shown that S4 can be a symptom of the failures F1, F3-F8, and F13-F15 when its value is lower than normal, and of the failures F2 and F12 if it is higher. Therefore, this parameter is a symptom of many failures. Its combination with other symptoms identifies the failure that occurs in each case. Similar to the previous case, the variation of S5 can be used as a symptom of F2 or F6 failures when it is higher than its normal value. It was observed that for the rest of the failures, this parameter was almost not affected. It is also shown that S6-S17 could be a symptom of the failures F4, F6, F8, and F13 when it is higher than its normal value, while it is a failure symptom of F7 if it is lower. S18 and S19 appears as a symptom of most failures. A rise is shown in this parameter for almost all failures, except the failures of F7 and F11, which show a reduction. However, it can only be used as a failure symptom in F4, F6, F8, and F13 when its variation is more than 5%. In the rest of failure modes, its variation is not high enough to consider it a symptom. As in the previous case, S20 and S21 can be used as symptom of the majority of failures. S20 and S21 rise significantly when the turbine fails F13, as expected. Moreover, they are also symptoms of F4, F6, F8, and F15 failures when they are higher than their normal value. It is noteworthy that S20 and S21 can detect an increase in the exhaust pressure after the turbine F15, while S18 and S19 are not able to detect this failure because the variation of these last parameters is less than the minimum variation of the 5% imposed to be relevant. Therefore, S20 and S21 has a higher influence as a symptom to the failures than S18 and S19 since its nominal value is considerably lower and its perceptual variation relative to the normal is higher. This has a positive effect in the sense that it is easier to detect the symptom, and negative, in the sense that small variations due to factors other than a failure can be mistaken for one, and as such, give false positives. However, by maintaining the 5% criterion, false positives should not occur.
In a similar way, Table A2 shows when other parameters not identified as symptoms in the original failure database (Table 3) can be used as failure symptoms according to the failure simulator. These new symptoms are the cooler inlet air temperature (S31-S32), exhaust manifold gas pressure (S33), indicated main effective pressure (IMEP) (S34), turbocompressor speed (S35-S36), and air mass flow (S37). It can be seen that S31 and S32 is a symptom of failures F5-F8 and F13-F15 when it is lower than its normal value, while it is a symptom of failures F4, F6, and F12 if it is higher. As S4, S31, and S32 can be indicative of a large number of thermodynamic failures, the variation of these parameters is mainly due to the effect that these failures are involved in the engine gas exchange. For example, if the turbine has a failure, the energy available for the compressor will be reduced; therefore, it compresses the intake air less, and consequently, S31 or S32 will be reduced. The response of S31 and S32 to other failures can be explained in the same way. S33 can be a failure symptom of failures F3, F4, F6-F8, and F14 when it is lower than its normal value and of the failures F13 and F15 if it is higher. Most of these failure modes are related to the engine gas exchange in the intake manifold (F3 and F6), in the exhaust manifold (F14 and F15), or the turbocompressors (F4 and F13). However, it is also related to the amount of fuel injected into the engine (F7), or the compression ratio loss in the cylinder (F8). As expected, the failure in the turbine F13 is the one that influences the most in the variation of this symptom. S34 could also be used as a failure symptom. It indicates a possible failure F6-F8 or F13 when it is lower than its normal value. In a similar way to S37, S34 falls under almost any thermodynamic failure. S35 and S36 can also be used as a failure symptom; it may indicate failures F4, F8, or F13 when it is lower than its normal value or failure F6 or F7 if it is higher. It is important to distinguish between the monitoring of the average regime of the turbocompressor, a symptom that is analyzed in this section, to the measurement of turbocompressors' instantaneous regime. The instantaneous regime measurement of the turbocompressors provides a greater chance of detecting engine failures, but their measurement is much more complicated and less reliable. Moreover, S37 could be a symptom of failures F1, F3, F4, F6-F8, F13, and F15 when it is lower than its normal value. As it can be seen, all the failures make S37 lower, except F12, because this failure is a delay in the injection timing, which usually comes with a greater energy in the exhaust gases, and therefore a higher energy in the turbocompressor. It should be noted that the effect on this symptom is important in almost all cases.

Appendix A2. Comparative Diagnosis between the Original FMECA Database and the Improved Database
In this part of Appendix A, a comparison between the detection of failures is presented for each failure. Highlights in red are used for when there is no diagnosis, in orange when the exact combination of symptoms is not fulfilled and a multiple diagnosis exists with several possible failures, and in green when the diagnosis is unmistakable because a unique combination of symptoms is fulfilled in the database. The results of each failure simulation are shown in Tables A3-A7. These tables indicate the symptoms that identify the original failure database (a) and the optimized database (b) at each operating point and the corresponding diagnosis.
To perform a better comparative evaluation, the diagnosis is offered with two different premises; first, using only parameters that the diesel engine thermodynamic model can simulate: S4-S21 and S31-S37 (see Tables A1 and A2), and second, taking into account the rest of the potential symptoms included in the databases: S1-S4 (see Table 3). These other symptoms are the same in both databases.
First, Table A3 shows the results of an excessive pressure drop simulation in filter bank A (F1). It was observed that the system only detected simulated symptoms when the engine reached full load, before this it detected nothing. At that time, the original database diagnosed six possible failures: F1-F5, F13, or F14. For its part, the optimized database unequivocally diagnosed the failure F1 that was actually occurring. In this case, the fundamental difference was the identification of the symptom of a low S37. The other symptom detected by both databases was a low S4. In the event that all the database symptoms were taken into account, including the non−simulated ones, the difference was that a problem would have been detected from the beginning, but without knowing which of the 15 failures would be the one that was occurring. This was because the symptoms of a low S2 and a high S3 would be activated according to both databases defined by experts using the RCM methodology. The symptom of a low S1 would be activated only at full load because the engine could not satisfy 100% of the power demanded. At full load, the diagnosis would be the same as the one indicated after taking into account only the simulated parameters, so nothing new was provided except for a higher diagnostic quality because there were more symptoms that identified the failure.
Second, Table A3 shows the results of the air cooler efficiency reduction (F2). It was observed that the system began to detect the simulated symptoms at a 75% load. At that time, both failure databases offered two options as a diagnosis, F2 and another one. The other possible failure according to the original failure database was F3, while the optimized database offered F6 as a second option. It was necessary to reach full load such that the optimized failure database unequivocally diagnosed the actual failure that was occurring, which was F2. If all the database symptoms were considered, including the non−simulated ones, both databases diagnosed the failure F2 unequivocally from the first moment. This was because although the symptoms of a low S1 and S2, and a high S3 occurred in the 15 failures, the symptom of a low S22 is only produced in F2.
Finally, Table A3 shows the results of an air cooler excessive pressure drop simulation (F3). It can be seen that the system detected symptoms from the beginning when the engine was running at low load. However, both the original database and the optimized database offered six failure mode options. At low load, both databases detected a low S4 as a symptom, while the optimized database also detected a low S33. When half the load was reached, the optimized database diagnosed the failure unequivocally as being F3 thanks to the detection of a third symptom, a low S37. To reach this diagnosis, it was necessary to monitor the parameters S33 and S37 of the engine that the original database did not consider. The results did not change if the non−simulated symptoms were added.
Moreover, the top of Table A4 shows the results of a failure simulation in air compressor bank A (F4). In this case, the system also detected symptoms from the beginning, when the engine was running at a low load. The original database diagnosed six options F1, F3-F5, F13 and F14, while the optimized database unequivocally identified the actual failure as being F4 from the beginning. Both databases detected a low S4 and high S6 and S18 as symptoms. In addition, the optimized database detected a high S20 and low S33, S35, and S37. In this case, it did not change the result of the diagnosis if non−simulated symptoms were added in both databases.
In the middle of Table A4, the results of an air leak simulation failure in the intake manifold bank A (F5) are presented. The system detected a single symptom from the beginning, a low S4. The original database diagnosed six possible failures, while the optimized database offered eleven possible failure modes. This high number of options was because this unique parameter changes under many failure modes, as shown in the comparison of both databases (Table 5). An exception occurred at the 50% load point, where the optimized database detected a new symptom, a low S31. This new symptom caused the real failure F5 to be diagnosed unequivocally.
The bottom of Table A4 shows the results of an intake valve failure simulation in cylinder 1A (F6). It can be seen that the system detected symptoms from the first moment. The original database diagnosed seven options, while the optimized database diagnosed the real failure in a unique way from the beginning. Both databases detected high S6 and S18 as symptoms. Apart from that, the optimized database detected high S20 and S31, and low S4, S33-S35, and S37. The combination of this high number of symptoms produced a unique and robust diagnosis by the optimized database. The diagnosis did not change when non−simulated symptoms were added in both databases.
At the top of Table A5, the results of a partial misfiring simulation in cylinder 1A (F7) can be seen. It was observed that the system detected symptoms from the beginning when the engine ran at a low load. The original database diagnosed three options, while the optimized database unequivocally identified the real failure as being F7 from the beginning. The two databases detected a low S6 as a symptom. In addition, the optimized database detected a high S35 and low S4, S33, S34, and S37. If all database symptoms were considered, including the non−simulated ones, both databases diagnosed the failure F7 unequivocally from the beginning. This was because although a low S1, low S2, and high S3 symptoms occurred in all failures, the symptoms of a low S23 and S30 are only produced in F7. However, it was necessary to have the results of the periodic analysis of S30 to be able to ensure the failure type F7 in the case of using only the original database. Using the optimized database, the failure could be diagnosed using only the data that is continuously monitored, which made it possible to predict the failure before it became important.
The middle of Table A5 shows the results of the low cylinder compression rate simulation in cylinder 1A (F8). The system detected symptoms from the beginning when the engine ran at a low load. The original database diagnosed 15 possible simulated thermodynamic failure modes, while the optimized database unequivocally diagnosed the actual failure as being F8. At higher load values, the original database reduced the number of possible failures it offered, but seven options remained. The two databases detected high S6 and S18 as symptoms. In addition, the optimized database detected a high S20 and low S4, S31, S33-S35, and S37. If all the database symptoms were considered, including the non−simulated ones, both databases diagnosed the failure F8 unequivocally from the beginning. This was because although the low S1, low S2, and high S3 symptoms are produced in all failures, the symptoms of a low S23 and high S24-S28 are produced only in F8. The symptoms of metal content in oil will appear and increase its value as the piston rings/cylinder liner wear increases. The symptoms of the content of metal particles in oil usually appears from an initial phase; therefore, they are expected to appear from the beginning. To dispose of them, it is necessary to carry out periodic analyses with the appropriate frequency or to have an oil monitoring system on line.
At the bottom of Table A5, the results of a simulation of a low clearance between the rocker arm and valves in cylinder 1A (F9) can be seen. The system did not detect any symptoms in any load, nor the original database, nor the optimized database. This was because although there are symptoms, they vary below the minimum level of variation set at 5% compared to the value when it works normally. If all the database symptoms were taken into account, including the non−simulated ones, the difference was that a problem was detected from the beginning but without knowing which of the 15 failures would be the one that was occurring. This was because the symptoms of low S1, low S2, and high S3 would be activated according in both databases defined by experts using the RCM methodology.
The top of Table A6 shows the results of a simulation of a high clearance between the rocker arm and valves in cylinder 1A (F10). The result was exactly the same as in the previous simulation failure F9. Therefore, the same conclusions are applicable in this case.
The middle of Table A6 shows the results of the injection timing failure simulation in cylinder 1A (injection advance) (F11). It can be seen that the system began to detect symptoms when the engine reached a 75% load. At this load, the original database still did not detect anything, while the optimized database detected the symptom of a low S4, which was enough to diagnose the actual failure F11 that was simulated because it was the only one that has this very symptom. Other failures have it, but combined with other symptoms that do not appear in this case. If all the database symptoms were considered, including the non−simulated ones, they would have been detected from the beginning that there was a problem, although not knowing which of the 15 failures would be the one that was occurring.
The bottom of Table A6 shows the results of the timing injection failure simulation in cylinder 1A (injection delay) (F12). The system began to detect symptoms when the engine reached a 50% load. When the engine rose to a 75% load, the diagnosis was not as efficient because the variation of a low S4 was lower than 5% and was no longer considered a symptom. On the other hand, the original database still did not detect anything. In general terms, the optimized database diagnosed the failure that was occurring any time the engine reached a 50% load. If all the symptoms were considered, they would have been detected that there is a failure from the beginning, although not knowing which of the 15 failures would be the one that was occurring. When the engine reached a 50% load, the diagnosis would be the same as the one indicated by considering only the simulated parameters.
The top of Table A7 shows the results of a failure simulation in turbine bank A (F13). The system detected symptoms from the first moment when the engine was at a low load. Both the original database and the optimized database offered failure F13 unequivocally. The diagnosis was maintained throughout the load range. The two databases detected a low S4 and high S6, S18, and S20 as symptoms. In addition, the optimized database detected low S31, S34, S35, and S37, and high S33 as symptoms. In this case, the diagnosis capacity was the same for the two databases, although the optimized database offered greater diagnostic reliability since it was composed of a combination of a larger number of symptoms.
The middle of Table A7 shows the results of a leakage in the exhaust manifold bank A (F14). It can be seen that the optimized database detected symptoms from the beginning, while the original database only did so at a 50% load. At a low load, the optimized database offered four possible failures as a diagnosis. When the engine reached a 50% load, it was able to uniquely diagnose the failure as being F14. For its part, the original database, which did not detect anything at low load, offered six options as a diagnosis when it reached a 50% load. The original and optimized databases detected the same symptom, a low S4; however, the optimized database also detected low S31 and S33 symptoms, whose combination produced the unmistakable diagnosis of the failure F14 at a 50% load. Considering the non−simulated symptoms with both databases did not change the result of the diagnosis made by the optimized database. Instead, the original database did detect that there was an anomaly but did not know what type of failure was occurring.
The bottom of Table A7 shows the simulation of an excessive pressure drop in the exhaust ducts (F15). It was observed that the original database did not detect anything at any time. Meanwhile, the optimized database detected symptoms from the beginning, although at low and medium load offered of two possible failures as a diagnosis; at a 75% load was when it unequivocally identified the failure as being F15. At low and medium loads, the optimized database first identified first a high S33, and later low S4 and S31, as symptoms. When it reached a high load, it also detected the symptoms of low S37 and high S20, which was when it diagnosed the failure in an unequivocal way. If all the database symptoms were considered, including the non−simulated ones, the diagnosis of the optimized database was the same. Instead, it improved the diagnosis made by original database, which went from not detecting anything identifying that there was an anomaly, but it could not distinguish the failure among the 15 possible failure modes. Table 6 shows a summary of the analysis between the original failure database and the optimized failure database.  S3 H  F1,F2,F3,F4,F5,F6,F7,F8,  F9,F10,F11,F12,F13,F14,F15  b) - S3 H  F1,F2,F3,F4,F5,F6,F7,F8,  F9,F10,F11,F12,F13,F14,F15

"-"
No diagnostics made b) Optimized database. "Fi" Several diagnostics possible SiL Symptom Si activated by low "L" level.
"Fi" A unique diagnostic made SiH Symptom Si activated by hig "H" level.
"F i " Several diagnostics possible SiL Symptom Si activated by low "L" level.
"F i " Several diagnostics possible SiL Symptom Si activated by low "L" level.

"F i "
A unique diagnostic made SiH Symptom Si activated by hig "H" level.