Jump to content

Design for availability

From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by Gregbard (talk | contribs) at 01:35, 2 May 2012 (added Category:Logistics; removed {{uncategorized}} using HotCat). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Design for Availability is the design of a system considering availability or readiness as the major part of goal specification.

The design parameters might include maintenance and inventory management, operation logistics, Prognostic Health Management (PHM) and reliability of system into the design process[1]. The general purpose of this type of systems is in outcome-based contracts. Availability is a function of an item’s reliability (how often it fails) and maintainability (how efficiently it can be restored when it does fail)[2]. Availability is a major factor of operational effectiveness along with performance of the system[3]. Minimum required availability of complex system is a key factor of many distributed and repairable systems like ATM network or Airliner.

In Availability-based Contracts[4] instead of parts, supplier is paid for a guaranteed level of services and performance a and system capability, like availability-based tarrif for electric power[5][6]. The supplier often has to guarantee the availability and preparedness of system at lesser costs by considering the logistics as part of design. The contractor will also have more control over logistics and supply chain of system.

Recent interest in availability contracts that specify a required availability has created an interest in deriving system design and support parameters directly from an availability-based contracts. Because reliability and availability are both probabilities, there is a common assumption that the method used to compute system reliability based on component data can also be used for system availability calculations.But, a point to point allocation from parameter of operation and support to meet availability requirement in the performance space, given the required availability distribution is a direct way of design which must be followed by a sensitivity analysis and robustness of parameters. However, determining design parameters from an availability requirement is a stochastic reverse design problem.

For safety, mission, and infrastructure critical systems, customers are often interested in buying the availability of a system through “availability contracts”, instead of actually buying the system itself [7]. However, evaluating an availability requirement is a challenge for manufacturers and supporters of systems because determining how to deliver a specific availability is not trivial. The required availability can be defined over the instance of system or over the fleet. It can be defined over different time windows or in different geographical boxes. However availability optimization approaches provide solutions only at selected points in time (not all times), using mean time to failure (or fixed rate demand) and mean time to repair as deterministic values as part of convex optimization.


Availability engineering in network world is generally toward reducing unplanned downtime or planned downtime by providing redundancy or fast switching systems.[8]. In this type of systems planned downtime include maintenance changes, operating system upgrades, backups, or any other activity that temporarily removes the application from service[9]. This area of design is the subject of different discipline with different approach. The main difference between network industry and manufacturing availability is that former is more targeting toward decreasing downtime where as in reliability world it might be seen as using higher reliability part in a cost effective manner.

In high availability server world Design for availability is configuration settings anticipating, detecting, and automatically resolving hardware or software failures before they result in service errors, event faults, or data corruption — thereby minimizing downtime. The operational part of the solution is to use only tested, proven processes to support the application throughout its entire lifecycle.[10]

See also

logistics

availability

References