Dynamic maintenance based on functional usage profiles

Abstract

Purpose

For many decades, it has been recognized that maintenance activities should be adapted to the specific usage of a system. For that reason, many advanced policies have been developed, such as condition-based and load-based maintenance policies. However, these policies require advanced monitoring techniques and rather detailed understanding of the failure behavior, which requires the support of an OEM or expert, prohibiting application by an operator in many cases. The present work proposes a maintenance policy that relieves the high (technical) demands set by these existing policies and provides a more accurate specification of the required (dynamic) maintenance interval than traditional usage-based maintenance.

Design/methodology/approach

The methodology followed starts with a review and critical assessment of existing maintenance policies, which are classified according to six different aspects. Based on the need for a technically less demanding policy that appears from this comparison, a new policy is developed. The consecutive steps required for this functional usage profiles based maintenance policy are then critically discussed: usage profile definition, monitoring, profile severity quantification and the possible extension to the fleet level. After the description of the proposed policy, it is demonstrated in three case studies on real systems.

Findings

A maintenance policy based on a simple usage registration procedure appears to be feasible, which enables a significantly more efficient maintenance process than the traditional usage-based policies. This is demonstrated by the policy proposed here.

Practical implications

The proposed maintenance policy based on functional usage profiles offers the operators of fleets of systems the opportunity to increase the efficiency and effectiveness of their maintenance process, without the need for a high investment in advanced monitoring systems and in experts interpreting the results.

Originality/value

The original contribution of this work is the explicit definition of a new maintenance policy, which combines the benefits of considering the effects of usage or environment severity with a limited investment in monitoring technology.

Citation

Tinga, T., Wubben, F., Tiddens, W., Wortmann, H. and Gaalman, G. (2021), "Dynamic maintenance based on functional usage profiles", Journal of Quality in Maintenance Engineering, Vol. 27 No. 1, pp. 21-42. https://doi.org/10.1108/JQME-01-2019-0002

1. Introduction

Maintaining complex assets is a challenging task. On the one hand, the number of failures must be kept to a minimum to achieve a high system availability and reduce the costs of consequential damage. On the other hand, the costs associated with the maintenance activities must be minimized. As the failure rate benefits from frequent maintenance and the costs from minimal maintenance, these two aspects are conflicting and a suitable compromise must be found. However, the compromise may be different for each application, since failure of a critical system (e.g. aircraft engine) must be prevented at any cost, while a noncritical system (e.g. television) can be maintained at minimal costs. The aircraft engine will therefore be subject to a preventive maintenance program, while the television can be repaired when it fails (i.e. corrective maintenance). It is generally accepted now that it is essential, especially for large and complex capital assets, to approach maintenance in a systematic and strategic manner (Simões et al., 2011).

1.1 Preventive maintenance

For preventive maintenance, the key issue is to determine the length of the maintenance intervals. When these intervals are too long, the system will fail and the availability will decrease, while too short intervals lead to unnecessary maintenance (also leading to a decreased availability) and high costs. Tinga (2010) has categorized the different approaches for interval determination. The two main categories differ in the moment in the system life cycle at which the intervals are determined:

1. Fixed interval, determined in design phase: traditionally, the manufacturer quantifies the interval during the design phase of the system or component, using an assumption on the future usage. This leads to a static maintenance concept in which fixed maintenance intervals are used during the complete service life of the system. For systems that are operated in a constant manner over time (i.e. a fixed operational context), such as standard production machines in a factory, this approach works well. Moreover, if larger numbers of systems are available, operational experience can rather soon be used to check or update the original equipment manufacturer (OEM) assumptions on usage and thus to optimize the maintenance intervals.

2. Variable interval, determined while the system is in use: when the usage or the operating conditions of the system considerably vary over the life cycle (i.e. a varying operational context), a fixed interval may not be the most effective and efficient strategy. In periods of severe usage, the intervals may appear to be too long, which leads to failures and system unavailability (ineffective maintenance), while in less severe operating periods, too much maintenance leads to unnecessary high costs (inefficient maintenance). In such a varying operational context, a more dynamic maintenance strategy is more suitable. By explicitly taking into account the system usage (severity), the length of the maintenance intervals can vary in time and across individual systems, which leads to a dynamic maintenance plan.

1.2 Existing approaches for dynamic maintenance

In literature, the necessity of adapting maintenance intervals to the specific usage has been stressed by many authors for decades now (Geraerds, 1972; Gits, 1992; Romero et al., 1996; Waeyenbergh and Pintelon, 2002; Dempsey et al., 2007; Gebler et al., 2018). The classical approaches (Gits, 1992) for this are (1) usage-based maintenance (UBM), where maintenance is based on a usage parameter such as months, operating hours or driven kilometers; and (2) condition-based maintenance (CBM), where the assessed condition of the system determines whether maintenance is necessary. In a UBM approach, the variation in usage is partly taken into account, but the effectiveness achieved with this method depends largely on the relevance of the usage parameter that is selected. For example, for a car tire the number of driven kilometers is a more relevant usage parameter than driving hours and much more relevant than calendar time (unless the car is not used at all and aging of the rubber finally leads to rupture of the tire). In more recent work on usage monitoring, advanced sensing systems and data analytics are adopted, for example, for the monitoring of electric current in conveyor belt motors (Gebler et al., 2018) and the clustering of power transformers into several usage profiles (Mulliez et al., 2018).

In a CBM policy, the condition of the system is assessed on a regular basis and maintenance is performed when the condition (or degradation) exceeds a predefined critical level. Many practical condition monitoring systems have been developed and applied in the past decades. Traditional techniques include vibration monitoring, oil analysis and thermography, and more recent developments include continuous pressure monitoring for compressors (Townsend and Affan Badar, 2018) and Internet of Things based monitoring of elevators (Lai et al., 2019). The success of this type of policy depends on the length of the so-called P-F interval (Moubray, 1997), the time between the detection of an imminent failure and the actual moment of failure. If this interval is very short, there is only limited time to plan a maintenance action and the policy is still very reactive. Another limitation of CBM is that suitable (and affordable) sensors have to be available and the component to be monitored must be accessible. So for both technical and economic reasons, application of CBM is not feasible for all systems.

Tinga (2010) added the two more advanced dynamic strategies, usage-severity-based and load-based maintenance (USBM and LBM), that require knowledge on the physics of failure. The usage-severity-based approach is an extension of UBM, which increases the relevance of the usage parameter. For example, one operating hour of an engine at full power is not equivalent in terms of degradation to an hour at low power. The USBM strategy incorporates this difference by applying a physical model of the component or system (Tinga, 2013a; Woldman et al., 2015). Load-based maintenance is a policy that focuses on the actual (physical) loading of components instead of the usage, which enables a more accurate assessment of the degradation rate (and associated remaining life). However, this policy can only be applied if the dominant loading of the component can be monitored with a suitable sensor (e.g. strain gauge, thermocouple). An example of this approach is the work on health monitoring of electronics based on temperature measurements (Vichare et al., 2004).

The relation between the different dynamic maintenance policies is illustrated in Figure 1 (Tinga, 2010). The top row of this scheme illustrates that the evolution of the remaining life of a system, which determines when (preventive) maintenance must be performed, is governed by the usage of the system. However, the quantitative relation between system usage and degradation is generally unknown, at least for an operator. This means that the blue “platform/system” box in reality is a “black box”. In Tinga (2010), it was shown that this “black box” can be made transparent by zooming in to the level of the physical failure mechanisms, as indicated by the blue arrow in Figure 1. This zoom-in offers the opportunity to quantify the damage accumulation in a specific component, provided that the internal loads (e.g. temperature, stress, voltage) can be derived from the usage, as is represented in the bottom row of the scheme. This requires on the one hand understanding of the physical behavior of the system (the associated usage-to-load and load-to-life time models are indicated by the numbers 1 and 2) and on the other hand monitoring of either usage, loads or condition (the green ellipses). And by doing so, the aforementioned policies UBM, LBM and CBM, respectively, can be applied to achieve a dynamic maintenance policy. It should be noted that all these policies require a certain amount of (physical) modeling and data acquisition, as will be discussed in more detail in the next section.

Yet another approach in making maintenance more dynamic is to use the principle of regime recognition. The operational usage of the system is divided into a limited number of operational conditions, which are called regimes. It is rather commonly applied in rotorcraft health and usage monitoring systems (HUMS) (Molent, 1998; Dempsey et al., 2007; Fraser, 1994), but also an application to a military ground vehicle is available (Heine and Barker, 2007). The approach relies on the (automatic) identification of operational regimes based on input from various sensors, typically vibration sensors/accelerometers and GPS. If the time spent in the various regimes is monitored, it is theoretically possible to predict the remaining life of the system, provided that the relation between a specific regime and the degradation rate can be quantified. Since the latter is not an easy task, flight regimes in rotorcraft HUMS systems are in most cases merely used to set the appropriate threshold values for the health (vibration) monitoring system. Maintenance intervals are thus not based on the distribution of the flight regimes, but still on flight hours (UBM) or vibration levels (CBM). In the military ground vehicle application (Heine and Barker, 2007), a test program provided the relation between the terrain types and the associated fatigue damage, resulting in a preliminary damage prediction model. Another application in this direction is the linking of mission types to cyclic loading of fighter aircraft (Newcamp et al., 2016).

In summary, the need for adaptation of the maintenance intervals to the system usage, thus enabling dynamic maintenance, has been recognized by many scholars and several maintenance policies have been proposed to realize that. However, the classical UBM policies are generally not very accurate, since they do not sufficiently incorporate the variation in operational usage, while the more advanced policies such as USBM, regime recognition, LBM and CBM require detailed insight in the failure behavior or sophisticated sensors and data acquisition.

In the present work, the functional usage profiles based maintenance (FUPBM) policy is proposed that constitutes a compromise between these two sides: it provides a more accurate specification of the required (dynamic) maintenance interval than UBM, but is at the same time less complex and requires less investments in sensors and data acquisition than LBM and CBM. This is achieved by firstly specifying a limited number of functional usage profiles, which define the essential variations in operational use of the system and its operating conditions, without the need to accurately understand the system degradation behavior. Secondly, this policy requires quantifying the relative degradation rate in each of the profiles. Only registering the relative occurrence of each of the usage profiles is then sufficient to estimate the length of the required maintenance interval. This means that the deployment of advanced sensors is not needed.

This paper is organized as follows. In the next section, the pros and cons of the various maintenance policies will be compared, and the benefit of the proposed new policy will be indicated. In Section 3, the details of the proposed policy are presented, and in Section 4, it will be demonstrated using three different case studies. Section 5 discusses the results and the validation of the proposed method. Finally, Section 6 forwards the conclusions of this work.

2. Comparison of maintenance policies

Since the range of available maintenance policies is quite extensive, it is important to consider the strengths and weaknesses of different policies. In this section, the policies introduced before will be compared on several aspects, and it will be indicated for which kind of system each policy is most suitable. Moreover, this comparison will demonstrate the added value of the policy proposed in the next section.

Figure 2 shows five different policies and compares them on six different aspects. The condition-based (CBM), load-based (LBM), usage-severity-based (USBM) and usage-based maintenance (UBM) policies were introduced in the previous section, as well as the regime recognition approach. The policy proposed in this work, the functional usage profiles based (FUPBM) policy, was also introduced briefly (and will be described in more detail in the next section). Note that the regime recognition approach is quite similar to the proposed functional usage profiles policy, since the operational usage of the system is also divided into a limited number of operational conditions, which are called regimes. The major difference between the regime recognition approach and the proposed functional usage profiles policy is the way in which the usage profiles or regimes are defined. For the regime recognition methods, sensors are deployed to collect data on system loading (or the vibration response to the loading), and the regimes are based on analyzing the sensor data. In the policy proposed here, the usage profiles are defined purely in functional terms, so no sensors are required and no direct reference to the system loading is made. The advantage and consequences of this approach are discussed next.

The five policies in Figure 2 are ranked in a global way, ranging from UBM at the lower end to CBM at the upper end of the spectrum. Then for each of the six aspects addressed here, the individual policies are compared by scaling them from left to right on a qualitative scale. The labels on the left-hand and right-hand side axes indicate which aspect is compared and what the extremes are for this comparison. The six aspects will now be introduced and discussed separately.

1. Component/system level: this aspect considers whether the policy is applied on the system or component level. For an operator, the relevant question is whether the system is available. However, failure of the system is caused by failure of one of the subsystems or components. Therefore, assessment or prediction of the system condition, as is done by the CBM and LBM/USBM policies, requires to focus on one or several components. The challenge in that case is to make sure that the appropriate components are monitored, that is, those that are responsible for the system availability. If the wrong components are monitored, failure of those components can be predicted, but failure of the complete system most probably not. The usage-based policies are generally less detailed and therefore focus on the availability of the complete system, by monitoring one or a limited number of usage parameters.

