The formal definition of reliability is …
“The probability that an item will perform its intended function under stated conditions, for either a specified interval or over its useful life.”
The three key terms in this statement are
- Intended Function
- Stated Conditions
- Specific Interval
A reliability statement made without all three of these factors has no meaning. Communicating that a product has a reliability of 99.999% means nothing. 99.999% reliability in what capacity? “What if I use it as a boat anchor? Does it have a 99.999% reliability in that function?” Will it have that 99.999% reliability in 25 years?” “Is it ok if I leave it outside when I’m not using it?”
A complete statement of reliability for a hard drive may be
- “99.999% reliability when used for data storage, interfacing with a Mac OS in an indoor environment class A, over a 5 year period.”
- “99.95% reliability when used for data storage, interfacing with a Mac OS in an indoor environment class B/C, over a 5 year period.”
- “99.2% reliability when used for data storage, interfacing with a Mac OS or Windows OS in an indoor environment class B/C, over a 10 year period.”
The same product may have several reliability statements based on the levels of use case, environment, or useful life. A product program must create definitions for these parameters early. The terms of the definitions will be based upon the product functional specification document. The reliability protocols will be based on the use-case, environment and life definitions. It’s a stack of parameters that quickly becomes unstable when any lower layer is not fully formed.
It’s difficult early in a program to be diligent and ensure all these factors are defined and captured. Having experienced the unnecessary iterations that occur in test and design due to fluctuating or ambivalent definitions; I can vouch for the value of getting these parameters and definitions complete as early as possible.