How can you model system reliability with reliability block diagrams?

When constructing a Reliability Block Diagram (RBD), it is crucial to avoid inadvertently portraying physical connections in place of logical ones. Consider a scenario where two gensets are physically linked in parallel, requiring both to operate simultaneously for the system to function. Despite the physical parallel connection, the RBD should illustrate them in series – if one genset fails, the system fails. This distinction ensures accurate representation of the logical dependencies, aligning the diagram with the true operational dynamics of the system.

When drawing a RBD, attention should be paid to not mistakenly represent physical connections instead of logical ones. For example, let’s imagine that two gensets are physically connected in parallel with each other and both have to be working at the same time to allow a system to operate. In this case, even though the gensets are physically conected in parallel, the RBD should represent one in series with the other (if one genset fails, the system fails).

One needs to be careful with the series/ parallel model in the block diagram. Also need to carefully choose the reliability metric. MTBF though widely used means the system has 37% reliability at the define duration of time. Say for eg, a system having a MTBF of 10years, would mean 67% of the systems may have failed at the 10th Year. A system engineer should carefully choose this metric based on application criticality. B50 or B10 are other metrics to think about.

Keep in mind that MTTF (Mean Time to Failure) is used just for non repairable itens. For repairable ones, MTBF (Mean Time Between Failures) is the parameter that should be used instead.

System reliability, the likelihood of the system functioning at a given time, hinges on the reliability of its components and their configurations. An important consideration in reliability analysis is that Mean Time to Failure (MTTF) is specifically applicable to non-repairable items. In the context of repairable components, the more appropriate parameter is Mean Time Between Failures (MTBF). This distinction is crucial for accurate assessment and modeling of the reliability characteristics, ensuring that the chosen metric aligns with the nature of the system components under consideration.

Modeling system reliability with a reliability block diagram involves breaking down the system into individual components or subsystems and representing their reliability relationships using blocks and connections. Each block represents a component, and connections between blocks indicate how they contribute to the overall system reliability. Use reliability data for each component, considering factors like failure rates and repair times. The overall reliability of the system is calculated based on the configured blocks and their reliability parameters, providing a visual representation of how the system components interact in terms of reliability.

Note that a RBD will promptly let you know what are the system’s single points of failure, which is an important information regarding element criticality. You can get this information by literally just looking at the RBD without any further analysis.

To identify critical components from Reliability Block Diagrams (RBDs), you need to perform a criticality analysis. This analysis involves assigning a criticality score or rating to each component in the RBD. The criticality score is determined by assessing the impact of component failure on the overall system function and performance. The higher the criticality score, the more critical the component is to the system's reliability. Once the criticality analysis is complete, you can prioritize maintenance and replacement activities based on the criticality ratings of the components.

A RBD is a comprehensive representation that shows the functional interdependencies between system elements and the reliability value of each element. Among other things, the RBD allows an easy identification of single points of failure (elements which their sole failure will incur in system failure). Examining a RBD gives precious insights on “weak links in the chain” that could be improved with added redundancies or by the replacement of system elements for more reliable ones.

A key element of any optimization effort is to define what factor or variable is being optimized. Reliability goals for a system may be quite different than throughput or production goals. A 10% increase in Reliability... a huge amount... might have only a negligible impact on the output of the system. Define optimize, then investigate from there.

Aspen Fidelis by AspenTech is also an excellent simulation tool. You can design your system or process, then use Monte Carlo simulations to arrive at many different system results.

The oversight of reliability requirements in system procurement is a pervasive issue, with profound implications for the system's life cycle. Neglecting reliability considerations during acquisition can result in substantial repercussions, including heightened failure consequences and escalated resource allocation for system repairs. A strategic countermeasure involves the establishment of explicit reliability requirements, meticulously validated through the lens of reliability block diagrams. This method ensures a systematic and technical approach to reliability verification, fostering resilience and minimizing the impact of uncertainties in the later stages of system utilization and support.

It is unfortunately quite common to overlook reliability requirements during system procurement, which is a huge mistake that will bring a salty price to be paid during the system’s utilization and support life cycle stages due to failure consequences and the resources that are going to be expended to repair the system. It is a good practice to establish reliability requirements and to check their attendance through reliability block diagrams.