Volume 12, Issue 1

Reliability Edge Home

New Analysis Capabilities in Synthesis Applications

With the release of Synthesis Phase I in Spring 2012, the Version 8 releases of Weibull++, ALTA, BlockSim, Xfmea and RCM++ were integrated into the groundbreaking new Synthesis Platform®. This new framework provides intelligent integration between reliability program activities and tools, while simultaneously facilitating effective information sharing and cooperation between engineering teams of any size. (Learn more at http://Synthesis.ReliaSoft.com.)

Together with Synthesis integration, the Version 8 upgrades also offer an exciting collection of powerful new analysis capabilities that many of ReliaSoft's customers and partners have been waiting for.

In the following sections, we will use simplified examples to highlight four of the most anticipated new capabilities:

We also provide a sneak peek at some of the new capabilities that will be added in the Synthesis Phase II release in 2013.

New in Weibull++ and ALTA

Solving for Design Parameters Based on Target Reliability

For many years, Weibull++ and ALTA users have been relying on the stress-strength analysis tool for situations when they need to estimate reliability by determining the probability that the strength of the component will exceed the stress expected in the operating environment.


This tool has now been extensively redesigned and expanded in Version 8, giving users the ability to:

  • Save these analyses in the project for future reference.
  • Generate a pdf plot to visualize the comparison.
  • Obtain confidence bounds on the calculated probability.

The Version 8 utility also provides two new integrated capabilities that have very useful applications for Design for Reliability (DFR) activities.

  • Target Reliability Parameter Estimator: Allows you to solve for the design parameters that would enable a component to meet the reliability goal (i.e., determine the parameters of the strength distribution that would yield the desired probability that strength will exceed stress).
  • Direct Integration with the Test Design Folio: Makes it easy to design a reliability demonstration test (e.g., a zero-failure test) to demonstrate that a component has the desired strength.

Application Example

A design group needs assistance with selecting and qualifying a steel component for a new product. Their main concern is the component's ability to withstand the tensile stresses in its intended application. The circumstances are as follows:

Reliability Target: The requirement for the component is a probability of failure of 1 in 100,000 due to tensile loads (or a reliability of 99.999%).

Stress Distribution: By estimating that the median tensile stress is 75 Mpa and the worst case load (99th percentile case) is 150 Mpa, they obtain a Weibull stress distribution with beta = 2.732021 and eta = 85.767713 Mpa.

Strength Distribution: The engineers have already tested 6 specimens and they have 10 more available for testing if the current information is not sufficient to demonstrate the reliability target. The first 6 specimens failed at the following tensile stress levels (in Mpa): 212, 236, 248, 254, 271 and 287.

If the current data set is not sufficient to demonstrate the reliability target, the engineers need to design a reliability demonstration test for the additional 10 specimens.

Perform the Stress-Strength Analysis with Available Data

The first step is to perform the stress-strength analysis for the available data to see if it is sufficient to demonstrate the reliability goal. The next picture shows the results.

Stress-Strength Analysis plot

The estimated reliability is 99.980787%, which is close to the target reliability, but not close enough.

Solve for the Necessary Strength Distribution

The next step is to use the new integrated Target Reliability Parameter Estimator to determine how strong the component needs to be in order to meet a reliability target of at least 99.999%. The next picture shows the results.

Target Reliability Parameter Estimator

Assuming that beta is similar to the value calculated from the original 6 specimens (2.732021), the utility calculates that the value of eta needs to be 356.417269 Mpa. In other words, when the engineers test the remaining 10 specimens and analyze the data, an eta of 356.42 Mpa or higher is estimated to be sufficient to use stress-strength analysis to demonstrate the target reliability.

Design a Reliability Demonstration Test

The last step is to design a reliability demonstration test for the remaining 10 specimens. The Version 8 stress-strength folio contains a new quick access icon that automatically creates a Reliability Demonstration Test (RDT) folio and populates the test plan with the tensile strength the team wants to be able to demonstrate. Because the software has automatically populated all of the inputs required for a parametric binomial test plan, the analysts simply need to specify the sample size (10), the maximum number of failures (0) and the value they want to solve for. They select to solve for the required test time because, in this case, the "time" is the tensile strength that the specimens must experience without failure.

The results are shown next. The analysis indicates that if the engineers test 10 specimens at a tensile stress of 307.990114 Mpa and there are no failures, then the desired strength to achieve the required reliability will have been demonstrated with a 90% confidence.

Test Design folio

[Editor's Note: The online version of this article corrects a small typo from the original printing. The calculated tensile stress was 307.990114 rather than 307.990113. Also note that, although the interface labels say "time," the data in this particular example is tensile stress in Mpa. So "test time per unit" means "tensile stress that each test unit must experience without failure."]

New in Xfmea and RCM++

Using FMEA to Calculate the Baseline System Reliability

Most reliability engineers have recognized the potential to make more effective use of the valuable product reliability knowledge captured in a Failure Modes and Effects Analysis (FMEA). For many years, ReliaSoft's database-driven Xfmea and RCM++ software tools have greatly improved an organization's ability to store this information in a centralized location that enables engineers to search for and extract the data they need. Now, with the transition to the Synthesis Platform in Version 8, the software provides even more opportunities to leverage the information from FMEAs.

The Failure Modes and Reliability Analysis (FMRA) is one of the most versatile new integration features. This new interface combines data from the system configuration and FMEAs in order to display all of the assemblies, components and failure modes that could have an impact on the overall system reliability in a single hierarchical tree. This provides a powerful and flexible new tool that can be used to facilitate a variety of more advanced reliability analyses.

One innovative application for the FMRA is to use the occurrence ratings from the FMEA's risk priority number (RPN) calculations to generate a preliminary baseline reliability estimate for the overall system very early in the development process. The FMRA also makes it possible to integrate new and better information as it becomes available, which enables design teams to continue to improve the reliability estimate as the design matures.

Application Example

A design group wants to start estimating the expected reliability for a new system but it is too early in the development process to have data from reliability testing. At this stage, only the following information is available:

  • Design FMEA performed by a cross-functional team.
  • Information about the reliability of some components when used in prior designs.
  • Engineering judgment and other design-stage analyses, such as DOE and physics of failure.

They decide to utilize this information and the new FMRA interface in Xfmea to build an initial reliability estimate based on the information that is currently available. They will use this baseline calculation as a starting point, and continue to improve the estimate as better data becomes available.

Defining Quantitative Values for FMEA Rating Scales

The first step is to define a quantitative value to be associated with each rating in the FMEA occurrence scale. The following figure shows the rating scale that was used by the cross-functional team when assigning occurrence ratings to calculate Risk Priority Numbers (RPNs) in the Design FMEA. As you can see, the rating scale criteria already includes quantitative values that the team used as a guide when performing the FMEA.

For example, the FMEA team used an occurrence rating of O = 6 if the probability of failure was estimated to be approximately 2 per thousand items. This equates to a quantitative value of 1/500 or .005. Likewise, a rating of O = 7 was used when the probability of failure was expected to be around 10 per thousand items, for a quantitative value of 1/100 or .01. And so on throughout the rest of the scale.

Based on these probabilities, a reliability engineer could easily build a 1-parameter exponential reliability model for each failure cause as follows:


This gives a simple failure distribution that can be assumed as a starting point for each potential failure mode until better information becomes available to model the probability more accurately.

Creating the "First Draft" FMRA

The next step is to use the failure distributions defined for the potential failure modes in order to estimate the reliabilities of the components and subsystems, and then finally to estimate the reliability of the system overall.

Assuming that any one of the failure modes defined in a component's FMEA could cause the component to fail (i.e., the failure modes are considered to be reliability-wise in series), an initial reliability estimate at any given time can be obtained by combining the cause probabilities to get the reliability of the component, and then combining the probabilities for components and assemblies until we reach the system level.


Because it is based only on the occurrence ratings obtained directly from the FMEAs and assumes a series reliability-wise configuration for all failure modes, we will call this the "first draft" FMRA. The following picture shows a highly simplified example that makes it easy to see how the calculations roll up to the failure mode, component and assembly (subsystem) level.

FMRA calculated results

Vetting and Revising the "First Draft" FMRA

The next — and most crucial — step is to evaluate the "first draft" FMRA and make the adjustments necessary to ensure it reflects the best possible estimate of the system reliability based on the information that is currently available. Some (but not all) of the recommendations for "vetting" the automatically generated FMRA include:

  • Discount or eliminate issues from the FMEAs that have no impact on reliability.
  • Incorporate other issues that impact reliability but were not considered in the FMEAs.
  • Account for "common causes" that may appear multiple times in the FMEAs but actually all represent the same failure cause.
  • Review the occurrence ratings and cross-reference them against any available data or past experience. If appropriate, coordinate with the FMEA team when assigned ratings may need further consideration.
  • Question the exponential distribution assumption (i.e., constant failure rate) and replace the automatically generated failure models with more appropriate distributions when applicable. For example, if beta is known, you can use a 1-parameter Weibull distribution coupled with the stated probability.
  • If the reliability-wise relationship between failure modes cannot be modeled with a simple series configuration, use the built-in synchronization with BlockSim (discussed in the next section) to define a more appropriate configuration (e.g., for parallel redundancy).

Once the analysis has been updated to consider all of the data and past experience currently available to improve the analysis, the FMRA will represent at least a partially data-driven starting point that can continue to be updated as the product design matures.

Synchronizing with BlockSim

If further analysis is required, the engineers have the option to transfer the FMRA to BlockSim, which automatically creates a reliability block diagram (RBD) based on the current information. The RBD can be used to calculate a variety of system reliability metrics of interest (such as BX% Life and Mean Life), and generate plots that are available in BlockSim (such as Reliability vs. Time and Static Reliability Importance).

Furthermore, if the calculated baseline reliability is lower than the required reliability, the engineer can use reliability importance measures to identify critical components or causes, add redundancy to the system by using a parallel configuration or perform reliability allocation in order to determine which components need to be improved in order to meet the target.

Allocation analysis data

The FMRAs in BlockSim and Xfmea can be synchronized so that any changes made in one tool can be reflected in the other. A case where this would be useful is if the performed FMEAs are at some point updated with additional failure modes or causes, or if the occurrence ratings for specific causes are revised. Additionally, as test data becomes available, the engineers can update the component failure distributions in the RBD in BlockSim in order to rerun the analysis and at the same time have this new information be reflected in corresponding FMEAs that include this component.

New in BlockSim

Building Fault Trees and RBDs from Data in an FMEA

Another powerful application for the direct integration between Xfmea/RCM++ and BlockSim within the Synthesis Platform is the ability to automatically build fault trees and/or reliability block diagrams (RBDs) based on data from FMEAs performed at any level in even the most complex system configuration. With the release of Version 8, there are now two automated utilities designed to facilitate this data sharing:

  • Use the Build Effect Fault Trees from Synthesis utility when you need to calculate the probability of occurrence and understand the risk associated with particular high severity effects that the organization is concerned about. Automation of this process is particularly useful when dealing with complex systems where multiple FMEAs are performed for different subsystems and components, and the same severe effect may be present in multiple locations.
  • Use Build RBDs and Fault Trees from Synthesis when you need to build a diagram to represent the entire system configuration and all of the FMEAs that have been performed. You can use these RBDs or fault trees to perform a variety of more complex system analyses, which can be used for reliability importance measures, reliability allocation, maintenance planning and more.

The following simplified example illustrates both of these potential applications.

Application Example

The picture below shows part of a turbofan engine system configuration that was built in Xfmea to manage the FMEAs performed for critical assemblies/components. Items identified with a blue "F" icon have a completed FMEA. Overall, there are more than thirty FMEAs for the system.

Part of a turbo fan engine system configuration

A cross-functional team has been assembled to evaluate the risk in the new design. As part of that effort, they want to use the data from the FMEAs to:

  • Build fault trees in BlockSim for the high severity effects of most concern in order to a) clearly depict all of the "failure paths" in the system that might lead to the particular effect and b) obtain a preliminary estimate of the probability of occurrence.
  • Build a set of RBDs (i.e., diagrams and subdiagrams) that represent the entire system configuration and all of the completed FMEAs so the team can identify the components that have the biggest impact on the system reliability and perform other system-level analyses.