2. Individual system/fleet: this aspect addresses the question whether the policies are used to optimize the maintenance of an individual system or can also be applied to optimize the maintenance process for a fleet of assets. Due to the focus on the component level, and the associated detailed physical level of loads and failure mechanisms, CBM and LBM policies are excellent in predicting failure for individual systems. Based on the monitored condition or predicted amount of degradation, the optimal moment for preventive maintenance can be determined. However, generalizing this information to the fleet level is generally impossible, since an operator will not be able to specify the evolution of the component condition or loading for the intended future operation of the fleet. The same argument holds for the regime recognition approach, since also in that case the decisions are based on a monitored quantity that cannot easily be estimated by an operator. However, for the usage-based policies, extension to the fleet level is rather straightforward, since the relation between functional usage (system operating hours, kilometers, preferably at certain conditions) and system degradation is available. By defining a future usage program for the whole fleet, the expected failure times and required maintenance activities can quickly be assessed.

3. Monitoring effort: another way to distinguish between the detailed policies focusing on the component level and the more system-level approaches is shown in Figure 3. The CBM and LBM/USBM can be denoted to represent the technical approach, requiring detailed monitoring of loads or usage severity of specific components and detailed understanding of the physical failure mechanisms. The relation between the system-level availability and the system usage relies on a functional breakdown into subsystems and components. After the service life consumption of all (or only the critical) components has been obtained, all individual contributions must be integrated into the system service life or availability. Contrary to this approach is the functional approach, in which the functional usage of the system is directly related to the system life consumption, without the zoom-in to the component level. This approach is typically much less demanding with regard to monitoring. The proposed functional usage profile based policy and the traditional UBM policy are representatives of this latter approach.

• (4)Costs and potential: these two aspects are closely related. CBM requires detailed monitoring by dedicated sensors and extensive data acquisition. If suitable sensors are not available, they might have to be developed, which also holds for the analysis methods. It is obvious that the costs associated to applying this policy are relatively high. However, at the same time the potential gain in maintenance performance (effectiveness and efficiency) is quite large, since the accurate insight in the component condition enables just-in-time maintenance. As is stated by several authors (Heine and Barker, 2007; Molent, 1998), application of such an advanced policy is only useful for complex and critical systems. For inexpensive/noncritical systems, the costs of developing and operating sophisticated monitoring systems do not outweigh the benefits. By going down the list of policies in Figure 2, the efforts in terms of sensing and monitoring gradually decrease, which also reduces the costs, but at the same time limits the potential gain in maintenance performance when that policy is applied.

• (5)OEM/operator development: this final aspect is important with regard to the policy proposed in this work. For many of the more advanced maintenance policies, the operator is dependent on the OEM. Since the operator generally lacks the detailed technical knowledge on the system, developing a CBM or LBM system is not a feasible option. In case an operator wants to optimize his maintenance process on the system, the only option is to obtain the CBM system from the OEM, or hire an external company or consultant to develop or build such a system. The big advantage of the policy proposed here is that the operator will be able to set up the policy himself. Since the usage profiles are defined in functional terms, no detailed insight in the technical system behavior is required. As will be shown in the next section, the only requirement is a certain amount of operational experience with the system, either quantified in terms of usage and failure data or in a qualitative sense in the minds of company experts. Therefore, application of the proposed policy can be done independent from the OEM.

The comparison of the five maintenance policies in Figure 2 yields the following insights. The more advanced policies, CBM and LBM, have a strong focus on component level and individual systems, therefore have a large potential, but are also associated with high development costs and require high involvement of the OEM or dedicated researchers. On the other end of the spectrum is the usage-based policy, which requires much less investments and OEM involvement, has a focus on the system level and the whole fleet, but only has limited potential in improving the maintenance process.

Regarding the proposed functional usage profile based policy, the claimed benefits are (1) the simplicity of the monitoring (only specifying one of the functional usage profiles); (2) the limited costs; (3) the possibility to optimize the maintenance on a fleet level; and (4) the independence of the OEM or technical specialist. Note that many of these advantages also hold for the traditional UBM policy, but it will be shown in the next section that the addition of usage profiles and operational conditions considerably improves the performance of the maintenance policy.

3. Functional usage profile based maintenance

The key premise of the proposed policy is the definition of a limited number of functional usage profiles that can be used to assess the effect of that usage on the system degradation. The benefits of this approach can only be achieved when three criteria are met: (1) the usage profiles are defined in a concise and unambiguous way; (2) the relative occurrence of each of the profiles during a certain operational period is registered correctly; (3) the relative severity of each of the profiles with respect to the system degradation can be quantified at a sufficiently accurate level. In this section, the three criteria will be discussed, starting with the monitoring procedure and the definition of the usage profiles. After that, the methods to quantify the relative severity of a profile will be treated. Finally, once the criteria are clear, the extension of the approach from individual system to the fleet level will be discussed.

3.1 Monitoring procedure

As was mentioned earlier, the proposed policy requires a proper monitoring procedure, which fits the low complexity of the policy. In the more advanced policies, such as LBM and CBM, extensive sensor networks are deployed to collect the relevant data automatically. However, the FUPBM approach is typically intended for systems and organizations that are less advanced in maintenance optimization. In industry sectors such as transport, maritime and manufacturing, it is very common that even the basic usage of individual systems (i.e. driven kilometers, operating hours, fuel consumption, etc.) cannot (easily) be retrieved from databases or management systems. Typically only average values of the complete fleet are available, or individual system values with a very low sample rate (quarterly or even yearly) can be obtained. The main reason for this lack of detailed usage data is the absence of automatic data collection systems. In more critical systems, for example, aircraft and nuclear plants, this kind of data collection is already common for decades, and also in more recent systems in other industries, for example, cars or wind turbines, data acquisition systems are connected to the digital control systems. However, for many legacy systems, still no data on the usage is available. And also for the lower levels (subsystem or component) of monitored systems, this information is not available. The only way to collect this information is then to request the operators of the systems to register their activities manually. The quality and completeness of the data then depend on the one hand on the motivation of the operator to register in an accurate manner and on the other hand on the prescribed format of the registration. If the latter is too complex or extensive, it will take too much time to complete and the operator will not be motivated anymore. Moreover, in many cases the format leaves the freedom to use certain nonspecific descriptions (e.g. the category “other” or “unknown”). This will reduce the quality of the data and also the potential of the analyses performed on the data.

The conclusion is that in those cases that monitoring data can only be obtained from operator registrations, the format should be concise and should be as close as possible to the context of the system operation. That is the main reason that in the proposed policy, functional usage profiles are defined, which specify what the system is doing in what type of operational circumstances (region and climate), instead of asking for derived quantities such as loads or degradation rates. These profiles can be recognized easily by operators, thus increasing the quality of the registrations.

