# Predicting Availability

Availability is an important driver that justifies the existence of technical systems. Performance indicators on availability are increasingly monitored or included in contracts, hence practical availability predictions become important. Almost any academic course on reliability engineering comprises availability predictions. Graduates who find these predictions adequate for decision-making should disregard this article as most likely they will not find anything new or they may find these issues irrelevant...

...You are still there? Then we may share some challenges in transferring theory into practice. This article may possibly contribute to our mutual quest for better performance predictions. Whilst not including a survey of availability definitions, this article arbitrarily poses the definition from [1], [2], [3]:

*The ability of an item to be in a state to perform a required function under given conditions at a given instant of time or over a time interval, assuming that the required external resources are provided. *

This definition is not very specific on how to quantify availability. I do not pretend to be able to exhaustively survey all conceivable approaches for quantification, but I have sincerely tried to deduce an approach that respects this definition. This article explains why availability predictions are encumbered by human influence and from the availability definition, the assessment of a “state” and an “ability” at a given instant of time are deepened. Other parts of the definition are referred to in the discussion. Finally, a case study based on recordings from industry illustrates the main points.

#### Assessment of an Item’s State

It seems a convention to define an item’s state by some Bernoulli variable (*Y*) that takes two values, either 0 or 1. Applied on our availability definition, *Y *may follow from **Equation 1**:

