Quarter 3, 2002
Critical Examination of a Common Assumption in System Availability Computations
In general, availability is defined as the probability that an
item will be able to function (i.e. the item is not failed or
undergoing maintenance) when called upon to do so. The
availability definition takes into account an item’s reliability (how
quickly it fails) and its maintainability (how quickly it can be
restored to operation) and it is therefore a key metric in
repairable systems analysis. Because reliability and availability
are both probabilities, there is a common assumption that the
method used to compute system reliability based on component
data can also be used for system availability calculations.
This article provides a critical examination of this
assumption and we conclude that it is only justified under certain
conditions. In most cases, another factor must be taken into
account when computing system availability.
Comparing System Reliability Computations and System
Availability Computations
To examine whether it is appropriate to compute system
availability with the same method used to compute system
reliability, we must first briefly review the computation method
for system reliability. For a system made up of components
Updating the Classic Reliability Block Diagram Methodology and Constructs
Reliability block diagrams (RBDs) have been around for a
long time, and have been widely used to model systems. A
reliability block diagram is a graphical representation of how
the components of a system are reliability-wise connected. As
with any approach or methodology, reliability block diagrams
have their advantages as well as disadvantages compared to
competing methods. Some of these disadvantages are rooted
in the basic elements and constructs used in a reliability block
diagram.
The constructs in the reliability block diagram methodology
have not changed since its inception. This is unlike many other
techniques/methodologies that have gone through multiple
revisions and changes to improve upon their original capabilities
(e.g. consider the improvements to the HTML markup language
as the methodology has matured). In order to address some of
the current inadequacies in reliability block diagrams, perhaps
it is time to revise the standard to make the methodology easier
Figure 1: Series Configuration
Volume 3, Issue 2
configured reliability-wise in series (i.e. if any one of the
components fails, the entire system will fail), we can simply
multiply the reliabilities of the components and the product is
the estimated reliability of the system. For example, consider a
simple system with two components configured reliability-wise
in series. At some time t, Component 1 has a reliability of 85%
and Component 2 has a reliability of 95%. Therefore, the system
reliability at time t is the product of these two reliabilities. In
other words, the reliability of the system is RS = R1 • R2 = (.85 •
.95) = .8075 or 81%. This simple computation method is based
on the fact that both values are probabilities and both events
must occur (i.e. both components must operate without failure
until time t) for system success at time t. Note: Of course,
components can be configured in parallel and other reliability-
wise configurations. However, in order to simplify the discussion,
only series configurations are discussed in this article.
Like reliability, availability is a probability. Thus, one might
assume, as many people do, that this same technique of
multiplying probabilities could be applied to estimate system
Please Turn to Page 2
to use and also more effective. This article reviews some of
the existing techniques and introduces some new constructs
to the tried and true reliability block diagram approach.
Series, Parallel and Series Parallel Combination
Configurations
The simplest and most elementary configurations of an
RBD are the series and parallel configurations. Items placed in
series must all work for the system to work, as shown in Figure
1, where the system fails if either A, B or C fails. Items placed
in parallel are considered to be redundant, as shown in Figure
2, where either D or B can fail and the system will continue to
Please Turn to Page 5
Figure 2: Parallel Configuration
Page 2 Quarter 3, 2002

In this Issue Continued from Page 1: “Critical Examination of a Common Assumption

in System Availability Computations”

Page 1 availability. For example, in the two- time (on the “system clock”) than it would
♦ Critical Examination of a Common component system described above, have if the system had not been down for
Assumption in System Availability suppose that the point availabilities at time the maintenance of another component.
Calculations t for Component 1 and Component 2 are This effect of system operation is not taken
♦ Updating the Classic Reliability Block 80% and 90%, respectively. If the system into account in the estimation of the
Diagram Methodology and Constructs availability is simply the product of the availability for the individual component
component availabilities then the system and yet it is quite relevant to the availability
Page 2 availability at time t would be AS = A1 • A2 = of the system.
♦ From the Editor’s Desk (.80 • .90) = .72 or 72%.
This method can be justified from a Simple Example to Demonstrate the
Page 7 Effect of System Operation on
probabilistic perspective because both
♦ Guest Commentary: How to Specify Component Availability
items need to be available when called
for Reliability The following deterministic scenario
upon in order for the system to be
Page 8 available. However, the method does not demonstrates the effect of system
operation on component availability.
♦ Failure Modes, Effects and Criticality take into account the effect on component
Analysis availability, if any, when the components Consider a system with two units
are operating together in a system configured reliability-wise in series, where
Page 16 configuration. If the component continues Unit 1 fails every 100 hours and takes 20
♦ Guest Submission: Integrating Weibull to operate even when the system is down hours to restore and Unit 2 fails every 75
Analysis into Bodyshop Reliability
due to the failure of another component, hours and takes 25 hours to restore.
Engineering Furthermore, neither component
then the availability will be the same when
♦ Case Study Report: Failure Reporting, continues to accumulate age when the
calculated individually as it is when
Evaluation and Display (FRED) system is down. The individual
Report calculated with respect to its behavior
within the system. However, if the availabilities of the components for 300
Page 20 component does not continue to operate hours are 86.6% and 75% respectively, as
♦ Resources for the Reliability when the system is down, then its shown in Figures 1 and 2 (page 3).
Professional on weibull.com availability will be different within the However, when we analyze the
system than when calculated individually. components operating together in a
Page 23 This is because when the system is down system, we see that Unit 2 will fail first at
♦ For Your Information 75 hours, causing the system to fail. The
due to the failure of another component,
♦ Bulletin Board the given component will not accumulate system will then be undergoing
age. Therefore, although the “system maintenance for 25 hours and will be
clock” will advance by the amount of time operational again at 100 hours. At 125
Reliability Edge is published four times a year. To that it takes to restore the other hours, the system will fail again, this time
obtain a free subscription, to send comments or to
component, the “component clock” for the due to Unit 1. This is because Unit 1 fails
submit articles for consideration:
given component will not advance and the after 100 hours of operation and it had
ReliaSoft Publishing
ReliaSoft Plaza component will be likely to fail at a later Please Turn to Page 3
115 S. Sherwood Village Drive
Tucson, AZ 85710 USA
Telephone: +1.520.886.0366 Fax: +1.520.886.0399
E-mail: ReliabilityEdge@ReliaSoft.com
From the Editor’s Desk...
This issue of Reliability Edge includes To submit, please prepare the article
Correspondence with the editor may be published, in two guest submission articles: a case in Microsoft Word and e-mail it to
whole or in part, in future issues of ReliaSoft
publications. study from Dave Whetton to demonstrate ReliabilityEdge@ReliaSoft.com. We will
An electronic copy of this document can be viewed an effort to integrate Weibull analysis into review the article and will notify you of our
or downloaded from: www.ReliaSoft.com/newsletter bodyshop engineering (page 16) and a intention to publish, then cooperate with
For information about products and services:
guest commentary on reliability you on any proofreading/editorial changes
ReliaSoft Sales specifications from Thimmiah Gurunatha that may be required. If the article includes
ReliaSoft Plaza (page 7). We appreciate their willingness graphics, we may request that you provide
115 S. Sherwood Village Drive
Tucson, AZ 85710 USA
to share their experiences with colleagues the original graphics in electronic format.
Telephone: +1.520.886.0410 Fax: +1.520.886.0399 and invite you to do the same. Prior to publication, you will be asked to
E-mail: Sales@ReliaSoft.com We welcome guest submission review and approve the final version of the
Web Site: www.ReliaSoft.com
articles on topics of interest within reliability article as it will appear in
This document may be reproduced without engineering and related fields. In general, Reliability Edge and to
permission provided that it is not altered in any way
and all pages are included in any reproduction.
we expect guest submission articles to be sign and submit a
relevant, readable and theoretically sound. publication release form.
©2002 ReliaSoft Corporation, ALL RIGHTS RESERVED.
ReliaSoft, Weibull++, Weibull.com, Reliability Edge, ALTA, The decision to publish (or not publish) a
BlockSim and RG are registered trademarks of
ReliaSoft Corporation.
specific article is made by our editorial
review panel. --Lisa Hacker
Quarter 3, 2002
Continued from Page 2: “Critical Examination of a Common Assumption in System Availability Computations”
accumulated 75 hours before system failure and another 25
after the system was restored. The same process can be
repeated yielding the system results shown in Figure 3.
As the example demonstrates, the distinction of whether a
component continues to operate when the system has failed
or if a component can fail when the system is undergoing repair
is very important and needs to be taken into account when
performing such analyses. Likewise, the computation used to
estimate system availability must take into account the
availabilities of the components with respect to their operation
within the system. The component availabilities determined
individually and with respect to system operation will be the
same only in situations where the component is not affected
by the failure of other components and/or the system (or where
no other components fail within the given time).
Figure 1: Up and Downtimes for Unit 1 Individually
Figure 2: Up and Downtimes for Unit 2 Individually
Figure 3: Up and Downtimes for the System
Page 3
Mathematical Demonstration
The following example mathematically demonstrates the
effect of the assumption that the system availability is always
simply the product of the component availabilities.
Consider a very simple system with two identical
components configured reliability-wise in series, and with
constant failure and repair rates. Both components cease to
operate when the system is down. (Note: We assume the
exponential distribution for both times-to-failure and times-to-
repair in order to simplify the calculations, while recognizing
that the exponential distribution is rarely appropriate to describe
failure behavior in the real world. The term “repair” is used to
describe the maintenance action required to restore the
component to operation and we assume that the component is
“good as new” as a result of the maintenance action.)
Since both the failure and repair distributions are
exponential, a closed-form solution can be easily obtained for
the point availability of each component. This is given by:
If we assume that the point availability for the system is
equal to the product of the component availabilities then:
or, for this example:
Eqn (1)
Since we are using a simple exponential distribution for
both the failure and repair distributions, it is easy to determine
the system availability using another methodology such as
Markov analysis. By comparison with the Markov result, we
can evaluate the assumption that the system availability is the
product of the component availabilities. The first step in the
Markov approach is to determine the possible system states.
These are:
• System is up (both units operate).
• System is down (unit 1 failed).
• System is down (unit 2 failed).
It is possible to make the argument that a fourth state exists:
“System is down due to the failure of both Unit 1 and Unit 2.”
However, for this fourth state to exist, both components must
Please Turn to Page 4
Page 4 Quarter 3, 2002
Continued from Page 3: “Critical Examination of a Common Assumption in System Availability Computations”
continuously operate regardless of the system status. If a represents the mean availability using Eqn (1) and the blue
system failure causes the system to shut down and line represents the mean availability using Eqn (2). The mean
subsequently stops the operation of the non-failed component, availability will also differ and is given by:
then this state is not possible (since both components would
have to fail at the same infinitesimal instant dt). Because the
components in this example do not continue to operate when
the system is down due to the failure of another component,
we can disregard this fourth possibility.
Now, and based on the three possible states, the Markov
diagram is as shown in Figure 4. From this, the point availability Conclusion
is given by: The examples in this article demonstrate that the simple
computation method of multiplying component availabilities is
appropriate only if all of the components in the system continue
Eqn (2) to operate even when the system is down due to the failure of
another component (i.e. when the operation of the overall
system has no effect on the operation of the component). If
this is not the case, then the overall effect of system operation
As it can be seen, the equations from multiplying the must be taken into account when computing system availability.
availabilities, Eqn (1) on page 3, and from the Markov analysis, If the effect of system operation is not taken into account then
Eqn (2), are different. This implies that the assumption that the the availability computation is likely to underestimate the
system availability is the product of the availabilities of the availability of the system.
RS
components is not appropriate under the circumstances of this
example. Further examination of the two equations reveals that
if Eqn (1) is used, we actually underestimate the system
availability. This is because Eqn (1) provides the availability of
the system when components continue to operate even if the
system is not operating. In other words, Eqn (1) allows for
component failures while the system is down and undergoing
repair; whereas Eqn (2) takes into account the fact that if the
system is not operating then non-failed units become idle (and
therefore do not continue to accumulate age) while the system
is undergoing repair.
Figure 5 illustrates the comparison between the two
methods to compute availability. In this plot, the red line

