In short. Availability is the fraction of time a system is able to supply the load. It rises with a longer mean time between failures (MTBF) and falls with a longer mean time to repair (MTTR). Series elements reduce availability and parallel redundant elements raise it. Modelling helps compare architectures, but results are only as good as the failure data and the assumption of independence.
Basic definitions
MTBF is the average operating time between failures. MTTR is the average time to restore service, including detection, response, repair and testing. Unavailability is 1 minus availability.
Series and parallel
| Structure | Rule | Effect |
|---|---|---|
| Series (all needed) | Multiply availabilities | Lower than the weakest element |
| Parallel (one of two needed) | Unavailability is the product of the two unavailabilities | Much higher than either |
| k-out-of-n | Binomial combination | Used for N+1 sets |
Worked example (illustrative figures)
One generator with availability 0.98 has unavailability 0.02. Two independent generators in parallel, either of which can carry the load, have unavailability 0.02 × 0.02 = 0.0004, so availability 0.9996. Now place an ATS with availability 0.999 in series: 0.9996 × 0.999 ≈ 0.9986. The ATS, a single element, now limits the system more than the generators do. This shows why a single series element can dominate, and why modelling the whole chain matters.
Convert to downtime. Availability of 0.9986 is about 12 hours of unavailability per year (0.0014 × 8,760). 0.9999 is about 53 minutes a year.
What to include in a model
- Sources, transfer devices, distribution and controls.
- Support systems such as fuel, cooling and DC supply.
- Repair times, spare availability and response.
- Maintenance outages, which reduce redundancy temporarily.
- Common-cause failures, represented explicitly. See common-cause failure.
The big limits
- Data quality: published MTBF values are generic and may not suit your environment or maintenance quality.
- Independence assumption: a product of unavailabilities overstates reliability when failures are correlated.
- Standby failures: a standby unit that fails to start on demand is a different failure from running failure; model both.
- Human factors: errors are not captured by component data.
How to use the results
Use the model to compare options and to see which elements dominate unavailability, not to promise an exact number to a customer. Sensitivity runs, such as changing a failure rate or repair time, show which assumptions matter most. Pair the model with failure-scenario testing. See reliability, availability and redundancy engineering.
Improving availability
- Reduce MTTR through spares, training and remote monitoring.
- Remove series elements that dominate, or add redundancy to them.
- Improve the detection of hidden failures.
- Limit maintenance-state exposure.
The arithmetic of availability
Availability A = MTBF ÷ (MTBF + MTTR); series: A = A1 × A2 × … ; parallel: U = U1 × U2, where U = 1 − A
Worked chain (illustrative)
| Element | Availability |
|---|---|
| Utility | 99.90 percent |
| Generator system (including start reliability) | 98.0 percent |
| Combined source (utility or generator) | 1 − (0.001 × 0.02) = 99.998 percent |
| ATS and switchgear (series) | 99.99 percent |
| UPS system | 99.99 percent |
| Distribution | 99.995 percent |
| Chain, approximate | 99.998 × 0.9999 × 0.9999 × 0.99995 ≈ 99.972 percent |
That is about 2.4 hours of expected downtime per year. The chain is dominated by series elements, which is why redundant paths at distribution level matter.
Using models properly
- Treat input data as estimates and show sensitivity.
- Include start failure of standby sets.
- Include common-cause failure and human error.
- Compare architectures on the same assumptions.
Models rank options; they do not predict actual outages exactly.
Data
Use maker data, industry databases and your own failure records. Keep the site’s own incident history, since it beats generic numbers.
See reliability and redundancy engineering.
Common mistakes
- Modelling only generators and UPS and ignoring transfer devices and controls.
- Quoting availability without the assumptions.
- Ignoring MTTR, which can be as influential as MTBF.
What to send us
Send the architecture and any failure and repair history you have. Send your application details. See also redundancy architectures.
Questions engineers ask
What is a good availability figure?
It depends on the site’s requirement. Convert to downtime per year to judge it, and compare it with the cost of an outage.
Why does adding a generator not improve availability much?
Because another series element, such as the transfer switch or a shared control, may now dominate.
Can I trust MTBF numbers?
Treat them as indicative. Site data, maintenance quality and conditions change real values.
Does repair time matter?
Yes. Unavailability scales with MTTR, so quick repair has the same effect as a longer MTBF.
Figures here are illustrative. Real modelling needs validated data and engineering judgement.