Reliability Phase Diagram Analysis

The term “phase diagram” is used in many disciplines with different meanings. For example, in physical chemistry, mineralogy and materials science, a phase diagram is a type of graph used to show the equilibrium conditions among the thermodynamically-distinct phases. In mathematics and physics, a phase diagram is used as a synonym for a phase space. In reliability engineering, ReliaSoft’s BlockSim 7 software introduces the term Reliability Phase Diagram (RPD) as an extension of the Reliability Block Diagram (RBD) approach to graphically describe the sequence of different operational and/or maintenance phases experienced by a system. Whereas a reliability block diagram is used to analyze the reliability of a system with a fixed configuration, a phase diagram can be used to represent and analyze a system whose reliability configuration and/or other properties change over time. In other words, during a mission the system may undergo changes in its reliability configuration (RBD), the available repair resources or the failure, maintenance and/or throughput properties of its individual components. Examples of this include:

Systems whose components exhibit different failure distributions depending on changes in the stress experienced by the system.

Systems or processes requiring different equipment to function in different stages of the operational cycle, such as start-up, normal production, shut-down, scheduled maintenance, etc.

Systems whose RBD configuration changes at different times, such as the RBD of the engine configuration on a four-engine aircraft during taxi, take-off, cruising and landing.

Systems with different types of machinery operating during day and night shifts and with different amounts of throughput during each shift.

To analyze such systems, each distinct operating condition during the mission can be represented by a phase whose properties are inherited from an RBD corresponding to that phase's reliability configuration, along with any associated resources of the system during that time. A phase diagram is then a series of such phases drawn (connected) in a sequence signifying a chronological order.

Using a case study involving the analysis of a race car, this article illustrates one potential application of RPD analysis, and the advantages over using RBDs alone for system analysis.

Analysis of a Race Car
Consider a race car that competes in 200-mile races. Assume that the main components of the race car are 1) the engine, 2) the transmission, 3) the front and rear suspensions and 4) the brakes. All of these components can be considered to be in a reliability-wise series configuration and are correctively replaced upon failure. After each race, the brakes are preventively replaced while the other components remain on the car for the next race. If any one of the front or rear brakes fails during the race, all other brakes on the car are also preventively replaced. For this example, suppose that the performance of the race car needs to be analyzed for ten consecutive races using the component failure and repair properties given in Table 1. All corrective and preventive maintenance actions are assigned durations of 0.0 miles. This is done because the analysis of the race car is carried out in units of miles. Since no miles are accumulated while maintenance is performed on any of the components of the race car, these actions can be considered as instantaneous for the purposes of the analysis.

Reliability Block Diagram Approach
The easiest approach to analyze the performance of the race car for the above scenario is to construct an RBD of the race car using the component properties given in Table 1. Failure and repair properties of each of the components are entered into the block properties window of the block representing each respective component. As shown in Figure 1, subdiagrams may be used to provide better visualization of the system's reliability configuration. Preventive maintenance actions for the brakes that are scheduled to occur every 200 miles are accounted for using the Preventive Maintenance Policy window in BlockSim (also shown in Figure 1). The “Upon Maintenance of another Group Item” option is selected and a common group number is assigned to all brake components in order to model the preventive replacement on all other brakes that occurs upon the failure of any one of the brakes.

A simulation is then run on the reliability block diagram with an end time setting of 2,000 miles to perform the required analysis for ten consecutive races. The next section discusses a few of the results obtained by running 1,000 simulations.

Figure 1: Race Car RBDs and Preventive Maintenance Policy for Brakes

Table 1: Component Failure and Repair Properties for the Race Car Components

RBD Simulation Results
Figures 2 and 3 present a sample of the simulation results generated by BlockSim. It is clear from the results displayed in these figures that the RBD simulation is useful in providing detailed information regarding system performance by answering questions such as: How many spare parts would be needed for the ten races? Which component causes the most failures of the race car? What is the expected cost of maintenance for each component for the ten races? Other advantages of this approach include the ability to:

Perform criticality and sensitivity analysis.
Identify weak components in the system.
Perform optimization and reliability allocation.
Obtain the expected number of failures, cost and other values at the component level as well as at the system level.

System Overview Results
Figure 2: RBD Simulation Results - System Overview
(Values marked with * are displayed as 0 because of zero duration)

Figure 3: RBD Simulation Results - Block Summary

Despite the wealth of information obtained from the RBD analysis, a few issues can easily be seen to exist within the results of the RBD simulation. For example, in Figure 2, the Mean Availability of the race car for the ten races is shown to be 1 or 100%. This implies that the race car is available for the entire duration of the period of its ten-race mission. In other words, if the race car were to be checked for mission readiness at any point in time (i.e. at any mile value) throughout its mission, it would be found to be 100% operational always. This, of course, is not the case as from Figure 2 it can also be seen that the expected number of failures of the race car for the period of the ten races is 5.104. Thus, on average five failures can be expected for the ten-race mission of the race car.