Quantify Occurrence Probabilities for Failure Modes

The first step is to assign a quantitative failure probability to all of the potential failure modes that have been identified in the FMEAs.

If information about the failure probability is already available, it can be used to define a statistical model for each failure cause. For example, if the engineers already have data about the probabilities of failure for known failure modes that have occurred when the component was used under similar circumstances in the past, they can analyze the data in Weibull++ and use the Synthesis Platform to "publish" models that can be linked from the failure causes in the FMEA.

If time-to-failure data is not yet available for all of the components and potential failure modes, the occurrence ratings from the FMEA's risk priority number (RPN) calculations can be used as a starting point for those modes.

In this case, the engineers review the criteria used by the FMEA team when setting the occurrence ratings, and they use Xfmea to associate a quantitative value with each rating, as shown next.

Occurrence rating scale

Build Fault Trees for High Severity Effects

The next step is to open the new Build Effect Fault Trees from Synthesis utility that is now available in BlockSim 8. This window allows the user to type any text criteria to identify the effect(s) of interest within the FMEA.

As an example, the "uncommanded engine shutdown" failure effect appears multiple times across different FMEAs, and it is a major safety concern. The FMEAs did not consistently use the exact same terminology to describe every situation in which an uncommanded engine shutdown might occur. However, the analysts believe that all instances contain the word "uncommanded" somewhere within the effect description. In the new BlockSim utility, they specify Effect then contains then uncommanded for the filter criteria. The results are displayed as shown next.

