CRE (Hong Kong Civil Service Exams) common mistakes
CRE · Understand the traps and how to avoid them.
Treating the Weibull shape parameter β as the failure rate and reporting β as a constant hazard, rather than interpreting β<1 as decreasing, β=1 as constant, and β>1 as increasing hazard, and computing the actual rate λ(t)=β/η·(t/η)^(β−1) when asked.
Candidates memorize the bathtub curve and the phrase 'β is the slope' and then shortcut to 'β = failure rate' because both are single numbers tied to Weibull plots; the scale parameter η and its role in the hazard expression get lost in review.
What to do instead
For every Weibull item, write the hazard function λ(t)=(β/η)(t/η)^(β−1) before answering, state which parameter is which, and check units: β is dimensionless, η has time units, and only λ has failures per unit time. Practice converting between β, η, MTTF=η·Γ(1+1/β), and the hazard at a specified time.
Computing series and parallel system reliability by averaging or summing component reliabilities instead of multiplying (series: R=ΠRi; parallel: R=1−Π(1−Ri)), and applying the wrong formula when the configuration is described in words rather than drawn.
Under time pressure the 'series means add failure rates, so reliability adds too' confusion takes over, and candidates do not translate a verbal block-diagram description into a topology before selecting a formula.
What to do instead
Redraw every described system as a reliability block diagram before computing. Use the rule: series multiplies reliabilities (and adds failure rates only for constant-hazard components), parallel multiplies unreliabilities. Sanity-check that a series system is less reliable than its weakest component and a parallel system more reliable than its best.
Confusing MTBF with MTTF and using the exponential MTBF=1/λ relationship for repairable-system availability questions, or plugging MTBF into R(t)=e^(−t/MTBF) when the item asks for availability A=MTBF/(MTBF+MTTR).
Both metrics are expressed in hours and both appear in reliability text, and the exponential model is the only closed form most candidates have practiced, so it gets applied indiscriminately.
What to do instead
Classify the item first: non-repairable item → MTTF; repairable system → MTBF and MTTR; uptime fraction → availability. Write the governing equation (A=MTBF/(MTBF+MTTR) for a single unit) and confirm the exponential assumption is stated or implied before using e^(−λt).
Skipping or misreading the FMEA severity/occurrence/detection logic - for example assigning detection credit to a failure mode that has no current control, or ranking RPN without noting that severity alone can mandate action regardless of RPN.
Candidates treat RPN as a simple product drill and forget that severity is judged against the effect on the end user or system, while detection scores the effectiveness of existing controls, not the likelihood of the failure.
What to do instead
For each FMEA item, write the effect first, then severity, then the cause and occurrence, then list the actual current control before assigning detection. Remember that a high-severity item requires action even with a low RPN, and that RPN thresholds are action triggers, not a ranking substitute for engineering judgment.
Mixing up fault tree gate logic - treating an AND gate as 'any input causes the top event' or an OR gate as requiring all inputs - and failing to convert a fault tree to its Boolean cut sets correctly.
The symbols are learned visually and then recalled from memory under exam pressure; the words 'and'/'or' in a narrative prompt are easy to invert, especially when the top event is a failure rather than a success.
What to do instead
Restate each gate in plain language before solving: AND gate means all inputs must occur for the output (a cut set containing all those basic events); OR gate means any one input suffices (each input is its own minimal cut set). Then list minimal cut sets and identify single-point failures as the highest-priority finding.
Treating maintainability metrics as interchangeable - reporting MTTR when the question asks for median time to repair, or using exponential repair-time assumptions when the lognormal or a specified distribution is given - and ignoring the difference between corrective and preventive maintenance intervals.
MTTR is the most familiar maintainability number and candidates default to it; distribution-specific repair models and the distinction between restoration time and scheduled downtime are less rehearsed.
What to do instead
Identify what is asked: mean (MTTR), median, or a percentile of repair time, and which distribution is stated. For availability, separate MTTR (corrective) from preventive maintenance downtime and logistics delay, and compute inherent vs operational availability with the correct terms in the denominator.
Applying the wrong reliability-growth or demonstration model - using Duane/Crow-AMSAA growth parameters to answer a fixed-design reliability prediction, or misreading the demonstrated MTBF from a test with a stated confidence level and discrimination ratio.
Growth models and statistical demonstration tests both involve test time, failure counts, and confidence, and candidates conflate 'reliability achieved during development' with 'reliability demonstrated at a confidence level'.
What to do instead
Ask whether the design is changing over test time (growth model: Duane slope or Crow-AMSAA β) or fixed (demonstration: use the stated confidence, consumer/producer risk, and discrimination ratio). Write the model name and its assumptions at the top of the scratch work before computing.
Misclassifying safety integrity levels and hazard categories - assigning SIL from consequence alone without considering frequency and exposure, or confusing a risk graph's exposure and avoidance parameters with probability of the initiating event.
SIL and hazard-risk schemes use several inputs that look similar (frequency, duration, avoidance possibility, demand rate) and candidates collapse them into one 'how bad is it' judgment.
What to do instead
For each risk-graph or SIL question, list every input parameter separately (consequence, frequency/duration of exposure, possibility of avoidance, demand rate for low-demand vs high-demand mode) and walk the graph or table explicitly rather than estimating the level from the severity description.
Confusing reliability, availability, and safety terminology in definitions items - for example calling a fail-safe design one that prevents failure, or equating redundancy with diversity, or labeling a single-point failure as a latent failure without checking whether it is revealed by a test.
These terms are near-synonyms in ordinary English but have precise, non-overlapping meanings in the BoK; candidates answer from everyday usage rather than the technical definition.
What to do instead
Build a one-line definition card for each term (fail-safe, fail-operational, redundancy, diversity, latent vs detected failure, single-point failure) and, on each item, match the scenario to the definition before choosing. Check specifically whether the failure is annunciated or hidden until a test or demand.
Ignoring units, time bases, and rounding in quantitative items - mixing failures per 10^6 hours with failures per hour, reporting MTTF in the wrong unit, or rounding intermediate results so the final answer misses the closest option.
Reliability data are commonly quoted per 10^6 or 10^9 hours while formulas use per-hour rates, and candidates chain calculations in a calculator without tracking the exponent, so a factor of 10^6 error survives to the answer choice.
What to do instead
Carry units through every step, convert all rates to a single base (per hour) at the start, keep full precision in intermediate values, and round only the final answer. If the result is off by a power of ten from the options, recheck the rate conversion before redoing the model.