Figure 5: Plot of Mean Availability vs. Time

Figure 4: Markov Diagram for the Simple System
Authors
Unless otherwise attributed, the articles in Reliability Edge
have been developed by ReliaSoft’s R&D staff. This dedicated
team of engineers, statisticians, mathematicians and
programmers works continuously with top experts in the
discipline to develop principles and theory that significantly
advance the current state of research and with industry
practitioners to successfully apply those principles in the field.
Contributing authors hold advanced degrees in Reliability
Engineering and related fields.
Quarter 3, 2002 Page 5
Continued from Page 1: “Updating the Classic Reliability Block Diagram Methodology and Constructs”
function. The concept can be expanded further, as shown in (such as the diagram in Figure 3) and thus require a more
Figure 3, with combinations of series and parallel configurations advanced analytical treatment. A network is a good example
in the same diagram. These elementary configurations form of system requiring a “Complex” reliability block diagram and
the basis of the reliability block diagram constructs. Figure 4 illustrates an example of this RBD type.
Complex Configurations K-out-of-N Nodes
If one takes the approach a step further, “Complex” block The creation of reliability block diagrams with series,
diagrams can be created. “Complex” diagrams cannot be parallel, combination and complex configurations required the
expressed as a simple combination of series and parallel blocks use of blocks and lines only. To extend the functionality of a
block diagram, one needs to
introduce some additional elements
to the “tool kit.” One such element is
the k-out-of-n node, which allows the
analyst to specify an alternative form
of redundancy known as k-out-of-n
redundancy. A k-out-of-n node can
have n paths leading into it, and
requires that k of those n paths must
function for the system to function.
Figures 5 and 6 present RBDs that
incorporate such nodes. The
configuration in Figure 5 includes a
Figure 3: Combination of Series and Parallel Configurations Please Turn to Page 6

Figure 4: Complex System Configuration Figure 5: k-out-of-n Node Configuration

FigureFigure 4: Complex
6: Complex System Configuration
Configuration with 2-out-of-5 Node
Page 6
Continued from Page 5: “Updating the Classic Reliability Block Diagram Methodology and Constructs”
k-out-of-n node where either B, C or D must operate for the
system to function but any two of the other items may fail without
causing system failure. With the traditional reliability block
diagram methodology, k-out-of-n redundancy could have been
specified for units drawn in parallel. However, with the
introduction of the node element in the diagram, one can specify
such redundancy for complex configurations, such as the one
shown in Figure 6 (page 5).
Standby Containers
A Standby Container can be used to represent items
configured with standby redundancy. Standby redundancy
configurations consist of items that are inactive and available
to be called into service when/if the active item fails (i.e. on
standby). A container block, with other blocks inside, is utilized
to better achieve and streamline the representation and analysis
of standby configurations. The container serves a dual purpose.
The first purpose is to clearly delineate and define the standby
relationships between the active unit(s) and standby unit(s).
The second purpose is to serve as the manager of the switching
process. For this purpose, the container can be defined with
its own probabilities of successfully activating standby units
Figure 7: Configuration with Standby Container
Figure 8: Configuration with Load Share Container
Quarter 3, 2002
when needed. Figure 7 includes a standby container with three
items in standby configuration where one component is active
while the other two components are idle. One block within the
container must be operating or, because the container block is
part of a series configuration, the system will fail.
Load Share Containers
The container concept can be expanded to also represent
load sharing configurations. As the name implies, load sharing
configurations consist of a components that are in load sharing
redundancy. Units in load sharing redundancy exhibit different
failure characteristics when one or more fail. In Figure 8, units
1, 2 and 3 are in a load share container and have their own
failure characteristics. All three must fail for the container to
fail. However, as individual items fail, the failure characteristics
of the remaining units change since they now have to carry a
higher load to compensate for the failed ones.
In addition to Standby and Load Share containers, other
new types of blocks can be used to increase the versatility of
reliability block diagram constructions and facilitate more rapid
creation of diagrams that are easier to read. These include
Subdiagram Blocks, Multi Blocks and Mirror Blocks, which are
described next.
Subdiagram Blocks to Represent Inheritance
A Subdiagram Block inherits some or all of its
properties from another block diagram. This allows the
analyst to maintain separate diagrams for portions of a
system and incorporate those diagrams as components
of another diagram. With this technique, it is possible to
generate and analyze extremely complex diagrams
representing the behavior of many subsystems,
subsubsystems etc. in a manageable way. In Figure 9,
Subdiagram Block A in the top diagram represents the
series configuration of the subsystem reflected in the
middle diagram, while Subdiagram Block G in the middle
diagram represents the series configuration of the
subsubsystem in the bottom diagram.
Please Turn to Page 7
Figure 9: Subdiagram Blocks to Represent Inheritance
Quarter 3, 2002
Continued from Page 6: “Updating the Classic Reliability Block
Diagram Methodology and Constructs”
Multi Blocks to Save Time and Space
By using Multi Blocks, a single block can represent multiple
identical blocks in series or in parallel configuration. This
technique is simply a way to save time when creating the RBD
and to save space within the diagram. Each item represented
by a Multi Block is a separate entity with identical reliability
characteristics to the others. However, each item is not rendered
individually within the diagram. In other words, if the RBD
contains a Multi Block that represents three identical
components in a series configuration, then each of those
components fails according to the same failure distribution but
each component may fail at different times. Because the items
are arranged reliability-wise in series, if one of those
components fails, then the Multi Block fails. It is also possible
to define a Multi Block with multiple identical components
arranged reliability-wise in parallel or k-out-of-n redundancy.
Mirror Blocks to Simulate Bi-Directional Paths
While Multi Blocks allow the analyst to represent multiple
items with a single block in the RBD, Mirror Blocks can be
used to represent a single item with more than one block placed
in multiple locations within the diagram. Mirror Blocks can be
used to simulate bi-directional paths within a diagram. For
example, in a reliability block diagram for a communications
system where the lines can operate in two directions, the use
of Mirror Blocks will facilitate realistic simulations for the system
maintainability and availability. It may also be appropriate to
use this type of block if the component performs more than
one function and the failure to perform each function has a
different reliability-wise impact on the system.
Conclusion
As this article demonstrates, it is possible to update and
expand the techniques available for reliability block diagrams
in order to increase the effectiveness of the analysis tool and
also improve the ease of creation and appearance of the
diagrams. The proposed enhancements to the methodology
include complex configurations, k-out-of-n nodes, Standby and
Load Sharing containers, Subdiagram Blocks to represent
inheritance from other diagrams, Multi Blocks to represent
multiple identical blocks and Mirror Blocks to represent the
same block in multiple locations within the diagram. ReliaSoft’s
BlockSim 6 software supports all of the standard RBD
techniques as well as the enhancements discussed in this
article. On the Web at http://BlockSim.ReliaSoft.com.
RS
Page 7
Guest Commentary
How to Specify for Reliability
Thimmiah Gurunatha
Principal Engineer - Xerox Corporation
TG Rainbow Incorporated
PE, CRE, CSSB and Six Sigma Master Black Belt - ASQ
As an American Society of Quality Six Sigma instructor
and mentor, I have observed abundant evidence that the
effective utilization of reliability specifications can be a
challenge to engineers. To address this challenge, I propose
for your consideration a simple step-by-step approach to
implement and integrate reliability specifications:
• Benchmark current reliability numbers for the function you
are replacing in your new design.
• Make sure that you consider both your past products and
the products of your competitors.
• Understand the current failure modes of the best product
and innovate to improve the reliability.
• Ensure that you do not create new failure modes.
• Based on the leading failure mechanisms of the system
or component, determine the survival distribution by
testing. I recommend accelerated testing.
• Specify the 2%, 50%, 63.2% (Characteristic Life) and 98%
failure points in hours, days, cycles or years, as
applicable.
• Ensure that you call out the real stresses under which
the component or subsystem is used. This is critical for
getting good correlation of test data to real life.
• Determine critical parameters that drive the quality and
reliability.
• Specify the reliability and critical specification of
parameters that drive the failure mechanisms. Parameter
specification comes from characterization and
optimization test results.
• Include a warranty note in the drawing to enable proper
controls at the supplier for the quality today, tomorrow
and thereafter.
• Ensure that proper field returns procedures are in place
to find root cause of failures.
• Ensure that you have resources and tools available for
immediate feedback to the source of problems.
To demonstrate the effectiveness of this methodology, I
would like to conclude with an example of its implementation.
The example involves a clean sheet design of a complex
product intended to replace the existing fleet with lower cost
units at no extra service cost. When the activity started, the
actual was 1 million cycles and the target was 5 million cycles.
By implementing the methodology described above, the
company was able to achieve a design with predicted reliability
from accelerated testing of 26 million cycles. For one
component, we were able to improve the reliability by 26 times
at no extra cost to the component, two years before launch!
Page 8 Quarter 3, 2002

Failure Modes, Effects and Criticality Analysis

Failure Modes and Effects Analysis (FMEA) and Failure • Current Controls: Examine the control mechanisms that
Modes, Effects and Criticality Analysis (FMECA) are will be in place to eliminate or mitigate the likelihood that
methodologies designed to identify potential failure modes for the potential failures will occur (e.g. end of line inspections,
a product or process before the problems occur, to assess the design reviews, etc.).
risk associated with those failure modes and to identify and • Recommended Actions: Identify the corrective actions
carry out measures to address the most serious concerns. that need to be taken in order to eliminate or mitigate the
This article presents a brief general overview of FMEA and risk and then follow up on the completion of those
FMECA analysis techniques and applications. ReliaSoft’s Xfmea recommended actions.
software has been designed to automate and facilitate the
• Prioritize Issues: Prioritize issues for corrective action
FMEA/FMECA process and provide flexible data management
according to a consistent standard that has been
and reporting capabilities.
established by the organization. Risk Priority Number (RPN)
ratings and Criticality Analysis are common methods of
FMEA/FMECA Analysis Overview
prioritization and they are described in more detail later in
There is a great variety within industry as to the specific
this article.
implementation details for individual FMEA/FMECA analyses.
A number of standards and guidelines have been developed • Other Details: Depending on the particular situation and
to set the requirements for the analysis and each organization on the analysis guidelines adopted by the organization,
may have a unique approach to the analysis. Some common other details may be considered during the analysis, such
FMEA/FMECA guidelines/standards include the U.S. as the operational mode when the failure occurs or the
Department of Defense’s MIL-STD-1629A, SAE International’s system’s intended mission.
J1739 and ARP5580 documents (for automotive and non- • Report: Generate a report of the analysis in the standard
automotive applications, respectively) and the Automotive format that has been established by the organization. This
Industry Action Group’s (AIAG) FMEA-3. In addition, some is generally a tabular format similar to the one shown in
practitioners distinguish various types of FMEA/FMECA Figure 1. In addition, the report may include block diagrams
analysis based on the item or process that is analyzed, the and/or process flow diagrams to illustrate the item or
stage in the manufacturing/development process when the process that is the subject of the analysis. If applicable,
analysis is performed and/or whether the analysis is performed the criticality analysis may be included in a separate table
on the hardware or the functions that the item is expected to and various plots/graphs can be included to display
perform. Some commonly acknowledged FMEA types include, statistics on the modes and rankings.
but are not limited to, Design FMEA (DFMEA), Process FMEA
(PFMEA), Functional FMEA and System FMEA. Figure 2 (page 9) shows ReliaSoft’s Xfmea interface with
Even though there are many different types and standards, the functions, failures, effects and causes displayed in a
most FMEAs/FMECAs consist of a common set of procedures. hierarchical fashion. The software also provides a “Worksheet
In general, FMEA analysis is conducted by a cross-functional View” of the analysis, which is similar to the tabular report output.
team at various stages of the design, development and Figure 3 (page 9) shows the properties window for the Failure
manufacturing process and typically consists of the following: Cause, which can be used for data entry and display.
Please Turn to Page 9
• Item/Process: Identify the item or process that will be the
subject of the analysis, including some investigation into
the design and reliability characteristics. For FMEA analysis
of a product or system, the analysis could be performed at
the system, subsystem, component or other level of the
system configuration.
• Functions: Identify the functions that the item or process
is expected to perform.
• Failures: Identify the known and potential failures that could
prevent or degrade the ability of the item/process to perform
its designated functions.
• Failure Effects: Identify the known and potential effects
that would result from the occurrence of each failure. It
may be desirable to consider the effects at the item level
(Local Effects), at the next higher level assembly (Next
Higher Level Effects) and/or at the system level (End
Effects).
• Failure Causes: Identify the known and potential causes
for each failure. Figure 1: Sample FMEA report from the Xfmea software
Quarter 3, 2002
Continued from Page 8: “Failure Modes, Effects and Criticality Analysis”
Prioritize Issues Based on RPN and/or Criticality
As mentioned previously, most FMEA/FMECA analyses
include some effort to prioritize issues in order to determine
the sequence and time-frame for the corrective actions that
will be performed. Although the methods used to set this priority
may vary by organization, two commonly used methods are
described next: Risk Priority Numbers and Criticality Analysis.
Risk Priority Numbers: The risk priority number (RPN)
system is a relative rating system that assigns a numerical
value to the issue in each of three different categories: Severity
(S), Occurrence (O) and Detection (D). The three ratings are
multiplied together to determine the overall RPN for the issue.
The rating scales typically range from 1 to 5 or from 1 to 10
and the criteria used in each rating scale will be determined
based on the particular circumstances for the product/process
that is being analyzed. Because all issues are rated according
to the same set of rating scales, this number can be used to
compare and rank issues within the analysis. However, because
the ratings are assigned relative to a particular analysis, it is
generally not appropriate to compare RPN numbers among
different analyses. The RPN is calculated as follows:
RPN = (S)(O)(D)
Where:
• Severity (S): A rating of the severity or seriousness of each
potential failure effect.
• Occurrence (O): A rating of the likelihood of occurrence
for each potential failure cause.
• Detection (D): A rating of the likelihood of detecting the
failure cause.
Page 9
The following rating criteria are applicable to the battery
failure mode:
• Severity: 8 - Extreme Effect. Product inoperable but safe.
Customer very dissatisfied.
• Occurrence: 5 - Low. Occasional number of failures likely;
expect about 2.7 failures per 1000 due to this cause.
• Detection: 1 - Almost Certain. The operator will almost
certainly be able to detect the failure.
The RPN for the issue is (8)(5)(1) = 40. This risk priority
number is then compared with the ratings for other issues to
help determine which areas to focus on for improvement.
Criticality Analysis: The Criticality Analysis method is
similar to the RPN rating system except that it calculates the
rankings in a different way. Criticality Analysis takes into account
the probability of failure for the item and the portion of the failure
likelihood that can be attributed to a particular failure mode.
The Criticality is calculated for each failure mode as follows:
Criticality = (Q)(FMFR)(PL)
Where:
• Item Unreliability (Q): The probability of failure for the item
at the time of interest for the analysis.
• Failure Mode Ratio of Unreliability (FMFR): The ratio of
the item unreliability that can be attributed to the particular
failure mode. For example, if an item has four failure modes,
then one mode may account for 40% of the failures, a
second mode may account for 30% and the two remaining
modes may account for 15% each.