It can also be observed from Figure 3 that the uptime for all components of the race car is estimated to be 2,000 miles, again implying that no miles are lost due to the failure and repair of any of the components and that the race car is always able to successfully complete all ten races. A look at the Expected NOF (Expected Number of Failures) column, however, makes it clear that components do fail during the mission.

The two seemingly incorrect results mentioned above are consequences of the underlying assumption included in this RBD analysis. Specifically, and as mentioned previously, it is assumed that repair actions on all components of the race car are instantaneous since no miles can be accumulated by the race car while a component is being repaired. Although this is a reasonable assumption, in RBD simulation analysis this also results in the race car being treated as a system that functions continuously without any repair downtime since all component failures are instantly fixed. Thus the race car is shown to have an availability of 100% and all components are shown to accumulate 2,000 miles of age for the ten-race mission. Another implication of this assumption is that the race car accumulates 2,000 miles during the simulation while in reality any system failure would mean that the race car is unable to complete the race and would therefore run for fewer than 200 miles per race whenever a system failure occurs. This further implies that the value of 5.104 obtained for the expected number of failures may not be realistic since it is based on the race car completing all 2,000 miles with no mileage lost due to failure.

Reliability Phase Diagram Analysis - A Better Approach
A better approach to the race car analysis would take into account the fact that when a critical failure occurs during a race (e.g. engine failure, transmission failure, etc.) the race car will drop out of that race and be sent for repairs. No miles are accumulated on the race car during these repairs. However miles lost because of missing the remaining race have to be accounted for. The race car can begin the next race after all failures of the previous race have been fixed.

This approach can be modeled easily in BlockSim 7 using reliability phase diagrams. In BlockSim’s RPDs, two types of phases are used: operational phases and maintenance phases. An operational phase is used to represent any stage of the system's mission that is not exclusively dedicated to the execution of maintenance tasks. Operational phases are always defined by (and linked to) an RBD. Each operational phase has a fixed, pre-defined time duration.

A maintenance phase represents the portion of a system's mission time where the system is down and maintenance actions are performed on some or all of its components. For ease of representation within the software, a maintenance phase is defined by (and linked to) a maintenance template. This template can be thought of as a list, or a collection, of the specific components (blocks) that are designated to undergo inspection, repair or replacement actions during the maintenance phase, along with their maintenance priority order. Given that all aspects of maintenance can be probabilistically defined, the duration of a maintenance phase, unlike an operational phase, is not fixed and the phase lasts as long as it takes to complete all actions specified in the maintenance template.

To model the race car analysis using reliability phase diagrams in BlockSim, an operational phase is used to represent each of the 200-mile races. The race car RBD of Figure 1 can be linked to this phase. However, no maintenance properties are defined for any of the components in this phase as it is not possible to fix failures during a race. Instead, a maintenance phase follows the operational phase and represents the period of time spent in corrective or preventive maintenance of the race car. As shown in Figure 4, the “Continue simulation” option is selected for the “On System Failure” property of the operational phase. This ensures that miles lost when the race car drops out of a race because of a system failure get recorded as downtime by the simulation. Figure 4 also shows the maintenance template linked to the maintenance phase and the preventive maintenance (PM) policy used for the RPD analysis. The PM policy applies to the brake blocks only. The policy models scheduled replacement of all brakes after each race (using the “Upon Start of a Maintenance Phase” option) and also takes into account the scenario when failure of one brake during a race leads to replacement of the other three brakes (using the “Upon Maintenance of another Group Item” option). CM and PM durations of 0.0 miles are used in the maintenance phase without affecting the duration of the race phase.

An RPD simulation with an end time of 2,000 miles can now be run on the resulting phase diagram to analyze the ten-race mission of the race car. Figures 5, 6 and 7 show results obtained by running 1,000 simulations.

Figure 4: RPD Analysis - Operational Phase Properties, Maintenance
Template and Preventive Maintenance Policy for Brakes

RPD Simulation Results
The RPD simulation results shown in Figure 5 can be compared to the results obtained from the RBD simulation shown in Figure 2. The following differences can be noted: [Click here to see the results side-by-side]

