Study for the CRE by treating each reliability concept as a definition plus an applicability condition. For every formula you learn, write one sentence describing when it is valid, then test yourself with short scenarios where the condition is met and where it is violated. Work distribution-choice, censoring, and redundancy problems by hand with small numbers so the assumptions stay visible. Finish each topic by explaining, out loud, which metric or model answers the question in the scenario and why the alternatives do not.
The distribution assumption hiding inside every reliability number
The exponential and Weibull distributions answer the same survival question differently. The exponential assumes a constant failure rate and no memory; the Weibull's shape parameter lets the failure rate rise or fall with age. Choose the distribution before computing.
The exponential distribution's defining property is memorylessness: a unit that has survived 10,000 hours has exactly the same probability of failing in the next hour as a brand-new unit. That is defensible for electronic components in their useful-life region, or for a large fleet where failures arrive randomly. It is not defensible for mechanical items that wear, corrode, or fatigue, where hazard grows with age.
The Weibull distribution adds the shape parameter beta: beta below 1 describes decreasing hazard (infant mortality), beta equal to 1 reduces to the exponential, and beta above 1 describes wear-out. The scale parameter eta is the characteristic life, the age at which about 63 percent of the population has failed. Your decision procedure should be: plot or reason about the hazard shape first, then justify the distribution in writing.
- Scenario: a pump fleet shows eta = 1,000 hours and beta = 2.5. At 500 hours, Weibull reliability is exp(-(500/1000)^2.5) = exp(-0.177) ≈ 0.84. An analyst who forces an exponential model with the same mean life (about 887 hours) gets exp(-0.564) ≈ 0.57 — far too pessimistic early on.
- The same mistake reverses at long ages: at 1,500 hours the Weibull gives exp(-1.5^2.5) ≈ 0.06, while the exponential gives exp(-1.69) ≈ 0.18. The exponential is now optimistic — a dangerous direction when the number supports an inspection interval.
- Why it matters: a single distribution choice changed both a warranty-cost estimate and a safety decision, in opposite directions at different ages. The better decision is to state the wear-out evidence, fit the Weibull, and reserve the exponential for items you can argue are age-independent.
MTBF, MTTF, and MTTR: similar acronyms, different mathematics
MTTF describes a non-repairable item's time to its only failure. MTBF applies to repairable systems between successive failures. MTTR measures restoration time and feeds availability. Repairable versus non-repairable is the switch that selects the right term.
For a non-repairable item such as a fuse or a disposable sensor, mean time to failure is the expected age at failure, and the item's lifetime reliability follows directly from the chosen distribution. For a repairable system such as a pump with a maintenance crew, mean time between failures describes the operating interval between repair events, and the system returns to service after each one.
Watch definitions closely: some texts define MTBF strictly as uptime between failures, excluding repair time; others use total operating time divided by the number of failures. Both appear in practice, and exam-style scenarios hinge on the definition stated in the problem. MTTR is the mean time to restore, and it pairs with MTBF in the availability formulas of the next section. When practicing, write the definition you are using at the top of every calculation.
Inherent or operational availability: which number answers the question?
Inherent availability uses only MTBF and MTTR: the design's theoretical uptime. Operational availability also counts waiting for spare parts, crews, or facilities. Maintenance contracts and spares decisions usually need the operational figure.
Inherent availability is a design property: Ai = MTBF / (MTBF + MTTR). It answers whether the equipment, if repaired instantly when it fails, meets its uptime commitment. Operational availability divides the same MTBF by MTBF plus mean downtime including administrative and logistic delay, so it answers what the customer actually experiences.
Scenario: a machine has MTBF = 2,000 hours and MTTR = 4 hours, giving Ai = 2,000/2,004 ≈ 0.998. But the mean wait for a spare module is 24 hours, so mean total downtime is 28 hours and Ao = 2,000/2,028 ≈ 0.986. The plausible mistake is reporting 0.998 against a contract written around real uptime. The better decision is to identify who asked the question: a designer comparing two redundant configurations can use inherent availability; a program manager setting spares stock levels needs operational availability, and reducing the logistic delay buys more uptime than shaving minutes off the repair itself.
Censored life-test data: why ignoring survivors biases the result
In most life tests, the test ends before every unit fails, so the data are right-censored. Suspended units prove survival up to the stop time and carry information. Averaging only the failure times understates mean life.
Distinguish the two common test designs: Type I (time-terminated) testing stops at a fixed calendar time and yields a random number of failures; Type II (failure-terminated) testing stops after a fixed number of failures and yields a random stop time. In both, the unfailed units are right-censored — known to have survived at least until removal. Their survival evidence must enter the estimate, whether through total unit-time methods, probability plotting with median ranks adjusted for suspensions, or maximum likelihood.
Scenario: ten units run; failures occur at 400, 520, and 700 hours; the test stops at 800 hours with seven survivors. The tempting shortcut averages the three failures: (400 + 520 + 700)/3 = 540 hours. The better decision, under the constant-failure-rate assumption, is to divide total test time by the number of failures: T = 400 + 520 + 700 + 7 × 800 = 7,220 unit-hours, and 7,220/3 ≈ 2,407 hours — more than four times the failure-only figure. (Dividing by all ten units instead, 722 hours, treats every unit as if it had failed and yields only a conservative lower bound.) Why it matters: the biased 540-hour figure would drive earlier replacement intervals and overstated spares budgets, and the direction of the bias is systematic, not random.
FMEA and FTA: opposite routes through the same system
FMEA works bottom-up, from component failure modes to system effects, and is qualitative and inductive. FTA works top-down, from an undesired top event through logic gates to causes, and can be quantitative. Choose direction by the question asked.
An FMEA asks, for each component: how can it fail, what effects follow, how severe, how likely, and how detectable? Many implementations combine these into a risk priority number to rank actions. It suits design reviews and maintenance planning because it systematically sweeps the whole design without needing a specific accident in mind.
A fault tree starts from one defined top event, such as loss of braking, and works downward through OR and AND gates to basic events. AND gates let you compute the probability of the top event from cause probabilities and identify cut sets — the minimal combinations of failures that cause it. Use FTA when a specific undesired event must be analyzed and quantified; use FMEA when the goal is comprehensive coverage of failure modes. The comparison below works as a decision rule rather than two isolated definitions.
| Question in the scenario | Better-fitting technique | Key assumption or definition to state |
|---|---|---|
| Rank design weaknesses across all components before build | FMEA | Severity, occurrence, and detection scales; qualitative ranking, not a failure probability |
| Quantify the chance of one specific accident | Fault tree analysis | Top event defined precisely; gate logic; independent basic events unless modeled otherwise |
| Predict survival at a given age for wearing hardware | Weibull analysis | Shape parameter above 1 implies wear-out; exponential is not justified |
| Predict survival for age-independent failures | Exponential model | Constant hazard; memoryless behavior must be defensible |
| Estimate mean life from a test that ended early | Censored-data methods | Suspended units contribute survival information; do not average failures only |
| Commit uptime in a contract with a maintenance operation | Operational availability | Includes logistic and administrative delay, not just MTTR |
Series, active parallel, and standby: redundancy is not automatically better
A reliability block diagram multiplies series reliabilities, so every added series element lowers system reliability. Active parallel redundancy raises it toward one, and standby redundancy can do better still — but only when switching works.
For independent elements in series, system reliability is the product of element reliabilities; a ten-element chain of 0.99 parts delivers only about 0.90. In active parallel (k-out-of-n with all units running), the system fails only if all n fail: two units at 0.90 give 1 − 0.1² = 0.99. Standby redundancy keeps the spare unpowered until needed, which for constant-failure-rate units with a perfect switch gives R = e^(−λt)(1 + λt) — better than active parallel for the same units.
Scenario, with simplified numbers: two units each at mission reliability 0.90. Active parallel gives 0.99; ideal standby gives about 0.995. The plausible mistake is assuming standby therefore always wins. If the switchover mechanism succeeds with probability 0.95, the standby advantage shrinks to roughly 0.985 — worse than plain active parallel — and real standby units can also degrade from cycling. Why it matters: the switch reliability and the failure-rate behavior of the dormant unit are assumptions you must verify, and a configuration decision made without them can go the wrong way.
A practice loop with self-check observations and a study sequence
Practice with small hand-worked datasets where each assumption is visible. Alternate between concept weeks (distributions, metrics, allocation) and integration weeks (scenarios combining censoring, availability, and redundancy). Score yourself against observations, not feelings.
Exercise: build a 12-unit life test on paper — six failures between 300 and 900 hours, six suspensions at a 1,000-hour stop. Compute the failure-only average, the constant-failure-rate estimate (total unit-hours divided by the number of failures), and an exponential reliability value at 500 hours. Then ask the three questions that follow: what would change if the hazard were increasing, what do the suspensions contribute, and which availability figure would a customer see? Expected observations: the failure-only average is visibly lower than the unit-hours-over-failures estimate, the suspend-inclusive estimate implies longer replacement intervals, and the exponential reliability at 500 hours sits between the early-age and late-age Weibull values you compute for comparison.
Suggested sequence for an adaptable plan: weeks one and two, distributions and life-data concepts — work five censored-data problems by hand and one probability-plotting exercise; weeks three and four, system models — series, parallel, standby, k-out-of-n, and allocation of a system target to subsystems using the same independence assumptions; weeks five and six, analysis techniques — FMEA structure, fault-tree gates and cut sets, and maintainability measures feeding availability; final stretch, timed scenario sets where you first write the definition and assumption, then compute. Self-check rubric: you are on track when you can (1) state the assumption behind every number you produce, (2) identify censored units in any dataset within seconds, (3) pick between FMEA and FTA with a one-sentence justification, and (4) explain when standby loses to active parallel. Treat these as learning milestones, not predictions of any score.
One administrative note: the ASQ page listed as the source for this guide could not be retrieved when it was checked, so verify current administrative details — scope, requirements, and logistics — directly with the issuer rather than from secondary summaries.
- Readiness check 1: given any short scenario, you can name the population (repairable or not), the distribution assumption, and the correct metric before touching a formula.
- Readiness check 2: you can recompute a censored-data estimate two ways — total unit-time over failures, and the conservative total-unit-time-over-all-units lower bound — and explain why they differ.
- Readiness check 3: you can draw a three-block reliability block diagram and convert it to a fault tree top event without mixing the two logics.
- Readiness check 4: you can explain, in one paragraph each, how MTTR, logistic delay, and redundancy each move operational availability.
References and further reading
Use these references to explore the concepts and check the latest information from the relevant organizations.