SOURCE: WIKIPEDIA ERRORS /OMMISSIONS REGRETTED

Reliability engineering is engineering that emphasizes dependability in the lifecycle

management of a product. Dependability, or reliability, describes the ability of a
system or component to function under stated conditions for a specified period of
time.[1] Reliability may also describe the ability to function at a specified moment or
interval of time (Availability). Reliability engineering represents a sub-discipline within
systems engineering. Reliability is theoretically defined as the probability of success
( Reliability = 1 Probability of Failure {\displaystyle {\text{Reliability}}=1-
{\text{Probability of Failure}}} ), as the frequency of failures; or in terms of

availability, as a probability derived from reliability, testability and maintainability.

Testability, Maintainability and maintenance are often defined as a part of "reliability
engineering" in Reliability Programs. Reliability plays a key role in the cost-
effectiveness of systems.

Reliability engineering deals with the estimation, prevention and management of high
levels of "lifetime" engineering uncertainty and risks of failure. Although stochastic
parameters define and affect reliability, according to some expert authors on
reliability engineering (e.g. P. O'Conner, J. Moubray[2] and A. Barnard[3]), reliability
is not (solely) achieved by mathematics and statistics. You cannot really find a root
cause (needed to effectively prevent failures) by only looking at statistics. "Nearly all
teaching and literature on the subject emphasize these aspects, and ignore the
reality that the ranges of uncertainty involved largely invalidate quantitative methods
for prediction and measurement."[4]

Reliability engineering relates closely to safety engineering and to system safety, in

that they use common methods for their analysis and may require input from each
other. Reliability engineering focuses on costs of failure caused by system downtime,
cost of spares, repair equipment, personnel, and cost of warranty claims. Safety
engineering normally emphasizes not cost, but preserving life and nature, and
therefore deals only with particular dangerous system-failure modes. High reliability
(safety factor) levels also result from good engineering and from attention to detail,
and almost never from only reactive failure management (reliability accounting /
statistics).[5]

Objective

The objectives of reliability engineering, in decreasing order of priority, are: [9]

1. To apply engineering knowledge and specialist techniques to prevent or to

reduce the likelihood or frequency of failures.
 2. To identify and correct the causes of failures that do occur despite the efforts
to prevent them.

3. To determine ways of coping with failures that do occur, if their causes have
not been corrected.

4. To apply methods for estimating the likely reliability of new designs, and for
analysing reliability data.

The reason for the priority emphasis is that it is by far the most effective way of
working, in terms of minimizing costs and generating reliable products. The primary
skills that are required, therefore, are the ability to understand and anticipate the
possible causes of failures, and knowledge of how to prevent them. It is also
necessary to have knowledge of the methods that can be used for analysing designs
and data.

Scope and techniques

Reliability engineering for "complex systems" requires a different, more elaborate

systems approach than for non-complex systems. Reliability engineering may in that
case involve:

System availability and mission readiness analysis and related reliability and
maintenance requirement allocation

Functional system failure analysis and derived requirements specification

Inherent (system) Design Reliability Analysis and derived requirements

specification for both Hardware and Software design

System Diagnostics design

Fault tolerant systems (e.g. by redundancy)

Predictive and preventive maintenance (e.g. reliability-centered maintenance)

Human factors / Human interaction / Human errors

Manufacturing- and Assembly-induced failures (effect on the detected "0-hour

Quality" and reliability)

Maintenance-induced failures

Transport-induced failures

Storage-induced failures
 Use (load) studies, component stress analysis, and derived requirements
specification

Software (systematic) failures

Failure / reliability testing (and derived requirements)

Field failure monitoring and corrective actions

Spare parts stocking (availability control)

Technical documentation, caution and warning analysis

Data and information acquisition/organisation (creation of a general reliability

development Hazard Log and FRACAS system)

Effective reliability engineering requires understanding of the basics of failure

mechanisms for which experience, broad engineering skills and good knowledge
from many different special fields of engineering, [10] for example:

Tribology

Stress (mechanics)

Fracture mechanics / Fatigue

Thermal engineering

Fluid mechanics / shock-loading engineering

Electrical engineering

Chemical engineering (e.g. corrosion)

Material science

Definitions

Reliability may be defined in the following ways:

The idea that an item is fit for a purpose with respect to time

The capacity of a designed, produced, or maintained item to perform as

required over time

The capacity of a population of designed, produced or maintained items to

perform as required over specified time
 The resistance to failure of an item over time

The probability of an item to perform a required function under stated

conditions for a specified period of time

The durability of an object.

Basics of a reliability assessment

Many engineering techniques are used in reliability risk assessments, such as

reliability hazard analysis, failure mode and effects analysis (FMEA),[11] fault tree
analysis (FTA), Reliability Centered Maintenance, (probabilistic) load and material
stress and wear calculations, (probabilistic) fatigue and creep analysis, human error
analysis, manufacturing defect analysis, reliability testing, etc. It is crucial that these
analysis are done properly and with much attention to detail to be effective. Because
of the large number of reliability techniques, their expense, and the varying degrees
of reliability required for different situations, most projects develop a reliability
program plan to specify the reliability tasks (SoW requirements) that will be
performed for that specific system.

Consistent with the creation of a safety cases, for example ARP4761, the goal of
reliability assessments is to provide a robust set of qualitative and quantitative
evidence that use of a component or system will not be associated with
unacceptable risk. The basic steps to take[12] are to:

First thoroughly identify relevant unreliability "hazards", e.g. potential

conditions, events, human errors, failure modes, interactions, failure
mechanisms and root causes, by specific analysis or tests

Assess the associated system risk, by specific analysis or testing

Propose mitigation, e.g. requirements, design changes, detection logic,

maintenance, training, by which the risks may be lowered and controlled for at
an acceptable level.

Determine the best mitigation and get agreement on final, acceptable risk
levels, possibly based on cost/benefit analysis

Risk is here the combination of probability and severity of the failure incident
(scenario) occurring.

In a deminimus definition, severity of failures include the cost of spare parts, man-
hours, logistics, damage (secondary failures), and downtime of machines which may
cause production loss. A more complete definition of failure also can mean injury,
dismemberment, and death of people within the system (witness mine accidents,
industrial accidents, space shuttle failures) and the same to innocent bystanders
(witness the citizenry of cities like Bhopal, Love Canal, Chernobyl, or Sendai, and
other victims of the 2011 Thoku earthquake and tsunami)in this case, reliability
engineering becomes system safety. What is acceptable is determined by the
managing authority or customers or the affected communities. Residual risk is the
risk that is left over after all reliability activities have finished, and includes the un-
identified riskand is therefore not completely quantifiable.

Risk vs Cost/Complexity.[13]

The complexity of the technical systems such as Improvements of Design and

Materials, Planned Inspections, Fool-proof design, and Backup Redundancy
decreases risk and increases the cost. The risk can be decreased to ALARA (as low
as reasonably achievable) or ALAPA (as low as practically achievable) levels.

Reliability and availability program plan

Implementing a reliability program is not simply a software purchase; it's not just a
checklist of items that must be completed that will ensure you have reliable products
and processes. A reliability program is a complex learning and knowledge-based
system unique to your products and processes. It is supported by leadership, built on
the skills that you develop within your team, integrated into your business processes
and executed by following proven standard work practices. [14]

A reliability program plan is used to document exactly what "best practices" (tasks,
methods, tools, analysis, and tests) are required for a particular (sub)system, as well
as clarify customer requirements for reliability assessment. For large-scale complex
systems, the reliability program plan should be a separate document. Resource
determination for manpower and budgets for testing and other tasks is critical for a
successful program. In general, the amount of work required for an effective program
for complex systems is large.

A reliability program plan is essential for achieving high levels of reliability, testability,
maintainability, and the resulting system Availability, and is developed early during
system development and refined over the system's life-cycle. It specifies not only
what the reliability engineer does, but also the tasks performed by other
stakeholders. A reliability program plan is approved by top program Management,
which is responsible for allocation of sufficient resources for its implementation.

A reliability program plan may also be used to evaluate and improve availability of a
system by the strategy of focusing on increasing testability & maintainability and not
on reliability. Improving maintainability is generally easier than improving reliability.
Maintainability estimates (repair rates) are also generally more accurate. However,
because the uncertainties in the reliability estimates are in most cases very large,
they are likely to dominate the availability calculation (prediction uncertainty
problem), even when maintainability levels are very high. When reliability is not
under control, more complicated issues may arise, like manpower (maintainers /
customer service capability) shortages, spare part availability, logistic delays, lack of
repair facilities, extensive retro-fit and complex configuration management costs, and
others. The problem of unreliability may be increased also due to the "domino effect"
of maintenance-induced failures after repairs. Focusing only on maintainability is
therefore not enough. If failures are prevented, none of the other issues are of any
importance, and therefore reliability is generally regarded as the most important part
of availability. Reliability needs to be evaluated and improved related to both
availability and the Total Cost of Ownership (TCO) due to cost of spare parts,
maintenance man-hours, transport costs, storage cost, part obsolete risks, etc. But,
as GM and Toyota have belatedly discovered, TCO also includes the downstream
liability costs when reliability calculations have not sufficiently or accurately
addressed customers' personal bodily risks. Often a trade-off is needed between the
two. There might be a maximum ratio between availability and cost of ownership.
Testability of a system should also be addressed in the plan, as this is the link
between reliability and maintainability. The maintenance strategy can influence the
reliability of a system (e.g., by preventive and/or predictive maintenance), although it
can never bring it above the inherent reliability.

The reliability plan should clearly provide a strategy for availability control. Whether
only availability or also cost of ownership is more important depends on the use of
the system. For example, a system that is a critical link in a production systeme.g.,
a big oil platformis normally allowed to have a very high cost of ownership if that
cost translates to even a minor increase in availability, as the unavailability of the
platform results in a massive loss of revenue which can easily exceed the high cost
of ownership. A proper reliability plan should always address RAMT analysis in its
total context. RAMT stands for Reliability, Availability, Maintainability/Maintenance,
and Testability in context to the customer needs.

Reliability requirements

For any system, one of the first tasks of reliability engineering is to adequately
specify the reliability and maintainability requirements allocated from the overall
availability needs and, more importantly, derived from proper design failure analysis
or preliminary prototype test results. Clear requirements (able to designed to) should
constrain the designers from designing particular unreliable items / constructions /
interfaces / systems. Setting only availability, reliability, testability, or maintainability
targets (e.g., max. failure rates) is not appropriate. This is a broad misunderstanding
about Reliability Requirements Engineering. Reliability requirements address the
system itself, including test and assessment requirements, and associated tasks and
documentation. Reliability requirements are included in the appropriate system or
subsystem requirements specifications, test plans, and contract statements. Creation
of proper lower-level requirements is critical. [15] Provision of only quantitative
minimum targets (e.g., MTBF values or failure rates) is not sufficient for different
reasons. One reason is that a full validation (related to correctness and verifiability in
time) of an quantitative reliability allocation (requirement spec) on lower levels for
complex systems can (often) not be made as a consequence of (1) the fact that the
requirements are probabalistic, (2) the extremely high level of uncertainties involved
for showing compliance with all these probabalistic requirements, and because (3)
reliability is a function of time, and accurate estimates of a (probabalistic) reliability
number per item are available only very late in the project, sometimes even after
many years of in-service use. Compare this problem with the continues
(re-)balancing of, for example, lower-level-system mass requirements in the
development of an aircraft, which is already often a big undertaking. Notice that in
this case masses do only differ in terms of only some %, are not a function of time,
the data is non-probabalistic and available already in CAD models. In case of
reliability, the levels of unreliability (failure rates) may change with factors of decades
(multiples of 10) as result of very minor deviations in design, process, or anything
else.[16] The information is often not available without huge uncertainties within the
development phase. This makes this allocation problem almost impossible to do in a
useful, practical, valid manner that does not result in massive over- or under-
specification. A pragmatic approach is therefore neededfor example: the use of
general levels / classes of quantitative requirements depending only on severity of
failure effects. Also, the validation of results is a far more subjective task than for any
other type of requirement. (Quantitative) reliability parametersin terms of MTBF
are by far the most uncertain design parameters in any design.

Furthermore, reliability design requirements should drive a (system or part) design to

incorporate features that prevent failures from occurring, or limit consequences from
failure in the first place. Not only would it aid in some predictions, this effort would
keep from distracting the engineering effort into a kind of accounting work. A design
requirement should be precise enough so that a designer can "design to" it and can
also provethrough analysis or testingthat the requirement has been achieved,
and, if possible, within some a stated confidence. Any type of reliability requirement
should be detailed and could be derived from failure analysis (Finite-Element Stress
and Fatigue analysis, Reliability Hazard Analysis, FTA, FMEA, Human Factor
Analysis, Functional Hazard Analysis, etc.) or any type of reliability testing. Also,
requirements are needed for verification tests (e.g., required overload stresses) and
test time needed. To derive these requirements in an effective manner, a systems
engineering-based risk assessment and mitigation logic should be used. Robust
hazard log systems must be created that contain detailed information on why and
how systems could or have failed. Requirements are to be derived and tracked in
this way. These practical design requirements shall drive the design and not be used
only for verification purposes. These requirements (often design constraints) are in
this way derived from failure analysis or preliminary tests. Understanding of this
difference compared to only purely quantitative (logistic) requirement specification
(e.g., Failure Rate / MTBF target) is paramount in the development of successful
(complex) systems.[17]

The maintainability requirements address the costs of repairs as well as repair time.
Testability (not to be confused with test requirements) requirements provide the link
between reliability and maintainability and should address detectability of failure
modes (on a particular system level), isolation levels, and the creation of diagnostics
(procedures). As indicated above, reliability engineers should also address
requirements for various reliability tasks and documentation during system
development, testing, production, and operation. These requirements are generally
specified in the contract statement of work and depend on how much leeway the
customer wishes to provide to the contractor. Reliability tasks include various
analyses, planning, and failure reporting. Task selection depends on the criticality of
the system as well as cost. A safety-critical system may require a formal failure
reporting and review process throughout development, whereas a non-critical
system may rely on final test reports. The most common reliability program tasks are
documented in reliability program standards, such as MIL-STD-785 and IEEE 1332.
Failure reporting analysis and corrective action systems are a common approach for
product/process reliability monitoring.

Reliability culture / human errors / human factors

Practically, most failures can in the end be traced back to a root causes of the type of
human error of any kind. For example, human errors in:

Management decisions on for example budgeting, timing and required tasks

Systems Engineering: Use studies (load cases)

Systems Engineering: Requirement analysis / setting

Systems Engineering: Configuration control

Assumptions

Calculations / simulations / FEM analysis

Design

Design drawings

Testing (incorrect load settings or failure measurement)

Statistical analysis

Manufacturing

Quality control

Maintenance

Maintenance manuals

Training

Classifying and Ordering of information

feedback of field information (incorrect or vague)

etc.

However, humans are also very good in detection of (the same) failures, correction
of failures and improvising when abnormal situations occur. The policy that human
actions should be completely ruled out of any design and production process to
improve reliability may not be effective therefore. Some tasks are better performed
by humans and some are better performed by machines. [18]

Furthermore, human errors in management and the organization of data and

information or the misuse or abuse of items may also contribute to unreliability. This
is the core reason why high levels of reliability for complex systems can only be
achieved by following a robust systems engineering process with proper planning
and execution of the validation and verification tasks. This also includes careful
organization of data and information sharing and creating a "reliability culture" in the
same sense as having a "safety culture" is paramount in the development of safety
critical systems.

Reliability prediction and improvement

See also: Risk Assessment Quantitative risk assessment

Reliability prediction is the combination of the creation of a proper reliability model

(see further on this page) together with estimating (and justifying) the input
parameters for this model (like failure rates for a particular failure mode or event and
the mean time to repair the system for a particular failure) and finally to provide a
system (or part) level estimate for the output reliability parameters (system
availability or a particular functional failure frequency).

Some recognized reliability engineering specialistse.g. Patrick O'Connor, R.

Barnardhave argued that too much emphasis is often given to the prediction of
reliability parameters and more effort should be devoted to the prevention of failure
(reliability improvement).[4] Failures can and should be prevented in the first place for
most cases. The emphasis on quantification and target setting in terms of (e.g.)
MTBF might provide the idea that there is a limit to the amount of reliability that can
be achieved. In theory there is no inherent limit and higher reliability does not need
to be more costly in development. Another of their arguments is that prediction of
reliability based on historic data can be very misleading, as a comparison is only
valid for exactly the same designs, products, manufacturing processes and
maintenance under exactly the same loads and environmental context. Even a minor
change in detail in any of these could have major effects on reliability. Furthermore,
normally the most unreliable and important items (most interesting candidates for a
reliability investigation) are most often subjected to many modifications and changes.
Engineering designs are in most industries updated frequently. This is the reason
why the standard (re-active or pro-active) statistical methods and processes as used
in the medical industry or insurance branch are not as effective for engineering.
Another surprising but logical argument is that to be able to accurately predict
reliability by testing, the exact mechanisms of failure must have been known in most
cases and thereforein most casescan be prevented! Following the incorrect
route by trying to quantify and solving a complex reliability engineering problem in
terms of MTBF or Probability and using the re-active approach is referred to by
Barnard as "Playing the Numbers Game" and is regarded as bad practise. [5]

For existing systems, it is arguable that responsible programs would directly analyse
and try to correct the root cause of discovered failures and thereby may render the
initial MTBF estimate fully invalid as new assumptions (subject to high error levels) of
the effect of the patch/redesign must be made. Another practical issue concerns a
general lack of availability of detailed failure data and not consistent filtering of failure
(feedback) data or ignoring statistical errors, which are very high for rare events (like
reliability related failures). Very clear guidelines must be present to be able to count
and compare failures, related to different type of root-causes (e.g. manufacturing-,
maintenance-, transport-, system-induced or inherent design failures, ). Comparing
different type of causes may lead to incorrect estimations and incorrect business
decisions about the focus of improvement.

To perform a proper quantitative reliability prediction for systems may be difficult and
may be very expensive if done by testing. On part level, results can be obtained
often with higher confidence as many samples might be used for the available
testing financial budget, however unfortunately these tests might lack validity on
system level due to the assumptions that had to be made for part level testing.
These authors argue that it can not be emphasized enough that testing for reliability
should be done to create failures in the first place, learn from them and to improve
the system / part. The general conclusion is drawn that an accurate and an absolute
predictionby field data comparison or testingof reliability is in most cases not
possible. An exception might be failures due to wear-out problems like fatigue
failures. In the introduction of MIL-STD-785 it is written that reliability prediction
should be used with great caution if not only used for comparison in trade-off studies.

Design for reliability

Reliability design begins with the development of a (system) model. Reliability and
availability models use block diagrams and Fault Tree Analysis to provide a graphical
means of evaluating the relationships between different parts of the system. These
models may incorporate predictions based on failure rates taken from historical data.
While the (input data) predictions are often not accurate in an absolute sense, they
are valuable to assess relative differences in design alternatives. Maintainability
parameters, for example MTTR, are other inputs for these models.

The most important fundamental initiating causes and failure mechanisms are to be
identified and analyzed with engineering tools. A diverse set of practical guidance
and practical performance and reliability requirements should be provided to
designers so they can generate low-stressed designs and products that protect or
are protected against damage and excessive wear. Proper Validation of input loads
(requirements) may be needed and verification for reliability "performance" by testing
may be needed.
A Fault Tree Diagram

One of the most important design techniques is redundancy. This means that if one
part of the system fails, there is an alternate success path, such as a backup system.
The reason why this is the ultimate design choice is related to the fact that high
confidence reliability evidence for new parts / items is often not available or
extremely expensive to obtain. By creating redundancy, together with a high level of
failure monitoring and the avoidance of common cause failures, even a system with
relative bad single channel (part) reliability, can be made highly reliable (mission
reliability) on system level. No testing of reliability has to be required for this.
Furthermore, by using redundancy and the use of dissimilar design and
manufacturing processes (different suppliers) for the single independent channels,
less sensitivity for quality issues (early childhood failures) is created and very high
levels of reliability can be achieved at all moments of the development cycles (early
life times and long term). Redundancy can also be applied in systems engineering by
double checking requirements, data, designs, calculations, software and tests to
overcome systematic failures.

Another design technique to prevent failures is called physics of failure. This

technique relies on understanding the physical static and dynamic failure
mechanisms. It accounts for variation in load, strength and stress leading to failure at
high level of detail, possible with use of modern finite element method (FEM)
software programs that may handle complex geometries and mechanisms like creep,
stress relaxation, fatigue and probabilistic design (Monte Carlo simulations / DOE).
The material or component can be re-designed to reduce the probability of failure
and to make it more robust against variation. Another common design technique is
component derating: Selecting components whose tolerance significantly exceeds
the expected stress, as using a heavier gauge wire that exceeds the normal
specification for the expected electric current.

Another effective way to deal with unreliability issues is to perform analysis to be

able to predict degradation and being able to prevent unscheduled down events /
failures from occurring. RCM (Reliability Centered Maintenance) programs can be
used for this.
Many tasks, techniques and analyses are specific to particular industries and
applications. Commonly these include:

Built-in test (BIT) (testability analysis)

Failure mode and effects analysis (FMEA)

Reliability hazard analysis

Reliability block-diagram analysis

Dynamic Reliability block-diagram analysis[19]

Fault tree analysis

Root cause analysis

Statistical Engineering, Design of Experiments - e.g. on Simulations /

FEM models or with testing

Sneak circuit analysis

Accelerated testing

Reliability growth analysis (re-active reliability)

Weibull analysis (for testing or mainly "re-active" reliability)

Thermal analysis by finite element analysis (FEA) and / or

measurement

Thermal induced, shock and vibration fatigue analysis by FEA and / or

measurement

Electromagnetic analysis

Avoidance of single point of failure (SPOF)

Functional analysis and functional failure analysis (e.g., function FMEA,

FHA or FFA)

Predictive and preventive maintenance: reliability centered

maintenance (RCM) analysis

Testability analysis

Failure diagnostics analysis (normally also incorporated in FMEA)

 Human error analysis

Operational hazard analysis

Manual screening

Integrated logistics support

Results are presented during the system design reviews and logistics reviews.
Reliability is just one requirement among many system requirements. Engineering
trade studies are used to determine the optimum balance between reliability and
other requirements and constraints.

Quantitative and qualitative approaches and the importance of language

Reliability engineers could concentrate more on "why and how" items / systems may
fail or have failed, instead of mostly trying to predict "when" or at what (changing)
rate (failure rate (t)). Answers to the first questions will drive improvement in design
and processes.[4] When failure mechanisms are really understood then solutions to
prevent failure are easily found. Only required Numbers (e.g. MTBF) will not drive
good designs. The huge amount of (un)reliability hazards that are generally part of
complex systems need first to be classified and ordered (based on qualitative and
quantitative logic if possible) to get to efficient assessment and improvement. This is
partly done in pure language and proposition logic, but also based on experience
with similar items. This can for example be seen in descriptions of events in Fault
Tree Analysis, FMEA analysis and a hazard (tracking) log. In this sense language
and proper grammar (part of qualitative analysis) plays an important role in reliability
engineering, just like it does in safety engineering or in general within systems
engineering. Engineers are likely to question why? Well, it is precisely needed
because systems engineering is very much about finding the correct words to
describe the problem (and related risks) to be solved by the engineering solutions we
intend to create. In the words of Jack Ring, the systems engineer's job is to
"language the project." [Ring et al. 2000]. [20] Language in itself is about putting an
order in a description of the reality of a (failure of a) complex function/item/system in
a complex surrounding. Reliability engineers use both quantitative and qualitative
methods, which extensively use language to pinpoint the risks to be solved.

The importance of language also relates to the risks of human error, which can be
seen as the ultimate root cause of almost all failuressee further on this site. As an
example, proper instructions (often written by technical authors in so called simplified
English) in maintenance manuals, operation manuals, emergency procedures and
others are needed to prevent systematic human errors in any maintenance or
operational task that may result in system failures.

Reliability modeling

Reliability modeling is the process of predicting or understanding the reliability of a

component or system prior to its implementation. Two types of analysis that are often
used to model a complete system availability (including effects from logistics issues
like spare part provisioning, transport and manpower) behavior are Fault Tree
Analysis and reliability block diagrams. On component level the same type of
analysis can be used together with others. The input for the models can come from
many sources: Testing, Earlier operational experience field data or data handbooks
from the same or mixed industries can be used. In all cases, the data must be used
with great caution as predictions are only valid in case the same product in the same
context is used. Often predictions are only made to compare alternatives.

A reliability block diagram showing a 1oo3 (1 out of 3) redundant designed

subsystem

For part level predictions, two separate fields of investigation are common:

The physics of failure approach uses an understanding of physical failure

mechanisms involved, such as mechanical crack propagation or chemical
corrosion degradation or failure;

The parts stress modeling approach is an empirical method for prediction

based on counting the number and type of components of the system, and the
stress they undergo during operation.

Software reliability is a more challenging area that must be considered when it is a

considerable component to system functionality.

Reliability theory

Main articles: Reliability theory, Failure rate, and Survival analysis

Reliability is defined as the probability that a device will perform its intended function
during a specified period of time under stated conditions. Mathematically, this may
be expressed as,

,
where is the failure probability density function and is the length of the period
of time (which is assumed to start from time zero).

There are a few key elements of this definition:

1. Reliability is predicated on "intended function:" Generally, this is taken to

mean operation without failure. However, even if no individual part of the
system fails, but the system as a whole does not do what was intended, then
it is still charged against the system reliability. The system requirements
specification is the criterion against which reliability is measured.
 2. Reliability applies to a specified period of time. In practical terms, this means
that a system has a specified chance that it will operate without failure before
time . Reliability engineering ensures that components and materials will meet
the requirements during the specified time. Units other than time may
sometimes be used.

3. Reliability is restricted to operation under stated (or explicitly defined)

conditions. This constraint is necessary because it is impossible to design a
system for unlimited conditions. A Mars Rover will have different specified
conditions than a family car. The operating environment must be addressed
during design and testing. That same rover may be required to operate in
varying conditions requiring additional scrutiny.

Quantitative system reliability parameterstheory

Quantitative Requirements are specified using reliability parameters. The most

common reliability parameter is the mean time to failure (MTTF), which can also be
specified as the failure rate (this is expressed as a frequency or conditional
probability density function (PDF)) or the number of failures during a given period.
These parameters may be useful for higher system levels and systems that are
operated frequently, such as most vehicles, machinery, and electronic equipment.
Reliability increases as the MTTF increases. The MTTF is usually specified in hours,
but can also be used with other units of measurement, such as miles or cycles.
Using MTTF values on lower system levels can be very misleading, specially if the
Failures Modes and Mechanisms it concerns (The F in MTTF) are not specified with
it.[16]

In other cases, reliability is specified as the probability of mission success. For

example, reliability of a scheduled aircraft flight can be specified as a dimensionless
probability or a percentage, as in system safety engineering.

A special case of mission success is the single-shot device or system. These are
devices or systems that remain relatively dormant and only operate once. Examples
include automobile airbags, thermal batteries and missiles. Single-shot reliability is
specified as a probability of one-time success, or is subsumed into a related
parameter. Single-shot missile reliability may be specified as a requirement for the
probability of a hit. For such systems, the probability of failure on demand (PFD) is
the reliability measurewhich actually is an unavailability number. This PFD is
derived from failure rate (a frequency of occurrence) and mission time for non-
repairable systems.

For repairable systems, it is obtained from failure rate and mean-time-to-repair

(MTTR) and test interval. This measure may not be unique for a given system as this
measure depends on the kind of demand. In addition to system level requirements,
reliability requirements may be specified for critical subsystems. In most cases,
reliability parameters are specified with appropriate statistical confidence intervals.

Reliability testing
A reliability sequential test plan

The purpose of reliability testing is to discover potential problems with the design as
early as possible and, ultimately, provide confidence that the system meets its
reliability requirements.

Reliability testing may be performed at several levels and there are different types of
testing. Complex systems may be tested at component, circuit board, unit, assembly,
subsystem and system levels.[21] (The test level nomenclature varies among
applications.) For example, performing environmental stress screening tests at lower
levels, such as piece parts or small assemblies, catches problems before they cause
failures at higher levels. Testing proceeds during each level of integration through
full-up system testing, developmental testing, and operational testing, thereby
reducing program risk. However, testing does not mitigate unreliability risk.

With each test both a statistical type 1 and type 2 error could be made and depends
on sample size, test time, assumptions and the needed discrimination ratio. There is
risk of incorrectly accepting a bad design (type 1 error) and the risk of incorrectly
rejecting a good design (type 2 error).

It is not always feasible to test all system requirements. Some systems are
prohibitively expensive to test; some failure modes may take years to observe; some
complex interactions result in a huge number of possible test cases; and some tests
require the use of limited test ranges or other resources. In such cases, different
approaches to testing can be used, such as (highly) accelerated life testing, design
of experiments, and simulations.

The desired level of statistical confidence also plays a role in reliability testing.
Statistical confidence is increased by increasing either the test time or the number of
items tested. Reliability test plans are designed to achieve the specified reliability at
the specified confidence level with the minimum number of test units and test time.
Different test plans result in different levels of risk to the producer and consumer. The
desired reliability, statistical confidence, and risk levels for each side influence the
ultimate test plan. The customer and developer should agree in advance on how
reliability requirements will be tested.

A key aspect of reliability testing is to define "failure". Although this may seem
obvious, there are many situations where it is not clear whether a failure is really the
fault of the system. Variations in test conditions, operator differences, weather and
unexpected situations create differences between the customer and the system
developer. One strategy to address this issue is to use a scoring conference
process. A scoring conference includes representatives from the customer, the
developer, the test organization, the reliability organization, and sometimes
independent observers. The scoring conference process is defined in the statement
of work. Each test case is considered by the group and "scored" as a success or
failure. This scoring is the official result used by the reliability engineer.

As part of the requirements phase, the reliability engineer develops a test strategy
with the customer. The test strategy makes trade-offs between the needs of the
reliability organization, which wants as much data as possible, and constraints such
as cost, schedule and available resources. Test plans and procedures are developed
for each reliability test, and results are documented.

Reliability testing is common in the Photonics industry. Examples of reliability tests of

lasers are life test and burn-in. These tests consist of the highly accelerated ageing,
under controlled conditions, of a group of lasers. The data collected from these life
tests are used to predict laser life expectancy under the intended operating
characteristics.[22]

Reliability test requirements

Reliability test requirements can follow from any analysis for which the first estimate
of failure probability, failure mode or effect needs to be justified. Evidence can be
generated with some level of confidence by testing. With software-based systems,
the probability is a mix of software and hardware-based failures. Testing reliability
requirements is problematic for several reasons. A single test is in most cases
insufficient to generate enough statistical data. Multiple tests or long-duration tests
are usually very expensive. Some tests are simply impractical, and environmental
conditions can be hard to predict over a systems life-cycle.

Reliability engineering is used to design a realistic and affordable test program that
provides empirical evidence that the system meets its reliability requirements.
Statistical confidence levels are used to address some of these concerns. A certain
parameter is expressed along with a corresponding confidence level: for example, an
MTBF of 1000 hours at 90% confidence level. From this specification, the reliability
engineer can, for example, design a test with explicit criteria for the number of hours
and number of failures until the requirement is met or failed. Different sorts of tests
are possible.

The combination of required reliability level and required confidence level greatly
affects the development cost and the risk to both the customer and producer. Care is
needed to select the best combination of requirementse.g. cost-effectiveness.
Reliability testing may be performed at various levels, such as component,
subsystem and system. Also, many factors must be addressed during testing and
operation, such as extreme temperature and humidity, shock, vibration, or other
environmental factors (like loss of signal, cooling or power; or other catastrophes
such as fire, floods, excessive heat, physical or security violations or other myriad
forms of damage or degradation). For systems that must last many years,
accelerated life tests may be needed.

Accelerated testing

The purpose of accelerated life testing (ALT test) is to induce field failure in the
laboratory at a much faster rate by providing a harsher, but nonetheless
representative, environment. In such a test, the product is expected to fail in the lab
just as it would have failed in the fieldbut in much less time. The main objective of
an accelerated test is either of the following:

To discover failure modes

To predict the normal field life from the high stress lab life

An Accelerated testing program can be broken down into the following steps:

Define objective and scope of the test

Collect required information about the product

Identify the stress(es)

Determine level of stress(es)

Conduct the accelerated test and analyze the collected data.

Common way to determine a life stress relationship are

Arrhenius model

Eyring model

Inverse power law model

Temperaturehumidity model

Temperature non-thermal model

Software reliability

Further information: Software reliability

Software reliability is a special aspect of reliability engineering. System reliability, by
definition, includes all parts of the system, including hardware, software, supporting
infrastructure (including critical external interfaces), operators and procedures.
Traditionally, reliability engineering focuses on critical hardware parts of the system.
Since the widespread use of digital integrated circuit technology, software has
become an increasingly critical part of most electronics and, hence, nearly all
present day systems.

There are significant differences, however, in how software and hardware behave.
Most hardware unreliability is the result of a component or material failure that
results in the system not performing its intended function. Repairing or replacing the
hardware component restores the system to its original operating state. However,
software does not fail in the same sense that hardware fails. Instead, software
unreliability is the result of unanticipated results of software operations. Even
relatively small software programs can have astronomically large combinations of
inputs and states that are infeasible to exhaustively test. Restoring software to its
original state only works until the same combination of inputs and states results in
the same unintended result. Software reliability engineering must take this into
account.

Despite this difference in the source of failure between software and hardware,
several software reliability models based on statistics have been proposed to
quantify what we experience with software: the longer software is run, the higher the
probability that it will eventually be used in an untested manner and exhibit a latent
defect that results in a failure (Shooman 1987), (Musa 2005), (Denney 2005).

As with hardware, software reliability depends on good requirements, design and

implementation. Software reliability engineering relies heavily on a disciplined
software engineering process to anticipate and design against unintended
consequences. There is more overlap between software quality engineering and
software reliability engineering than between hardware quality and reliability. A good
software development plan is a key aspect of the software reliability program. The
software development plan describes the design and coding standards, peer
reviews, unit tests, configuration management, software metrics and software
models to be used during software development.

A common reliability metric is the number of software faults, usually expressed as

faults per thousand lines of code. This metric, along with software execution time, is
key to most software reliability models and estimates. The theory is that the software
reliability increases as the number of faults (or fault density) decreases or goes
down. Establishing a direct connection between fault density and mean-time-
between-failure is difficult, however, because of the way software faults are
distributed in the code, their severity, and the probability of the combination of inputs
necessary to encounter the fault. Nevertheless, fault density serves as a useful
indicator for the reliability engineer. Other software metrics, such as complexity, are
also used. This metric remains controversial, since changes in software development
and verification practices can have dramatic impact on overall defect rates.

Testing is even more important for software than hardware. Even the best software
development process results in some software faults that are nearly undetectable
until tested. As with hardware, software is tested at several levels, starting with
individual units, through integration and full-up system testing. Unlike hardware, it is
inadvisable to skip levels of software testing. During all phases of testing, software
faults are discovered, corrected, and re-tested. Reliability estimates are updated
based on the fault density and other metrics. At a system level, mean-time-between-
failure data can be collected and used to estimate reliability. Unlike hardware,
performing exactly the same test on exactly the same software configuration does
not provide increased statistical confidence. Instead, software reliability uses
different metrics, such as code coverage.

Eventually, the software is integrated with the hardware in the top-level system, and
software reliability is subsumed by system reliability. The Software Engineering
Institute's capability maturity model is a common means of assessing the overall
software development process for reliability and quality purposes.

Vs safety engineering

Reliability engineering differs from safety engineering with respect to the kind of
hazards that are considered. Reliability engineering is in the end only concerned with
cost. It relates to all Reliability hazards that could transform into incidents with a
particular level of loss of revenue for the company or the customer. These can be
cost due to loss of production due to system unavailability, unexpected high or low
demands for spares, repair costs, man hours, (multiple) re-designs, interruptions on
normal production (e.g. due to high repair times or due to unexpected demands for
non-stocked spares) and many other indirect costs. [23]

Safety engineering, on the other hand, is more specific and regulated. It relates to
only very specific and system safety hazards that could potentially lead to severe
accidents and is primarily concerned with loss of life, loss of equipment, or
environmental damage. The related system functional reliability requirements are
sometimes extremely high. It deals with unwanted dangerous events (for life,
property, and environment) in the same sense as reliability engineering, but does
normally not directly look at cost and is not concerned with repair actions after failure
/ accidents (on system level). Another difference is the level of impact of failures on
society and the control of governments. Safety engineering is often strictly controlled
by governments (e.g. nuclear, aerospace, defense, rail and oil industries). [23]

Furthermore, safety engineering and reliability engineering may even have

contradicting requirements. This relates to system level architecture choices. [citation
needed]
For example, in train signal control systems it is common practice to use a fail-
safe system design concept. In this concept the wrong-side failure need to be fully
controlled to an extreme low failure rate. These failures are related to possible
severe effects, like frontal collisions (2* GREEN lights). Systems are designed in a
way that the far majority of failures will simply result in a temporary or total loss of
signals or open contacts of relays and generate RED lights for all trains. This is the
safe state. All trains are stopped immediately. This fail-safe logic might unfortunately
lower the reliability of the system. The reason for this is the higher risk of false
tripping as any full or temporary, intermittent failure is quickly latched in a shut-down
(safe) state. Different solutions are available for this issue. See the section on fault
tolerance below.
Fault tolerance

Main article: Fault tolerance

Reliability can be increased here by using a 1oo2 (1 out of 2) redundancy on part or

system level, but this does in turn lower the safety levels (more possibilities for
wrong side and undetected dangerous failures). Fault tolerant voting systems (e.g.
2oo3 voting logic) can increase both reliability and safety on a system level. In this
case the so-called "operational" or "mission" reliability as well as the safety of a
system can be increased. This is also common practice in Aerospace systems that
need continued availability and do not have a fail-safe mode (e.g. flight computers
and related electrical and / or mechanical and / or hydraulic steering functions need
always to be working. There are no safe fixed positions for rudder or other steering
parts when the aircraft is flying).

Basic reliability and mission (operational) reliability

The above example of a 2oo3 fault tolerant system increases both mission reliability
as well as safety. However, the "basic" reliability of the system will in this case still be
lower than a non redundant (1oo1) or 2oo2 system! Basic reliability refers to all
failures, including those that might not result in system failure, but do result in
maintenance repair actions, logistic cost, use of spares, etc. For example, the
replacement or repair of 1 channel in a 2oo3 voting system that is still operating with
one failed channel (which in this state actually has become a 2oo2 system) is
contributing to basic unreliability but not mission unreliability. Also, for example, the
failure of the taillight of an aircraft is not considered as a mission loss failure, but
does contribute to the basic unreliability.

Detectability and common cause failures

When using fault tolerant (redundant architectures) systems or systems that are
equipped with protection functions, detectability of failures and avoidance of common
cause failures becomes paramount for safe functioning and/or mission reliability.

Reliability versus quality (Six Sigma)

Six Sigma has its roots in manufacturing and reliability engineering is a sub-part of
systems engineering. The systems engineering process is a discovery process that
is quite unlike a manufacturing process. A manufacturing process is focused on
repetitive activities that achieve high quality outputs with minimum cost and time.
The systems engineering process must begin by discovering the real (potential)
problem that needs to be solved; the biggest failure that can be made in systems
engineering is finding an elegant solution to the wrong problem [24] (or in terms of
reliability: "providing elegant solutions to the wrong root causes of system failures").

The everyday usage term "quality of a product" is loosely taken to mean its inherent
degree of excellence. In industry, this is made more precise by defining quality to be
"conformance to requirement specifications at the start of use". Assuming the final
product specifications adequately capture original requirements and customer (or
rest of system) needs, the quality level of these parts can now be precisely
measured by the fraction of units shipped that meet the detailed product
specifications.[25]

Variation of this static output may affect quality and reliability, but this is not the total
picture. More inherent aspects may play a role or variation at microscopic levels may
not be measured or controlled by any means (e.g. one good example is the
unavoidable existence of micro cracks and chemical impurities in standard metal
products, which may progress over time under physical or chemical "loading" into
macro level defects). Furthermore, on system level, systematic failures may play a
dominant role (e.g. requirement errors or software or software compiler or design
flaws).

Furthermore, for more complex systems it should be questioned if (derived, lower

level) requirements and related product specifications are validated? Will it later
result in worn items and systems, by general wear, fatigue or corrosion mechanisms,
debris accumulation or due to maintenance induced failures? Are there interactions
on any system level (as investigated by for example Fault Tree Analysis)? How many
of these systems still meet function and fulfill the needs after a week of operation?
What performance losses occurred? Did full system failure occur? What happens
after the end of a one-year warranty period? And what happens after 50 years (a
common lifetime for aircraft, trains, nuclear systems, etc...)? That is where "reliability"
comes in. These issues are far more complex and can not be controlled only by a
standard "quality" (six sigma) way of working. They need a systems engineering
approach.

Quality is a snapshot at the start of life and mainly related to control of lower level
product specifications and reliability is (as part of systems engineering) more of a
system level motion picture of the day-by-day operation for many years. Time zero
defects are manufacturing mistakes that escaped final test (Quality Control). The
additional defects that appear over time are "reliability defects" or reliability fallout.
These reliability issues may just as well occur due to Inherent design issues, which
may have nothing to do with non-conformance product specifications. Items that are
produced perfectlyaccording all product specificationsmay fail over time due to
any single or combined failure mechanism (e.g. mechanical-, electrical-, chemical- or
human error related). All these parameters are also a function of all all possible
variances coming from initial production. Theoretically, all items will functionally fail
over infinite time.[26] In theory the Quality level might be described by a single fraction
defective. To describe reliability fallout a probability model that describes the fraction
fallout over time is needed. This is known as the life distribution model. [25]

Quality is therefore related to manufacturing, and reliability is more related to the

validation of sub-system or lower item requirements, (system or part) inherent design
and life cycle solutions. Items that do not conform to (any) product specification in
general will do worse in terms of reliability (having a lower MTTF), but this does not
always have to be the case. The full mathematical Quantification (in statistical
models) of this combined relation is in general very difficult or even practically
impossible. In case manufacturing variances can be effectively reduced, six sigma
tools may be used to find optimal process solutions and may thereby also increase
reliability. Six Sigma may also help to design more robust related to manufacturing
induced failures.
In contrast with Six Sigma, reliability engineering solutions are generally found by
having a focus into a (system) design and not on the manufacturing process.
Solutions are found in different ways, for example by simplifying a system and
therefore understanding more mechanisms of failure involved, detailed calculation of
material stress levels and required safety factors, finding possible abnormal system
load conditions and next to this also to increase design robustness against variation
from the manufacturing variances and related failure mechanisms. Furthermore,
reliability engineering use system level solutions, like designing redundancy and fault
tolerant systems in case of high availability needs (see Reliability engineering vs
Safety engineering above).

Next to this and also in a major contrast with reliability engineering, Six-Sigma is
much more measurement based (quantification). The core of Six-Sigma thrives on
empirical research and statistics where it is possible to measure parameters (e.g. to
find transfer functions). This can not be translated practically to most reliability
issues, as reliability is not (easy) measurable due to the function of time (large times
may be involved), specially during the requirements specification and design phase
where reliability engineering is the most efficient. Full Quantification of reliability is in
this phase extremely difficult or costly (testing). It also may foster re-active
management (waiting for system failures to be measured). Furthermore, as
explained on this page, Reliability problems are likely to come from many different
(e.g. inherent failures, human error, systematic failures) causes besides
manufacturing induced defects.

Note: What is called a defect however in six-sigma / quality literature is not the same
as a failure (Field failure | e.g. fractured item) in reliability. A defects in six-sigma /
quality refers generally to a non-conformance with a (basis functional or dimensional)
requirement. Items can however fail over time, even if these requirements (e.g. a
dimension) are all fulfilled. Quality is normally not much concerned with the question
if the requirements are correct.

Quality (manufacturing), Six Sigma (processes) and reliability (design) departments

should provide input to each other to cover the complete risks more efficiently.

Reliability operational assessment

After a system is produced, reliability engineering monitors, assesses and corrects

deficiencies. Monitoring includes electronic and visual surveillance of critical
parameters identified during the fault tree analysis design stage. Data collection is
highly dependent on the nature of the system. Most large organizations have quality
control groups that collect failure data on vehicles, equipment and machinery.
Consumer product failures are often tracked by the number of returns. For systems
in dormant storage or on standby, it is necessary to establish a formal surveillance
program to inspect and test random samples. Any changes to the system, such as
field upgrades or recall repairs, require additional reliability testing to ensure the
reliability of the modification. Since it is not possible to anticipate all the failure
modes of a given system, especially ones with a human element, failures will occur.
The reliability program also includes a systematic root cause analysis that identifies
the causal relationships involved in the failure such that effective corrective actions
may be implemented. When possible, system failures and corrective actions are
reported to the reliability engineering organization.

One of the most common methods to apply to a reliability operational assessment

are failure reporting, analysis, and corrective action systems (FRACAS). This
systematic approach develops a reliability, safety and logistics assessment based on
Failure / Incident reporting, management, analysis and corrective/preventive actions.
Organizations today are adopting this method and utilize commercial systems such
as a Web-based FRACAS application enabling an organization to create a
failure/incident data repository from which statistics can be derived to view accurate
and genuine reliability, safety and quality performances.

It is extremely important to have one common source FRACAS system for all end
items. Also, test results should be able to be captured here in a practical way. Failure
to adopt one easy to handle (easy data entry for field engineers and repair shop
engineers)and maintain integrated system is likely to result in a FRACAS program
failure.

Some of the common outputs from a FRACAS system includes: Field MTBF, MTTR,
Spares Consumption, Reliability Growth, Failure/Incidents distribution by type,
location, part no., serial no, symptom etc.

The use of past data to predict the reliability of new comparable systems/items can
be misleading as reliability is a function of the context of use and can be affected by
small changes in the designs/manufacturing.

Reliability organizations

Systems of any significant complexity are developed by organizations of people,

such as a commercial company or a government agency. The reliability engineering
organization must be consistent with the company's organizational structure. For
small, non-critical systems, reliability engineering may be informal. As complexity
grows, the need arises for a formal reliability function. Because reliability is important
to the customer, the customer may even specify certain aspects of the reliability
organization.

There are several common types of reliability organizations. The project manager or
chief engineer may employ one or more reliability engineers directly. In larger
organizations, there is usually a product assurance or specialty engineering
organization, which may include reliability, maintainability, quality, safety, human
factors, logistics, etc. In such case, the reliability engineer reports to the product
assurance manager or specialty engineering manager.

In some cases, a company may wish to establish an independent reliability

organization. This is desirable to ensure that the system reliability, which is often
expensive and time consuming, is not unduly slighted due to budget and schedule
pressures. In such cases, the reliability engineer works for the project day-to-day, but
is actually employed and paid by a separate organization within the company.
Because reliability engineering is critical to early system design, it has become
common for reliability engineers, however the organization is structured, to work as
part of an integrated product team.

Education

Some universities offer graduate degrees in reliability engineering. Other reliability

engineers typically have an engineering degree, which can be in any field of
engineering, from an accredited university or college program. Many engineering
programs offer reliability courses, and some universities have entire reliability
engineering programs. A reliability engineer may be registered as a professional
engineer by the state, but this is not required by most employers. There are many
professional conferences and industry training programs available for reliability
engineers. Several professional organizations exist for reliability engineers, including
the American Society for Quality Reliability Division (ASQ-RD), [27] the IEEE Reliability
Society, the American Society for Quality (ASQ),[28] and the Society of Reliability
Engineers (SRE).[29]

A group of engineers have provided a list of useful tools for reliability engineering.
These include: RelCalc software, Military Handbook 217 (Mil-HDBK-217), and the
NAVMAT P-4855-1A manual. Analyzing failures and successes coupled with a
quality standards process also provides systemized information to making informed
engineering designs.[30]

See also

Engineering portal

Factor of safety

Failing badly

Failure mode and effects analysis (FMEA)

Solid mechanics

Highly accelerated life test

Highly accelerated stress test

Human reliability

Industrial engineering

Institute of Industrial Engineers

Logistic engineering
 Performance engineering

Product qualification

RAMS

Reliability, availability and serviceability

Reliability theory of aging and longevity

Security engineering

Software reliability testing

Spurious trip level

Structural fracture mechanics

Strength of materials

Temperature cycling

References

1.

Institute of Electrical and Electronics Engineers (1990) IEEE Standard Computer

Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York, NY
ISBN 1-55937-079-3
RCM II, Reliability Centered Maintenance, Second edition 2008, page 250-
260, the role of Actuarial analysis in Reliability
Why You Cannot Predict Electronic Product Reliability (PDF). 2012 ARS,
Europe. Warsaw, Poland.
O'Connor, Patrick D. T. (2002), Practical Reliability Engineering (Fourth Ed.),
John Wiley & Sons, New York. ISBN 978-0-4708-4462-5.
Barnard, R.W.A. (2008). "What is wrong with Reliability Engineering?" (PDF).
Lambda Consulting. Retrieved 30 October 2014.
Saleh, J.H. and Marais, Ken, "Highlights from the Early (and pre-) History of
Reliability Engineering", Reliability Engineering and System Safety, Volume 91, Issue
2, February 2006, Pages 249-256
Juran, Joseph and Gryna, Frank, Quality Control Handbook, Fourth Edition,
McGraw-Hill, New York, 1988, p.24.3
Wong, Kam, "Unified Field (Failure) Theory-Demise of the Bathtub Curve",
Proceedings of Annual RAMS, 1981, pp402-408
Practical Reliability Engineering, P. O'Conner - 2012
"Articles - Where Do Reliability Engineers Come From? - ReliabilityWeb.com:
A Culture of Reliability".
 Using Failure Modes, Mechanisms, and Effects Analysis in Medical Device
Adverse Event Investigations, S. Cheng, D. Das, and M. Pecht, ICBO: International
Conference on Biomedical Ontology, Buffalo, NY, July 2630, 2011, pp. 340345
Federal Aviation Administration (19 March 2013). System Safety Handbook
(PDF). U.S. Department of Transportation. Retrieved 2 June 2013.
Kokcharov I. "Structural Safety". Structural Integrity Analysis (PDF).
Reliability Hotwire - July 2015
Reliability Maintainability and Risk Practical Methods for Engineers Including
Reliability Centred Maintenance and Safety - David J. Smith (2011)
Practical Reliability Engineering, O'Conner, 2001
System Reliability Theory, second edition, Rausand and Hoyland - 2004
The Blame Machine, Why Human Error Causes Accidents - Whittingham,
2007
Salvatore Distefano, Antonio Puliafito: Dependability Evaluation with Dynamic
Reliability Block Diagrams and Dynamic Fault Trees. IEEE Trans. Dependable Sec.
Comput. 6(1): 4-17 (2009)
The Seven Samurais of Systems Engineering, James Martin (2008)
Ben-Gal I., Herer Y. and Raz T. (2003). "Self-correcting inspection procedure
under inspection errors" (PDF). IIE Transactions on Quality and Reliability, 34(6), pp.
529540.
"Yelo Reliability Testing". Retrieved 6 November 2014.
Reliability and Safety Engineering - Verma, Ajit Kumar, Ajit, Srividya, Karanki,
Durga Rao (2010)
INCOSE SE Guidelines
"8.1.1.1. Quality versus reliability".
"The Second Law of Thermodynamics, Evolution, and Probability".
American Society for Quality Reliability Division (ASQ-RD)
American Society for Quality (ASQ)
Society of Reliability Engineers (SRE)

1 "Top Tools for a Reliability Engineer's Toolbox: 7 Reliability Engineering

Experts Reveal Their Favorite Tools, Tips and Resources". Asset Tag & UID
Label Blog. Retrieved 2016-01-18.

Further reading

Blanchard, Benjamin S. (1992), Logistics Engineering and Management

(Fourth Ed.), Prentice-Hall, Inc., Englewood Cliffs, New Jersey.

Breitler, Alan L. and Sloan, C. (2005), Proceedings of the American Institute of

Aeronautics and Astronautics (AIAA) Air Force T&E Days Conference,
Nashville, TN, December, 2005: System Reliability Prediction: towards a
General Approach Using a Neural Network.

Ebeling, Charles E., (1997), An Introduction to Reliability and Maintainability

Engineering, McGraw-Hill Companies, Inc., Boston.

Denney, Richard (2005) Succeeding with Use Cases: Working Smart to

Deliver Quality. Addison-Wesley Professional Publishing. ISBN. Discusses the
 use of software reliability engineering in use case driven software
development.

Gano, Dean L. (2007), "Apollo Root Cause Analysis" (Third Edition),

Apollonian Publications, LLC., Richland, Washington

Holmes, Oliver Wendell, Sr. The Deacon's Masterpiece

Kapur, K.C., and Lamberson, L.R., (1977), Reliability in Engineering Design,

John Wiley & Sons, New York.

Kececioglu, Dimitri, (1991) "Reliability Engineering Handbook", Prentice-Hall,

Englewood Cliffs, New Jersey

Trevor Kletz (1998) Process Plants: A Handbook for Inherently Safer Design
CRC ISBN 1-56032-619-0

Leemis, Lawrence, (1995) Reliability: Probabilistic Models and Statistical

Methods, 1995, Prentice-Hall. ISBN 0-13-720517-1

Frank Lees (2005). Loss Prevention in the Process Industries (3rdEdition

ed.). Elsevier. ISBN 978-0-7506-7555-0.

MacDiarmid, Preston; Morris, Seymour; et al., (1995), Reliability Toolkit:

Commercial Practices Edition, Reliability Analysis Center and Rome
Laboratory, Rome, New York.

Modarres, Mohammad; Kaminskiy, Mark; Krivtsov, Vasiliy (1999), "Reliability

Engineering and Risk Analysis: A Practical Guide, CRC Press, ISBN 0-8247-
2000-8.

Musa, John (2005) Software Reliability Engineering: More Reliable Software

Faster and Cheaper, 2nd. Edition, AuthorHouse. ISBN

Neubeck, Ken (2004) "Practical Reliability Analysis", Prentice Hall, New

Jersey

Neufelder, Ann Marie, (1993), Ensuring Software Reliability, Marcel Dekker,

Inc., New York.

O'Connor, Patrick D. T. (2002), Practical Reliability Engineering (Fourth Ed.),

John Wiley & Sons, New York. ISBN 978-0-4708-4462-5.

Shooman, Martin, (1987), Software Engineering: Design, Reliability, and

Management, McGraw-Hill, New York.

Tobias, Trindade, (1995), Applied Reliability, Chapman & Hall/CRC, ISBN 0-

442-00469-9
 Springer Series in Reliability Engineering

Nelson, Wayne B., (2004), Accelerated TestingStatistical Models, Test

Plans, and Data Analysis, John Wiley & Sons, New York, ISBN 0-471-69736-2

Bagdonavicius, V., Nikulin, M., (2002), "Accelerated Life Models. Modeling

and Statistical analysis", CHAPMAN&HALL/CRC, Boca Raton, ISBN 1-58488-
186-0

Todinov, M. (2016), "Reliability and Risk Models: setting reliability

requirements", Wiley, 978-1-118-87332-8.

US standards, specifications, and handbooks

Aerospace Report Number: TOR-2007(8583)-6889 Reliability Program

Requirements for Space Systems, The Aerospace Corporation (10 Jul 2007)

DoD 3235.1-H (3rd Ed) Test and Evaluation of System Reliability, Availability,
and Maintainability (A Primer), U.S. Department of Defense (March 1982).

NASA GSFC 431-REF-000370 Flight Assurance Procedure: Performing a

Failure Mode and Effects Analysis, National Aeronautics and Space
Administration Goddard Space Flight Center (10 Aug 1996).

IEEE 13321998 IEEE Standard Reliability Program for the Development and
Production of Electronic Systems and Equipment, Institute of Electrical and
Electronics Engineers (1998).

JPL D-5703 Reliability Analysis Handbook, National Aeronautics and Space

Administration Jet Propulsion Laboratory (July 1990).

MIL-STD-785B Reliability Program for Systems and Equipment Development

and Production, U.S. Department of Defense (15 Sep 1980). (*Obsolete,
superseded by ANSI/GEIA-STD-0009-2008 titled Reliability Program
Standard for Systems Design, Development, and Manufacturing, 13 Nov
2008)

MIL-HDBK-217F Reliability Prediction of Electronic Equipment, U.S.

Department of Defense (2 Dec 1991).

MIL-HDBK-217F (Notice 1) Reliability Prediction of Electronic Equipment,

U.S. Department of Defense (10 Jul 1992).

MIL-HDBK-217F (Notice 2) Reliability Prediction of Electronic Equipment,

U.S. Department of Defense (28 Feb 1995).

MIL-STD-690D Failure Rate Sampling Plans and Procedures, U.S.

Department of Defense (10 Jun 2005).
 MIL-HDBK-338B Electronic Reliability Design Handbook, U.S. Department of
Defense (1 Oct 1998).

MIL-HDBK-2173 Reliability-Centered Maintenance (RCM) Requirements for

Naval Aircraft, Weapon Systems, and Support Equipment, U.S. Department of
Defense (30 JAN 1998); (superseded by NAVAIR 00-25-403).

MIL-STD-1543B Reliability Program Requirements for Space and Launch

Vehicles, U.S. Department of Defense (25 Oct 1988).

MIL-STD-1629A Procedures for Performing a Failure Mode Effects and

Criticality Analysis, U.S. Department of Defense (24 Nov 1980).

MIL-HDBK-781A Reliability Test Methods, Plans, and Environments for

Engineering Development, Qualification, and Production, U.S. Department of
Defense (1 Apr 1996).

NSWC-06 (Part A & B) Handbook of Reliability Prediction Procedures for

Mechanical Equipment, Naval Surface Warfare Center (10 Jan 2006).

SR-332 Reliability Prediction Procedure for Electronic Equipment, Telcordia

Technologies (January 2011).

FD-ARPP-01 Automated Reliability Prediction Procedure, Telcordia

Technologies (January 2011).

GR-357 Generic Requirements for Assuring the Reliability of Components

Used in Telecommunications Equipment, Telcordia Technologies (March
2001).

UK standards

In the UK, there are more up to date standards maintained under the sponsorship of
UK MOD as Defence Standards. The relevant Standards include:

DEF STAN 00-40 Reliability and Maintainability (R&M)

PART 1: Issue 5: Management Responsibilities and Requirements for

Programmes and Plans

PART 4: (ARMP-4)Issue 2: Guidance for Writing NATO R&M Requirements

Documents

PART 6: Issue 1: IN-SERVICE R & M

PART 7 (ARMP-7) Issue 1: NATO R&M Terminology Applicable to ARMP's

DEF STAN 00-42 RELIABILITY AND MAINTAINABILITY ASSURANCE GUIDES

 PART 1: Issue 1: ONE-SHOT DEVICES/SYSTEMS

PART 2: Issue 1: SOFTWARE

PART 3: