ELSEVIER PIi: S0951-8320(96)00130-5 Reliability Engineering and System Safety 56 (1997) 91-94 ~) 1997 Elsevier Science Limited All rights reserved. Printed in Northern Ireland 0951-8320/97/$17.00 System degraded availability Alberto Sols ISDEFE, Edison 4, 28006 Madrid, Spain (Received 15 September 1995; revised 17 July 1996; accepted 31 October 1996) The concept of degraded availability is introduced, and the required definitions and assumptions are presented. Appropriate metrics are formulated for the quantification of degraded availability at function, mission and system level. This degraded availability model is an extension to the model for availability of multifunctional systems (Sols, A., Availability of continuously operated, coherent, multifunctional systems. Master's thesis, Virginia Polytechnic Instit- ute and State University, 1992). © 1997 Elsevier Science Limited. 1 INTRODUCTION The fact that an element of a system is not available at some point in time does not necessarily imply that the entire system is 'down' at that moment. Even in the event of a failure of an element, some of the system functions could probably still be actuated and the system would be therefore capable of fulfilling, to a certain extent, some of the missions it was designed for. A model based on the element-level failure and repair renewal process was developed for defining and evaluating availability of multifunctional systems [1, 2]. That model eliminated the restrictive need posed by traditional availability models in which systems had to have a series configuration and their elements had to have a time to failure and a time to repair that followed negative exponential distributions. Clearly, those two strong restrictive assumptions limited severely the applicability of the model built upon them to accurately represent the behaviour of modern systems. 2 DEGRADED AVAILABILITY 2.1 The concept The need for multistate logic systems has been long recognized [3, 4]. Systems will be assumed to be divided into elements whose state is binary, that is, elements will be either working (or capable of working) or failed. Subsets of elements provide system functions, and groups of functions enable the performance of system missions. Even if the state of the elements is assumed to be binary, it is possible to consider degraded states of accomplishment of a function and, therefore, of a mission. In other words, 91 functions and missions can, and have to, be considered as multistate even if element state is assumed to be binary. The failure of an element will imply, in some cases, that a function cannot be performed, but in other cases the failure of one or several elements may mean that a function can only be performed to some acceptable extent. As an example, one may think of a car. Not all of its elements are always required. For example, the headlights are only needed when there is not enough daylight (like at night, or in the presence of fog); clearly, on a sunny day the headlights do not need to be turned on (leaving aside certain regulations in some countries). But even if they are required, it could happen that one of the front lights (let us say, the left one) has burned out. Without considering the driving regulations, which are different from one country to the next, it is up to the driver (the system user) to decide whether his remaining headlight provides him with enough visibility so as to complete his mission (for example, drive back home in the evening or at night). If he considers it enough, that would be a case of degraded performance (in this example, of the car headlight function) accepted by the system user. Consequently, the system will not be truly available in that case because one of its elements has failed (the left headlight), will not be entirely unavailable either. The system will be in an intermediate state, which in fact is the one in which most systems happen to be for a good part of their operational lives. The system will be in a state of 'degraded availability'. In many applications, the specification of degraded-availability type of require- ments may be a necessary complement to the specification of 'true' or 'pure' availability require- ments. The important fact is that only the system user can specify what function and mission degradations are acceptable to him.