Study the CRE by drilling the decision that each scenario forces: repairable or not, which availability definition, which distribution, and which block diagram configuration. Work scenarios where a plausible shortcut produces a wrong answer, then verify your reading against a rubric before comparing with practice questions.
MTBF vs MTTF: the repairable assumption that changes the whole calculation
MTBF applies to repairable systems and counts operating time between failures; MTTF applies to non-repairable items and measures expected life to the single failure. Using one when the scenario describes the other invalidates the estimate and every downstream decision.
The distinction is about what happens after a failure. A repairable system, such as a pump or a server rack, is restored to service, so total operating time divided by the number of failures is a mean time between failures. A non-repairable item, such as a bearing, a fuse, or an electronics board that is replaced rather than fixed, has one failure in its life, so its expected life is a mean time to failure. The arithmetic looks similar but the denominators and assumptions differ, and the renewal process for a repairable system is not the same as a sample of lifetimes.
Apply a two-question check to any scenario stem: does the item get repaired and returned to service, and does the stem report failures per unit time or lifetimes of failed units? If failed units are described as replaced or scrapped, you are reading lifetime data and MTTF thinking applies. If the system continues in service after maintenance, MTBF thinking applies. This check also tells you whether a constant-failure-rate simplification is even on the table, because repairable systems with aging may need renewal-process treatment rather than a single lifetime distribution.
| Metric | Applies to | What it measures | Watch for in the stem |
|---|---|---|---|
| MTTF | Non-repairable items | Expected time to the one and only failure | Failed units replaced, scrapped, or tested to failure |
| MTBF | Repairable systems | Operating time divided by number of failures | System repaired and returned to service |
| MTTR | Repairable systems | Mean time to restore after a failure | Repair crew times, diagnostics, parts waits |
| Inherent availability | Design model | MTBF divided by (MTBF + MTTR) | Only corrective repair downtime counted |
| Operational availability | Field environment | Uptime fraction including all downtime | PM schedules, logistics delays, staffing limits |
Availability tiers: matching inherent, achieved, and operational to the stem
Availability answers differ by which downtime categories are included: inherent availability counts only corrective repair time, achieved availability adds preventive maintenance time, and operational availability adds logistics, administrative, and standby delays.
The definitions form a hierarchy. Inherent availability uses only mean corrective maintenance, typically MTBF divided by (MTBF plus MTTR). Achieved availability brings preventive and scheduled maintenance into the downtime total. Operational availability divides actual uptime by calendar time in the operating environment, so queueing for parts, waiting for a repair crew, and scheduled shutdowns all reduce it. A scenario that mentions spare-part lead times or shift coverage is pointing at operational availability even though the same MTBF and MTTR numbers appear.
Worked scenario: a cooling pump has MTBF of 2,000 hours, MTTR of 8 hours, and a 20-hour annual preventive maintenance window, running 8,760 hours per year. A common shortcut is to report 2,000 / 2,008, roughly 0.996, but that is inherent availability. With about 4.38 expected failures per year, corrective downtime is about 35 hours, plus 20 hours of PM, giving operational availability of roughly 1 minus 55/8,760, about 0.994. If the stem also adds a 6-hour average wait for the on-call technician, operational availability drops further. The better decision is to inventory every downtime category named in the stem before selecting a formula, and only then compute the tier the stem is asking about.
Exponential vs Weibull: reading the shape parameter before you compute
The exponential distribution assumes a constant failure rate and fits the useful-life portion of the bathtub curve; the Weibull distribution uses a shape parameter beta to model decreasing failure rate below 1, constant at 1, and increasing above 1.
Selecting a distribution is itself the task in many scenario items. The exponential is memoryless: past operating time does not change the probability of failure in the next interval, which suits electronics in their stable period or any system explicitly described as having a constant failure rate. Weibull generalizes this, and the shape parameter does the interpretive work: beta below 1 indicates infant mortality or early-life failures, beta equal to 1 reduces to the exponential, and beta above 1 indicates wear-out with an increasing failure rate. A beta near 2, for example, signals a wear-out mechanism where age-based replacement can help.
A practical exercise: take three failure datasets from any reliability text or your own maintenance log, fit or estimate beta for each, and write the maintenance implication of each value. Expected observations are that beta below 1 points to improved screening or burn-in rather than scheduled replacement, beta near 1 makes age-based replacement useless for reliability because failure timing is unpredictable, and beta well above 1 makes preventive replacement at a chosen age meaningful. The self-check rubric: can you state the failure-rate direction implied by beta, name the mechanism class it suggests, and explain why a constant-rate assumption is wrong when beta differs from 1 by a meaningful margin?
Block diagram logic: series, parallel, and k-out-of-n in scenario wording
Series systems fail when any single component fails, active parallel systems fail only when all components fail, and k-out-of-n systems require at least k of n operating. The stem's failure condition, not the drawing, defines the configuration.
Worked scenario: a control system needs at least two of its three identical sensor channels operating, each with reliability 0.9 over the mission. A plausible mistake is to treat the channels as full parallel redundancy and compute 1 minus 0.1 cubed, about 0.999. That answers a different question, namely how often all three fail. The correct 2-out-of-3 calculation is three ways to choose the surviving pair, each 0.9 squared times 0.1, plus all three surviving at 0.9 cubed: 0.243 plus 0.729, which is 0.972. The gap between 0.999 and 0.972 is the cost of misreading the requirement: partial redundancy is weaker than full redundancy, and the minimum-units-operating line is what tells you which configuration applies.
Train the parse in this order: identify what event the stem defines as system failure, then decide whether that means any one unit failing, all units failing, or a threshold of failures. Then draw the block diagram from that condition and compute from the drawing. Two traps to watch: components that are physically adjacent but functionally in series, and standby configurations where the standby unit has its own failure rate while dormant, which a simple parallel formula ignores. If a stem mentions a switching device or a standby that can fail while idle, the simple active-parallel formula no longer applies.
- Series: R = product of component reliabilities; every unit must operate.
- Active parallel: R = 1 minus product of (1 minus R); failure needs all units down.
- k-out-of-n: sum the binomial terms for exactly k, k+1, up to n surviving units.
- Standby with imperfect switching: include switch reliability and dormant failure rates separately.
FMEA vs FTA: which direction of analysis the scenario is asking for
FMEA is a bottom-up method that starts from component failure modes and lists effects and severity; FTA is a top-down method that starts from an undesired system event and traces the logic combinations that can cause it.
The two methods answer different questions and organize information differently. An FMEA worksheet walks through each component or function, records its failure modes, local and system-level effects, causes, current controls, and ratings for severity, occurrence, and detection, which combine into a risk priority number. A fault tree starts at a defined top event, such as loss of braking function, and decomposes it through AND and OR gates into basic events, allowing minimal cut sets and quantitative probability evaluation. Scenario wording signals the direction: a request to prioritize a list of failure modes for action points to FMEA; a request to find the combinations of events that produce a specified system failure points to FTA.
Build a two-column comparison from memory and test it against example stems. Expected observations: FMEA never requires a single defined top event, and it can detect single-point failures by reading severity and occurrence rows; FTA requires the top event to be stated and handles interactions between multiple simultaneous faults, which a component-by-component FMEA handles awkwardly through its detection column. A useful self-check is to take one system, such as a heating loop, draft both analyses at a shallow depth, and note which failure information each method surfaced that the other did not. That contrast, not memorized definitions, is what lets you identify the requested method in a scenario.
Run-to-failure vs preventive replacement: deciding when maintenance adds value
Preventive replacement improves availability only when failures are age-related, meaning an increasing failure rate; for constant or decreasing failure rates, scheduled replacement does not reduce failure probability and may add downtime without benefit.
This decision links the bathtub curve, the shape parameter, and the maintenance budget. If failures follow a constant rate, replacing a working unit at any age yields a unit with the same failure characteristics as the old one, so a preventive replacement policy neither raises nor lowers reliability; it only adds planned downtime. If beta exceeds 1 and wear-out dominates, replacing before the rising portion of the hazard curve can prevent failures, and the scenario becomes an optimization between replacement cost, failure cost, and the downtime each consumes. The skill to practice is reading a hazard description in a stem and rejecting a maintenance policy that does not fit it.
Practice the reasoning with a simple cost comparison exercise: choose a wear-out item and a constant-rate item from your experience, sketch their implied hazard curves, and for the wear-out item write out the trade-off you would weigh in choosing a replacement interval, noting which quantities you would need, such as failure cost, replacement cost, and the age-reliability relationship. Expected observations: for the constant-rate item you should conclude that no interval improves reliability, and for the wear-out item you should see that the best interval depends on the cost ratio, not on the failure rate alone. This trains the conditional logic: the correct policy follows from the failure-rate behavior, and the scenario must supply evidence of that behavior before a policy claim is justified.
A preparation sequence with a self-check rubric and readiness checks
Sequence your preparation in three passes: definitions and metric distinctions first, distribution and configuration selection second, and full scenario drills third, with a rubric check after every drill rather than a score alone.
A workable sequence: spend the first pass building the distinction cards from sections one and two, writing for each metric the stem wording that selects it. In the second pass, drill distribution selection and block diagram parsing with short scenarios you write yourself or find in reliability textbooks, forcing yourself to state the failure condition and the shape-parameter implication before computing. In the third pass, run full mixed scenarios under time pressure, then grade them with a rubric instead of only marking right and wrong. Keep a decision log recording, for each item, which distinction the item turned on and whether your first instinct matched the stem.
Self-check rubric for each scenario drill, scored one to three points per line: you correctly classified the system as repairable or non-repairable before computing; you named the availability tier the stem asked for and justified it with the downtime categories present; you stated the failure-rate behavior implied by the distribution evidence; you wrote the system failure condition and drew the block diagram before any arithmetic; and you identified the analysis direction, bottom-up or top-down, when an FMEA or FTA was requested. A first-pass total of nine or fewer out of fifteen marks the distinction categories to re-drill; treat the score as a learning milestone for your own tracking, not as a prediction of exam performance. Readiness checks: you can reproduce the metric table from section one from memory, explain in two sentences why parallel-redundancy arithmetic overstates a k-out-of-n system, and convert a plain-language maintenance policy into its implied hazard-curve assumption. For administrative details such as eligibility and scheduling, refer to the issuer's page at asq.org rather than secondary sources.
- Pass 1: distinction cards for MTBF/MTTF, availability tiers, FMEA/FTA direction.
- Pass 2: distribution selection and block diagram parsing drills with written failure conditions.
- Pass 3: timed full scenarios graded against the five-line rubric, with a decision log.
- Readiness: metric table from memory, k-out-of-n explanation, policy-to-hazard translation.
References and further reading
Use these references to explore the concepts and check the latest information from the relevant organizations.