KEVOS® MAKEOS · Maintenance
Reliability Demonstration Test Plan (MTBF Objective, Confidence, Allowed Failures, Test Length)
How many unit-hours of testing do I need to show, at my confidence level, that a machine or component meets its MTBF objective, and can it be done in the time I have?
Test length to demonstrate a mean time between failures for equipment with a constant failure rate (exponential or HPP model): the chi-square test-length factor for the confidence and the number of failures allowed, the total unit-hours needed, the hours each unit must run and the calendar days at your running hours, against the days available, with the factor for allowing one more and one fewer failure.
Open the calculatorRuns in your browser. No account needed.
How this tool works
Inputs, units and where to find them
| Input | Unit | Typical source |
|---|---|---|
| MTBF objective | h | MTBF the equipment must be shown to meet, from the specification or contract. |
| Confidence | % | Confidence required that the true MTBF is at least the objective if the test is passed. |
| Failures allowed during the test | failures | Number of failures the test may have and still pass; more allowed failures need a longer test. |
| Test resources | ||
| Units on test | units | Identical units tested together (their running hours add up). |
| Running hours per day | h/day | Hours each unit runs per day on test. |
| Calendar days available | days | Calendar days available for the test. |
What each input means
Open an input to see what it is, its units, the worked example and the common mistakes, with a small diagram.
What this means: MTBF objective
- What it is
- The mean time between failures the equipment must be shown to achieve, the figure the test is designed to prove.
- Units and format
- Enter a number in h: hours. The form accepts 0.000001 h or more. Required: the tool does not calculate until every input is valid.
- Example
- The form opens with 200 h as a worked example. It is an illustration, not a recommended value: replace it with your own figure.
- Effect on the result
- The test length rises in proportion to the objective.
- Get it right
- Use the MTBF in the specification or contract, in running hours, not calendar hours.
What this means: Confidence
- What it is
- The confidence you need that the true MTBF is at least the objective if the test is passed.
- Units and format
- Enter a number in %: percent: the number is read as a percentage, so type 8 for 8 %. The form accepts 50% to 99.9%. Required: the tool does not calculate until every input is valid.
- Example
- The form opens with 90% as a worked example. It is an illustration, not a recommended value: replace it with your own figure.
- Effect on the result
- Raises the test-length factor and so the hours needed.
- Get it right
- Higher confidence needs a longer test; 80 or 90 % is common for acceptance tests.
What this means: Failures allowed during the test
- What it is
- The number of failures the test may have and still pass, agreed before the test starts.
- Units and format
- Enter a number in failures: failures. The form accepts 0 failures to 100 failures. Use a whole number. Required: the tool does not calculate until every input is valid.
- Example
- The form opens with 4 failures as a worked example. It is an illustration, not a recommended value: replace it with your own figure.
- Effect on the result
- Each extra failure allowed lengthens the test, by about one more MTBF or more.
- Get it right
- Allowing zero gives the shortest test but fails a good design on one random failure.
Test resources
What this means: Units on test
- What it is
- The number of identical units running on test at the same time, whose running hours add up towards the total.
- Units and format
- Enter a number in units: a count of units. The form accepts 1 units to 100000 units. Use a whole number. Required: the tool does not calculate until every input is valid.
- Example
- The form opens with 2 units as a worked example. It is an illustration, not a recommended value: replace it with your own figure.
- Effect on the result
- More units shorten the calendar time in proportion; the total unit-hours do not change.
- Get it right
- Units must be the same design and build standard; mixing versions invalidates the result.
What this means: Running hours per day
- What it is
- The hours each unit runs on test per day, which turns unit-hours into calendar days.
- Units and format
- Enter a number in h/day: h/day. The form accepts 0.000001 h/day to 24 h/day. Required: the tool does not calculate until every input is valid.
- Example
- The form opens with 16 h/day as a worked example. It is an illustration, not a recommended value: replace it with your own figure.
- Effect on the result
- More hours per day shorten the calendar time in proportion.
- Get it right
- Count only the hours the units actually run under test conditions.
What this means: Calendar days available
- What it is
- The calendar days available to finish the test, compared with the days the plan needs.
- Units and format
- Enter a number in days: days. The form accepts 0.000001 days to 100000 days. Required: the tool does not calculate until every input is valid.
- Example
- The form opens with 60 days as a worked example. It is an illustration, not a recommended value: replace it with your own figure.
- Effect on the result
- Only moves the pass or fail line; the hours needed do not change.
- Get it right
- Allow for set-up, interruptions and analysis time outside the running days.
Method and formulas
- Test-length factor = ½ χ²(confidence; 2(r + 1)), the chi-square quantile with 2(r + 1) degrees of freedom (NIST e-Handbook 8.3.1.1).
- Total unit-hours = MTBF objective × factor; hours per unit = total ÷ units; calendar days = hours per unit ÷ running hours per day.
- Pass the test if no more than r failures occur in the total unit-hours.
- Example: factor 7.9936; 1,598.7 unit-hours, or 49.96 days with 2 units.
Limitations
- Constant failure rate only: early-life failures and wear-out make the exponential model optimistic or pessimistic; burn in first and do not test past wear-out.
- Allowing few failures shortens the test but raises the chance that a good design fails it by bad luck.
- Example values are illustrations. Replace them with values for your actual task.
Typical uses
- Plan an acceptance run for a new machine or supplier part
- Decide how many units to put on test to finish in time
- Show a customer what an MTBF claim would take to prove
Who it is for
- Reliability engineers
- Quality and test engineers
- Engineering managers
What you get
- Test-length factor
- Total unit-hours needed and hours per unit
- Calendar days needed
- Factor if one more or one fewer failure is allowed
Interpreting the result
- Allowing zero failures gives the shortest test, but a single random failure then fails a good design; one or two allowed failures is often a better balance.
References
- NIST/SEMATECH e-Handbook of Statistical Methods, 8.3.1.1 Exponential life distribution (or HPP model) tests — https://www.itl.nist.gov/div898/handbook/apr/section3/apr311.htm
Learn the Concepts Behind This Tool
These KEVOS® Library readings explain the method this tool uses, with worked examples.
Method explained here · KEVOS® original book
Qualification testing: run length, feed envelope and yield basis
In First-of-a-Kind Technology by the Numbers
What it covers: Size a qualification run with chi-square bounds (1,500 h for MTBF 500 h at 80%), test across a 5–13% contamination envelope, and correct a claimed 84% yield to 78.9%.
Method explained here · KEVOS® original book
Proving the settings
In Trips and Alarms by the Numbers
What it covers: Turning calculated trip and alarm settings into evidence: end-to-end response tests, a planned demonstration of the nuisance-trip rate with confidence bounds, and an auditable register entry.
Useful alongside · KEVOS® original book
How many units, and for how long
In Accelerated Life Testing by the Numbers
What it covers: Zero-failure demonstration tests, the success-run formula, trading test time for units with a known Weibull shape, allowing a failure, FL-60's driver plan, and a failure explained away.
KEVOS® tools are screening and decision-support utilities. Verify important financial, engineering, safety, legal or operational decisions using appropriate professional standards and your organisation’s approved data.