Build Effect FTs from Synthesis

By scanning through the query results, the analysts confirm that all of these effects are of interest except "uncommanded acceleration" so they clear the check box for that record and click Next to create the fault tree. The next figure shows part of the fault tree for the "uncommanded shutdown" effect.

Sample fault tree

The top gate represents the effect of interest, the gates on the next level represent the failure modes associated with the effect (in any of the FMEAs for the system) and the end events represent all the causes of the failure modes. Each event in the fault tree contains the cause occurrence probabilities as defined in Xfmea.

The Show Results option in the control panel allows the analysts to use the fault tree diagram to estimate the probability of an uncommanded shutdown at 3,000 hours, as shown next.

Sample fault tree with results

The team then uses a similar process to build fault trees for the other high severity effects of interest.

Build RBDs to Represent the Entire System

The last step is to build reliability block diagrams that represent the entire system configuration and all of the completed FMEAs. For this purpose, BlockSim 8 provides another utility called Build RBDs and Fault Trees from Synthesis. With this tool, the engineers select their preferences on the first page then proceed to the next page to see the hierarchical representation of the diagram that will be created. At that point, the user has an opportunity to exclude specific data from the analysis, if desired, by clearing check boxes in the hierarchical tree. The following picture shows a portion of the hierarchical representation for the RBDs that will be created for the turbofan engine.

Build RBDs and FTs from Synthesis

Once the diagrams are created, the team uses them to perform a variety of system reliability analyses, such as identifying the components and failure modes that have the biggest impact on system reliability (and unreliability).

New in RCM++

Improving the Effectiveness of Maintenance Task Packaging

Task packaging is the process of combining discrete maintenance tasks into an efficient, effective and executable maintenance program. Concurrent tasks are combined into a set of "work packages" in which the objective is to minimize downtime and optimize the use of resources.

With the release of Version 8, RCM++ now offers a new task packaging tool that provides more flexibility for experimenting with possible packaging strategies. Users can group tasks based on task interval, specific task properties, or some combination of both.

Group by Task Interval: When grouping based on task interval, you can specify a number of time clusters and the software will automatically propose groups based on the defined intervals for all unpackaged tasks. If these intervals are too wide, you can automatically bisect specific groups as needed until you reach a practical strategy. You also have the option to specify exact intervals and the software will automatically group the tasks that meet the specified criteria.

Group by Properties: The utility also provides the option to group tasks based on the task type (failure finding, condition based, etc.), or based on the location of the maintained equipment using the "Zone" or "Access" task properties. This packaging option can be very useful in cases where maintaining a specific piece of equipment requires considerable effort or has a significant effect on system operation (e.g., if the maintenance for a specific piece of equipment significantly reduces or halts production).