For example, consider the following partial FMEA for a • Probability of Loss (PL): The probability that the failure
battery, which uses ten point rating scales to rank the severity, mode will cause a system failure (or will cause a significant
occurrence and detection: loss). This is an indication of the severity of the failure effect
and may be set according to the following scale:

Item Function Failure Effect S C au se O D R PN

o Actual Loss = 100%
o Probable Loss = 50%
Battery Provide Fails to System 8 Battery 5 1 40
adequate provide fails to plates o Possible Loss = 10%
relay adequate operate are o No Loss = 10%
voltage power shorted Please Turn to Page 11

Figure 2: Xfmea interface with item and FMEA hierarchies Figure 3: Xfmea Failure Cause Properties window

™Life-Stress Relationships
-Arrhenius
-Eyring
-Inverse Power Law
-Temperature-Humidity
-Temperature-NonThermal
-Proportional Hazards
-General Log-Linear
-Cumulative Damage
™Time-Dependent Stress Profiles
™Life Distributions
-Weibull
-Exponential
-Lognormal
™Maximum Likelihood Estimation
™Confidence Bounds
™Calculated Results
-Reliability & Probability of Failure
-Mean Life
-Warranty Time Information
-B(X) Life
-Acceleration Factor
-Failure Rate
™Automated 2D and 3D Plots
-Probability
-Reliability vs. Time
-Unreliability vs. Time
-Probability Density Function (pdf)
-Failure Rate vs. Time
-Life vs. Stress
-Standard Deviation vs. Stress
-Acceleration Factor vs. Stress
-Residuals Plots
-3D Likelihood Function
-3D Failure Rate vs. Stress
-3D pdf vs. Stress
-3D Reliability vs. Stress
-3D Unreliability vs. Stress
™Degradation Analysis
™Integration with Weibull++ 6
™Customized Analyses
™Automated Reports and Graphs
+1.520.886.0410
A NALYZE ACCELERATED LIFE DATA
WITH UP TO 8 SIMULTANEOUS STRESS
TYPES OR WITH STRESS
PROFILES THAT V ARY
WITH TIME
Quantitative Accelerated Life Testing
In a quantitative accelerated life test, the stress(es) that cause product failure are accelerated under
controlled conditions to cause the product to fail in a shorter period of time. This testing approach
produces time-to-failure information for products more quickly but does not introduce additional failure
mechanisms that would not occur under normal use conditions. Mathematical models can be used
to extrapolate a use-level cumulative distribution function (cdf) for the product from the life data
obtained under accelerated conditions. Quantitative accelerated life data analysis provides reliability
and probability of failure, warranty time, mean life, B(X) life and other reliability metrics for the
product under normal use conditions from accelerated life data.
ALTA 6 and ALTA 6 PRO
The mathematical models required to analyze data obtained from
quantitative accelerated life tests are as complex as they are powerful.
ReliaSoft's ALTA is the first and only commercially available software
package designed expressly for quantitative accelerated life testing
data, using rigorous scientific analysis methods.
This product, the next generation of the ALTA
software, is available in two versions: Standard
(ALTA 6) and Professional (ALTA 6 PRO). Both
versions provide an enhanced interface, expanded
plotting and reporting capabilities, integration with
Weibull++ 6 and additional utilities for degradation
analysis and other supplementary analyses. In
addition, ALTA 6 PRO provides new life-stress
relationship models that allow you to analyze data
from tests with time-dependent stress profiles
or with up to eight simultaneous stress types.
Minimum System Requirements: Windows 98, Me, NT, 2000 or XP. Pentium class processor with 32 MB
RAM, SVGA display and at least 35 MB of hard disk space.
Documentation: Complete and detailed on-line help, as well as printed product documentation and a reference
book that presents accelerated life testing analysis principles and theory.
Support: ReliaSoft’s unparalleled after-sale support includes free telephone, fax and e-mail support and free
minor version updates.
ALTA 6 Standard Price: $995. Upgrade from ALTA 1.0 for $395.
ALTA 6 PRO Price: $4,995 (includes free training course). Upgrade from ALTA 1.0 or from
ALTA 6 Standard for $4,195 (includes free training course).
For a free evaluation copy or additional information:
Phone +1.520.886.0410
Fax +1.520.886.0399
Toll Free 1.888.886.0410 (U.S. and Canada)
E-mail Sales@ReliaSoft.com
http://ALTA.ReliaSoft.com
Quarter 3, 2002
Continued from Page 9: “Failure Modes, Effects and Criticality Analysis”
For example, consider a criticality analysis for the partial
FMEA on the battery. The reliability of the battery is 92% at the
operating time of interest, therefore the unreliability is 8%. The
portion of the item unreliability that can be attributed to the
given failure mode is 25% (or 25% of the item failures are likely
to be due to this particular failure mode). The probability of
loss is 100% because the occurrence of the failure mode will
cause a system failure. The Criticality for the failure mode is
(.08)(.25)(1.00) = .02, or 2%. As with the RPN method, this
Criticality value can be compared with the Criticalities for other
failure modes to help rank the issues that must be addressed.
Item Q Function Failure FMFR Effect PL C au se
Battery .08 Provide Fails to .25 System 1.00 Battery .02
adequate provide fails to plates are
relay adequate operate shorted
voltage power
Figure 4 displays the Xfmea Criticality Analysis utility, which
can also be used to generate FMECA charts and reports.
Applications and Related Analyses
FMEA/FMECA techniques are used throughout industry
for a variety of applications and the flexible analysis method
can be performed at various stages in the product life cycle.
FMEA/FMECA analysis can be employed to support design,
development, manufacturing, service and other activities to
improve reliability and increase efficiency. For example, there
is widespread use of both design and process FMEAs within
the automotive industry and documentation of this analysis is
a common requirement for automotive suppliers. This
methodology is also widely used in the aerospace, medical
and other manufacturing industries.
The MSG-3 procedures used by the airline industry
incorporate FMEA techniques into the analysis procedure.
(Reliability Edge Volume 3, Issue 1 contains an article on MSG-
3 and ReliaSoft’s MPC 3, software designed to automate the
process.) Likewise, Reliability Centered Maintenance (RCM)
procedures incorporate FMEA as a primary component of the
analysis.
In addition, the FMEA reporting structure can be used to
provide a centralized location for reliability-related information
Figure 4: Xfmea Criticality Analysis utility
Page 11
for the system/process. For example, the FMEA can be
incorporated into an effective Reliability Growth management
policy by providing a structure to organize information about
product failures and assisting with efforts to identify the failure
modes that have been observed during reliability growth testing
and the failure modes that may still yet be observed.
Conclusion
FMEA/FMECA analysis is a flexible process that can be
adapted to meet the particular needs of the industry and/or the
organization. However, most analyses include the basic
procedures and data requirements described in this article.
Cr
ReliaSoft’s Xfmea software supports these basic procedures,
the major published industry standards (e.g. J1739, MIL-STD-
1629A, etc.) and also provides the flexibility to customize the
analysis and reports to meet the user’s needs for a particular
application. On the Web at http://XFMEA.ReliaSoft.com.
FMEA/FMECA References
Many references for FMEA/FMECA analysis are available
in print and on the Web. Some useful references include:
• Kececioglu, Dimitri, Reliability Engineering Handbook
Volume 2. Prentice-Hall Inc., Englewood Cliffs, New Jersey,
1991. Pages 473-506.
• MIL-STD-1629A: Procedures for Performing a Failure
Mode Effects and Criticality Analysis. U.S. Department of
Defense, Washington, D.C., November 28, 1984. Note:
This standard was cancelled by the DoD in August 1998.
• SAE Aerospace Recommended Practice ARP5580:
Recommended Failure Modes and Effects Analysis (FMEA)
Practices for Non-Automobile Applications. SAE
International, Warrendale, PA, 2001.
• SAE Surface Vehicle Recommended Practice J1739:
Potential Failure Mode and Effects Analysis in Design
(Design FMEA), Potential Failure Modes and Effects
Analysis in Manufacturing and Assembly Processes
(Process FMEA), and Potential Failure Mode and Effects
Analysis for Machinery (Machinery FMEA). SAE
International, Warrendale, PA, June, 2000.
• Stamatis, D.H., Failure Mode and Effect Analysis: FMEA
from Theory to Execution. American Society for Quality
(ASQ), Milwaukee, Wisconsin, 1995.
RS
Reliability Training
ReliaSoft's training seminars provide instruction in reliability
engineering principles and theory as well as the software tools
designed to put that theory into practice. Upcoming seminar
dates include November 18 - 22, 2002, February 24 - 28, 2003,
May 19 - 23, 2003, November 17 - 21, 2003 and February 23 -
27, 2004 in Tucson, Arizona. On-site seminars are also available
as well courses on other reliability topics. Please consult the
Web or contact ReliaSoft for more information.
On the Web at: http://Seminars.ReliaSoft.com
Over the past three years, ReliaSoft's scientists and engineers, along with
corporate partners and selected user groups, have quietly worked to create
the ultimate system visualization and analysis tool. The result of
this effort is a monumental breakthrough encompassing
astounding analytical power while maintaining an
artful simplicity of use: BlockSim 6.

