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
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:
The Version 8 utility also provides two new integrated capabilities that have very useful applications for Design for Reliability (DFR) activities.
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.
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.
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.
[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++
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.
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:
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.
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:
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.
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
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:
The following simplified example illustrates both of these potential applications.
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.
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:
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.
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.
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.
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.
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.
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++
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).
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.
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
Experiment Design and Analysis
Reliability Growth and Repairable Systems Analysis
Simulation Software for Probabilistic Event and Risk Analysis
Standards Based Reliability Prediction
MSG-3 Aircraft Maintenance Program Creation Tool