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:
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 example 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.
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:
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, predefined 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.
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]
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.
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:
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.
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://www.ReliaSoft.com/blocksim.