This revolutionary software includes

significantly enhanced analytical engines for
exact reliability computations of the most
complex systems, including configurations
with standby redundancy as well as load
sharing. On the simulation front, a
new and comprehensive
discrete event simulation
engine allows for
complete analysis of
highly complex
repairable
systems.
Flexible Reliability Block Diagram (RBD) Creation
BlockSim’s interface for Reliability Block Diagram creation is the most intuitive,
flexible and polished in the industry.
Simple drag-and-drop techniques allow you to build RBDs for the simplest to the
most complex systems. Configuration options include Series, Parallel, and
k-out-of-n (in various complex combinations) plus...
Load Sharing Blocks: In a load sharing configuration, each block supports
a percentage of the total load.
Standby Blocks: In a standby configuration, standby blocks are available to become
active under specified circumstances.
Mirrored and Multi Blocks: Provide increased versatility with the ability to simulate
bi-directional paths, save time/space when entering multiple identical blocks, and more...
Unlimited subdiagram capability to link diagrams as components in other diagrams.
Customizable graphical display with the ability to export diagram graphics.
Pre-defined templates and import/export to save time and ensure consistency, ability to de-activate
individual blocks for "what-if" analyses, file attachments, and more...

Exact Reliability Results/Plots and Optimum Reliability Allocation

Using an exclusive algorithm pioneered by ReliaSoft, BlockSim algebraically computes the
exact system reliability function for even the most complex system so you can obtain exact
system reliability results based on component data. Results include Reliability, Failure Rate,
MTTF, Warranty Time, B(X) Life, pdf plots, Reliability Importance plots, and more...

Also exclusively in BlockSim, you can enter cost and feasible reliability growth information to
determine the most cost-effective component reliability allocation strategy to meet a
system reliability goal.

Extensive Simulation Options for Repairable Systems Analysis

BlockSim’s simulation capability for repairable systems maintainability and availability analysis is more
sophisticated and realistic than ever.
Corrective Maintenance (CM), Preventive Maintenance (PM) and Inspection Properties
Maintenance Duration and Restoration Factors: Specify time-dependent distributions or fixed
durations. Also specify whether the item will be “good as new” or less than 100% restored by the
maintenance action.
Maintenance Policies: Describe the conditions under which maintenance will be
performed (e.g. upon fixed interval, upon maintenance of another group item, etc.).
Spare Parts Pools and Maintenance Crews: Describe the conditions under
which spare parts can be obtained and crews are available to perform
maintenance, as well as the associated costs.
Comprehensive Results and Plots: Maintainability and availability results per system
and/or per block including: Uptime, Downtime, Mean Time to First Failure (MTTFF),
Mean Availabilities, Point Availabilities, Point Reliabilities,
Number of Failures, Number of PMs, Number of
Inspections, Plots of System Uptime/Downtime, Point
Availability vs. Time, Point Reliability vs. Time, and more...
Plus: Cost summaries, Throughput estimations,
Optimum PM time calculations, and more...

Unparalleled Supporting Features

BlockSim 6 provides all of the supporting features that
you have come to expect from ReliaSoft’s software:
intuitive graphical user interface, extensive graphics and
plotting, custom analysis tools, comprehensive
documentation, complete support, and more...
 D FMEA , P FMEA AND B EYOND ...
E XPER T S UPPOR T FOR ALL T YPES
OF FMEA AND FMECA
Failure Modes and Effects Analysis (FMEA) and Failure Modes, Effects and Criticality
Analysis (FMECA) are methodologies designed to identify potential failure modes for a
product or process before they occur, to assess the risk associated with those failure modes,
to rank the issues in terms of importance and to identify and carry out corrective actions to
address the most serious concerns.
ReliaSoft's Xffmea software facilitates the FMEA/FMECA analysis process
and provides flexible data management and reporting capabilities.
SAE J1739
Support for Major Industry Guidelines plus... AIAG FMEA-3
Extensive Customization Options SAE ARP5580
MIL-STD-1629A
Xffmea supports the major industry standards for all types of FMEA/FMECA plus...
analysis, including Design FMEA (DFMEA), Process FMEA (PFMEA),
FMEA/FMECA analysis also
Machinery FMEA (MFMEA), FMECA, and more...
addresses requirements in
ISO 9000, QS 9000,
In addition to the pre-defined formats, the software provides extensive
ISO/TS 16949, Six Sigma
capabilities to customize the interface and the reports, including the ability to
and other guidelines.
rename fields, hide/display fields, customize the RPN rating criteria and other
options to allow you to determine the configuration for analysis and reporting.

Intuitive Interface, Easy Data Entry,

Time-Saving Shortcuts
Xffmea provides two complementary views to facilitate data entry. The
worksheet view displays the analysis in the traditional tabular format for
FMEA reports. The intuitive hierarchical view displays the item
configurations at-a-glance along with the related functions, failures, effects,
causes, actions and controls.

For consistency and to save effort, the software allows

you to re-use descriptions from any existing analysis
or to select phrases from pre-defined phrase libraries.
The software also provides:

- Integration with Weibull++ and BlockSim.

- Ability to link or attach other files to the analysis,
such as process flow charts, design drawings, etc.
- Ability to copy/paste entire sections of an analysis
and import/export sections among different analyses.
- And much more...
Xfmea streamlines the analysis and reporting for all types of FMEA/FMECA
Risk Assessment: RPNs and Criticality Analysis
Xffmea supports the Risk Priority Number (RPN) ranking method as well as Criticality Analysis. This
includes automatic RPN calculation for both initial and revised RPNs as well as automatic "roll-up" capability
to calculate RPNs for other analysis levels (such as Item) based on the RPNs for the potential causes of
failure. The software is shipped with an extensive array of pre-defined rating scales for Severity, Occurrence
and Detection and also allows you to create and manage your own rating scales. In addition, the software
automatically calculates Mode and Item Criticalities and generates charts and reports of the criticality analysis.

