reliabilityedge_v7i1

24
ReliaSoft’s Reliability Edge Volume 7, Issue 1 A system is a collection of subsystems, assemblies and/or components arranged in a specific design to achieve the desired functionality. A system can be repairable or non- repairable and the appropriate analysis method will differ based on this distinction. This article describes a mistake that is often made in repairable systems analysis (i.e. distribution analysis of times between failure) and presents two methods that are more appropriate for this type of analysis (i.e. analyzing system level data with a stochastic process model or analyzing component level data with a reliability block diagram). An example using race car field data demonstrates why distribution analysis of times between failure is not appropriate. This example is also used to highlight the advantages and disadvantages of the stochastic process model and reliability block diagram approaches. Repairable Systems A repairable system is a system that can be restored to an operating condition following a failure. Questions of interest in repairable systems analysis include: Avoiding a Common Mistake in the Analysis of Repairable Systems Ongoing Comprehensive Warranty Analysis for Repairable Systems The costs and liabilities that companies incur in supporting their warranty policies could consume staggering percentages of their budgets. Therefore, warranty analysis is an important activity for a manufacturing company's financial planning. Continuous monitoring for emerging negative reliability issues is also extremely important. An ongoing comprehensive warranty analysis program helps in revealing the truth in warranty data and provides much useful and insightful information, such as warranty returns and related cost forecasts, optimum schedules of spares shipments and deviation between the actual and predicted warranty returns. In addition, a comprehensive warranty analysis program will look at warranty data from several different angles to help identify trends, warranty issues and possible corrective actions. These analyses should look at the big picture, or global view, and should also look at the customer’s perspective during the warranty period. Some warranty analyses that can be performed on non- repairable systems (or at the component level if a failed component is replaced by a new one or repaired to perfect "as good as new" condition) involve using distribution analysis methods (commonly known as Weibull analysis). For repairable systems, however, distribution analysis is not valid as systems are typically not put back into a like new condition after repair. In general, the intervals between failures of a complex system do not follow the same distribution. Therefore, for systems that are repaired and not replaced when they fail during warranty, the analysis methods provided in ReliaSoft’s RGA 6 software are generally appropriate. Some of the RGA 6 methods, e.g. the Global Fleet Analysis, will also apply to systems that are replaced when they fail. This article presents different types of warranty analysis for repairable systems that address different sets of warranty data and related questions. The total package of analyses gives an ongoing assessment of the reliability during the warranty period from several viewpoints. Warranty analysis can help in forecasting future return numbers and costs of fulfilling warranty claims, observing MTBF change over time and predicting changes in the future, verifying constancy in warranty performance and checking for wearout or infant mortality problems (quality problems) during warranty. Please Turn to Page 9 Also Inside... Is Enterprise-wide, Web-based Software Right for You? Team-Based Problem Solving Methods and XFRACAS How many failures will occur over a fixed time interval? What is the probability of a failure in the next time interval? What is the availability of the system? How many spare parts should be purchased? What is the cost of maintaining the system? What is the optimum overhaul time? Common Mistake When Analyzing Repairable Systems One of the most common mistakes in analyzing repairable systems is fitting a distribution to the system's interarrival data. Interarrival data consists of the times between failure of a repairable system, as shown in the following picture where T i is the cumulative time to failure and t i is the interarrival time = T i - T i -1. Please Turn to Page 4

Upload: malkeet-singh

Post on 18-Nov-2015

10 views

Category:

Documents


1 download

DESCRIPTION

reliability