Note that the recent developments in data analytics can assist in automatically determining (functional) usage profiles of specific systems. Even in the absence of advanced sensors to directly monitor loads or system condition, analyzing process control signals (e.g. SCADA) can provide insight in the usage profile. Examples are the monitoring of electric current in conveyor belt motors (Gebler et al., 2018) and the clustering of power transformers into several usage profiles (Mulliez et al., 2018).

3.2 Usage profile definition

The definition of the functional usage profiles is crucial for the success of the FUPBM policy. The profiles should together cover the whole spectrum of operating conditions of the system, but should also sufficiently distinguish the different levels of severity in the system usage, thus enabling to quantify the variation in degradation rates. And finally, the functional profiles should be recognizable for the operators, to obtain monitoring data of sufficient quality.

To meet these criteria, a usage profile will be defined here as a combination of a task and an operational context, as is also indicated in the left-hand side of Figure 3. The task describes what the system is doing, for example, driving at high speed (for a vehicle) or producing product A (for a manufacturing machine). In addition, the operational context describes under what circumstances the task is fulfilled, for example, on a badly paved road (vehicle) or at high humidity and high temperature (manufacturing). Both the task and the operational context will affect the rate at which the system degrades, which is essential for the determination of the preventive maintenance intervals. The notion that the operational context is important to consider is quite common. For example, Moubray (1997) mentions that a reliability-centered maintenance analysis should always be performed for only one specific operational context. However, using a combination of task and operational context to determine the maintenance intervals in a more dynamic way has not been found in literature. In the case studies in Section 4, examples of functional usage profiles will be given.

3.3 Quantifying the usage profile severity

Finally, to be able to quantify the effect of a certain usage profile on the degradation of the system, the relative load or usage severity of that profile must be assessed. The deliberate choice for defining functional usage profiles close to the operational context has some implications. Firstly, the relation of the monitored quantity (of usage) with system degradation is less direct than in case of load monitoring (strain, temperature) or condition monitoring. And secondly, the focus is on the system level, while degradation and failure typically occur on the component level. To solve both issues, two different approaches can be followed. The first approach is based on selecting the most dominant subsystems or components and quantifying the effect of the various usage profiles on the degradation of these specific components. The second approach is based on finding relations between the availability and usage profiles directly on the system level from a set of historic usage and failure data.

3.3.1 Selection of critical components

To bridge the gap between the system and subsystem/component level, the subsystem or component that is decisive for the lifetime of a system must be assessed. Relating the degradation of that component to the defined usage profiles will yield a reliable estimate of the system reliability decrease over time. In literature, several approaches are available to select the critical component. One common method is the failure mode, effect and criticality analysis (FMECA), which is part of the RCM process (Moubray, 1997). The obtained risk priority numbers (RPN) for the various failure modes indicate the relative criticality. An extension of this approach is the degrader analysis proposed by Banks et al. (2008), which yields a list of cost drivers and performance killers for the concerned system.

Note that for a real system typically not one single component, but a series of components are critical. A certain usage of the system may cause the one component to fail first (and cause the whole system to go down), while at a slightly different usage another component may become critical. If that is the case, all these potentially critical components will have to be considered in the next step. Note that this is typically seen in electronic components (e.g. a printed circuit board), where many similar parts together determine the failure behavior of the component or subsystem. As the parts all have a slightly different failure behavior, the overall behavior is often considered to be random.

The final step in this approach is then to quantify the relation between each of the functional usage profiles and the degradation rate for the critical component(s). This can be achieved in two ways, that is, model-based and experience-based. The former approach adopts a model that describes the physical failure mechanism of the component, for example, fatigue, corrosion or wear. Whereas in the USBM or LBM policies, the detailed loads on the component are available (from measurements) and can be used as input for such a model (Tinga, 2010; Woldman et al., 2015), in the FUPBM policy, only a rough estimate of these loads can be made. The estimate is then typically based on expert judgment or standard reliability models available in literature.

The second approach in quantifying the relative severity is an experience-based approach. Without having a model of the failure mechanism, but based on historic data or experience, the failure of the critical component is directly correlated to the variations in usage profiles. Note that the historic data can either be real (failure and usage) data available from a database or (again) the experience of people that are closely involved in the operation and maintenance of the system. Although a correlation with actual historic data potentially gives the best quantitative relation, in practice some problems are encountered. While failure data is in many cases available from databases, the associated historic usage profiles are typically not retrievable. Moreover, for a component with a long service life, the variation in usage profiles during its lifetime is often quite large, which makes it difficult to find the precise correlation between failures and usage profiles. Therefore, in many practical situations the expert knowledge will form the basis of the quantification, which, if possible, will be reinforced with some data. For this approach, no specific knowledge on the loads or failure mechanisms is required, as only the direct correlations between usage and failures are sought. Again, the recent developments in artificial intelligence (AI) and data analytics, using techniques such as machine learning, can assist in deriving relations from (incomplete and heterogeneous) historic data sets, especially when these sets are relatively large.

3.3.2 System-level correlations

Instead of first selecting the critical components in a system, the relation between usage and failure can also directly be derived on the system level. As in that case it is unknown which of the subsystems causes the failure of the system, a model-based approach is not applicable. The only option is therefore to find correlations between usage profiles and failures based on historic data or experience. This approach is similar to the experience-based approach described in the previous subsection, but now applies to the whole system instead of to a specific component. In literature, one example was found where this approach was followed in a case study on agricultural vehicles (Jung and Ismail, 2011).

Choosing between the critical component selection and system-level approach depends on the availability of data and experience. The critical component approach has the advantage that the cause of system failure is better understood, and potentially a more accurate relation between usage and failure can be found, especially when a model-based approach is followed. However, this requires the availability of data or knowledge/experience on the component level, which is not always available. Moreover, this approach only works when all critical components are addressed. If one of these is overlooked, the prediction of the failure can be very inaccurate. If only limited knowledge or experience with the system is available, the system-level approach is often still feasible, although the achieved accuracy of the predictions will be lower. However, compared to sticking to the standard OEM-prescribed maintenance intervals, such an approach may still lead to considerable improvements.

3.4 Application of the policy

Once the functional usage profiles have been defined, their relative severity has been quantified and the relative occurrence is monitored in practice, the maintenance intervals can be adapted to the actual usage of the system. Starting point will be the maintenance intervals that are provided by the OEM. These intervals are based on some assumed usage profile, which is then considered to be the reference usage profile. For example, a typical car is prescribed to have a periodic check after either 15,000 km or one year. This is based on an average usage profile, for example, driving on paved roads in a moderate climate, making trips of 20 km.