Actions Management and Support for Team Effort

Xffmea allows you to fully define and manage the recommended actions identified by the analysis in order to
close the loop on corrective actions. Detailed reports on current controls are also available.

The software has been designed to allow multiple users to work cooperatively on the analysis and
provides simple techniques to share portions of an analysis with other users as well as revision tracking
mechanisms. In a networked environment, you can assign permissions to allow more than one authorized
user to access the same database.

Extensive Reporting Capabilities in Microsoft Word and Excel

Xffmea provides a complete set of reports for your analysis. In addition to the standard FMEA spreadsheet,
you can generate summaries for items, failures, effects, causes, recommended actions, current controls and
other reports. You can also perform ad-hoc queries on your analysis databases.

You can choose to generate each report in Microsoft

Word or Excel, which provides maximum flexibility
for customization and generation of HTML and PDF
versions of the reports, as desired.

System Requirements: Windows 98, Me, NT, 2000 or XP. Microsoft Office 97 or higher.
Support: ReliaSoft’s unparalleled after-sale support includes free telephone, fax and e-mail support.
Free minor version updates are also included.

For a free evaluation copy or complete product brochures:

Phone: +1.520.886.0410
Toll Free: 1.888.886.0410 (U.S. and Canada)
Fax: +1.520.886.0399
E-mail: Sales@ReliaSoft.com
Page 16
Introduction to Case Study Report: Integrating Weibull Analysis
into Bodyshop Reliability Engineering
Dave Whetton
Engineering Quality Manager, Comau Estil UK
Comau Estil UK designs and builds vehicle assembly
systems for the automotive sector. Recent advances in lean
manufacturing have greatly increased the importance of sound
reliability engineering and valid reliability predictions, especially
in highly automated manufacturing facilities. This introduction
and the case study report presented below demonstrate some
of Comau Estil UK’s efforts in response to this demand.
Background: Historically, our reliability models were based
upon classical calculations of MTBF and MTTR. We realized
that this method carried with it the assumption of constant failure
rate. However, the method was easy to use in the absence of
statistically acceptable analysis tools. In an effort to improve
upon existing methods, Ford Motor Company investigated
several options for developing standardized reliability reporting
based on calculating actual time-to-failure and time-to-repair
distributions. As a result of this study, Ford adopted the use of
ReliaSoft’s Weibull++ and BlockSim software for reliability
improvement and performance modeling. This has been
complemented by Ford’s new corporate Reliability and
Maintainability (R&M) specification, which requires standard
reports incorporating analysis outputs from the ReliaSoft
software. Consequently, the American Institute of Quality (AIQ)
has been commissioned to roll out strategic training to promote
awareness among the supplier base about the advanced
statistical techniques. The Ford expectation has been
formalized in the five points of FRED (Failure Reporting,
Evaluation and Display). Evolving supplier selection criteria is
placing increasing weight on standardized reliability reporting
using output from ReliaSoft software for predictive models.
Comau Estil UK Initiatives: Comau Estil UK has seized
the initiative to apply advanced statistical techniques by
retaining consultancy support from Jambor & Associates and
Case Study Report: Failure Reporting, Evaluation and Display (FRED) Report
Station 003 Front Structure
Jaguar Castle Bromwich
PROJECT – X202
Bodyshop
30/8/02
Objective(s)
The primary objective of this FRED report is to identify an
opportunity to improve and raise the baseline of acceptable
reliability levels of the production equipment. This reliability
growth can only be accomplished through root cause analysis
and then by engineering a sound, verifiable fix.
Introduction
The following report represents an Availability study of the
X202 Front Structure Station 003 in the Jaguar Castle Bromwich
Plant. ReliaSoft’s Weibull++ MT and BlockSim MT (version 1)
Quarter 3, 2002
Guest Submission
applying comprehensive statistical methodologies for vehicle
program launch support, many of which are consistent with
the five points of FRED. Our application of ReliaSoft software
has been piloted in the Jaguar Halewood and Jaguar Castle
Bromwich Body Assembly Plants. Comau Estil UK’s specific
case studies have targeted the “X” Type Jaguar bodyside and
framing systems and the “S” Type Jaguar front structure system.
Even before its acquisition by Ford, Jaguar placed high
emphasis on reliability techniques such as Machinery FMEAs,
reliability allocation models and control plans. Jaguar has
welcomed Comau Estil UK’s approach to analyzing reliability
using the ReliaSoft software, not only as the basis for reliability
improvement but also for the benchmarking of existing facility
to incorporate the results into our throughput simulation model
as a predictor of future performance. The FRED report
presented below, which represents Comau Estil UK’s
standardized reporting format, was executed to evaluate the
impact of integrating aluminium joining technology into a facility
where spot welding has been historically dominant.
Conclusion: Our current capability includes four
workstations with the Weibull++ and BlockSim software. We
expect our use of the software to increase and result in more
licensed workstations and further training from AIQ. Based on
case studies that Comau Estil UK has performed to date, we
have identified recommendations for enhanced capabilities that
would make the software more useful for bodyshop-specific
applications. The areas of innovation would be:
• Automated scaling of the eta parameter to reflect machine
busy time when utilization is below 100%.
• The ability to start a simulation at an arbitrary point in the
life of the tool instead of assuming a starting point of zero.
• More flexible capability to define shift patterns.
• Automated capability to combine similar reliability entities
into “typical” models (e.g. geometry setting stations, etc.).
software applications were used to produce the FRED charts,
as prescribed by Point 1 of the Ford Corporate R&M
specification.
Methodology
The raw data set used was from the equipment fault detail
report of POSMON (the facility’s event tracking system)
beginning 07:30 on 28th May 2002 and ending 12:00 on 19th
July 2002. The study included all components in Station 003,
as shown in the BlockSim block diagram in Figure 2 (page 17).
During this period, 882 events were recorded in the specified
shift pattern. Events were analyzed at three levels: Station,
Component (e.g. Rivet Gun, Proximity) and Fault Code.
To make the POSMON downtime log readable by
Weibull++ MT, some pre-processing was required. First, the
data set was filtered to remove any events that fell outside the
specified shift pattern and then events were removed that had
a continuous duration over planned downtime. The data set
Please Turn to Page 17
Quarter 3, 2002
Continued from Page 16: “Case Study Report: Failure Reporting Evaluation and Display (FRED) Report”
was then entered into the Weibull++ data entry form. For the
Weibull analysis, the Rank Regression estimation method was
used because of the completeness of the data. Time-to-failure
and time-to-repair (or failure duration) distributions with their
parameters were then used to build a reliability block diagram
in BlockSim. Within BlockSim, a simulation was run for 10,000
minutes (approximately 2 weeks of production) with results
calculated for instantaneous availability 10 times. The simulation
resolution was set to run 100 inner loops and 10 outer loops.
This means that 100 simulation points were generated for each
reliability entity and results were returned for each of the 100
runs; then the simulation returned results 10 times at system
level, each time with a new stream of random numbers for the
simulation points. This yielded 10 different system reliability
values and 100 reliability entity values. The system reliability
at the specified time returned by the simulation was the average
of these 10 reliability values. The simulation results were used
to estimate MTBF, MTTR and Availability at the System level.
Similar steps were taken to work down the availability
hierarchy from Component level to Fault Code level, as shown
on the FRED chart in Figure 1.
Results
Figures 1 through 4 demonstrate the results of the analysis.
Figure 1: Front Structure Station 003 FRED Tree
Figure 2: Front Structure Station 003 Block Diagram
Page 17
Conclusions
The immediate opportunity for reliability improvement
follows a critical path of Component = Proximity (98.53%
availability) to Fault Code = 102062 waiting part present (98.5%
availability).
The study has highlighted the importance of having data in
electronic format that can be operated on for pre-processing
before entry into the analysis software. The study also
demonstrates the value of the ReliaSoft software for performing
the analysis and creating graphical representations of the
output. Finally, the study illustrates the value of automated
analysis to point out the dominant areas and sources of failure
as an aid to prioritize reliability improvement efforts.
For Comau Estil UK’s throughput simulation model, the
most easily understood input would be the MTBF from the
FRED tree generated by BlockSim. It would be preferable to
use MCBF, which represents the failure frequency based on
station/component busy time.
RS
Figure 3: Front Structure Station 003 Pareto
Figure 4: Front Structure Station 003 Rivet Gun FRED Tree
RAC is ready to provide total, turn-key solutions including
training, data, consulting services, information and support
for both government and commercial businesses.

