Choose failure-frequency and downtime metrics with explicit event and time definitions instead of treating MTBF as an availability promise.
Ask what time and event the metric counts
Reliability estimates require defined failure events, exposure and model assumptions; NIST's reliability-analysis guidance emphasizes the underlying data and model. Mean time between failures concerns failure frequency under its stated interpretation. Availability also involves time spent unavailable, including the applicable restoration process. A large MTBF value therefore cannot, by itself, establish a small production loss or a guaranteed percentage of useful operating time.
NIST: reliability data analysis supports the technical principle above.
Write a metric contract before requesting a number
Define what counts as a failure, which operating hours form the exposure and what starts and ends downtime. Separate repair work from waiting for a part, diagnosis, access or restart when those distinctions matter to the business question. State whether planned stops and changeovers are included. Otherwise two apparently equal availability reports may count very different events.
Choose the intended use: comparing failure frequency, planning spares support or understanding lost production time. Preserve the observation period and covered equipment population. Do not transfer a component reliability figure into a complete-line availability claim without the relevant system model and data.
Hypothetical availability comparison
Under a simplified two-state repairable-system teaching model, availability is represented as MTBF/(MTBF + mean restoration time). Imagine both cases have an assumed MTBF of 100 hours. Case A assumes one hour to restore service, giving 100/101 = approximately 99.0%. Case B assumes ten hours, giving 100/110 = approximately 90.9%. The equal failure-frequency assumption produces different modeled availability because restoration differs. This arithmetic is not a measured result, production guarantee or complete-line calculation for HM equipment. Its assumptions exclude many real operating complications and are deliberately stated so the output is not mistaken for observed performance.
Use the distinction to specify support needs
The project's support discussion can then address the factors that actually extend downtime: spare availability, diagnosis, access and the agreed restoration process. Keep those commitments distinct from a statistical failure estimate. After service begins, collect events using the same definitions so observed metrics answer the original question. For new machinery, provide the duty and consequences of interruption when discussing support. This guide supplies a metric-selection worksheet, not a promised MTBF, repair duration or availability percentage for any offered configuration.
Also name the boundary of the reported system. A component, a machine and an interconnected line can have different outage definitions even when they share an observation period.
Customer Questions
Does higher MTBF automatically guarantee higher availability?
No. Availability also depends on the applicable downtime and restoration behavior.
Should waiting for a spare count as downtime?
Define it explicitly according to the metric's purpose; do not leave that boundary implicit.
Are the example percentages measured performance?
No. They are outputs of an explicitly simplified hypothetical model.
Related Equipment References
Review the actual offered equipment and application separately from this educational example.
Primary References
These references support the technical principles discussed in this guide. The worked examples and review questions are educational.
Discuss Your Machine Requirement
Share your product, container, required output and the evidence needed for your technical review.
Request a Technical Review