Now the functional usage profiles could be different than this reference usage, which also means that the maintenance need might be higher or lower than in the OEM-prescribed schedule. For example, the functional usage profiles of a specific car could be “driving on unpaved road” or “making trips of only 2 km.” The first profile will largely reduce the service life of the shock absorbers (e.g. by a factor 3), while the second profile will affect the service life of the starter engine or brakes. If these two components are not driving the maintenance schedule, the change will have no effect on the intervals. However, if the shock absorber is one of the critical components, for which the 15,000 km interval has been set, the new usage profile will make that maintenance is already required after one-third of the reference interval, that is, 5,000 km.

3.5 Extension to the fleet level

If all systems in the fleet are operated in a similar manner, the adaptations to the original maintenance program as derived for one specific system can of course also be applied to all other systems in a fleet.

But even if the systems are not operated in the same manner, the proposed policy can quite easily be extended to a fleet of systems. It is then only required to divide the fleet in a number of subgroups (e.g. intercontinental, regional and city hopper aircraft for an airliner) and correctly specify the possible usage profiles for each of the subgroups. A simple registration or estimation of the actual usage profile distribution for each of the subgroups is then sufficient to predict the associated degradation rates for that group.

Note that this extension to a fleet of systems is not that straightforward for LBM or CBM policies. In those policies the maintenance activities are tailored to the individual systems, based on the sensor data obtained specifically for that system. If another system in the fleet is not equipped with sensors, there is no way to apply the CBM policy, as the specific load or condition is unknown. The only exception is when the fleet is known to be operated in very similar conditions (e.g. several wind turbines at the same location). In the latter case the monitoring of only one system can be regarded to be representative for all systems in the group. This is the basic idea of the flight leader concept developed for off-shore wind farms (Obdam et al., 2009).

4. Case studies

In this section, three case studies will be conducted to demonstrate the proposed concept on real systems and show that it can be applied to a range of problems. The cases concern a military combat vehicle, a naval radar system and a helicopter.

4.1 Case 1: military combat vehicle

In the first case study, the military combat vehicle CV-90, see Figure 4, will be used as the case object. The analysis on this vehicle has been performed before (Tiddens, 2011; Tinga, 2013a, b), but is now reused and aligned with the proposed maintenance policy. For this case, the critical components approach (Section 3.3.1) will be followed, so the following steps will be taken:

1. Determine the critical (sub)systems;

2. Define the functional usage profiles for the system;

3. Quantify the relation between the usage profiles and the degradation rates;

4. Monitor the usage and optimize the maintenance intervals.

4.1.1 Selection of critical components

To determine which subsystems or components of the CV-90 are critical, the degrader analysis proposed by Banks et al. (2008) is applied. The analysis starts with assessing the top five cost drivers and availability killers. This is achieved by using both data obtained from the maintenance management system and expert opinion. The two most critical subsystems, being both a cost driver and availability killer, are the track system and the engine. For the third step, the quantification of the relation between usage and failures, also knowledge on the failure modes or mechanisms, is helpful. For the track system the major failure modes are track link wear or fracture and track pad wear. For the engine the failure modes are less clear, so this subsystem will not be considered.

4.1.2 Definition of functional usage profiles

The second step is the definition of a limited number of usage profiles that enable (1) the functional description of the system usage and (2) the specification of different severity levels of usage. As was explained in Section 3.2, a usage profile is a combination of the task and the operational context (e.g. environment). For the combat vehicle, the task and operational context have been defined in terms of 14 parameters. Note that some of the parameters are binary (yes or no), for example, water crossing and combat loaded. Other parameters such as kilometers, speed and hours are continuous parameters and some parameters have a discrete number of options. For example, the terrain surface type can be selected from: paved road, unpaved road, light terrain, medium terrain or heavy terrain. Similarly, the roughness of the terrain is either flat or hilly or mountainous. These parameters can rather easily be related to the degradation rates of different components, as will be discussed in the next step in 4.1.3.

However, as was motivated in Section 3.1, the monitoring procedure should be as simple as possible. For that reason the usage of the system should be specified in functional profiles that can easily be registered by operators of the system. The parameters introduced earlier are already too complex and extensive for that. Therefore, an additional level is defined, specifying the different mission types a CV-90 can perform, for example, “set-up of road block” or “driving in towns.” These mission types also differentiate in the type of subsystems that experience degradation. For example, thermal imaging equipment will be used intensively when setting up a road block, but could experience higher rates of degradation when encountering high levels of vibration during fast-moving patrols. Operators can easily specify which mission they performed and only have to add the amount of km and operating hours for that mission. The translation from a functional usage profile into the usage parameters introduced before can be done through a predefined relation. As an example, the translation for the mission “driving in towns” is shown in Table 1.

In this manner, the usage of the vehicle can completely be described in terms of the functional usage profiles, which each can be translated into the relevant usage parameters.

4.1.3 Quantifying relation usage profiles – degradation rates

The third step in the analysis is the most important and generally the most difficult step. The relation between the different usage profiles or usage parameters and the degradation rates of the critical systems must be quantified. The procedure will be demonstrated here for the most critical subsystem, the track pad of the combat vehicle. These pads are pieces of rubber that are placed in the steel track to reduce the noise and minimize the amount of damage caused, to both road and tracks, when driving on a paved road. The dominant failure mode for the track pads is wear. This means that especially the surface type and roughness of the terrain will have a large influence on the expected service life (see Table 1).

In this case the experience-based approach (see 3.3.1) for quantifying the relative severity is adopted. Several experts have been interviewed to assess the effect of surface types and terrain roughness on track pad wear. The results are shown in Table 2. This indicates, for example, that driving on a paved road causes the track pads to wear a factor two faster than driving on an unpaved road. Note that the assessment of the usage severity is performed here in a rather subjective manner (expert opinion). However, although the numbers given by the different experts differ (as expected), using the average values as presented in Table 2 filters out the extremes and the values are considered to be reasonably representative. This aspect will be elaborated on in the discussion in Section 5. More objective measures could be obtained by collecting failure data for a longer period or by performing wear tests with track pads at different surfaces. An example of the latter approach is the assessment of the sprocket wheel wear rate in different sand varieties using a physical model for the wear mechanism (Woldman et al., 2015).

The expert approach can also be improved when knowledge on the predefined engineering mean time to failure (MTTF), set by the OEM, is used. During the purchasing process, typically a couple of operational profiles are determined on which the OEM bases the MTTFs of the parts. By re-engineering the calculations of the OEM, using the logic presented further, improved knowledge about the usage severity can be obtained easily.

