CRPE Engineer Registration common mistakes
CRPE Engineer Registration · Understand the traps and how to avoid them.
Computing MTBF as total operating time divided by number of failures without checking whether the test was time-terminated or failure-terminated, then quoting the result as an unbiased estimate of the mean life.
The naive ratio is the maximum likelihood estimate for an exponential time-terminated test, but it is biased low for failure-terminated (test-until-r-failures) plans and for any non-exponential life distribution. Candidates memorize one formula and apply it to every dataset without asking how the data were collected.
What to do instead
Before dividing, write down the test plan: time-terminated, failure-terminated, or field data with censoring. For failure-terminated exponential tests use the chi-square-based interval and note the bias correction; for non-exponential data use a probability plot or MLE with the correct likelihood. State the assumption explicitly in the answer.
Treating MTBF as a probability of success, for example claiming a unit with 1,000-hour MTBF has a 63% chance of surviving 1,000 hours regardless of distribution shape.
The exponential constant-hazard model is taught first and its 1/e survival at t = MTBF is memorable, so candidates apply it to wear-out or infant-mortality populations where the hazard is not constant. The confusion between MTBF and mean life, and between hazard rate and probability, is reinforced by casual field usage.
What to do instead
Always state the assumed distribution before converting. For exponential, R(t) = exp(-t/MTBF); for Weibull, use R(t) = exp(-(t/eta)^beta) with the shape parameter. Check the shape parameter or the failure-rate-versus-time plot first, and say in the answer that MTBF alone does not define a survival probability.
Assigning criticality numbers in an FMECA by multiplying severity by occurrence without defining the severity and occurrence scales, or by ranking failure modes by RPN alone and ignoring severity.
RPN arithmetic feels objective, so candidates skip the qualitative scale definitions and treat the product as a decision rule. High-occurrence, low-severity modes then outrank a single catastrophic mode, and the analysis loses its purpose of driving design change.
What to do instead
Define ordinal scales for severity, occurrence, and detection before scoring, tie severity to the end effect (safety, mission, cost) rather than the local part failure, and use a criticality matrix or severity-first screening. Report the RPN as an input to prioritization, not the decision, and justify any mode with high severity regardless of RPN.
Building a fault tree with the top event defined too broadly and then mixing hardware failures, human errors, and external events at the same gate level without a consistent boundary.
Top events such as 'system fails' invite everything into one tree, and candidates add branches as they think of them. Without a defined boundary and a complete basic-event set, the tree is neither mutually exclusive in its cut sets nor exhaustive, so the Boolean reduction is misleading.
What to do instead
Write the top event as a specific, observable system-level failure with a stated mission time and success criterion, then decompose through the physical architecture. Separate hardware, software, human, and environmental branches; verify each gate is an AND or OR that truly reflects the logic; and check that cut sets are minimal before quantifying.
Quantifying a reliability block diagram by multiplying block reliabilities in series when the blocks are actually in parallel redundancy, or ignoring common-cause failure in a redundant configuration.
Series arithmetic is the first formula learned and gives a satisfying small number, so candidates default to it. Redundancy diagrams drawn as parallel paths invite the assumption of independence, which overstates the benefit of two identical units sharing a power supply, environment, or maintenance crew.
What to do instead
Translate the diagram into success logic first: series blocks all must work, parallel blocks need one path. Use R = 1 - product(1 - Ri) for active redundancy, adjust for standby with switching probability, and add a common-cause term (beta factor or similar) whenever redundant units share a resource. State the independence assumption and its violation.
Reporting inherent availability as A = MTBF/(MTBF+MTTR) while the question asks about operational or achieved availability that includes logistics delay and administrative time.
The three-parameter formula is compact and universally memorized, so candidates substitute whatever numbers appear without checking which time elements the problem defines. Inherent availability excludes preventive maintenance, supply delay, and queueing, so it overstates what the user experiences.
What to do instead
Classify the time elements in the problem before computing: inherent availability uses only corrective MTTR; achieved availability adds preventive maintenance time; operational availability adds logistics and administrative delay. Use A = uptime/(uptime+downtime) with the downtime defined by the availability type requested, and label the result.
Extrapolating reliability growth from a Duane or Crow-AMSAA plot beyond the range of the test data and presenting the projected MTBF as demonstrated.
The log-log plot is close to linear over the observed segment and invites a straight-line extension, but growth slows as the easy fixes are exhausted and the model assumes continued corrective action of similar effectiveness. Candidates also confuse instantaneous and cumulative MTBF on the same plot.
What to do instead
Distinguish cumulative from instantaneous MTBF and state which the model reports. Limit projections to a stated confidence and to a plausible number of additional test hours, note that the growth slope reflects the fix effectiveness observed so far, and require a follow-on test or demonstration to claim demonstrated MTBF.
Designing a reliability demonstration test by choosing sample size and test time from intuition, then accepting the unit because no failures occurred, without linking the plan to the specified MTBF, consumer risk, and producer risk.
Zero-failure pass/fail thinking is intuitive, and the statistical planning step (discrimination ratio, confidence, test duration) is skipped under time pressure. The result is a test that cannot distinguish a good from a bad design or that has unknown confidence.
What to do instead
Start from the requirement: specified MTBF, discrimination ratio, and the confidence or producer/consumer risks. Use the exponential test-plan relationships (for example the chi-square or Poisson zero-failure formula) to derive test time or sample size, and state the confidence the pass demonstrates. Document the plan before testing.
Treating human error as a single generic probability in a risk or fault tree analysis instead of decomposing the task, and omitting performance-shaping factors such as time pressure, fatigue, and procedure quality.
Human reliability data are scarce and the analysis feels subjective, so candidates drop in a round number and move on. That hides the design and procedural levers that actually reduce error, and it makes the human branch of the tree unverifiable.
What to do instead
Break the task into steps, assign error probabilities from a recognized method or task-specific data, and adjust for performance-shaping factors explicitly. Identify the recovery paths and independent checks, and document the basis and uncertainty of each human error probability so the assumption can be challenged.
Writing a reliability program plan that lists activities and deliverables but omits the allocation flowdown, the quantitative requirements, the review gates, and the feedback loop from test and field data into design.
Plans are often written to a template that emphasizes schedule and document lists, and candidates reproduce the template without connecting activities to the requirements they are meant to verify. The plan then cannot show how a requirement is allocated, demonstrated, or corrected.
What to do instead
Structure the plan around the requirement lifecycle: derive quantitative requirements, allocate to subsystems, assign verification methods (analysis, test, demonstration), set review gates with entry and exit criteria, and define the FRACAS loop that feeds failures back into design and the growth curve. Tie each activity to the requirement it closes.