experience
The Reliability Analysis Center
(RAC) is a Department of Defense
(DoD) Information Analysis Center
operated by IITRI for more than
33 years. The DoD has chartered
RAC as a Center of Excellence and
a scientific and technical resource for
information, data, analysis, analytical
tools, training and technical
assistance in the broadly defined
fields of Reliability, Maintainability,
Supportability and Quality.
Although chartered by the DoD,
RAC undertakes a variety of other
government organization and
industrial support projects each year.
Our 60+ local engineers are
backed by IITRI resources at 15
IITRI locations with over 1300
employees of various technical
backgrounds and expertise.
training
Learn from the experts with RAC’s
world-renowned professional
reliability training program. Courses
are taught by practicing professionals
using relevant experience and real-
world examples. To learn at your
own pace, RAC’s distance learning
is structured for all individuals
working in the reliability engineering
realm, including systems and circuit
design engineers, program managers,
quality engineers and members of
related disciplines.
consultation and
implementation
RAC’s technical staff is ready to
provide support at all levels and in all
areas of reliability. Organizations
which already have relatively mature
reliability programs have RAC work
on very specific problems or issues.
Others have no formal reliability
program and RAC provides a wider
range of support beginning with an
assessment of the organization’s
reliability needs. Depending on a
customer’s needs, RAC will provide
short-term, quick responses to
immediate needs, or long-term
studies and independent analysis.
Our philosophy is to bring the
customer’s level of knowledge and
experience to a point where the
customer can independently and
successfully implement the
reliability program for the long
term. After that point, RAC can
provide assistance to solve specific
problems or deal with unique issues
not envisioned in the initial reliability
program plan.
reliability data
publications
and software
As the central resource for DoD and
industry reliability data, RAC offers
the data that’s important to your
business, and we integrate this
information into our products,
including our publications and
software. Our extensive line of
reliability publications offers
something for everyone: managers
achieve a high-level understanding of
the relationship between reliability and
the bottom line, design engineers
receive support for design trade-off
analyses and decisions, and reliability
practitioners will find practical
application and how-to guides. RAC’s
software provides reliability
professionals with the tools needed to
make accurate, informed decisions and
perform required program activities
with efficiency. RAC’s PRISM®
software sets a new standard in
reliability prediction as a
comprehensive resource that includes
next generation component failure rate
models, searchable failure rate
databases, software reliability
predictions and operating and non-
operating failure rates.

free services

We offer a number of free services