TRANSCRIPT

  • ReliaSofts Reliability Edge Volume 7, Issue 1

    A system is a collection of subsystems, assemblies and/orcomponents arranged in a specific design to achieve thedesired functionality. A system can be repairable or non-repairable and the appropriate analysis method will differbased on this distinction. This article describes a mistake thatis often made in repairable systems analysis (i.e. distributionanalysis of times between failure) and presents two methodsthat are more appropriate for this type of analysis (i.e.analyzing system level data with a stochastic process modelor analyzing component level data with a reliability blockdiagram). An example using race car field data demonstrateswhy distribution analysis of times between failure is notappropriate. This example is also used to highlight theadvantages and disadvantages of the stochastic processmodel and reliability block diagram approaches.

    Repairable SystemsA repairable system is a system that can be restored to an

    operating condition following a failure. Questions of interest inrepairable systems analysis include:

    Avoiding a Common Mistake in the Analysis of Repairable Systems

    Ongoing Comprehensive Warranty Analysis for Repairable SystemsThe costs and liabilities that companies incur in

    supporting their warranty policies could consume staggeringpercentages of their budgets. Therefore, warranty analysis isan important activity for a manufacturing company's financialplanning. Continuous monitoring for emerging negativereliability issues is also extremely important. An ongoingcomprehensive warranty analysis program helps in revealingthe truth in warranty data and provides much useful andinsightful information, such as warranty returns and relatedcost forecasts, optimum schedules of spares shipments anddeviation between the actual and predicted warranty returns.In addition, a comprehensive warranty analysis program willlook at warranty data from several different angles to helpidentify trends, warranty issues and possible correctiveactions. These analyses should look at the big picture, orglobal view, and should also look at the customersperspective during the warranty period.

    Some warranty analyses that can be performed on non-repairable systems (or at the component level if a failedcomponent is replaced by a new one or repaired to perfect "asgood as new" condition) involve using distribution analysismethods (commonly known as Weibull analysis). Forrepairable systems, however, distribution analysis is not validas systems are typically not put back into a like new condition

    after repair. In general, the intervals between failures of acomplex system do not follow the same distribution.Therefore, for systems that are repaired and not replacedwhen they fail during warranty, the analysis methods providedin ReliaSofts RGA 6 software are generally appropriate.Some of the RGA 6 methods, e.g. the Global Fleet Analysis,will also apply to systems that are replaced when they fail.

    This article presents different types of warranty analysisfor repairable systems that address different sets of warrantydata and related questions. The total package of analysesgives an ongoing assessment of the reliability during thewarranty period from several viewpoints. Warranty analysiscan help in forecasting future return numbers and costs offulfilling warranty claims, observing MTBF change over timeand predicting changes in the future, verifying constancy inwarranty performance and checking for wearout or infantmortality problems (quality problems) during warranty.

    Please Turn to Page 9

    Also Inside... Is Enterprise-wide, Web-based Software Right for You? Team-Based Problem Solving Methods and XFRACAS

    How many failures will occur over a fixed time interval?What is the probability of a failure in the next timeinterval?What is the availability of the system?How many spare parts should be purchased?What is the cost of maintaining the system?What is the optimum overhaul time?

    Common Mistake When Analyzing Repairable SystemsOne of the most common mistakes in analyzing

    repairable systems is fitting a distribution to the system'sinterarrival data. Interarrival data consists of the timesbetween failure of a repairable system, as shown in thefollowing picture where Ti is the cumulative time to failure andti is the interarrival time = Ti - Ti-1.

    Please Turn to Page 4

  • Page 2 Volume 7, Issue 1

    Reliability Edge is published up to four times a year.To obtain a free subscription, to send comments or to

    submit articles for consideration:

    ReliaSoft PublishingReliaSoft Plaza

    115 S. Sherwood Village DriveTucson, AZ 85710 USA

    Telephone: +1.520.886.0366 Fax: +1.520.886.0399E-mail: [email protected]

    Correspondence with the editor may be published, inwhole or in part, in future issues of ReliaSoft

    publications.

    An electronic copy of this document can be viewed ordownloaded from: www.ReliaSoft.com/newsletter/

    For information about products and services: ReliaSoft SalesReliaSoft Plaza

    115 S. Sherwood Village DriveTucson, AZ 85710 USA

    Telephone: +1.520.886.0410 Fax: +1.520.886.0399E-mail: [email protected] Web Site: www.ReliaSoft.com

    This document may be reproduced without permissionprovided that it is not altered in any way and all pages

    are included in any reproduction.

    2006 ReliaSoft Corporation, ALL RIGHTS RESERVED.ReliaSoft, Weibull++, weibull.com, Reliability Edge, ALTA,

    BlockSim, Xfmea, RCM++, Lambda Predict, XFRACAS, RENOand RGA are registered trademarks of

    ReliaSoft Corporation.

    In this IssuePage 1 Avoiding a Common Mistake in

    the Analysis of RepairableSystems

    Ongoing ComprehensiveWarranty Analysis forRepairable Systems

    Page 2 Is Enterprise-wide, Web-based

    Software Right for You? ItDepends on the Application!

    From the Editors Desk

    Page 19 Software Tips: Data Entry

    Shortcuts

    Page 20 Team-Based Problem Solving

    Methods and XFRACAS

    Page 23 For Your Information

    Bulletin Board

    From the Editors Desk...In this issue of Reliability Edge, we

    are pleased to introduce XFRACAS, atruly Web-based, enterprise-wideFRACAS system that can be configuredto meet your organizations specificneeds with no custom programmingrequired.

    This issue also includes two articlesthat discuss approaches to repairablesystem analysis, an article on team-based problem solving techniques,software tips and other reliability andsoftware-related news.

    As always, you can send e-mail [email protected] if youwish to comment on the content of thisnewsletter, suggest topics that may be ofinterest in future issues. If you have aspecific analysis method or applicationthat will be of interest to your peers, youcan also submit anarticle that may appearas a guest submissionin a future issue. Wewelcome your input.

    --Lisa Hacker

    Over the last few years, many of ourcustomers have struggled with thedecision of the type of implementationthey should follow for their reliabilitysolutions. Quite often, there areconflicting requirements and needs,from both an engineering and aninformation technologies (IT) standpoint,which necessitate a compromisebetween functionality, usability, ease ofinitial deployment, long-term support,cost, etc. This article addresses some ofthe questions to consider when decidingwhich type of software or system is thebest fit for each particular applicationand presents a brief introduction to howa terminal server approach might beapplied for specific applications.

    Background There are many factors to take into

    consideration when purchasing softwarefor your specific reliability, quality and/ormaintainability data analysis andreporting needs. The degree to whichthe tool provides desired functionality,the usability of the interface anddocumentation, the availability ofknowledgeable support and training andthe software vendor's reputation shouldof course be at the top of your list offactors to consider. The method ofdeploying the software (e.g. standaloneor client-server software, Web-basedsystem, etc.) is another consideration.You, or your companys IT department,may have an up-front preference forenterprise-wide systems that can bedeployed via Web browser and this isindeed the best approach for someapplications. However, in many cases, a

    standalone or client-server approach willprovide better performance with lessoverhead. A terminal server approachcan also be considered as a way toaddress the IT department's desire for ascalable, manageable solution while stillsatisfying the users demands forfunctionality, usability and performance.

    Do You Need Enterprise Software?The first question to consider is

    whether you need enterprise-widesoftware for your particular application.By enterprise-wide, we are referring tosoftware that provides centralized datastorage and allows multiple users toaccess the system simultaneously. Thistype of software is typically moreexpensive and more complex toimplement. It requires adequate serverhardware, experienced IT personnel toconfigure and support the server(s),appropriate licensing for the underlyingdatabase (e.g. ORACLE or SQLServer), a secure and reliableconnection to the server for each user,ongoing database maintenance andbackups, and so on.

    An enterprise-wide system is likelyto be appropriate if you are dealing withprocess-oriented analyses that requireinput and review by multiple people,such as FMEA or FRACAS. In thesecases, the organization will benefit fromcentralized data storage and the abilityfor multiple users to log in to the systemfrom various locations and query orupdate the shared information.ReliaSoft's Xfmea Enterprise andXFRACAS products are examples of

    Is Enterprise-wide, Web-based Software Right for You? It Depends on the Application!

    Please Turn to Page 3

  • Volume 7, Issue 1 Page 3

    Continued from Page 2: Is Enterprise-wide, Web-based Software Right for You? It Depends on the Application!enterprise-wide software designed to support the FMEA andFRACAS needs of the entire organization, while providingconsistency, a feedback loop for corrective actions, asearchable "knowledge base" of known issues, etc.

    Another powerful application for an enterprise-widesystem would be an automated data analysis andpresentation system, such as ReliaSoft's Dashboard. Thistype of system is designed to collect data from a variety ofsources (e.g. shipments, warranty claims, failure analyses,etc.), automatically analyze the data and present the analysisresults throughout the organization. This approach isappropriate for analyses that can be performed without inputfrom an experienced analyst (such as line charts showingtrends over time or bar charts of issues ranked by quantity)and usually requires custom development to establish thedata flow, analysis and presentation mechanisms that areappropriate for an organizations particular processes.

    However, if you are working with individual statistical dataanalyses (such as fitting a distribution to life data or simulatingthe operation of a complex system over time), an enterprise-wide system is not required, even if you have many usersacross the enterprise. In this case, the analysis is typically(and appropriately) performed by one analyst at a time andusually requires the computing power and usability that astandalone software product such as ReliaSoft's Weibull++ orBlockSim can provide. Under this scenario, employing anenterprise-wide Web-based system would be both prohibitiveand unnecessary.

    Web-based or Client-Server?If you have decided that an enterprise-wide system is

    appropriate, the next question to consider is whether it shouldbe Web-based or client-server. With systems that aredeployed via a Web browser, there is little or no software thatneeds to be installed or updated on each user's computer.This characteristic is understandably attractive to many ITdepartments! If a Web-based system can deliver the desiredfunctionality, usability and performance then it may bepreferred over a client-server approach, which requiressoftware to be installed and updated for each user.

    The technology available for developing Web-basedsystems has been improving and continues to improve allthe time. However, for many types of tasks, userscontinue to expect a higher level of usability andperformance than can currently be achieved in a Web-based interface. In those cases, your organization willneed to carefully weigh the advantages anddisadvantages of the relative convenience of the Web-based system versus the superior performance andusability of the client-server option or consider aterminal server approach, as described next.

    Consider a Terminal Server ApproachIf you have decided that your organization does not

    want to install a client application on each individualuser's computer but you would prefer the usability andperformance of a client-server solution, then you may

    consider some sort of terminal server implementation (suchas Microsoft's Terminal Services or Citrix) as a viablealternative to a truly Web-based system. With this approach,the application software will be installed on one or moreserver computers but the individual users will employ a "thinclient" to remotely connect to the server and operate thesoftware on the server, instead of on the user's own computer(depending on the implementation, this could be a Webbrowser or a small utility such as Microsoft's RemoteDesktop). With this type of implementation, the applicationsoftware needs to be updated on the server computer(s) onlybut each individual user enjoys the full functionality, usabilityand performance of a Windows-based graphical userinterface. There is some IT setup required, of course, but it iscomparable to (or even less than) the effort required to hostand support a Web-based system. As an example, the figurebelow shows ReliaSoft's Xfmea being operated on a remoteserver via a Web browser.

    ConclusionAs this article demonstrates, the answer to the question of

    whether enterprise-wide Web-based software is right for youdepends on the application. In general, you will get morefunctionality and better performance, with less overhead,when you perform individual statistical analyses in standaloneapplications. An enterprise-wide system will be appropriate forapplications where centralized data storage is required andmultiple users must cooperate on the data entry and analysis.Among enterprise-wide systems, a Web-based interface maybe preferred because of the minimal installation requirementsfor individual users. However, if a Web page cannot deliverthe desired level of usability and performance, a client-serverimplementation (with or without terminal server) is also aviable option. In developing our suite of reliability software andsystems, ReliaSoft has endeavored to provide the appropriatetool for each particular application. This includes standaloneand client-server Windows-based software, which can bedeployed via terminal services if desired, as well as truly Web-based enterprise-wide systems.

  • Page 4 Volume 7, Issue 1

    When fitting a distribution, we assume that the events arestatistically independent and identically distributed (s.i.i.d.).However, in a repairable system, the events (failures) are notindependent and in most cases are not identically distributed.When a failure occurs in a repairable system, the remainingcomponents have a current age. The next failure eventdepends on this current age. Thus, the failure events at thesystem level are dependent.

    When we perform a distribution analysis on the timesbetween failure, this is equivalent to saying that we have 9different systems, and System 1 failed after t1 hours ofoperation, System 2 failed after t2,, etc.

    This is the same as assuming that the system is AS-GOOD-AS-NEW after the repair, which is not true inrepairable systems in general. In most cases, the system isAS-BAD-AS-OLD after the repair. This is particularly true forlarge systems, where replacing a component does not have agreat impact on the system reliability. For example, replacingthe starter does not have a great impact on the reliability of acar since there are many other ways that it may fail.

    Example: Will the Driver Finish the Race?To demonstrate the problems with this analysis approach,

    consider the following example, which uses test data toanalyze how a car will perform in a race. Each race is 200 Km.The brakes are changed after each race but all othercomponents stay on the car for the next race. Table 1 displaysdata from three race cars operating under test. During thetest, all vehicles operated under similar conditions and thebrakes were preventively replaced every 305 Km. Note thatthe preventive maintenance (PM) interval for the brakes islonger in the test conditions than in the field so that the testspecimens can be observed for a longer operating period.

    As shown in Figure 1, we could use Weibull++ to fit adistribution to the times between failure for each system. Notethat the PM times are not considered and the time betweenthe last failure and the current age of the system is treated asa suspension. This analysis assumes that we have a sampleof 19 systems, and one system failed at 7.3 Km, anotherfailed at 27.4 Km, and so on. The result is a 2-parameterWeibull distribution with beta = 1.1043 and eta = 336.7140.When you use this analysis to calculate the probability that thedriver will finish the 200 Km race, the estimate is 56.97%.However, this result is not valid because the events (timesbetween failure) are not s.i.i.d. When applied inappropriately,the analysis method yields incorrect results.

    Continued from Page 1: Avoiding a Common Mistake in the Analysis of Repairable Systems

    Figure 1: Distribution Analysis on Times Between Failure(in Weibull++)

    System 1Age = 2500 Km

    Time-to-Event Component

    249.8 Engine

    305.0 PM Brakes

    584.2 Front Suspension

    610.0 PM Brakes

    915.0 PM Brakes

    972.0 Engine

    1220.0 PM Brakes

    1525.0 PM Brakes

    1830.0 PM Brakes

    1861.7 Front Suspension

    1994.6 Rear Suspension

    2127.0 Transmission

    2134.3 Right Rear Brake

    2134.3 PM Brakes

    2186.9 Engine

    2439.3 PM Brakes

    System 2Age = 1976 Km

    Time-to-Event Component

    305.0 PM Brakes

    610.0 PM Brakes

    872.4 Engine

    899.8 Right Front Brake

    899.8 PM Brakes

    1204.8 PM Brakes

    1371.7 Right Front Brake

    1371.7 PM Brakes

    1470.4 Engine

    1572.6 Rear Suspension

    1676.7 PM Brakes

    1754.9 Transmission

    System 3Age = 800 Km

    Time-to-Event Component

    305.0 PM Brakes

    453.9 Rear Suspension

    610.0 PM Brakes

    743.5 Transmission

    Please Turn to Page 5

    Table 1: Field Data for 3 Race Cars

  • Volume 7, Issue 1 Page 5

    Instead of fitting a distribution to the times between failurefor each system, we could fit a distribution to the first time-to-failure for each system. These are statistically independentand identically distributed events. Figure 2 shows thisanalysis performed in Weibull++.

    The results from this type of analysis are limited,however. We could use this analysis to estimate theprobability that the car will not fail in the first 200 Km(84.17%). But the confidence interval for this estimate is verywide (one-sided lower 90% bound = 51.13%). When we go onto estimate the probability that no failures will occur in the firstten races (2,000 Km), we find that the system will fail at leastonce in the next ten races (i.e. the reliability is 0%). However,we cannot use this analysis to estimate how many times thecar will fail during the ten races. We also cannot determinewhether and/or when to overhaul the system, and so on.

    Clearly, a different analysis approach is required that willprovide answers to these and other important questions. Theremainder of this article presents two methods that are moreappropriate for repairable systems analysis and considers theadvantages and disadvantages of each method.

    Using a Stochastic Process Model to Analyze Data at theSystem Level

    For proper analysis of repairable systems, we need amodel that will take into account the fact that the system hasa current age whenever a failure occurs. For example, inSystem 1, the system has a current age of 249.8 Km after theengine is replaced. In other words, all other components in thesystem are 249.8 Km "old" and the next failure event will bebased on this fact. Since the engine was just replaced, it isless likely to fail soon; whereas the failure probability for anyof the other components is affected by the fact that they havealready operated for 249.8 Km.

    The Non Homogeneous Poisson Process (NHPP) with aPower Law Failure Intensity is such a model. It assumes thatthe system is AS-BAD-AS-OLD after each repair and is givenby:

    Where:

    Pr[N(T)=n] is the probability that n failures will beobserved by time T.L(T) is the Failure Intensity Function (Rate of Occurrenceof Failures).

    NOTE: If we assume that the repair partially renews thesystem and it is not AS-BAD-AS-OLD after the repair, then theNHPP model may not be the most appropriate model for theanalysis. The General Renewal Process (GRP) may be usedinstead. This model has been discussed in a previousReliability Edge article (Volume 6, Issue 1, on the Web athttp://www.ReliaSoft.com/newsletter/v6i1/restoration.htm)and is available in Weibull++ 7's Parametric RDA folio.

    Using the NHPP Power Law Model for the Race CarAnalysis

    As shown in Figure 3 and Figure 4 (page 7), we can useReliaSoft's RGA software to apply the NHPP Power Lawmodel to the race car data. This analysis estimates 6 failuresper system over 10 races. With 2 cars in each race, thatmeans we can expect 12 failures per fleet. If the average cost

    Continued from Page 4: Avoiding a Common Mistake in the Analysis of Repairable Systems

    Figure 2: Distribution Analysis on First Time-to-Failureper System (in Weibull++)

    Please Turn to Page 7

    Figure 3: NHPP Power Law Analysis (in RGA 6)

  • Supports complete and right censored (suspended) data, entered individually and in groups,with up to eight stress types.

    Lifetime distributions include Weibull, lognormal and exponential.

    Life-stress relationships include Arrhenius, Eyring, Inverse Power Law, Temperature-Humidity,Temperature-NonThermal, Proportional Hazards, General Log-Linear and Cumulative Damage.

    Supports stress profiles that vary with time, such as step-stress, ramp-stress, etc.

    Provides a complete array of results and plots, with confidence bounds available for parametersand calculated results.

    And much more...

    http://ALTA.ReliaSoft.com

    The software is available in two versions: RGA Standard and RGA PRO, which provides advancedcapabilities.

    Supports traditional reliability growth analysis for time-to-failure (continuous), success/failure(discrete) and reliability data, analyzed with the Crow-AMSAA (N.H.P.P.), Duane, Gompertz,Modified Gompertz, Logistic or Lloyd Lipow models.

    Supports the enhanced data analysis methodology developed by Dr. Crow to provide reliabilitygrowth projections and evaluate the reliability growth management strategy.

    Supports Dr. Crows methods to combine multiple fielded repairable systems into a singlesuperposition system that can be used to estimate the optimum overhaul time and othermetrics without the detailed data sets that would normally be required.

    http://RGA.ReliaSoft.com

    ALTA is the first and only commercially availablesoftware package designed expressly for

    quantitative accelerated life testing data, usingrigorous scientific analysis methods. The software

    is available in two versions: ALTA Standard andALTA PRO, which provides advanced capabilities.

    RGA was developed with cooperation from theleading authority in reliability growth analysis,

    Dr. Larry Crow. It combines the mostcomprehensive and powerful reliability growth

    analysis software with fielded (repairable)system data analysis capabilities designed to

    make the most of a limited data set.

  • Volume 7, Issue 1 Page 7

    Continued from Page 5: Avoiding a Common Mistake in the Analysis of Repairable SystemsUsing an RBD for the Race Car Analysis

    To use the race car example to demonstrate the RBDapproach, let's assume that we have data for 6 replaceablecomponents:

    EngineTransmissionFront & Rear BrakesFront & Rear Suspension

    We can use Weibull++ to analyze the times-to-failure andsuspensions for each component. The results are shown inTable 2.

    per failure is $192,000, then the total maintenance cost for thefleet is estimated to be: 12 Failures * $192,000/failure =$2,304,000.

    Using the Quick Calculation Pad, we can also estimatethe probability that the driver will finish the first race (87.31%)and the probability that the driver will finish the third racegiven that his car has run the first two races, (66.70%). Wecan estimate the optimum overhaul time for the car byconsidering the average repair cost ($192,000) and theoverhaul cost ($500,000). This is about 1,560 Km(approximately once every 8 races per vehicle). These resultsare shown in Figure 5.

    As you can see, the NHPP analysis allows us to answermany questions of interest for a repairable system. However,there are still some unanswered questions, including:

    How many spare parts should we purchase?Which components cause most of the failures?Can we get a more accurate cost estimate?

    If we have data at the component level (LowestReplaceable Unit, LRU), we can use a Reliability BlockDiagram (RBD) approach to answer these and otherquestions.

    Figure 5: Probabilities of Finishing Race 1 and Race 3 andOptimum Overhaul Time (estimated in RGA 6)

    Figure 4: Cumulative Number of Failures from the NHPPAnalysis in RGA 6

    Component Distribution Parameter 1 Parameter 2

    Brakes Front L Weibull 3.22 716.12

    Brakes Front R Weibull 3.22 716.12

    Brakes Rear L Weibull 15.36 391.41

    Brakes Rear R Weibull 15.36 391.41

    Engine Weibull 2.82 905.79

    Front Suspension Lognormal 7.29 0.65

    Rear Suspension Weibull 2.46 1564.36

    Transmission Weibull 3.14 1737.35

    Table 2: Component Distributions and Parameters

    Please Turn to Page 8

  • Page 8 Volume 7, Issue 1

    Continued from Page 7: Avoiding a Common Mistake in the Analysis of Repairable SystemsWe can then use ReliaSoft's BlockSim software to create

    an RBD that represents the reliability-wise configuration ofthese components, as shown in Figure 6. We use theWeibull++ analyses to define the failure characteristics foreach block in the diagram and also enter the repair durationsand costs. For the brakes, we define a preventivemaintenance policy, which specifies that all four brakes will bereplaced every 200 Km.

    By simulating the operation of the system for 2,000 Km,we obtain the results displayed in Figures 7 and 8. Some ofthe results of interest include the expected number of systemfailures (5.104), the total costs ($910,1942), the number ofspare parts required for each component, etc.

    The advantages of this approach include the ability to:

    Perform criticality and sensitivity analysis.Identify weak components in the system.Perform optimization and reliability allocation.Obtain availability, downtime, expected failures, etc., atthe component level as well as the system level.

    The main disadvantage is that the analysis requiresdetailed information, including failure and repair data at theLRU level.

    ConclusionAs this article demonstrates, it is not appropriate to

    analyze a repairable system by applying distribution analysisto interarrival data because time between failure events donot meet the s.i.i.d. requirement. Instead, you may choose tocollect data at the system level and analyze it with astochastic process model, such as the NHPP. Or, you maychoose to collect data at the component level and analyze itwith a reliability block diagram. Your choice will depend on thedata available and the questions you wish to answer based onthe analysis.

    For more information on the software used to perform theanalyses described in this article, visit ReliaSofts Web site athttp://Weibull.ReliaSoft.com, http://RGA.ReliaSoft.com andhttp://BlockSim.ReliaSoft.com.

    Figure 6: Race Car RBDs Figure 8: Component-Level Results

    Figure 7: System-Level Results

    System Diagram

    Front Assembly Subdiagram

    Rear Assembly Subdiagram

  • Volume 7, Issue 1 Page 9

    Global Fleet AnalysisThis analysis tracks the number of failures and warranty

    age mix of systems in an operating fleet (where systems canhave different ages and can age at different rates) overdifferent time increments during a warranty period. The fleet isdefined as all units that are under warranty during the timeperiods of interest. As noted earlier, the Global Fleet Analysiscan be applied to both repairable and non-repairable systems.

    The Global Fleet Analysis uses the fleet warranty failuresand total fleet operating hours over successive periods ofcalendar time to:

    Determine if a trend exists.Calculate the as-is average fleet MTBF.Determine the chief failure modes influencing anynegative trends and low fleet MTBF.Project new fleet MTBF if certain problem warranty failuremodes receive corrective action.Address associated cost avoidance.

    Sample Data and RGA 6 Instructions

    The data set for this type of analysis is to be grouped bya certain increment (e.g. months, quarters), which shows theaccumulated hours (or other time unit such as mileage) of allthe systems in the field and the number of fleet failures. Thistype of analysis uses the following data type and model inRGA 6:

    Grouped Failure Times (under Developmental Testing)Crow-AMSAA (NHPP) Model

    In Table 1, the warranty data are grouped according toquarters. In each quarter we note the total number of fleetoperating hours for all systems that are under warranty andthe number of failures during the quarter. The results from thisanalysis were discussed in a recent Reliability HotWire article,see http://www.weibull.com/hotwire/issue65/relbasics65.htm.

    Global Fleet Analysis with Failure ModesThe next type of analysis is the same data setup as the

    previous type (Global Fleet Analysis), but with the addition offailure modes and classification on fleet failures. If certainfailure modes of the system received corrective action, theCrow Extended model can be used to understand theinfluence of repairs targeted toward certain failure modes on

    Continued from Page 1: Ongoing Comprehensive Warranty Analysis for Repairable Systemsthe global fleet's warranty returns. Failure modes are to beidentified and classified according to the type of correctiveaction they received, if any.

    A: No corrective action will be appliedBC: Corrective actions have been applied to all systemsduring the operating period being analyzedBD: Corrective actions were delayed and have not beenapplied during the operating period being analyzed

    Sample Data and RGA 6 Instructions

    As mentioned above, the data set is to be grouped by acertain increment (e.g. months, quarters), which shows theaccumulated hours of all the systems in the field and thenumber of fleet failures. Failure modes are named and

    Quarter Fleet AccumulatedHours per QuarterNumber of

    Failures

    Q1 125000 992

    Q2 267000 1190

    Q3 386000 981

    Q4 524000 1096

    Table 1: Global Fleet Data

    MonthNumber

    ofFailures

    FleetAccumulated

    HoursClassification Mode

    Month 137

    5050

    BDBD

    FM1FM2

    Month 2

    1112

    100100100100

    BD BCBD A

    FM4FM21FM5FM3

    Month 3

    1121131

    150150150150150150150

    BD A

    BD BDBCBD BD

    FM7FM16FM8FM5

    FM22FM9

    FM10

    Month 4

    1111

    200200200200

    BCBCBD BD

    FM8FM19FM10FM11

    Month 5

    2111111

    300300 300 300 300 300 300

    ABD A

    BD A

    BD BD

    FM17FM12FM3FM1

    FM18FM6

    FM13

    Month 6

    111121211

    400400 400 400 400 400 400 400 400

    BD AA

    BD BD BD A

    BD BD

    FM4FM3

    FM17FM12FM10FM5

    FM18FM14FM15

    Table 2: Global Fleet with Failure Modes Data

    Please Turn to Page 10

  • Page 10 Volume 7, Issue 1

    classified depending on the repair action type. This type ofanalysis uses the following data type and model in RGA 6:

    Grouped Failure Times (under Developmental Testing)Crow Extended Model

    In Table 2 (page 9), the warranty data are grouped bymonths. In each month we note the total number of fleetoperating hours for all systems that are under warranty, thenumber of failures during the month and the type of repairaction received by each failure mode.

    Figure 1 shows the estimated effectiveness factors for thefailure modes with delayed fixes (i.e. the BD modes). Theeffectiveness factor estimates the percent decrease in theitems failure rate after the corrective actions are applied. Thefigure also shows a chart with the demonstrated MTBF of thepopulation at the end of the 6th month, the Projected MTBF(after including the delayed repairs) and the Growth PotentialMTBF (i.e. the maximum MTBF that can be attained with thecurrent management strategy when all BD modes have beenobserved and fixed with an effectiveness equal to the averageof the effectiveness factors that have been estimated for theobserved BD modes).

    Within Warranty Cycle AnalysisThe next type of analysis addresses the serialized

    system's reliability within the warranty period. This is also acustomer view of the system reliability during the warrantyperiod. The analysis requires the failure times for each systemin the field (if some systems never failed, these systemsshould also be included in the data set). If collecting data forall systems is not possible or too difficult, a random sample ofserialized systems can be used (the sample might includesystems that never failed). This type of warranty analysis usesthe Power Law model, which is a generalization of thehomogeneous Poisson process that allows for changes in theintensity function as the repairable system ages.

    Sample Data and RGA 6 Instructions

    This type of analysis uses the following data type andmodel in RGA 6:

    Repairable (under Fielded Systems)Power Law Model

    Table 3 shows the failure times for each unit in a sampleof 11 fleet systems; the end time is the last recorded knownage when the analysis was performed. Figure 2 shows theprobability (with 90% 2-sided confidence bounds) that asystem that accumulated 2,000 hours of operation willoperate for another 200 hours.

    Across Warranty Cycle Analysis (Fleet Analysis)The next type of analysis addresses serialized system

    data across warranty periods. For this analysis, the systemsare sorted from the oldest configuration to the most recent

    Figure 2: RGA QCP with Conditional Reliability Results

    Continued from Page 9: Ongoing Comprehensive Warranty Analysis for Repairable Systems

    System ID End Time Failure Time

    System 1 1268 68, 1137, 1167

    System 2 1300 682, 744, 831

    System 3 1593 845

    System 4 1421 263, 399

    System 5 1574 No Failures

    System 6 1415 No Failures

    System 7 1290 598

    System 8 1556 No Failures

    System 9 1426 No Failures

    System 10 1124 730

    System 11 1568 No Failures

    Table 3: Within Warranty Data

    Please Turn to Page 11

    Figure 1: Effectiveness Factors for the BD Failure Modesand Some Results from the Global Fleet Analysis

  • Volume 7, Issue 1 Page 11

    Continued from Page 10: Ongoing Comprehensive Warranty Analysis for Repairable Systemsconfiguration (or any other ordering of interest). As in theprevious analysis types, the analysis requires the failure timesfor each system in the field, even if some systems neverfailed. If collecting data for all systems is not possible or toodifficult, a random sample of serialized systems can be used(the sample might include systems that never failed). Thedata should reflect the complete history of the systems duringthe entire warranty period. For the most recent systems in theanalysis we should still try to use systems with completedwarranty cycles in order for the trend analysis ( estimate) tobe valid and reflect whether there are changes in warrantyfailures as a function of configuration build dates. For stableconfigurations, we would expect no trend (i.e. estimate closeto 1).

    Sample Data and RGA 6 Instructions

    After entering the failure data, this analysis requiresconverting the timeline into grouped data. To accomplish this,a group interval is required. The group interval length shouldbe chosen so that it is representative of the data and issufficiently large to ensure that there are failures within eachinterval (this can also be determined automatically by RGA 6

    using a proprietary algorithm). Also note that the intervals donot have to be of equal length. This type of analysis uses thefollowing data type and model in RGA 6:

    Fleet (under Fielded Systems)Crow-AMSAA (NHPP) Model

    Table 4 is a data sample for an automotive product thathas a 10,000 mile warranty policy. The systems are sortedfrom the oldest configuration to the most recent one. The dataset shows the entire failure record of each system during thewarranty period. The group interval is defined to be anincrement of 1,000 miles.

    First, we verify the assumption that is close to 1. Asshown in Figure 3, using the RGA QCP, we find that we cansay with 90% confidence that the interval on includes 1.Therefore, the assumption is valid. Figure 3 also shows theestimated MTBF at 12,000 miles for this analysis.

    Across Warranty Cycle Analysis (Fleet Analysis) WithFailure Modes

    The next type of analysis uses the same data as in theprevious analysis type but with failure mode identification andclassification added into the analysis. This model addressesthe projected average configuration reliability if certain failuremodes receive corrective action in the future. This analysisaddresses mainly the inherent average reliability of a serialnumber configuration during the entire warranty period. Thatis, the warranty age mix of the fleet is not a factor. Forprojections, the application of this model requires theconfigurations to be consistent, as verified by a value closeto 1.

    Please Turn to Page 16

    Build System ID End Time Failure Time

    Build 1

    123456

    10,00010,00010,00010,00010,00010,000

    No Failures3160, 9430

    8869227, 1289, 3987, 4589

    No Failures5678, 8987

    Build 2

    789

    1011121314

    10,00010,00010,00010,00010,00010,00010,00010,000

    20248460

    6000, 7897525, 2345, 6789, 8989

    2074, 91055079

    No Failures498, 1232, 2345, 7899

    Build 3

    1516171819

    10,00010,00010,00010,00010,000

    9161348, 1200, 4497, 7900, 9939

    98304233, 82346877, 8527

    Build 4

    2021222324252627282930

    10,00010,00010,00010,00010,00010,00010,00010,00010,00010,00010,000

    No Failures95568085

    No Failures135, 568, 1239, 6789

    No Failures6228, 9795No Failures

    81207023

    128, 1396, 5600, 8796Figure 3: Parameter Bounds and MTBF calculated by

    RGA for the Across Warranty Cycle Analysis

    Table 4: Across Warranty Data

  • ReliaSofts XFRACAS is a Web-based, closed-loop, incident (failure) reporting, analysis andcorrective action system (FRACA/FRACAS) designed for the acquisition, management and

    analysis of product reliability, quality and safety data from multiple sources, along with themanagement of problem resolution activities.

  • ReliaSoft's Web-based XFRACAS system supports the entire incident management process, from theinitial development stages to complete tracking of fielded serialized units. It includes completesupport for FRACAS or DRACAS activities and a configurable array of problem resolution processes,such as 8D, Six Sigma DMAIC, and others.

    The only truly Web-based, closed-loop, user-configurable, enterprise-wideFRACAS in a box!

    Customer SupportXFRACAS includes a complete array of resources to facilitate support activities for incidents reportedthrough customer care channels.

    Incident Reporting / FRACASXFRACAS provides full support for incident (failure) reporting, analysis and corrective action activities(FRACA/FRACAS) at any stage in the product life cycle, from cradle to grave.

    System Configuration Management and Part TrackingXFRACAS supports complete system configuration management and part tracking from the original Bill ofMaterials (BOM), through part repairs and replacements, to detailed failure analysis and remanufacturingof parts. XFRACAS also supports generic system configuration tracking when serial numbers are not used.

    Problem ResolutionXFRACAS provides problem identification, analysis and management resources that allow product designpersonnel to manage failure analysis, corrective action and problem resolution activities. This includes fullsupport for the 8D problem solving process or the flexibility to create your own process with 4 to 8 steps.

    Actions Management and WorkflowXFRACAS makes it easy to manage problem resolution activities by assigning actions to specific personneland tracking the progress of resolution activities. This includes quick access to information of interest toyou (via the personalized portal) and the ability to generate automated notifications via e-mail.

    Queries, Reports, Plots and AnalysesXFRACAS provides extensive and flexible query, reporting and plotting capabilities with the ability toexport data to Microsoft Excel and/or to ReliaSofts reliability analysis tools for additional reliabilityanalysis. Separate Search, Report, Dashboard and Analysis utilities put your data to work in a snap.

    Extensive Configuration OptionsXFRACAS provides extensive configuration utilities that allow you to control the look and feel of userinterfaces to meet your organizations particular needs, including the ability to capture the additional datafields specific to your organizations products.

    Web-based System AccessThe systems Web-based user interfaces allow for easy access, collaboration and deployment for multiplesites, suppliers and dealers. The system is configurable, flexible and scalable to fit your organization'sparticular products/process and to grow with your needs.

    Architecture: The XFRACAS architecture is Web-based, n-tier, scalable and robust. It requires a SQL Server or ORACLEdatabase and Internet Explorer for user access. Please consult the Web site or contact ReliaSoft for specific requirements.

    Detailed product information is available on the Web:

    http://XFRACAS.ReliaSoft.com

    WWEBEB-B-BASEDASED FFAILUREAILURE RREPOREPORTINGTING, A, ANALNALYSISYSIS ANDAND CCORRECTIVEORRECTIVE AACTIONCTION SSYSTEMYSTEM

    http://XFRACAS.Rel iaSoft .comhttp://XFRACAS.Rel iaSoft .com

    Implementationbenefits include:Addresses data capture

    and managementdeficiencies to providetimely and accurateproduct reliability,quality and safety data.

    Streamlines incidentreporting and problemresolution activities.

    Provides a closed-loopsystem for managingcorrective actions.

    Contributes to designimprovements, fasterproduct release, betterservice and enhancedcustomer satisfaction.

    Generates financialrewards through betterproduct designs,enhanced control ofproduct warranties andmore efficient customersupport.

    And more...

  • Weibull++ is the industry standard in reliability and lifedata analysis (Weibull analysis) for thousands ofcompanies worldwide. The software performs life dataanalysis utilizing multiple lifetime distributions (includingall forms of the Weibull distribution), with a clear andconcise interface geared toward reliability engineering.

    For Version 7, Weibull++ was redesigned from the groundup. It incorporates many new and enhanced features,including a greatly enhanced user interface, an expandedwarranty analysis utility, integrated reliability blockdiagrams, recurrence data analysis and much, muchmore...

    The stThe standard for reliability life datandard for reliability life data analysisa analysis TMTM

  • Weibull++ provides a complete array of data analysis, plotting and reporting tools for standardlife data analysis (Weibull analysis) with integrated support for a variety of related analyses. Builtby reliability engineers for reliability engineers, this package continues to raise the bar forstatistical analysis software for reliability applications.

    All the options you need for standard life data analysis...All Types of Data: Weibull++ supports Complete, Right Censored (Suspended), LeftCensored, Interval Censored and Free-Form data, entered individually or in groups. Aspecialized interface to analyze event log data is also available. All Major Lifetime Distributions: The software supports data analysis with the 1, 2 and 3parameter Weibull, Mixed Weibull, 1 and 2 parameter Exponential, Lognormal, Normal,Generalized Gamma, Gamma, Logistic, Loglogistic, Gumbel and Weibull-Bayesian lifetimedistributions. The Distribution Wizard automatically performs goodness-of-fit tests to help youselect the most appropriate distribution for each data set.

    Results at the click of a button and unparalleled plots and graphics...Parameter Estimation and Calculated Results: Weibull++ supports both Rank Regressionand Maximum Likelihood Estimation (MLE) for parameter estimation. Integrated utilities quicklyreturn calculated results (such as reliability given time and BX life) based on the data analysisand your inputs. Confidence bounds are available for all parameters and calculated results.Plots and Automated Reports: The software automatically generates a complete array ofreliability plots, with customizable settings. Plots are metafile graphics that can be annotatedand used in your reports and presentations. Automated report generation is also available.

    A complete array of related analyses...Warranty Analysis: Perform life data analysis and make warranty projections based on salesand returns data, entered in a Nevada, Times-to-Failure or Dates of Failure format. Reliability Block Diagram: Use Reliability Block Diagrams (RBDs) that are integrated withcalculated data folios to analyze competing failure modes and perform other system analyses. Recurrence Data Analysis: Use parametric or non-parametricmethods to analyze events that are dependent and notidentically distributed (such as repairable system data) and/or tomodel the number of occurrences of an event over time.Degradation Analysis: Use the Linear, Exponential, Power,Logarithmic, Gompertz or Lloyd-Lipow models to extrapolatethe failure times of a product based on its performance(degradation) over a period of time. SimuMatic: Automatically perform large quantities of analyseson simulated data sets in order to investigate various reliabilityquestions, including confidence bounds, testing scenarios, etc.Design of Reliability Tests: Determine the appropriatesample size, test duration or other variables for reliabilitydemonstration tests.

    And much more!!!

    TTHEHE SSTTANDARDANDARD FORFOR RRELIABILITYELIABILITY LLIFEIFE DDAATTAA AANALNALYSISYSIS

    +1.520.886.0410+1.520.886.0410

    New and enhancedfeatures in Version 7:- Enhanced Interface

    with Project Explorer- Additional Distributions

    - Gamma- Logistic- Loglogistic- Gumbel- Weibull-Bayesian

    - Bayesian Confidence Bounds- Failures/Suspensions Plots- Integrated RBDs- Enhanced Warranty Analysis- Recurrence Data Analysis

    - Parametric (GRP)- Non-Parametric (MCF)

    - New Degradation Models- Gompertz- Lloyd-Lipow

    - Event Log Data Entry Sheet- Using Simulation for

    Risk Analysis and Probabilistic Design

    - SimuMatic- Enhanced Reporting Utility

    Requirements: Windows NT, 2000 or XP. Support: ReliaSofts unparalleled after-sale support includes free telephone, fax and e-mail support.

    Free minor version updates are also included.Integration: ALTA, BlockSim, RENO, RGA, Xfmea and RCM++.

    For more information:

    Phone: +1.520.886.0410 Toll Free: 1.888.886.0410 (U.S. and Canada)Fax: +1.520.886.0399 E-mail: [email protected]: http://Weibull.ReliaSoft.com

    http://Whttp://Weibull.ReliaSofeibull.ReliaSoft.comt.com

  • Page 16 Volume 7, Issue 1Continued from Page 11: Ongoing Comprehensive Warranty Analysis for Repairable Systems

    As shown in Figure 4, we first verify the assumption that is close to 1; it is. Figure 4 also shows the accumulatednumber of failures per system at 5,500 miles.

    Note: If < 1, this could be a sign that the environment inwhich the systems are operated is changing over time (e.g.less harsh use of the systems). In other words, even if nocorrective actions were implemented, it is possible to seeimprovement in the systems. This, however, should not beinterpreted as actual growth or configuration improvement.Rather, the failure times may be extended because the useconditions are becoming less stressful. If there are actualengineering changes that caused < 1, the use of the CrowExtended model's BC modes classifications may be justifiedand the model may be used to evaluate the reliabilityimprovement. If > 1, the use of the Crow Extended model isnot recommended. This is a negative trend, which means thatthe average warranty reliability is getting worse with eachconfiguration build. In such cases, this issue should becorrected and future system configurations should bestabilized ( close to 1) before direct projection analysis maybe applied using the Crow Extended model.

    ConclusionWarranty analysis and forecasting is an important activity

    for manufacturing companies. It plays a central role infinancial planning for warranty repair cost estimates and indetecting alarming reliability issues. This article presenteddifferent types of practical warranty analysis for repairablesystems that can be performed in RGA 6 to address variousdata types and questions. These types of methodologies canbe utilized at different stages of the warranty period and usedto look at the warranty data from different vantage points. Formore information, go to http://RGA.ReliaSoft.com and look foradditional articles in future issues of the Reliability Edge andReliability HotWire. The RGA software and this article weredeveloped in cooperation with Larry H. Crow of CrowReliability Resources.

    SystemID

    EndTime Failure Time(s) Class. Mode

    1 5000 1396 BD FM12 5000 4497 BD FM23 5000 525 A FM144 5000 1232 BD FM35 5000 227 BD FM46 5000 135 BD FM27 5000 19 BD FM28 5000 812 BD FM19 5000 2024 BD FM1

    10 5000 316, 943 BD, A FM5, FM1411 5000 60 BD FM112 5000 4233, 4234 BD, BD FM2, FM613 5000 1877, 2527 BD, BD FM7, FM214 5000 2074, 2105 BD, BD FM4, FM215 5000 4079 BD FM116 5000 546, 577 BD, A FM1, FM1417 5000 453, 4085 BD, BD FM8, FM118 5000 1023 A FM1419 5000 161 BD FM320 5000 36, 4767 BD, BD FM2, FM121 5000 2795, 3375, 4228 BD, BD, BD FM1, FM9, FM122 5000 68 BD FM1023 5000 1830 BD FM124 5000 1241 BD FM1125 5000 871, 2573 BD, BD FM12, FM126 5000 3556 BD FM1327 5000 186 BD FM2

    Table 5: Across Warranty with Failure Modes Data

    Figure 4: Parameter Bounds and Number of Failurescalculated for the Across Warranty with Modes Analysis

    Sample Data and RGA 6 InstructionsSince this analysis studies the effect of future reliability

    improvements on the fleet, the only logical failure modeclassifications are A (no action) and BD (delayed fixes); no BCfailure mode classification should be used for this analysissince it represents failure modes that receive improvementsduring the observed operating period. Similarly to theprevious analysis type, this analysis requires grouping thedata by a certain interval increment. This type of analysis usesthe following data type and model in RGA 6:

    Fleet (under Fielded Systems)Crow Extended Model

    The data set in Table 5 was gathered from the failure logsof 27 military systems during their warranty period (5,000miles). The manufacturer tracks the failures by mileage ofoccurrence and records the failure cause based on failureanalysis performed when the manufacturer is requested torepair failures and decide whether the failure mode needs tobe addressed in a future planned improvement (BD modes) orcan be ignored (A modes).

  • Supports the Equipment Selection, Failure Effect Categorization and Maintenance Task Selection logicfrom the major RCM standards and allows you to customize the logic to meet specific needs.

    Provides simulation-based calculations to compare maintenance strategies based on cost and averageavailability over the life of the equipment and to calculate the optimum interval for preventivemaintenance tasks.

    Provides a complete set of print-ready reports generated in Microsoft Word or Excel, a variety ofpareto (bar), pie and matrix charts and a flexible query utility.

    Allows multiple users to work cooperatively on the analysis and provides numerous ways to leverage thelessons learned from previous analyses, including copy/paste, import/export, etc.

    Incorporates FMEA/FMECA capabilities, including Risk Priority Numbers (RPNs), Criticality Analysis,recommended actions tracking, etc.

    And much more...

    http://RCM.ReliaSoft.com

    Xfmea facilitates Failure Mode and Effects Analysis (FMEA) and Failure Modes, Effects andCriticality Analysis (FMECA) and provides flexible data management and reporting capabilities.

    Supports the major industry standards, such as SAE J1739, AIAG FMEA-3 and MIL-STD-1629A, for alltypes of FMEA/FMECA.

    Provides extensive capabilities to customize the interface and reports.

    Supports Risk Priority Numbers (RPNs) and Criticality Analysis for risk assessment.

    Provides a complete set of print-ready reports generated in Microsoft Word or Excel, a variety ofpareto (bar), pie and matrix charts and a flexible query utility.

    Allows multiple users to work cooperatively on the analysis and provides numerous ways to leverage thelessons learned from previous analyses, including copy/paste, import/export, etc.

    And much more...

    http://Xfmea.ReliaSoft.com

    RCM++ facilitates analysis, data management andreporting for Reliability Centered Maintenance(RCM) analysis.

    EEXPERTXPERT SSUPPORTUPPORT FORFOR AALLLL TTYPESYPESOFOF FMEAFMEA ANDAND FMECAFMECA SMSM

    Putting the Reliability back into Putting the Reliability back into Reliability Centered MaintenanceReliability Centered Maintenance TMTM

  • Data Entry Tips for RGA

    If you are using the Crow Extended model, you can enterthe Classification and Mode data together in theClassification column (e.g. BC1) and then select ParseModes from the Data menu to separate the Classification(e.g. BC) from the Mode (e.g. 1).

    You can copy/paste data from an Excel spreadsheet oruse the File Import Wizard to import data from Excel(select Import from the File menu).

    The Advanced System View (select Advanced SystemView from the View menu) provides an alternativeinterface for entering data for multiple systems. Tosimplify data entry, this view uses a separate spreadsheetfor each system in the analysis, as shown next.

    Easy Data Entry Techniques for Xfmea

    You can import system configuration data (e.g. Bill ofMaterials) and FMEA data from Excel spreadsheets. Therequired import templates are installed in the Examplesfolder in the application directory. To import systemconfiguration data, select Import Items then From ExcelSpreadsheet from the Project menu. To import FMEAdata, select Import/Export Items FMEA then Importfrom Excel from the System Hierarchy menu.

    Xfmea provides flexible import/export and copy/pastefunctionality to re-use portions of existing analyses. Inaddition, the Import Wizard (select Import Wizard fromthe Project menu) combines query and importcapabilities to allow you to search for, and import, existinganalyses based on any item property (e.g. DesignEngineer, Part Number, Supplier, etc.).

    The Select Existing utility is available for every text fieldwithin Xfmea. It allows you to search for and re-use textfrom an existing analysis or phrase set. To access, clickthe icon on the right side of the description field.

    The Bulk Add feature allows you to create multiplerecords at the same time using existing descriptions fromother analyses and/or pre-defined phrase sets.

    Volume 7, Issue 1 Page 19

    Data Entry Shortcuts for Weibull++ and ALTAWhen entering complete and right-censored (suspended)data, a positive number in the time column is treated as afailure and a negative number is treated as a suspension.The software automatically inserts the F or S into theState F or S column.

    For grouped data entry, the software automatically insertsa 1 into the Number in Group or Number in Statecolumn if you leave it blank.

    You can copy/paste data from an Excel spreadsheet orimport data from an Excel or delimited text file. In ALTA orWeibull++ 6, select Import from the File menu. InWeibull++ 7, select Add from File from the Projectmenu.

    Time-Saving Shortcuts for BlockSim

    Selecting another block name from the Active Blockmenu at the bottom of the Block Properties window savesany changes to the current block and displays theproperties for the block you have selected.

    You can apply the properties of a selected Template blockto all blocks with the same name or part number that existin the current projects Diagram Sheets and Templates.Select the Template block then select Global Update byName or Global Update by Part Number from the Blockmenu or shortcut menu, as shown next.

    The Format Painter tool (select Format Painter from theEdit menu) allows you to copy the block properties and/orstyle from one block and apply them to another block inthe current Diagram Sheet.

    Any change that you make in the Block Properties orBlock Style window will be applied to all currently selectedblocks. To select multiple blocks, drag a box around agroup of blocks or press Ctrl while clicking each block.

    The Multi blocks feature saves time and space byallowing you to use a single block in the diagram torepresent multiple blocks with the same properties.

    Software Tips: Data Entry Shortcuts

  • Page 20 Volume 7, Issue 1

    The organization's Failure Reporting Analysis andCorrective Action System (FRACAS) is a valuable tool forcapturing the details related to incidents for a product orprocess (i.e. failures, events, suggestions, etc.) and followingup with the appropriate corrective actions. When there aremany incident reports that all result from the same underlyingproblem, the organization may choose to assemble a teamthat has the responsibility to take whatever actions may benecessary to effectively resolve the problem.

    There are many different approaches to team-basedproblem solving, each with its own acronyms and buzzwords.Some methodologies can be described with four steps, suchas PDCA (plan, do, check and act) or DCOV (define,characterize, optimize and verify). Some methodologies usefive steps, such as DMAIC (define, measure, analyze,improve and control) or DMEDI (define, measure, explore,develop and implement). Other methodologies, such as the8D (TOPS) approach, use eight steps.

    This article provides a brief overview of three commonlyused problem solving methodologies -- 8 Disciplines (8D), SixSigma DMAIC and the PDCA cycle (Deming Cycle) -- anddescribes how ReliaSoft's XFRACAS system can beconfigured to fit these and other problem solving approaches(from 4 to 8 steps).

    8 Disciplines (8D) - TOPSThe 8 Disciplines (8D) approach, sometimes also referred

    to as "Team-Oriented Problem Solving (TOPS), wasdeveloped within Ford Motor Company in the 1980s. As thenames imply, the approach involves a cross-functional teamfollowing eight guidelines (or steps) that have been designedto enable the team to understand a problem, resolve it andtake steps to prevent the same or similar problems fromrecurring in the future. The approach consists of the following8 Disciplines (8Ds).

    D1 - Use Team ApproachEstablish a team (with an effective team leader) that hasthe knowledge, time, authority and skill to solve theproblem and implement corrective actions.

    D2 - Describe the ProblemFully describe the specific problem in measurable terms.

    D3 - Contain the ProblemDefine and implement intermediate actions that willprotect the customer from the problem until permanentcorrective action can be implemented. Verify theeffectiveness of these actions.

    D4 - Identify/Define and Verify Root CausesIdentify all potential causes that could explain why theproblem occurred. Test each potential cause against theproblem description and data. Identify alternativecorrective actions to eliminate the root cause.

    D5 - Choose Corrective ActionsChoose corrective actions that will permanently resolvethe problem for the customer and will not causeundesirable side effects. Define other actions, ifnecessary, based on the potential severity of the problem.

    D6 - Implement/Validate Corrective ActionsImplement and validate the permanent corrective actionsthat have been identified. Choose ongoing controls toensure that the root cause has been eliminated. Once inproduction, monitor the long-term effects and implementadditional controls as necessary.

    D7 - Prevent RecurrenceIdentify and implement steps that need to be taken toprevent the same or a similar problem from occurring inthe future.

    D8 - Reward the TeamRecognize the collective efforts of the team and take theappropriate steps to make sure that the organizationlearns from what they did.

    Six Sigma DMAICThe DMAIC process (often pronounced duh-MAY-ick)

    which is a key component of the Six Sigma methodologies,provides another structured approach to understanding andaddressing an identified problem. This approach consists ofthe following five steps.

    D - DefineDefine the problem that needs to be resolved.

    M - MeasureDevelop and implement a plan to collect any data thatmay be required to understand and address the problem.

    A - AnalyzeAnalyze the data to determine the root cause of theproblem and evaluate what corrective actions would beappropriate.

    I - ImproveIdentify creative solutionsto address the problem.Develop and deploy theimplementation plan forcorrective actions.

    C - ControlEstablish an ongoingmonitoring plan and takewhatever steps may benecessary to keep theissue under control in thefuture.

    Team-Based Problem Solving Methods and XFRACAS

    Please Turn to Page 21

  • Volume 7, Issue 1 Page 21

    Plan - Do - Check - Act CycleThe Plan - Do - Check - Act cycle (also called the PDCA

    cycle, the Deming Wheel or the Shewhart cycle) is anothercommonly employed problem solving approach. In use sincethe 1940s and 50s, this four-step process was designed to berepeated until an effective solution has been employed. Thisapproach consists of the following steps.

    PlanSelect and clearly define the problem to be analyzed. Seta measurable goal for solving the problem. Analyze andidentify the root cause of the problem.

    DoConsider possible solutions to the problem. Select, planand implement the solution on a limited (pilot) basis.

    Check (or Study)Gather data and analyze the pilot implementation for theproposed solution. If the solution did not prove to beeffective, repeat the process in order to develop and testan alternative solution.

    ActIdentify and perform the actions that are required toimplement the solution on a larger scale and plan forongoing monitoring of the solution.

    The cycle begins again when the organization identifiesthe next problem or further opportunities for improvement.

    Configuring XFRACAS to Support Your ProcessReliaSofts XFRACAS system is a Web-based, closed-

    loop, incident (failure) reporting, analysis and correctiveaction software system (FRACA / FRACAS) designed for the

    acquisition, management and analysis of product reliability,quality and safety data from multiple sources, along with themanagement of problem resolution activities.

    Although XFRACAS provides the tools necessary toaddress and "close the loop" on each reported incidentindependently, a team-based problem resolution approachcan be more efficient and effective when individual incidentreports signal an underlying problem that needs to beresolved. XFRACAS provides a flexible framework for this viathe Problem Resolution Report (PRR) interface. With the PRRapproach, you can assign multiple incident reports to a singlePRR. Resolving the underlying problem addresses all relatedincidents and improves the design and/or the process toprevent similar problems from occurring in the future. Thesystem administrator can configure the PRR interface tosupport any problem resolution methodology, from 4 to 8steps. For example, Figure 1 shows the XFRACAS systemconfigured for the DMAIC approach while Figure 2 shows an8D configuration.

    The PRR utility provides a configurable array of tools toenable you to coordinate and manage problem solvingactivities. In addition to the systems powerful closed-loopaction management capabilities (with automated e-mailnotifications, easily generated status reports, etc.), XFRACASalso allows you to create checklists, link or attach relateddocuments, query the knowledge base of pastissues/solutions, identify stages (gates) that require formalreview/approval, and much more. For more information on theXFRACAS system, please visit the product Web site athttp://XFRACAS.ReliaSoft.com or contact ReliaSoft.

    Continued from Page 20: Team-Based Problem Solving Methods and XFRACAS

    Figure 1: The DMAIC Process in XFRACAS Figure 2: The 8D Process in XFRACAS

  • A comprehensive platform forStandards Based

    Reliability Prediction Analysis

    BlockSim algebraically computes exact system reliability results and optimum reliabilityallocations. The software also provides a sophisticated discrete event simulation engine forreliability, maintainability, availability, throughput, life cycle cost summaries and relatedanalyses.

    BlockSim 6 SBlockSim 6 Sttandard andard uses a Reliability Block Diagram (RBD) approach to model systems.Configuration options include Series, Parallel, Complex and k-out-of-n plus Load Sharing andStandby Redundancy. Mirrored, multi and subdiagram blocks provide additional modelingflexibility.

    BlockSim 6 FTIBlockSim 6 FTI provides integrated support for Fault Trees, RBDs or a combination of both!BlockSim supports all of the traditional fault tree gates (AND, OR, Voting, etc.) and event symbols(Basic, Trigger, Conditional, etc.) and introduces new logic gates to represent Load Sharing andStandby Redundancy configurations.

    http://BlockSim.ReliaSoft.com

    The Ultimate System The Ultimate System VVisualization and isualization and Analysis TAnalysis Toolool SMSM

    ReliaSofts Lambda Predict provides a comprehensive platform for Standards Based ReliabilityPrediction analysis, including all major reliability prediction standards, an extensive set ofcomponent libraries, results, plots, reports, and more!

    Supports MIL-HDBK-217, Bellcore (Telcordia), RDF 2000 and China 299B for the analysis ofelectronics and related components plus NSWC-98/LE1 for mechanical components.Available component libraries provide data for over 240,000 components, including capacitors,diodes, resistors, coils, integrated circuits and the electromechanical components from RACNPRD.Provides a complete array of calculated results, plots and reports, including Failure Rates,MTBFs, Pi Factors and other metrics.And much more...

    http://Predict.ReliaSoft.com

  • Volume 7, Issue 1 Page 23

    For Your Information Bulletin BoardSeminarsThe next Master the Subject, Master the Tools Foundations Series trainingseminars are scheduled for November 14 - 18 in Tucson, Arizona and also inSingapore. On the Web at http://Seminars.ReliaSoft.com.

    ReliaSoft continues to address the needs ofour global customers by expanding ourworldwide presence through regional centersand independent sales/support partners. Inaddition to our U.S. headquarters and majorregional offices in Europe, South America, AsiaPacific and India, we have partnered with anumber of country-specific distributors for localsales and support assistance.

    One of the many benefits of having a localpresence can be illustrated with the recentrelease of multiple language interfaces forWeibull++. Built-in language support forGerman, Portuguese, French, Spanish andChinese are now available in version 7.1 andare free to registered users of Weibull++. Formore information, see:http://Weibull.ReliaSoft.com/multilanguage.htm. Multi-language support for other ReliaSoftsoftware will be released to the public as thelanguage packs become available.

    Another outcome of our global presencecan be seen with training courses now offeredin locations around the world. Please check ourworldwide seminar calendar on the Web athttp://Seminars.ReliaSoft.com/dates.htm for alook at publicly scheduledcourses, dates and locations.On-site training is alsoavailable worldwide. Technical SupportPhone: +1.520.886.0366 Fax: +1.520.886.0399 E-mail: [email protected]

    ReliaSoft SalesToll Free: 1.888.886.0410 (U.S. and Canada) Phone: +1.520.886.0410Fax: +1.520.886.0399 E-mail: [email protected]

    --Doug OgdenVP Customer Services

    ReliaSofts Standard Software Products

    Weibull++Version 7.1.2, Built 8/8/06

    Weibull++ DE (Developer Edition)

    Life Data Analysishttp://Weibull.ReliaSoft.com

    http://Weibull.ReliaSoft.com/deved

    ALTA and ALTA PROVersion 6.5.4, Built 6/8/06

    Accelerated Life Test Data Analysishttp://ALTA.ReliaSoft.com

    BlockSim and BlockSim FTIVersion 6.5.4, Built 9/22/06

    System Reliability, Maintainability andAvailability Analysishttp://BlockSim.ReliaSoft.com

    RGAVersion 6.5.2, Built 6/8/06

    Reliability Growth Analysishttp://RGA.ReliaSoft.com

    XfmeaVersion 3.5.3, Built 7/13/06

    Failure Mode and Effects Analysishttp://Xfmea.ReliaSoft.com

    RCM++Version 3.5.3, Built 7/13/06

    Reliability Centered Maintenance http://RCM.ReliaSoft.com

    MPC 3Version 3.0.14, Built 6/15/05

    Maintenance Program Creatorhttp://MPC.ReliaSoft.com

    RENOVersion 1.0.7, Built 2/28/06

    Visual Stochastic Event Simulationhttp://RENO.ReliaSoft.com

    Lambda PredictVersion 1.0.2, Built 10/3/05

    Standards Based Reliability Predictionhttp://Predict.ReliaSoft.com

    ReliaSofts MPC 3 software is an MSG-3 compliant maintenanceprogram creator designed for the aerospace industry. From theidentification of maintenance significant items (MSIs) through theanalysis of functions, failures, effects, causes and tasks, to theautomatic generation of the final Maintenance Review Board(MRB) report, MPC 3 guides you through the entire MSG-3process for Aircraft Systems and Powerplant Analysis.

    Data storage and management in relational databases withsupport for use in team environments.Integration with Microsoft Word for automatic reportgeneration.Time-saving capabilities to re-use text descriptions andportions of the analysis within and among projects.And much more...

    MSG-3 Compliant Maintenance Program Creator

    http://MPC.ReliaSoft.com

  • Prst StdU.S. Postage

    PAIDTucson, AZPermit #541

    ReliaSoft CorporationReliaSoft Plaza115 S. Sherwood Village DriveTucson, AZ 85710

    Volume 7, Issue 1