Reliability engineering has a shared language, but not always a shared understanding. Terms are often used loosely or interchangeably, particularly in cross-functional teams.
It would obviously be impractical to cover every term here. From experience however, a few distinctions often cause confusion.
Reliability vs Availability
Reliability is about how often failures occur. Availability is about whether the system is ready when needed.
A system can be unreliable yet still available if it is quick to repair. Equally, a system can be highly reliable but unavailable if recovery, logistics or support are poor (see Reliability Bites #3).
Maintainability vs Maintenance
Maintainability is a design characteristic of how easily a system can be restored to service. Maintenance is the activity performed to do so.
Regular maintenance does not automatically indicate unreliability, it may be part of the intended support strategy. Poor maintainability however, is often exposed when a relatively simple failure leads to disproportionate downtime
Failure vs Fault
A fault is a defect or abnormal condition. A failure occurs when the system can no longer perform its required function.
A system may contain faults without failing. Stakeholders may classify events differently, so early agreement between customers and suppliers on what constitutes a failure, how degraded modes are treated and how events are recorded is essential to avoid disputes, misaligned expectations and unreliable performance data.
Mean Time Between Failures (MTBF)
MTBF is a statistical average based on the assumption of a constant failure rate over time. It is not a guarantee or failure-free period. It does not mean a system will operate for that duration, nor that failures will be evenly spaced.
Used without context, MTBF can create false expectations. It says little about severity, early-life issues, wear-out behaviour or mission impact. Reducing reliability to a single average can mask important risk.
Inherent vs Achieved Reliability
Inherent reliability reflects design capability under defined conditions. Achieved reliability reflects performance in service. Confusing the two can lead to optimism unsupported by operational evidence.
These distinctions are not academic. They influence how systems are specified, analysed, contracted and supported. Clarifying terminology early prevents misunderstandings from becoming embedded in requirements, design decisions and performance metrics.
Reliability terminology isn’t about being pedantic, it’s about ensuring decisions are based on a shared understanding of performance and risk.
Next up…
Reliability Bites #12: Reliability requirements and targets – where do the numbers really come from?
Leave a Reply