4.1.4 Monitoring usage and optimization of maintenance intervals

Finally, to apply this information in a FUPBM policy, the usage profiles of the combat vehicle must be monitored for a certain period. This yields a certain mix of the various mission types, combined with the number of kilometers and operating hours in each mission. As this mission information is confidential, only the resulting distribution of driving distance over the different combinations of surface type and terrain roughness for a specific vehicle is shown in Table 3. For this vehicle, exactly one-quarter (25%) of the kilometers is driven in medium terrain at hilly roughness. Combining the two sets of factors in Table 2 yields the relative severity numbers for all combinations of surface type and roughness, as is shown in Table 4. The number of 1.00 at the combination of unpaved road and flat roughness indicates that this situation is the reference condition, to which all other operating conditions are related.

The relative severity of the usage profile of this specific vehicle can then be assessed by combining Tables 3 and 4. Let's assume, for illustration purposes, a given nominal driving distance of 800 km. For this nominal driving distance, the equivalent distance for each combination of surface type and terrain roughness can be calculated. For example, driving on paved roads at hilly roughness represents 5% of the total driving distance, which is 40 km. Moreover, the relative severity of this usage is 2.5. Multiplication of these two numbers yields an equivalent distance of 2.5 × 40 = 100 km. This result is shown in Table 5, together with the equivalent distances for all other conditions. Summation of all 15 contributions yields a total equivalent distance of 1,292 km. This number implies that a nominal distance of 800 km at this specific usage profile causes damage to the track pads, which is equivalent to driving 1,292 km at unpaved roads and flat terrain roughness (the reference situation). The average usage severity for the usage profile monitored for this vehicle is therefore 1,292/800 = 1.62.

As the usage profile monitored for this example vehicle is a training profile, it will be executed a lot in practice. Therefore, the collected failure data on the track pads will generally be related to this usage profile. From the collected failure data, the MTTF for the pads appears to be 1,883 km. Combination of this MTTF and the calculated severity (1.62) of the “training” usage profile then enables the prediction of the MTTF for any other usage profile. For a usage profile only consisting of driving on unpaved roads at light roughness (severity = 1.0), the expected MTTF will be 1.62/1.0 × 1883 = 3,050 km. However, for a more severe usage profile, for example, severity = 2.7, the expected MTTF will be even shorter, that is, 1.62/2.7 × 1883 = 1,130 km.

4.1.5 Discussion

This case clearly demonstrates that variations in usage profiles have a significant effect on the life times of parts. Applying the OEM-provided standard MTTF would in many cases lead to premature failures (in heavy terrain), but might as well lead to unnecessary replacements. A condition-based policy could lead to more “just-in-time” maintenance, but in this case would require regular inspection (and measurement of the thickness) of the track pads. That would lead to higher costs and is therefore not efficient. The proposed FUPBM policy is then a suitable alternative: only registering the usage profiles of vehicles enables to adapt the MTTF provided by the OEM to the usage profile of a specific vehicle.

4.2 Case 2: radar system

The second case study concerns a phased array radar system on a navy ship. Such a radar system contains a large number of electronic subsystems and components, and most of them are critical to the system performance. Also for this case, the critical components approach (Section 3.3.1) will be followed.

4.2.1 Selection of critical components

The criticality of the radar components is again determined by the cost drivers and performance killers. As almost all components directly affect the functionality of the complete radar system, the performance is directly related to the component failure rates. And since in this case (i.e. military application) availability is much more important than costs, the critical component selection will be fully based on number of failures per time unit. This is obtained by multiplying the failure rate of a specific component by the number of those components present in the system.

Two sources are available for the failure rates of the parts: the theoretical values calculated by the OEM during the design and the observed failure rates as obtained by the operator during a certain service period. These two values differ considerably, which may be a good motivation to include the variation in usage in the life predictions, as will be discussed in 4.2.4. However, the ranking of the various parts in the two sources is quite similar, so determining which parts are critical is rather easy.

The printed circuit boards (PCBs) of the so-called column assemblies (CAs) appear to have one of the highest failure rates and they fail rather unexpectedly. These components are shown in Figure 5 and appear to be the suitable candidate for the present analysis.

4.2.2 Definition of functional usage profiles

The functional usage of a navy ship and all of its subsystems can be defined in terms of mission types. Examples are “in harbor,” “mission in polar conditions” and “training.” Further, each mission contains a number of mission phases, which indicate what type of activity is executed. Examples of mission phases are “transit,” “surveillance” and “anti-submarine” (Tinga and Janssen, 2013). In that way it is quite easy for the crew or a ship manager to register what the usage profile of an individual ship has been in a certain period of time. That usage profile is then also applicable to the subsystems such as the radar system.

4.2.3 Quantifying relation usage profiles – degradation rates

The usage profiles, that is, the mission types and phases, must now be related to the degradation rates of the CAs in the radar. In this case previous work (Politis, 2015; Tinga et al., 2017) based on generic reliability models for electronics is used instead of expert judgment.

For the PCBs in the CAs, two factors are affecting the failure rates: vibration level and thermal cycles. The vibrations are caused by other systems inside the ship, such as diesel engines and pumps, or by wind or waves. The thermal cycles are due to the switching behavior and operating modes of the PCBs. When they are switched on, the electric current heats the components. The magnitude of the temperature increase is governed by the power setting (high, low or fluctuating power) and duration, while the number of cycles depends on the number of on–offs. Note that vibration and thermal cycling are not specific for the CAs, but are generally governing the life time of any electronic component. So although a specific component has been selected here, the loads can still be considered to be on the (sub)system level rather than the component level.

These loads then have to be related to the functional usage profiles as defined in 4.2.2. This is achieved by measuring the vibration levels on the CA during various mission phases (see 3rd photograph in Figure 5). The temperature changes in the PCB are assessed with a thermal camera for several realistic operating modes in a test setup used during maintenance. Based on expert judgment, the number of on–offs in each mission phase and the distribution of time over the three operating modes are estimated.

Finally, the Manson–Coffin model for thermal cycling (Nist/Sematech, 2012) and the Steinberg model for vibration fatigue (Steinberg, 2000) are used to relate the measured vibration and temperature change values to the life time of the PCBs. As the lifetime of the PCBs appears to be completely dominated by the thermal cycles, and vibrations do not lead to PCB failure within the service life of the radar system, the latter will be neglected. The Manson–Coffin model has been applied and tuned to the PCB of the CA. The damage rates for the nine mission types are presented in Table 6. It can be observed that the missions in hotter environments have the higher damage rates.

4.2.4 Monitoring usage and optimization of maintenance intervals

