Predict availability

Availability is the useful measure for any system that runs continually — a security system is the classic example. Once it’s switched on, it operates until it needs service, and availability tells you how much of that time it stays up.

Prediction Inputs

What availability needs from the rest of the model

These are the required inputs for predicting availability.

Input

Tab

Predict size

Required inputs, under the Survey tab

Predict defect density

All Survey tabs except Failure Modes

Duty cycle, fraction of defects affecting availability, installed sites, release schedule

Required inputs, under the Survey tab

Growth rate and growth period

Predicted from installed sites on Required Inputs

Months between major releases

Required Inputs tab (years between releases)

Predicted MTSWR

Average time to restore after a loss of availability

Go to the Required Inputs page and enter the following:

Typical fraction of defects found in operation that affect availability. Determine this from past failures on a similar system, or from testing — e.g. 1,000 defects were found testing the last release, and 10 affected availability with no workaround, a fraction of 0.01.
The number of installed sites that most closely matches how many installations of this version are planned.
The number of years between releases — the time from the start of development to field deployment.
The size estimates.
The expected duty cycle per month of one typical installation.
The predicted Mean Time To Software Restore (MTSWR) — see below.
The development factors, per the survey instructions.

MTSWR

Mean time to software restore

MTSWR is a weighted average of these software-related restore actions.

Maintenance action

Relative % of defects

Typical time

Restart

% clearable with a restart

Usually minutes

Reboot

% clearable with a reboot

Several minutes — hardware and software both initialize

Workaround

% avoidable with a workaround

Hours if unknown to the operator, otherwise minutes

New software release

% addressable only with a release

Hours, days, or weeks depending on repeatability

Your system may have other restore actions — reloading the software, for example. Either way, MTSWR is a weighted average across all of them. In the worked example used throughout this help set, MTSWR is half an hour.

Dashboard Prediction

Reading the availability result

The Prediction sub-tab on the Dashboard shows the average availability calculation along with its lower and upper bounds, which follow from the bounds on the defect density and size estimates.

Availability prediction

Availability = average MTTF ÷ (MTSWR + average MTTCF)

Predicted Growth

How availability moves release to release

Availability is calculated for every month after delivery. Because predictions only hold until the next major release, the best case is the prediction at the final month before release and the worst case is month one — e.g. with releases every 12 months, month 12 is best and month 1 is worst.

Inherent availability, month i

Availability_i = MTTF ÷ (MTSWR + MTTCF_i)
Unavailability_i = 1 − Availability_i

Bounds follow the relative error on the size estimate. At 50% relative error, the MTTCF upper bound sits 50% below the nominal failure-rate prediction and the lower bound sits 50% above it — upper bounds are always the worst case, lower bounds always the best.

Reliability growth trends The trend extends over eight years. Discovered defects and failure rate typically trend upward over that period, which pulls availability predictions downward unless restore time can be reduced — software systems get larger over time, and every new release resets reliability growth as a function of the new code added. The software is never done.

Continue to the next stage of the prediction.

Availability feeds directly into the final reliability calculation.

Predict Reliability → ← Back to Failure Rate / MTTF