Blueprint for a Comprehensive Reliability Program 01

Blueprint for a Comprehensive Reliability Program
请参考
1 Introduction...................................................................................................1
2 Foundations of Reliability ............................................................................2
2.1 Fostering a Culture of Reliability .......................................................................... 2
2.2 Product Mission ................................................................................................... 3
2.2.1 Reliability Specifications .............................................................................................3
2.3 Universal Failure Definitions ................................................................................ 4
3 Reliability Testing .........................................................................................6
3.1 Customer Usage Profiling .................................................................................... 6
3.2 Test Types ........................................................................................................... 6
3.2.1 Development Testing..................................................................................................7
3.2.2 Manufacturing Testing ................................................................................................8
4 Field Data.....................................................................................................10
4.1 The “Disconnect” Between In-House and Field Data......................................... 10
4.2 Sales and Forecasting (Shipping) Data ............................................................. 10
4.3 Warranty Data.................................................................................................... 11
4.4 Field Service Data.............................................................................................. 11
4.5 Customer Support Data ..................................................................................... 12
4.6 Returned Parts/Failure Analysis Data................................................................ 12
5 Data Collection............................................................................................13
5.1 In-House Test Data Collection ........................................................................... 13
5.1.1 Test Log ....................................................................................................................14
5.1.2 Failure Log................................................................................................................14
5.1.3 Service Log...............................................................................................................15
5.2 Field Data Collection.......................................................................................... 16
5.2.1 ReliaSoft’s Dashboard ..............................................................................................16
6 Data Analysis and Reporting .....................................................................19
6.1 Non-Parametric Analysis ................................................................................... 19
6.1.1 Non-Parametric Reliability Analysis..........................................................................19
6.2 Parametric Analysis ........................................................................................... 21
6.2.1 Examples of Reporting for Parametric Data Analysis ..............................................22
6.2.1.1 Probability Plot...................................................................................................22
6.2.1.2 Reliability Function ............................................................................................23
6.2.1.3 Probability Density Function..............................................................................23
6.2.1.4 Failure Rate Function ........................................................................................23
6.2.1.5 Life vs. Stress ....................................................................................................24
6.2.1.6 Likelihood Function............................................................................................24
6.2.1.7 Reliability Importance ........................................................................................25
6.2.1.8 Reliability Growth...............................................................................................25
7 Bringing It All Together ..............................................................................26
7.1 Connecting Field and Lab Data ......................................................................... 26
7.2 Reliability Growth ............................................................................................... 26
7.3 Optimum Design Level Determination ............................................................... 27
7.4 Competitive Assessment ................................................................................... 28
7.5 Marketing and Advertising ................................................................................. 28


1 INTRODUCTION
At the highest level, the purpose of a reliability engineering program is to test and
report on the reliability of an organization's products. This information is then
used to assess the financial impact of the reliability of the products, and to
improve the overall product reliability and consequently the financial strength of
the organization.
Reliability assessment is based on the results of testing from in-house labs and
data pertaining to the performance results of the product in the field. The data
produced by these sources is to be utilized to accurately measure and improve
the reliability of the products being produced. This is particularly important as
market concerns drive a constant push for cost reduction. However, one must be
able to keep a perspective on "the big picture," instead of merely looking for the
quick fix. It is often the temptation to cut corners and save initial costs by using
cheaper parts or cutting testing programs. Unfortunately, cheaper parts are
usually less reliable, and inadequate testing programs can allow products with
undiscovered flaws to get out into the field. A quick savings in the short term by
the use of cheaper components or small test sample sizes will usually result in
higher long-term costs in the form of warranty costs, or loss of customer
confidence. The proper balance must be struck between reliability, customer
satisfaction, time to market, sales and features. Figure 1 illustrates this concept.
The polygon on the left represents a properly balanced project. The polygon on
the right represents a project in which reliability and customer satisfaction have
been sacrificed for the sake of sales and time to market.