In the phase diagram simulation (Figure 5), the Mean Availability for the race car is estimated to be 80.33%, implying that the race car is available only about 80% of the 2,000 miles that are to be covered during the ten races. This availability value is much more meaningful than the value of 100% obtained from the RBD simulation (Figure 2).
In the phase diagram simulation, the expected number of failures is estimated to be 3.835 (Figure 5). This value is less than the value of 5.104 obtained in the RBD simulation (Figure 2). The higher value obtained from the RBD simulation results from the fact that miles are counted even for the races where the car fails and drops out of the race (as failures are assumed to be repaired
instantaneously). Thus the race car in the RBD simulation actually runs for a longer distance than the ten-race mission although the simulation end time is the same for both the RBD and RPD simulations. This leads to a higher number of failures being recorded in the RBD simulation. Consequently the value of the expected number of failures reported in the RPD simulation is more accurate.
In the phase diagram simulation, the uptime is estimated to be 1,606.5343 (Figure 5). This is the mileage accumulated by the race car during the ten races. The value of 2,000 for this metric shown in Figure 2 may be misleading due to the fact that miles lost because of the failure of the race car are not taken into account in the RBD simulation.
The total downtime shown in Figure 5, 393.4657, represents the total miles lost by the race car for the ten-race mission when the car drops out of races due to a system failure. This information is not provided by the RBD simulation.
The total cost metric in Figure 5 is $858,341.30. This represents the maintenance cost of the race car for the ten races. This value is less than the value of $1,167,570.00 shown in Figure 2 because the phase diagram simulation estimates a smaller expected number of failures, as explained previously.

RPD Simulation Results - System Overview
Figure 5: RPD Simulation Results - System Overview
(Values marked with * are displayed as 0 because of zero duration)

Figure 6: RPD Simulation Results - Block Summary

Figure 6 shows the results obtained from the RPD simulation at the block level. These results can
also be displayed for the individual phases and they facilitate detailed analysis of how each block (component) affects the system's mission. For example, the Block Downtime column displays
how many race-miles were lost by the race car due to failure of each individual block. A number of other results, such as the mean availability, expected number of failures, maintenance downtimes and
costs are also available in BlockSim 7 in the form of tables and plots.

Phases Summary Results
Figure 7: RPD Simulation Results - Phases Summary

Figure 7 shows results for each phase at each cycle. Availability and other results during any of
the ten races can be obtained from the spreadsheet shown in this figure. For example, availability at the
end of the third race (shown as EPPA or End of Phase Point Availability) is estimated to be 69%.

There are many other potential applications for the phase diagram analysis capability described here. This includes the ability to model:

Different failure and repair distributions for the blocks for each phase of the mission.

For example, the compressor of an automobile air conditioning unit may have a different failure distribution during peak summer days.

Changes in the reliability configuration of the system across different phases of operation.

For example, the landing gear of an aircraft may not be included in the system RBD representing the cruising phase of the mission.

Changes in stress on the system or intermittent usage (by using the Phase Duty Cycle option).

For example, all components in an aircraft may experience increased stress during take-off.

Logic to skip phases depending on the consequences of system failure.

For example, a system failure may require that the system be sent directly to the maintenance phase upon failure and skip the other phases that it would have experienced if the failure had not occurred.

Repeated executions (cycling) of a phase diagram.

For example, in the present race car RPD analysis, the phase diagram was executed ten
times to model aging of components from the first race to the last race.

A flexible-duration maintenance phase to represent maintenance actions on the system's components.

For example, depending on the availability of necessary resources (such as repair crews and spare parts), maintenance actions may have different completion durations at different times.

Priorities in a maintenance phase to model shared resources.

For example, if five components require the same repair crew then the crew needs to follow a priority order in the case where two or more components are in a failed state during the same period.

System Age Threshold to advance the occurrence of maintenance tasks and reduce maintenance costs by incorporating scheduled maintenance actions into a maintenance phase.

For example, the 3,000-mile oil change (preventive maintenance) on a car may be included in the 60,000-mile service (maintenance phase) if the oil change is due at 60,300 miles.

Variable phase-dependent throughput.

For example, a production plant may have different throughput during start-up than during normal production.

As an illustration of how some of these additional modeling capabilities may be applicable to our race car example, please consider the following variation. Suppose that the race car participates in three races, where each race covers different distances and stresses the car’s components differently. This could be modeled with the RPD shown in Figure 8 where the total distance to be covered in the second race is 315 miles (specified as Phase Duration) and the stress on the components during this race is 1.5 times the stress experienced during the other 200-mile long races (specified as Phase Duty Cycle). Other possible variations could be modeled by making different selections in BlockSim’s Block Properties, Phase Properties and other settings windows.

Another application of the RPD analysis approach for race car analysis
Figure 8: Another application of the RPD analysis approach for the race car analysis

Conclusion
This article has demonstrated the advantages of using reliability phase diagram (RPD) simulation to model complex system analysis scenarios that are either inaccurately modeled or impossible to evaluate using reliability block diagram (RBD) simulation. Phase diagrams in BlockSim 7 provide flexibility that is a tremendous leap forward in the ability to simulate these complex scenarios more realistically. More information on BlockSim 7 is available on the Web at http://BlockSim.ReliaSoft.com.