As many CAs are present in the radar, failure of one CA does not directly lead to a nonfunctioning radar, but a graceful degradation process takes place. Moreover, CAs can be replaced rather easily, without long downtimes of the radar. This means that the components are not preventively replaced, but only after a certain number of CAs have failed. Therefore, an accurate prediction of the time to failure (MTTF) is not essential for the preventive maintenance. However, spare CAs must be available on-board at the moment that a replacement is necessary, so it is essential to assess the required number of spare CAs for a specific mission in advance. This will be possible with the proposed FUPBM policy.

The OEM estimated the MTTF of the CA to be 2,500 days, but the operator observed a much lower MTTF of 1,894 days. The OEM estimate (using theoretical statistical models) is based on standard conditions that appear to be representative for the situation where the ship is in harbor (mission type 1). The life assessment model has been tuned to provide an MTTF of 2,500 days in these conditions. Then a scenario with all nine mission types with representative relative durations is simulated. The resulting MTTF of the PCB in the CA is then 2,419 days, so the overall average mission severity is apparently slightly higher than the reference condition (harbor). Another scenario, assuming that only the most severe mission (type 8) is executed in a certain period of time, leads to an MTTF of 1,953 days. This clearly shows that the variation in operating conditions and environment significantly affects the degradation rate of the CA. Moreover, by considering a specific usage profile, and including its effects on part degradation, the calculated MTTF can be much closer to the MTTF of 1,894 days that is observed in practice.

4.2.5 Discussion

This case study again demonstrates that including usage variations in life predictions is essential. The regular usage-based policy (and associated MTTF) proposed by the OEM appears to be ineffective. CBM could in this case lead to better maintenance performance. However, the actual condition of electronics cannot easily be determined, so accurate load monitoring would be necessary to predict the time to failure of individual parts. This would require continuous monitoring of vibration levels and temperature cycles in each individual radar system (or maybe even in every CA), which would lead to very high costs. Application of the FUPBM policy as discussed here only requires a one-time generic measurement campaign on one radar system to relate vibration levels and thermal cycling to the various mission phases. After that, only registration of functional profiles (mission types) is required, which then enables to calculate the degradation rates for all radar systems in a fleet. This provides MTTF predictions, which are much more specific than the generic OEM estimates. Also the models used to relate the thermal cycles to life time do not need to be developed, as these are readily available in reliability handbooks.

4.3 Case 3: helicopter

The final case study concerns the NH-90 tactical and transport helicopter. This helicopter is operated by the Royal Netherlands Navy, which implies that it is often operated in a maritime environment. For this case, the system-level approach (Section 3.3.2) will be followed.

4.3.1 Definition of functional usage profiles

Upon operating the helicopter in a maritime (saline) environment, many corrosion problems have been encountered on the system, which was not fully foreseen during the design of the helicopter. It also appears that helicopters operated from a ship are more susceptible to corrosion than the on-shore operated helicopters within the fleet. The standard maintenance procedure is to inspect the helicopter after four years if any saline condition has been encountered in that period. However, several failures occurred far before the four-year interval, so the purpose of this case study is to include the effect of saline flight hours in the maintenance/inspection interval assessment. This means that the functional usage profiles are rather simple and are fully based on the relative amount of saline flight hours (FH):

1. Profile 1: no saline flight hours;

2. Profile 2: 0–25% of flight hours in saline conditions;

3. Profile 3: 25–50% of flight hours in saline conditions.

4.3.2 Quantifying relation usage profiles – degradation rates

To quantify the effect of saline flight hours on degradation (corrosion) rates of the helicopter, one specific failure is taken as example. To enable storing the helicopter in the limited space on-board a naval ship, it contains a rotor blade folding system, which is driven by the main rotor sleeve locking actuator (MRSLA). A safety device inside the locking actuator is activated during the helicopter's operation to prevent that the MRSLA is activated during flight. However, corrosion of this device makes that the two flyweights inside are not retracted to their original position after engine shutdown, the safety switch stays active and folding the blades becomes impossible.

A corrosion model for a representative steel alloy has been used to determine corrosion rates for the MRSLA safety device (Heerink, 2012; Heerink et al., 2012). This enabled to calculate the number of flight hours in saline conditions leading to the observed failure, which appeared to be 55–60 FHs. The calculation was validated with nine occurrences of the failure on four different helicopters, for which the number of saline FHs was known. For helicopters not flying in saline conditions, the failure was not observed in practice, and the associated MTTF is assumed to exceed the regular four-year inspection interval (∼1,000 FHs).

4.3.3 Monitoring usage and optimization of maintenance intervals

As the effect of saline flight hours on the corrosion problems of the helicopter has been quantified, the application of the FUPBM policy in this case is as follows:

1. Register for each helicopter in the fleet the (relative) number of saline flight hours;

2. Based on that number, select the appropriate inspection interval by:

   • Profile 1 (no saline FHs): no need to deviate from OEM policy: inspect after four years/1000 FH;

   • Profile 2 (0–25% saline FH): inspect after 220 FH (limit of 55 saline FHs = 25% × 220 FH);

   • Profile 3 (25–50% saline FH): inspect after 110 FH.

By applying this policy based on a simple registration of the saline flight hours, corrosion-related failures can be prevented in the complete fleet of helicopters.

4.3.4 Benefits

Also this case demonstrates the relevance of including variations in usage profiles in the maintenance interval determination. The traditional usage-based policy prescribed by the OEM, that is, inspecting after four years, proved to be ineffective. A condition-based policy, for example, inspecting the helicopter or specific corrosion-sensitive subsystems and parts on a regular basis (every flight, every week), would prevent the failures to occur. However, that would require a considerable inspection effort, leading to high costs and more downtime. Application of the proposed FUPBM policy is again an attractive compromise: with only a limited effort (registering usage profiles in terms of saline FHs), the inspection intervals can be adapted to the specific usage of each individual helicopter in the fleet. The used (corrosion) model is again available in literature, but even if no model would be available, the limiting number of saline FHs could easily be retrieved from the failure registrations.

4.4 Summary of case studies

The three case studies have illustrated how the proposed FUPBM policy can be applied in practice. The different approaches followed for the three main FUPBM steps introduced in Section 3 are summarized for the three cases in Table 7.

5. Discussion and validation

The FUPBM policy proposed in Section 3 has been applied to three different cases studies in the previous section. These cases demonstrate that the approach is generic and offers potential benefits for many applications in being an attractive compromise between standard (inaccurate) usage-based policies and more advanced (but expensive) CBM policies. However, full validation of the proposed approach, for example, by a one-to-one comparison of FUPBM with OEM provided MTTF values or with more advanced (e.g. CBM) approaches is still rather challenging.