2 FOUNDATIONS OF RELIABILITY
There are a certain number of "up-front" activities that need to be undertaken in
order to be able to successfully implement a reliability program. Most of these
activities are relatively simple, but they are vital to the design and implementation
of a reliability program. It is like the foundation of a house: relatively inexpensive
and largely forgotten once the major construction has begun, but vital to the
structure nonetheless. The reliability "foundation building" concepts need to be
addressed in order to put a strong reliability program in place.
2.1 FOSTERING A CULTURE OF RELIABILITY
The most important part of developing a reliability program is having a culture of
reliability in the organization. It is vital that everyone involved in the product's
production, from upper management to assembly personnel, understands that a
sound reliability program is necessary for the organization's success.
Achieving this culture of reliability may actually be more difficult than it seems, as
some organizations may not have the history or background that lends itself to
the support of a reliability program. This can be particularly true in situations
where the organization has had a niche market or little or no previous
competition with the products that it produces. In the past, the organization's
customers may have had to accept the reliability of the product, good or bad. As
a consequence, the organization may have developed a mentality that tends to
overlook the reliability of a product in favor of the "damn-the-torpedoes, fullsteam-
ahead" method of product development. In this type of organization,
reliability engineering methods and practices tend to be viewed as superfluous or
even wasteful. "We don't need all of this reliability stuff, we'll just find the
problems and fix them," tends to be the attitude in these circumstances.
Unfortunately, this attitude often results in poorly-tested, unreliable products
being shipped to customers.
The first step in developing the necessary culture of reliability is to have the
support of the organization's top management. Without this, the implementation
of a reliability program will be a difficult and frustrating process. Adequate
education as to the benefits of a properly constructed reliability program will go a
long way towards building support in upper management for reliability techniques
and processes. Most important is the emphasis of the financial benefits that will
accrue from a good reliability program, particularly in the form of decreased
warranty costs and increased customer goodwill. This latter aspect of the
benefits of reliability engineering can sometimes be an elusive concept to
appreciate. An adage in the reliability field states that if customers are pleased
with a product, they will tell eight other people, but if they are dissatisfied, they
will tell twenty-two other people.1 While this anecdote is rather eye-opening, it
must be put in a financial context to have the full impact. It is possible to
construct a model that links reliability levels of a product with the probability of
repeat sales. It is therefore possible to calculate a loss of sales revenue based
on the unreliability of the product. This type of information is useful in educating
upper management on the financial importance of reliability. Once the upper
management has been adequately educated and is supportive of the
implementation of reliability concepts, it will be a great deal easier to go about
implementing those concepts.
However, one should not stop with upper management when it comes to
educating an organization on the benefits of a proposed reliability program. It is
vital to have the support and understanding of the rest of the organization as
well. Since the implementation of a reliability program will affect the day-to-day
activities of middle management, the engineers, and the technicians, it is also
necessary to convince these groups of the benefits of reliability-oriented
activities. It is important to demonstrate to them how these activities, which may
initially seem pointless or counterproductive to them, will ultimately benefit the
organization. For example, if test technicians have a good understanding of how
the test data are going to be put to use, they will be less likely to cut corners
while performing the test and recording the data. Overall, a reliability program
stands the greatest chance of success if everyone in the organization
understands the benefits and supports the techniques involved.
2.2 PRODUCT MISSION
The underlying concept in characterizing the reliability of a product involves the
concept of product mission (e.g., operate for 36 months, or complete 1000
cycles). A textbook definition of reliability is:
“The conditional probability, at a given confidence level, that the equipment will
perform its intended functions satisfactorily or without failure, i.e., within specified
performance limits, at a given age, for a specified length of time, function period,
or mission time, when used in the manner and for the purpose intended while
operating under the specified application and operation environments with their
associated stress levels. ”2
With all of the conditions removed, this boils down to defining reliability as the
ability of a product to perform its intended mission without failing. The definition
of reliability springs directly from the product mission, in that product failure is the
inability of the product to perform its defined mission.
2.2.1 RELIABILITY SPECIFICATIONS
In order to develop a good reliability program for a product, the product must
have good reliability specifications. These specifications should address most, if
not all, of the conditions in the reliability definition above, including mission time,
usage limitations, operating environment, etc. In many instances, this will require
a detailed description of how the product is expected to perform reliability-wise.
Use of a single metric, such as MTBF, as the sole reliability metric is inadequate.
Even worse is the specification that a product will be "no worse" than the
previous model. An ambiguous reliability specification leaves a great deal of
room for error, and this can result in a poorly-understood and unreliable product
reaching the field.
Of course, there may be situations in which an organization lacks the reliability
background or history to easily define specifications for a product's reliability. In
these instances, an analysis of existing data from previous products may be
necessary. If enough information exists to characterize the reliability performance
of a previous product, it should be a relatively simple matter to transform this
reliability performance of the new product.
Financial concerns will definitely have to be taken into account when formulating
reliability specifications. Planning for warranty and production part costs is a
significant part of financial planning for the release of a new product. Based on
financial inputs such as these, a picture of the required reliability for a new
product can be established. However, financial wishful thinking should not be the
sole determinant of the reliability specifications. It can lead to problems such as
unrealistic goals, specifications that change on a regular basis to fit test results,
or test results that get "fudged" in order to conform to unrealistic expectations. It
is necessary to couple the financial goals of the product with a good
understanding of product performance in order to get a realistic specification for
product reliability. A proper balance of financial goals and realistic performance
expectations are necessary to develop a detailed and balanced reliability
specification.
2.3 UNIVERSAL FAILURE DEFINITIONS
Another important foundation for a reliability program is the development of
universally agreed-upon definitions of product failure. This may seem a bit silly,
in that it should be fairly obvious whether a product has failed or not,3 but such a
definition is quite necessary for a number of different reasons.
One of the most important reasons is that different groups within the organization
may have different definitions as to what sort of behavior actually constitutes a
failure. This is often the case when comparing the different practices of design
and manufacturing engineering groups. Identical tests performed on the same
product by these groups may produce radically different results simply because
the two groups have different definitions of product failure. In order for a reliability
program to be effective, there must be a commonly accepted definition of failure
for the entire organization. Of course, this definition may require a little flexibility
depending on the type of product, development phase, etc., but as long as
everyone is familiar with the commonly accepted definition of failure,
communications will be more effective and the reliability program will be easier to
manage.
Another benefit of having universally agreed-upon failure definitions is that it will
minimize the tendency to rationalize away failures on certain tests. This can be a
problem, particularly during product development, as engineers and managers
may tend to overlook or diminish the importance of failure modes that are
unfamiliar or not easily replicable. This tendency is only human, and a person
who has spent a great deal of time developing a product may find justification for
writing off oddball failures as a "glitch" or as failure due to some other external
error. However, this type of mentality also results in products with poorly-defined
but very real failure modes being released into the field. Having a specific failure
definition that applies to all or most types of tests will help to alleviate this
problem.
However, a degree of flexibility is called for in the definition of failure, particularly
with complex products that may have a number of distinct failure modes. For this
reason, it may be advisable to have a multi-tiered failure definition structure that
can accommodate the behavioral vagaries of complex equipment.
The following three-level list of failure categories is provided as an example:
• Type I – Failure: Severe operational incidents that would definitely
result in a service call, such as part failures, unrecoverable
equipment hangs, DOAs, consumables that fail/deplete before their
specified life, onset of noise, and other critical problems. These
constitute “hard-core” failure modes that would require the services
of a trained repair technician to recover.
• Type II – Intervention: Any unplanned occurrence or failure of
product mission that requires the user to manually adjust or
otherwise intervene with the product or its output. These tend to be
“nuisance failures” that can be recovered by the customer, or with
the aid of phone support. Depending on the nature of the failure
mode, groups of the Type II failures could be upgraded to Type I if
they exceed a predefined frequency of occurrence.
• Type III – Event: Events will include all other occurrences that do not
fall into either of the categories above. This might include events that
cannot directly be classified as failures, but whose frequency is of
engineering interest and would be appropriate for statistical analysis.
Examples include failures caused by test equipment malfunction or
operator error.
During testing, all of these occurrences will be logged with codes to separate the
three failure types. Other test-process-related issues such as deviations from test
plans will be logged in a separate test log. There should be a timely review of
logged occurrences to insure proper classification prior to metric calculation and
reporting. These and other procedural issues will be discussed in detail in the
next section.