through our website, including
technical information, a searchable Visit RAC online today at
bibliographic database, directories of
software tools and related industry http://rac.iitri.org/CONTACT/adresponse.html
websites, an open industry forum, a
for a free subscription to the RAC Journal.
calendar of events, how-to documents
and more. Our Technical Inquiry
Line provides customers up to eight
hours of free phone specialized Reliability Analysis Center
support. And our free quarterly 201 Mill Street, Rome, NY 13440-6916
technical journal, The RAC Journal, Phone: 315.337.0900 or 1.888.RAC.USER
contains articles, editorials, industry Fax: 315.337.9932
announcements, and product and Email: rac@iitri.org
service information of significance to
the reliability community.
Page 20
Resources for the Reliability Professional on weibull.com
With a better understanding of the principles and theory
that underlie the reliability analysis tools and technique that
they use, engineers, their managers and other professionals
are able to make more informed decisions with respect to the
reliability of their products. The weibull.com site (located on
the Web at http://www.weibull.com) has been established to
support the activities of quality and reliability professionals and
provides a wide array of practical and theoretical resources.
These resources are provided courtesy of ReliaSoft Corporation
and they have been developed by a dedicated team of
engineers, statisticians, mathematicians and programmers with
a thorough understanding of both reliability theory and software
development. This article provides a brief introduction to the
tools and references available on weibull.com. This quick
overview is intended to alert reliability professionals to the
variety of free resources that they can tap into.
Web-Based iTools
The iTools section is the newest addition to the weibull.com
site. The iTools are Web-based computational utilities that
provide quick statistical results. These tools are based on the
same powerful computation engines that drive the Weibull++
life data analysis software package and they provide results
directly through your Web browser. The following tools are
currently available:
• Simple Weibull Analysis: Enter data and calculate the
parameters for the two-parameter Weibull distribution.
• Rank Calculator: Obtain the rank value for a given
percentage, sample size and order number.
• Quick Statistical Reference: Obtain values for commonly
used statistical functions, such as cumulative binomial
probability, student’s t values, chi-squared values, etc.
Figure 1 displays the QSR iTool with a chi-squared value
calculated with the click of a button.
• Exponential Design of Reliability Tests Calculator:
Determine the test time required to obtain a given MTBF
or Reliability, assuming an exponential distribution.
Figure 1: Quick Statistical Reference (QSR) iTool
Quarter 3, 2002
Other Reliability Analysis Tools
In addition to the new iTools section, the weibull.com site
also provides other reliability analysis tools via the Web. For
instance, hundreds of users have downloaded the probability
plotting papers that are available in PDF format (*.pdf) from
the site. Papers for the Weibull, lognormal, normal and
exponential distributions are available. These files have been
generated by the Weibull++ software and can be used to print
high-quality papers for manual probability plotting. Practitioners
can use the Rank Calculator iTool or obtain the required ranks
from the rank tables provided on the site.
The weibull.com site also provides software tools designed
to support ancillary reliability analyses. These tools were
developed by ReliaSoft Corporation and are available for free
download to registered users. One of these tools, the
SimuMatic® utility, can be used to explore reliability life data
analysis using Monte Carlo simulation. Some of the applications
for this tool include the ability to construct simulation-based
confidence intervals and to experiment with the influences of
sample sizes and censoring schemes on analysis methods.
Volume 2, Issue 1 of Reliability Edge (available on the Web at
http://www.ReliaSoft.com/newsletter) includes an article that
examines these and other applications for the utility. The SPRT
tool, another free utility available from weibull.com, performs
the calculations required for sequential probability ratio testing
with the Weibull distribution. This testing and analysis method
can be used to demonstrate compliance with a given reliability
requirement using a minimum number of test units. Figure 2
displays the SPRT utility with a sample analysis.
Reliability eTextbooks
In addition to the growing collection of hands-on and
application-oriented resources, weibull.com also provides an
extensive array of theoretical references. One set of references,
the Reliability eTextbooks, provide comprehensive treatments
of fundamental reliability analysis subjects in a flexible Web-
based format. These searchable on-line references provide
table of contents, index and free text search capabilities to
provide quick access to the specific information of interest.
Please Turn to Page 21
Figure 2: The SPRT utility, available for free download
Quarter 3, 2002
Continued from Page 20: “Resources for the Reliability Professional on weibull.com”
Reliability eTextbooks are currently available for:
• Life data analysis (Weibull analysis).
• Accelerated life testing data analysis, with an emphasis
on quantitative accelerated life testing (QALT) analysis.
• System reliability, maintainability and availability analysis,
with an emphasis on reliability block diagram approaches.
• Reliability growth analysis.
Reliability References, Case Studies and Other Resources
Other references on weibull.com include:
• Quick Subject Guides: The site’s Quick Subject Guides
provide a brief overview of some of the key topics in
reliability engineering to provide a quick and easy-to-
understand foundation in the subject. These references
also provide suggestions for further, more detailed,
research.
• Case Studies: The site provides access to case studies
for subjects such as life data analysis and accelerated life
data analysis. These case studies include step-by-step
instruction for performing the analyses in ReliaSoft’s
software packages.
• Reliability Publications: The site provides access to on-
line versions of the Reliability Edge quarterly newsletter
as well as the HotWire monthly eMagazine. In addition,
the site includes a comprehensive subject index to the
articles in those publications.
• Research Papers: Scholarly research papers that have
been published/presented by ReliaSoft’s R&D personnel
are available for download in PDF format (*.pdf).
• Seminars and Training Guides: The site provides access
to information on training seminars for reliability engineering
and related subjects, as well as training guides in PDF
format (*.pdf). The training guides include step-by-step
examples for reliability analyses performed with ReliaSoft’s
software products.
Figure 3: Home page for weibull.com
Page 21
• Other Resources: Other resources provided by
weibull.com include lists of recommended reliability books,
reliability- and quality-related Web links, an on-line glossary
of reliability terms as well as a complete “blueprint” for
implementing a successful reliability program. Resources
are added and improved on an ongoing basis.
Discussion Forum
The weibull.com site is provided as a service to the
reliability community and, as such, features an interactive
discussion forum designed to facilitate communication within
the field. Discussion topics include a general reliability
discussion, employment opportunities and questions/comments
regarding ReliaSoft’s standard software products. These forums
are open to everyone and no password is required. ReliaSoft
personnel monitor and participate in the discussions.
Conclusion
The extensive array of reliability resources described in
this article attracts thousands of visitors each month to
weibull.com. The weibull.com site (shown in Figure 3) is
updated and enhanced on an ongoing basis and ReliaSoft
makes every effort to be responsive to requests from the
reliability community. To make suggestions for improvement or
to request additional references and tools, contact
Webmaster@ReliaSoft.com or complete the simple form
located on the Web at http://www.weibull.com/Feedback.
RS
Another Reliability Publication
In addition to the Reliability Edge quarterly newsletter,
ReliaSoft also publishes a monthly eMagazine for reliability
professionals, which is distributed via e-mail and available on
the Web. The Reliability HotWire eMagazine provides
information and tips on how to best improve reliability practices
and get the most out of ReliaSoft’s tools for reliability and life
data analysis. This monthly publication brings practical hints
regarding reliability engineering and life data analysis to the
novice and seasoned practitioner alike. In addition, Reliability
HotWire presents tips on how to get the best use out of
ReliaSoft’s reliability analysis software tools. Recent HotWire
articles include:
• Looking at Thermal Cycling in Quantitative Accelerated Life
Testing (QALT)
• Contour Plots and Confidence Bounds on Parameters
• Verifying the Assumption of a Constant Shape Parameter
in Accelerated Life Data
• Comparison of MLE and Rank Regression When the Data
Set Contains Suspensions
• Financial Applications for Weibull Analysis
• plus numerous tips and techniques for effective use of
ReliaSoft’s software.
Subscriptions are free and can be obtained by contacting
HotWire@ReliaSoft.com or by completing the registration form
on the Web at http://www.weibull.com/hotwire.
 Weibull++ 6 builds upon the strengths of
previous versions of ReliaSoft’s
Weibull++ software package, the
standard in reliability life data analysis
for thousands of users and hundreds of
Fortune 500 companies worldwide.

Weibull++ 6 is designed specifically for

reliability life data analysis and provides a
powerful collection of calculation, plotting and
report generation tools that allow you to perform
a wide variety of statistical analyses.

Analyze complete, left censored, right censored

(suspended) and interval censored life data.
Life distributions include Weibull, mixed Weibull,
normal, lognormal, exponential and generalized
gamma.
Rank regression on X, rank regression on Y or maximum likelihood (MLE) for parameter estimation.
Confidence bounds using Fisher matrix, likelihood ratio or beta-binomial techniques.
Quick Calculation Pad that returns reliability, warranty time, mean life and other common reliability results.
General Spreadsheet and Report Work Center utilities that allow you to manipulate data from multiple
sources for custom analyses, custom plots and professional reports and presentations.
Special utilities to allow you to extrapolate failure times based on a product’s performance (degradation)
over a period of time, convert shipping and warranty return data for a product into time-to-failure and
suspension data and perform non-parametric analyses with Kaplan-Meier and actuarial techniques.
New and enhanced analysis of variance (ANOVA), reliability test design, and test of comparison
tools. Improved user-defined and non-linear equation fit solvers.
Quick Statistical Reference that provides common statistical function results (such as median ranks, chi-
squared, student’s t, etc.) and frees you from tedious lookups in tables.
Distribution Wizard that automatically performs multiple goodness-of-fit tests for each distribution and
recommends the one that best fits your data set.
Unparalleled graphics and plotting capabilities. Automatically create standard probability,
reliability vs. time, unreliability vs. time, pdf, failure rate vs. time and likelihood ratio contour
plots or create custom plots from a variety of data sources. Side-by-Side Plots tool for
viewing and printing up to six plots at once.

Minimum System Requirements: Windows 98, Me, NT, 2000 or XP. Pentium class processor with 32 MB RAM, SVGA
display and at least 35 MB of hard disk space.
Documentation: Complete and detailed on-line help files, as well as printed product documentation (Weibull++ User’s
Guide) and a reference book that presents life data analysis principles and theory (ReliaSoft’s Life Data Analysis Reference).
Support: Support includes free telephone, fax and e-mail support and free minor version updates.
Price: $795 for a single user. Upgrade from Weibull++ 5.0 for just $295.
For a free evaluation copy or additional information:
Phone +1.520.886.0410
Fax +1.520.886.0399
Toll Free 1.888.886.0410 (USA & Canada)
E-mail Sales@ReliaSoft.com

+1.520.886.0410 http://Weibull.ReliaSoft.com
Quarter 3, 2002 Page 23

For Your Information Bulletin Board

You all know ReliaSoft as a world class
developer of reliability analysis tools, but did
you know that ReliaSoft has a proficient team
of consultants who are ready to assist you in
the areas of quality and reliability engineering?
ReliaSoft consultants can provide expertise in
any of the following areas:
• Complete Reliability Program
Development
• Test and Experiment Design
• Data Analysis and Reporting
• Developing, Evaluating and
Communicating Reliability Requirements
• Equipment Reliability, Maintainability and
Availability Assessment
• Theoretical Development
We realize under today’s economic
conditions company reliability resources are
stretched to the limit and you may not have
time to take on another project. So whether
you have a large project you can’t find time for
or merely need another set of eyes to review
your analysis or report, please consider giving
us a call. We would be happy
to discuss your requirements
and promptly provide you with
a cost and time estimate for
completion of the project.
--Doug Ogden
Vice President,
Corporate Relations
Seminars
The next “Master the Subject, Master the Tools” basic training seminars are
scheduled for November 18 - 22, 2002 and February 24 - 28, 2003 in Tucson,
Arizona. On the Web at http://Seminars.ReliaSoft.com.
Software
Detailed product information for ReliaSoft software products, including free
product updates and free evaluation copies, is available on the Web.
ReliaSoft's Standard Softw are Products
Weibull++ Life Data Analysis
Version 6.0.8, Built 4/25/02 http://Weibull.ReliaSoft.com
Weibull++ MT (Machine Tools) http://Weibull.ReliaSoft.com/mt
Weibull++ DE (Developer Edition) http://Weibull.ReliaSoft.com/deved
ALTA and ALTA PRO Accelerated Life Test Data Analysis
Version 6.0.9, Built 6/20/02 http://ALTA.ReliaSoft.com
BlockSim System Reliability, Maintainability
Version 6 To Be Released, and Availability Analysis
Winter 2002 http://BlockSim.ReliaSoft.com 123 123
RG Reliability Growth Analysis
Version 1.0.0, Built 1/10/97 http://RG.ReliaSoft.com
MPC 3 Maintenance Program Creator
Version 3.0.6, Built 9/16/02 http://MPC.ReliaSoft.com
Xfmea Failure Modes and Effects Analysis
To Be Released, Winter 2002 http://XFMEA.ReliaSoft.com
Technical Support
Phone: +1.520.886.0366 Fax: +1.520.886.0399 E-mail: Support@ReliaSoft.com
ReliaSoft Sales
Toll Free: 1.888.886.0410 (U.S. and Canada) Phone: +1.520.886.0410
Fax: +1.520.886.0399 E-mail: Sales@ReliaSoft.com

MSG-3 Compliant Maintenance Program Creator

ReliaSoft’s MPC 3 software is an MSG-3 compliant maintenance
program creator designed for the aerospace industry. From the
identification of maintenance significant items (MSIs) through the
analysis of functions, failures, effects, causes and tasks, to the
automatic generation of the final Maintenance Review Board
(MRB) report, MPC 3 guides you through the entire MSG-3
process for Aircraft Systems and Powerplant Analysis.

• Data storage and management in relational databases with

support for use in team environments.
• Integration with Microsoft Word for automatic report
generation.
• Time-saving capabilities to re-use text descriptions and
portions of the analysis within and among projects.
• And much more...

http://MPC.ReliaSoft.com
ReliaSoft Corporation Prst Std
ReliaSoft Plaza U.S. Postage
PAID
115 S. Sherwood Village Drive Tucson, AZ
Tucson, AZ 85710 Permit #541

Quarter 3, 2002