Choose the correct tool to model system behavior-RBDs, fault trees or Markov diagrams

A Reliabilty Block Diagram can be configured to optimize the operation of a power plant. Source: Relex Software Corp.

Reliability block diagrams (RBD), fault trees and Markov diagrams are all used to model system behavior. When selecting a modeling tool, which is the best to use?

Most reliability problems involve some type of randomness. A system that has a random nature follows a stochastic process. Both RBDs and fault trees are high-level modeling tools that graphically represent the success or failure logic of a system subject to a stochastic process. The graphical nature of these tools allows system failure and repair behaviors to be easily specified. Therefore, when possible, it is recommended that these high-level tools be used. When complex dependencies exist among various parts of the system, using a low-level Markov tool may be necessary. While specifying system behavior in a Markov tool is time-consuming and skill-

intensive, the power and flexibility

it offers is unsurpassed.

The Relex Fracas supports a closed-loop process to ensure that the operator’s modeling approach is continually improved through the use of actual test and field data. Source: Relex Software Corp.

The details

Reliability engineering deals with the failure and repair behaviors of systems and their components. In general, failure and repair times are random. Therefore, predicting exact failure and repair times in advance is impossible. However, the random nature of these times can be represented using statistical distributions. Failure and repair behaviors that follow stochastic processes are known as stochastic systems.

Stochastic processes have a number of states that describe the behavior of a set of random variables. The behavior of the stochastic process varies with respect to an index. In reliability engineering, this index generally is system time. This means that the stochastic process is used to describe the dynamics of a system with respect to time.

State space is the set of all possible states of a process, and index space is a set of all possible index values. At a particular time, or index value, a system will be in one of its possible states. In each state, a set of events can occur. The occurrence distribution of each state depends on the history of the system or all previous events and state transition times.

A Markov process is a special kind of stochastic process. In a Markov process, the future behavior of the system depends only on the current state of the system; the history of prior events is irrelevant. Systems that follow a Markov process are known as Markovian systems. A Markov chain is a Markov process in which the system has discrete state-space. RBDs, fault trees and Markov chains are used to represent Markovian systems.

Reliability engineering deals with two types of problems associated with stochastic processes:

• Finding the stochastic behavior of individual components. The goal is to determine underlying failure and repair distributions and their parameters. Reliability prediction and failure data, or Weibull analysis, are used for this purpose.

• Determining the reliability, or failure and repair, characteristics of the system using the reliability characteristics of the components and the given system failure logic. Fault trees, RBDs and Markov chains are used for this purpose.

This Fault Tree provides a powerful analytical approach to study and improve system safety. Source: Relex Software Corp.

High-level tools

In high-level modeling tools, system success and failure logic can be shown graphically as a combination of component or event successes or failures. RBDs and fault trees are high-level tools because they provide easy system behavior specification and accurate results. In general, RBDs represent system success logic, and fault trees represent system failure logic. The behavior of each component or event is independently specified.

Introduced during World War II, RBDs made it easy to specify and understand system success in terms of component successes. By the 1960s, highly developed RBDs were being used extensively to attain safety and reliability goals. However, causes for system failure are not always a result of component failure.

In 1961, W. A. Watson of Bell Telephone Laboratories developed a plan to evaluate the safety of the Minuteman Launch Control System. This plan was the forerunner of what is now known as Fault Tree analysis. It is used to model system failures caused by component failures or external events, environmental influences, human errors, and operational and maintenance errors. Today, highly developed fault trees are used to model systems that can fail in several modes and may experience unsafe situations. They also are used to model operational systems that experience unsafe situations.

In most cases, a fault tree can be converted to an RBD, and an RBD can be converted to a fault tree. If, however, a fault tree contains events other than component failures, converting it to an RBD generally is illogical. If a fault tree contains common cause failures or disjoint events, converting it to an RBD is likely to be infeasible.

Low-level tools

In low-level modeling tools, the analyst explicitly specifies all system behaviors. State transition diagrams provide a low-level method for specifying Markov chains.

The benefits of low-level Markov tools include power and flexibility. When complex dependencies exist among various parts of the system, failure and repair behaviors may only be able to be represented using a Markov tool. For example, it may be necessary to use a Markov tool to model combinations of the following scenarios:

• Standby failures

• Nonstandard common cause failures

• Induced failures and shared

load systems

• Imperfect fault coverage and switchover mechanisms

• Priorities in repairs

• Limited repair resources

• Failure sequence-dependent


Although powerful and flexible, Markov tools require advanced modeling skills. For large systems, the system specification process is time-consuming and prone to human error. Therefore, if a system can be represented using a high-level modeling tool, its use generally is recommended.

Evolutionary high-level tools

High-level tools have been enhanced over time so that they can model common scenarios that occur in reliability engineering. For example, the recent introduction of dynamics gates, or logic symbols, to fault trees allows them to model several sequence-dependent behaviors. Similarly, the addition of spare gates provide for modeling cold or warm standby components. Such enhancements to fault trees have made the use of Markov tools unnecessary for these situations. Similarly, the addition of switch failures, standby blocks and junctions to RBDs allows them to model situations that could once be handled only by Markov tools.

The enhancement of high-level modeling tools continues to be an evolutionary process. As the need to model a particular scenario becomes more common, additional capabilities often are incorporated. Some systems now support common spare pools, imperfect maintenances and limited repair resources, but including capabilities for modeling all types of scenarios in a high-level modeling tool is impossible because the tool would become too complex, causing solution quality to decrease, so the need for low-level Markov tools will remain.

High-level modeling tools avoid the explicit system specification required by low-level Markov tools. However, it is impossible to find a high-level tool that conveniently represents all kinds of stochastic processes. To choose the correct modeling tool, the manufacturer needs to be aware of the tool's current features and limitations. For some reliability problems, it may be beneficial to use RBDs for various portions, and fault trees and Markov diagrams for other portions. In such cases, the use of diagram linking to create hybrid models is highly desirable. Q

Hunter O. Shaw is vice president, Enterprise Solutions Group, Relex Software Corp. (Greensburg, PA). He can be reached at [email protected].