The first reason for that is the lack of information on the OEM calculation of the MTTF. In some cases the OEM also has no information on usage profiles and just provides a generic MTTF based on assumed nominal operating conditions and environment. In other cases the OEM incorporates information on usage profiles, but does not share these analyses with the operator. In both cases a detailed comparison of the OEM value and the adapted MTTF obtained via the FUPBM policy is not possible. However, both the radar case and the helicopter case showed that the MTTF observed in practice deviates (considerably) from the initial MTTF provided by the OEM, which strongly motivates the development of a FUPBM policy.

Secondly, the proposed policy and the resulting MTTF values can only be fully validated with real data when both the failures and the usage history of a system are fully known. In that case, simulating the usage history of the system should yield a time to failure close to the observed failure. In practice, however, this information is often hard to retrieve. Whereas detailed registration of individual failures is reasonably organized in most organizations, the retrieval of the detailed usage history is often impossible, as is confirmed by the case studies. Only in the helicopter case study, both the time to failure data and the usage profiles for each of the involved systems were available. For the vehicle case the history of individual vehicles (in terms of missions, environment) could not be tracked. Also for the radar system PCBs, configuration management and system tracking was too immature to retrieve the actual historic variations in usage and environment.

Another challenge faced in this work is the key aspect of the proposed approach, namely defining the relation between usage profiles and degradation rates. The case studies demonstrated three different ways to obtain these relations: expert opinion, phenomenological models and field data. It is hard to provide guidelines for which approach is preferable. The expert opinions will be subjective to some extent, and the accuracy will heavily depend on the number of experts and their knowledge and experience. On the other hand, this method is rather quick and cheap. If a higher accuracy is required, the model-based approach would be more suitable. However, this takes a larger (development) effort and the feasibility of model validation will ultimately determine the accuracy. In the end, using field data (on failures and usage variation), potentially combined with a physical model, will always be the best approach, as most of the model/expert uncertainty will be absent. But since the number of cases where this type of information is available is rather limited, there is often no other option than adopting one of the first two approaches.

Despite these limitations with respect to validation and challenges in the definition of the proper relations, the cases do demonstrate the potential of the proposed approach. At the same time, companies should be aware that application in practice (and full validation of the approach) will only be feasible when registration of failures and tracking of usage and environment are organized properly.

6. Conclusion

For many decades it has been recognized that maintenance activities should be adapted to the specific usage of a system. In addition to the existing policies based on advanced monitoring techniques, this work has proposed a new policy. The FUPBM policy relieves the high demands set by existing policies, but still provides a more accurate specification of the required (dynamic) maintenance interval than traditional UBM. This is achieved by firstly specifying a limited number of functional usage profiles, which define the essential variations in operational use of the system and its operating conditions, and secondly quantifying the relative degradation rate in each of the profiles. Only registering the relative occurrence of each of the usage profiles is then sufficient to estimate the length of the required maintenance interval. The proposed policy has been compared to existing policies on six different aspects and has been explained in detail. After that, the proposed policy is demonstrated using three real case studies, clearly showing the benefits of the method.

Figures

Figure 1

Schematic representation of the relation between usage, loads, condition and life consumption (Tinga, 2010)

Figure 2

Comparison of maintenance policies

Figure 3

Difference between the detailed technical component-level approaches and the functional system-level approach

Figure 4

Combat vehicle CV-90 (source: Wikipedia, https://creativecommons.org/licenses/by-sa/2.5/deed.en)

Figure 5

Left: taking out a column assembly (CA) from the radar; middle: generic layout of the PCB; right: vibration sensor (in red circle) positioned on CA (Politis, 2015; Tinga et al., 2017)

Table 1

Mission parameter values for the mission “driving in towns”

Maneuverability	Idling = No	Roughness of terrain	Flat
Driving	Driving behavior = calm	Terrain surface type	Paved road
	Speed = 0–30 km/h
	Water crossing = No	Load	Combat loaded = No

Table 2

Relative severity of track pad wear for different surface types and terrain roughness

Surface type		Roughness of terrain
Paved road	2	Flat	1
Unpaved road	1	Hilly	1
Light terrain	1	Mountainous	1
Medium terrain	1.25
Heavy terrain	1.5

Table 3

Monitored distribution of driving distance over surface type and terrain roughness

Roughness	Surface type
	Paved	Unpaved	Light terrain	Medium terrain	Heavy terrain
Flat	2%	4%	2%	10%	2%
Hilly	5%	10%	5%	25%	5%
Mountainous	5%	15%	2%	6%	2%

Table 4

Relative severity of wear for different combinations of surface type and roughness

Roughness	Surface type
	Paved	Unpaved	Light terrain	Medium terrain	Heavy terrain
Flat	2.00	1.00	1.00	1.25	1.50
Hilly	2.50	1.25	1.25	1.56	1.88
Mountainous	3.00	1.50	1.50	1.88	2.25

Table 5

Effective driving distance (km) for different combinations of surface types and roughness (800 km)

Roughness	Surface type
	Paved	Unpaved	Light terrain	Medium terrain	Heavy terrain
Flat	32	32	16	100	24	204
Hilly	100	100	50	313	75	638
Mountainous	120	180	24	90	36	450
Total	252	312	90	503	135	1,292

Table 6

PCB damage rates due to thermal cycling for various mission types

Mission type	Damage rate (/day)	Relative damage rate
1. Harbor	0.000400	1.00
2. Working	0.000448	1.12
3. Exercise (normal)	0.000392	0.98
4. Exercise (cold)	0.000393	0.98
5. Antipiracy	0.000394	0.99
6. West	0.000413	1.03
7. Miniexercise	0.000399	1.00
8. Mission (hot)	0.000512	1.28
9. Mission (normal)	0.000392	0.98

Table 7

Comparison of case studies regarding approach and benefits

FUPBM steps	Case 1 – combat vehicle	Case 2 – naval radar	Case 3 – helicopter
1. Monitoring	User registration of mission types and duration	User registration of mission types/phases and duration	User registration of saline flight hours (FHs)
2. Usage profiles	High level: mission types Lower level: surface type and terrain roughness	High level: mission types Lower level: vibrations, temp. changes	High level: fraction saline FHs
3. Quantifying severities	A. Component level B. Expert Opinion	A. Component level B. Phenomenological model	A. System level B. Phenomenological model
Benefits	Maintenance of track pads can be adapted to encountered terrain	Number of required spare parts can be adapted to planned mission type	Repair/replacement of safety device MRSLA can be planned more effectively and efficiently