Application Example

An engineering team has just concluded an RCM analysis of a gas compression system. The team performed FMEAs on the most critical equipment and used the information about important functional failures to identify new maintenance tasks that are needed, revise existing tasks to be more effective and remove any tasks that were found to not provide additional value. After all maintenance tasks have been defined, the team decides to create task packages to make the maintenance effort more efficient.

First, they decide to group the tasks that take place in critical locations. For example, the maintenance of the fuel gas system results in an interruption of operation; therefore, all tasks for this system are set to be performed at the same time. The remaining tasks are chosen to be grouped automatically by the tool into 12 groups based on their proposed task intervals.

The team then reviews the suggested groups to determine whether further adjustments are needed. They find that although most of the proposed packages are appropriate, the range of task intervals is too wide in some of the automatically created groups. Therefore, they choose to ungroup those tasks and manually set time intervals that are more appropriate. Finally, they update each package to fit the practical circumstances and apply a suitable name (e.g., 2937 hours gets rounded down to 2880 and becomes "4 month maintenance interval").

The figures below show part of the finalized set of packages, along with the options at the top of the window that are available for experimenting with different groupings. When the team decides to apply the packaging strategy that is currently displayed in the window, the software automatically updates the properties of each task record to reflect the time interval of the package it belongs to. In the figures below, this is demonstrated for the "Dump valve overhaul" task, where the originally proposed interval of 883.602 hours gets superseded by the 960 hours interval that was defined for the "40 day maintenance" package.

What's Coming in Synthesis Phase II?

Lastly, we wanted to take this opportunity to give you a sneak peek at what's coming in the Phase II Synthesis release that is currently expected to be available by the end of 2Q 2013. This will include major version upgrades for ReliaSoft's XFRACAS, DOE++, RGA, RENO, Lambda Predict and MPC.

In the new version, these applications will be integrated into the same platform with Weibull++, ALTA, BlockSim, Xfmea and RCM++, and they will have all of the integration and data management features that were introduced in Synthesis Phase I (such as centralized data storage, simultaneous access by multiple users, etc.). With this release, we will also introduce the ability for all Synthesis applications to share specific resources with any analysis project in the entire data repository (in addition to the resources that can already be shared at the project level in Phase I applications).

Here is a brief sampling of some of the new capabilities that will be added to individual applications in Phase II.


Failure Reporting, Analysis and Corrective Action System

  • Enhanced utilization of FRACAS-sourced data used in other Synthesis applications (e.g., Weibull++ and RGA).
  • Enhanced reporting.
  • Multi-chart dashboards.
  • Support for Chrome® and Firefox® web browsers.


Experiment Design and Analysis

  • Design evaluation, including power study and D-efficiency calculations.
  • Measurement system analysis, including gage R&R, linearity and bias study, and gage agreement study.
  • Optimal design, including D-optimal and distance-based optimal design.
  • New optimization tool that can optimize the life response and other responses simultaneously.


Reliability Growth and Repairable Systems Analysis

  • Improved interface for reliability growth planning.
  • Increased the maximum number of test phases to 10.


Simulation Software for Probabilistic Event and Risk Analysis

  • Ability to define global variables that allow for dynamic changes to the characteristics of models during simulation.
  • Ability to use BlockSim’s simulation and analytical diagrams in RENO simulations.

Lambda Predict

Standards Based Reliability Prediction

  • New FIDES module.
  • Support for Telcordia SR-332, Issue 3.


MSG-3 Aircraft Maintenance Program Creation Tool

  • Support for MSG-3 Revision 2011.1.
  • Addition of structural analysis.

End Article


ReliaSoft.com Footer

Copyright © 1992 - ReliaSoft Corporation. All Rights Reserved.
Privacy Statement | Terms of Use | Site Map | Contact | About Us

Like ReliaSoft on Facebook  Follow ReliaSoft on Twitter  Connect with ReliaSoft on LinkedIn  Follow ReliaSoft on Google+  Watch ReliaSoft videos on YouTube