Y = {0*, item is in a state to perform a required function… *

{1*, item is NOT in a state to perform a required function… *

For some items, such as simple electronic components, the assessment of *Y *is common sense. Unfortunately, it seems to be rather the rule than the exception that *Y*’s assessment is not straightforward. Definitely, it helps to carefully articulate a function as explained in [4]. For example the expression “to pump water at 100 m3/hr” is more precise than “to pump water”. One may interpret “to pump water at 100 m3/hr” as:

- A required function that has been posed by some person.
- An inherent function that refers to some intrinsic ability; for example a name plate capacity asserts what an item could perform (but not necessarily does).
- An observed function that has been measured.

An overall equipment effectiveness indicator [5] typically compares an inherent function with an observed function. Quality is a degree to which a set of inherent characteristics fulfils requirements [6]. I therefore interpret *Y *as a quality indicator that compares a required function with an inherent function. So, *Y *is *not *an immediately observable property of an item. Moreover, our availability definition requires satisfaction of “given conditions” and “external resources are provided”, *Y *is unobservable when these conditions are violated.

Some try to infer *Y *by some fault tree like formalism. However, these formalisms may contribute to *Y*’s assessment if and only then if:

- the explanatory variables of
*Y*are better assessable; - the (logical) function that relates these explanatory variables to
*Y*is known or inferable.

Finally, some basics on requirements engineering [7], or quality function deployment [8] learn that trawling for a requirements process typically only captures most functional requirements. So, building *Y *on any (enumerable set of) functional requirement(s) is arguable.

**Figure 1. Observed daily output.**

#### Assessment of an Ability

Although “ability” is not closely associated with some mathematical formalism, it seems common practice to choose probability. A probability then expresses a degree of certainty to obtain a state *Y *= 0. Equation 2 shows a probabilistic approach to an item’s instantaneous availability (*A**t*).

* A**t **= Pr (Y**t **=*0 *| C) *(2)

The availability definition asserts that “given conditions” (*C*) are essential. This may be understood from the following example. If I would invite you to predict *A**t *of a car but I do not tell you which car, you may end up with *A**t *= 0,5 since you may lack arguments to see *Y**t *= 0 more or less probable than *Y**t *= 1. Adding information about the car’s mileage, its driver and its last successful mission may highly influence your estimation of *A**t *regardless that the physical properties of the car did not change. So, *A**t *is not an exclusive attribute of the car, it is driven by your appraisal of information admitted to *C*.

Apart from “assuming that the required external resources are provided”, the availability definition does not specify *C*, it determines the replications among the evidence. Since science is not about unique miracles but about reproducible outcomes, the number of variables in *C *should be far below the amount of evidence.

Textbooks often pose that *C *only comprises past failures while ignoring other knowledge, therefore, particularly field experts are expected to refute availability predictions from reliability engineering textbooks because these books typically ignore their expertise.

For a scientific inference of availability, *C *should comprise all influential variables for *A**t *but *C *should also be a small enumerable set. A choice for *C *typically depends on someone’s suspicions.

#### Case Study

**Figure 1** depicts the daily output of some item over a period of 1977 consecutive days. The operational intent is to maximise daily output.

Assessing *Y *requires some arbitrary decisions. Firstly, we pose **Equation 3** as a criterion to distinguish *Y *= 0 from *Y *= 1.

* Y = {*0,

*Inherent output*> 19 (3)

{1, *Inherent output *≤ 19

Since it is illusive to encompass all stakeholder requirements in a mapping to *Y*, extending the set of functional requirements may mitigate, but does not eliminate controversy about **Equation 3.**

Finally, we pose that inherent output and observed output are equal. This may not be a bold assumption seen the operational intent to maximise output. Figure 2 shows the *Y *that follows from these decisions. During these 1977 days, some stakeholder definitely lacked some external resources, the tentative *y **[1,1977] *obtained under the assumption that “all required external resources would have been provided” are *not *in Figure 2.

**Figure 2** implies that in 1569 out of 1977 days the item’s state was satisfactory (*Y *= 0). Someone may arbitrarily pose *C *to be an empty set (*C *= { }). Like throws of a fair dice, all *Y**t *from a time series *y **[1,1977] *are then seen as replications. *C *= { } implies that any additional knowledge about the item’s maintenance or operations does not affect *A**t*. Anyone who refutes this bold claim acknowledges that Equation 4 is wrong:

Pr(Yt = 0) ≈

Ât = x|Yx = 0;1 ≤ x ≤ 1977 / x|1 ≤ x ≤ 1977

= 1569 / 1977

Fortunately for those who earn their living by supporting this item, Figure 3 wildly differs from Figure 1. So, Figure 1 is unlikely to come from an entirely random process. This justifies a refutation of *C *≠ { }.

Someone may arbitrarily pose that *C *= {*Y**t-1*}. For this memoryless process, *A**t *depends on *Y**t-1*.

Pr(Yt = 0|Yt-1 = 0)

≈ Ât = x|Yx = 0; Yx-1 = 0; 2 ≤ x ≤ 1977 / x|Yx = 0;2 ≤ x ≤ 1977

= 1481 / 1568

Pr(Yt = 0|Yt-1 = 1)

≈ Ât = x|Yx = 0;Yx-1 = 1;2 ≤ x ≤ 1977 / x|Yx = 1;2 ≤ x ≤ 1977

= 87 / 407

**Equation 5** with **Equation 4** shows the consequence of extending *C*. The number of estimates for *A**t *increases whereas the number of replications (in the denominator) decreases. A resampling under *C *= {*Y**t-1*} leads to Figure 4 that better approaches Figure 1 than Figure 3 did. Textbooks typically extend *C *= {*Y**t-1*} to *C *= {*Y**t-1*,*Y**t-2*,…} while ignoring other candidate variables for *C*. For example results from condition based maintenance are irrelevant for any *C *= {*Y**t-1*,*Y**t-2*,…}.

This case raised some concerns about availability. A time series analysis on Figure 1 is possibly more straightforward.

**Figure 2. A Bernoulli variable Yt built on daily output.**

**Figure 3. A typical pattern of Y[1,1977] from an independent and identically distributed ****process (At=1529/1977).**

**Figure 4. A typical pattern of Y[1,1977] from a memoryless process (At|Yt-1= 0 = 1481/1568; At|Yt-1=1=87/407).**

**Conclusion**

Availability prediction may be seen as a subjective probability measure on a subjectively assessed Bernoulli variable. Since textbooks typically ignore any knowledge beyond past failures, their use for availability predictions is limited. A time series analysis on performance may be more straightforward.

**Acknowledgement**

Many thanks to Dr. **Knezevic **from MIRCE Akademy who carefully reviewed a draft. Of course, I remain fully accountable for the errors.

»»**References** ›› [1] International Electrotechnical Commission. (1990). IEC 50 International Electrotechnical Vocabulary Chapter 191: Dependability and quality of service. Geneve: IEC. ›› [2] ARMP-7. (2008). Nato R&M terminology applicable to ARMPs. Brussels: NATO. ›› [3] EN13306:2001. (2001). Maintenance terminology. CEN (European Committe for Standardization). ›› [4] Moubray, J. (2004). Reliability Centred Maintenance. Elsevier. ›› [5] Nakajima, S. (1988). Introduction to TPM: Total Productive Maintenance (preventative maintenance series). Productivity Press. ›› [6] ISO9000. (2005). Quality management systems; fundamentals and vocabulary. ›› [7] Robertson, S., & Robertson, J. (2006). Mastering the requirements process. Addison Wesley. ›› [8] Akao, Y. (. (1990). Quality Function Deployment; integrating customer requirements into product design. Portland: Productivity Press.