dido:public:ra:1.4_req:2_nonfunc:20_maintainability
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
dido:public:ra:1.4_req:2_nonfunc:20_maintainability [2021/01/06 15:35] nick [DIDO Specifics] |
dido:public:ra:1.4_req:2_nonfunc:20_maintainability [2021/07/26 16:13] (current) murphy [About] |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== 4.2.3 Maintainability ====== | + | ====== 4.3.3 Maintainability ====== |
| [[dido:public:ra:1.4_req:2_nonfunc: | return to Non-Functional Requirements]] | [[dido:public:ra:1.4_req:2_nonfunc: | return to Non-Functional Requirements]] | ||
| - | |||
| - | * **<color #FF0000><todo @char>Please Review</todo></color>** | ||
| ===== About ===== | ===== About ===== | ||
| - | [[dido:public:ra:1.4_req:2_nonfunc:20_maintainability | Return to Top]] | + | [[dido:public:ra:xapend:xapend.a_glossary:m:maintainability]] is the //characteristic that represents the degree of effectiveness and efficiency with which a product or system can be modified to improve it, correct it or adapt it to changes in its environment and requirements. This characteristic is composed of the following sub-characteristics://(( |
| - | + | ||
| - | The [[dido:public:ra:xapend:xapend.a_glossary:m:maintainability]] is the //characteristic represents the degree of effectiveness and efficiency with which a product or system can be modified to improve it, correct it or adapt it to changes in environment, and in requirements. This characteristic is composed of the following sub-characteristics://(( | + | |
| ISO/IEC 25010, __Maintainability__, Accessed 27 July 2020, [[https://iso25000.com/index.php/en/iso-25000-standards/iso-25010/64-maintainability]] | ISO/IEC 25010, __Maintainability__, Accessed 27 July 2020, [[https://iso25000.com/index.php/en/iso-25000-standards/iso-25010/64-maintainability]] | ||
| )) | )) | ||
| Line 17: | Line 13: | ||
| * //**[[dido:public:ra:1.4_req:2_nonfunc:20_maintainability:testability| Testability]]** - Degree of effectiveness and efficiency with which test criteria can be established for a system, product or component and tests can be performed to determine whether those criteria have been met.// | * //**[[dido:public:ra:1.4_req:2_nonfunc:20_maintainability:testability| Testability]]** - Degree of effectiveness and efficiency with which test criteria can be established for a system, product or component and tests can be performed to determine whether those criteria have been met.// | ||
| - | + | Maintainability is a characteristic of a system that is able to resume full operation after a failure in a component of the system. Components that are mission critical for the system can include equipment, machine, power, air conditioning, software, etc. Maintainability is expressed as the probability of recovery based on a specified time frame, usually done in terms of [[dido:public:ra:xapend:xapend.a_glossary:f:five_nines]] (i.e., 99%, 99.9%, 99.99%, and 99.999%). For example, a 99.999% maintainability would be for 5 minutes, 15 seconds or less of [[dido:public:ra:xapend:xapend.a_glossary:d:downtime|downtime]] in a year. The downtime must include all the steps required to recover with full operational capabilities, so the time must include removal, diagnostics, assembly of resources required to perform the maintenance (i.e., parts, bays, tools, personnel, etc.) and the re-installation of the failed component.(( | |
| - | + | ||
| - | Maintainability is a characteristic of a system to resume full operation after a failure in a component of the system. Components are mission critical for the system and can include equipment, machine, power, air conditioning, software, etc. Maintainability is expressed as a probability of recovery based on a specified time frame, usually this is done in terms of [[dido:public:ra:xapend:xapend.a_glossary:f:five_nines]] (i.e., 99%, 99.9%, 99.99%, and 99.999%). For example, a 99.999% maintainability would be for 5 minutes, 15 seconds or less of [[dido:public:ra:xapend:xapend.a_glossary:d:downtime|downtime]] in a year. The downtime must include all the steps required to recover with full operational capabilities, so the time must include removal, diagnostics, assembly of resources required to perform the maintenance (i.e, parts, bays, tools, personnel, etc.) and the re-installation of the component.(( | + | |
| Maintainability Definition & Calculations, Upkeep, answered 4 June 2019, Accessed 13 July 2020, [[https://www.onupkeep.com/answers/preventive-maintenance/maintainability-definitions-calculations/]] | Maintainability Definition & Calculations, Upkeep, answered 4 June 2019, Accessed 13 July 2020, [[https://www.onupkeep.com/answers/preventive-maintenance/maintainability-definitions-calculations/]] | ||
| )) ((**Note:** Maintainability is part of [[dido:public:ra:xapend:xapend.a_glossary:r:ram]])) | )) ((**Note:** Maintainability is part of [[dido:public:ra:xapend:xapend.a_glossary:r:ram]])) | ||
| - | There are two main aspects of Maintainability that need to be addressed for all systems or components: | + | Two main aspects of Maintainability need to be addressed for all systems or components: |
| * [[dido:public:ra:xapend:xapend.a_glossary:s:servicability]] - the ease of conducting scheduled inspections and servicing | * [[dido:public:ra:xapend:xapend.a_glossary:s:servicability]] - the ease of conducting scheduled inspections and servicing | ||
| * [[dido:public:ra:xapend:xapend.a_glossary:r:repairability]] - the ease of restoring service after a failure | * [[dido:public:ra:xapend:xapend.a_glossary:r:repairability]] - the ease of restoring service after a failure | ||
| - | Maintainability is a projection of the downtime of a system, obviously, as a projection it is not a guarantee that a system will only be down for a certain amount of time. Maintainability therefore must rely on models to calculate the failures for the components which are based on actual failure rates for components in the past or on test results of the components. | + | Maintainability is a projection of the downtime of a system. Given that it is, by its very nature, a projection, it should not viewed as a guarantee that a system will only be down for the projected amount of time. Maintainability must therefore rely on models to calculate the probability of failures for components based on actual failure rates for components in the past or test results of the components. |
| : //There are a wide range of models that estimate and predict reliability (Meeker and Escobar 1998). Simple models, such as exponential distribution, can be useful for “back of the envelope” calculations.// | : //There are a wide range of models that estimate and predict reliability (Meeker and Escobar 1998). Simple models, such as exponential distribution, can be useful for “back of the envelope” calculations.// | ||
| Line 40: | Line 34: | ||
| )) | )) | ||
| - | All these models are abstractions of reality, and so at best approximations to reality. To the extent they provide useful insights, they are still very valuable. The more complicated the model, the more data necessary to estimate it precisely. The greater the extrapolation required for a prediction, the greater the imprecision. However, obtaining all the data required as input to the models is difficult, time consuming and the data that is available is not very accurate. | + | All these models are abstractions of reality; therefore, at best they are only approximations of reality. To the extent they provide useful insights, they are still very valuable. The more complicated the model, the more data necessary to develop precise estimations. The greater the extrapolation required for a prediction, the greater the imprecision. Also, obtaining all the data required as input to the models is difficult, time consuming, and may not even be very accurate. |
| - | Measuring the [[dido:public:ra:xapend:xapend.a_glossary:m:mttr]], is also used as part of Availability ( see [[dido:public:ra:1.4_req:2_nonfunc:14_reliability:02_availability]] ). | + | Measuring the [[dido:public:ra:xapend:xapend.a_glossary:m:mttr]], is also used as part of [[dido:public:ra:xapend:xapend.a_glossary:a:availability|Availability]] (see [[dido:public:ra:1.4_req:2_nonfunc:14_reliability:02_availability]]). |
| - | The MTTR, identifies the average time to restore a system or component after experiencing a failure or breakdown to the expected (i.e., specified) operating conditions. The formula for MTTR is: | + | The MTTR, identifies the average time to restore a system or component after experiencing a failure or breakdown in the expected (i.e., specified) operating conditions. The formula for MTTR is: |
| - | + | : <color white>o</color> <m format idiom size> | |
| - | <m format idiom size> | + | |
| MTTR = {Total downtime (hours)} / {Number of failure events} | MTTR = {Total downtime (hours)} / {Number of failure events} | ||
| - | </m> | + | </m> \\ |
| - | + | \\ | |
| - | The lower MTTR value correspond to a higher level of maintainability and consequently, maintainable systems take less time to repair. | + | A lower MTTR value corresponds to a higher level of maintainability and which means that maintainable systems take less time to repair. |
| ===== DIDO Specifics ===== | ===== DIDO Specifics ===== | ||
| [[dido:public:ra:1.4_req:2_nonfunc:20_maintainability | Return to Top]] | [[dido:public:ra:1.4_req:2_nonfunc:20_maintainability | Return to Top]] | ||
| - | Regardless of the systems, there always needs to be maintenance. To reduce the impact of performing maintenance, using physical (hardware) [[dido:public:ra:xapend:xapend.a_glossary:m:module|modules]] (components) that require the fewest number of repairs in a given time frame and choosing hardware and designs that require the least amount of downtime is one way to reduce the impact of maintenance. Another way to reduce the impact of maintenance is to design a system anticipating maintenance and provides redundancy to handle downtime required for maintenance. However, managing redundancy is not a trivial task which adds complexity to the overall system. The more components that require redundancy the more complex the system becomes unless the [[dido:public:ra:xapend:xapend.a_glossary:m:midware]] can manage the transition seamlessly, easily and transparently. | + | All systems, regardless of their level of complexity, require maintenance. To reduce the impact of performing maintenance, using physical (hardware) [[dido:public:ra:xapend:xapend.a_glossary:m:module|modules]] (components) that require the fewest number of repairs in a given time frame and choosing hardware and designs that require the least amount of downtime is one way to reduce the impact of maintenance. Another way to reduce the impact of maintenance is to design a system that anticipates maintenance and provides redundancy to handle the downtime required for maintenance. Nevertheless, managing redundancy is not a trivial task and adds complexity to the overall system. The more components that require redundancy, the more complex the system becomes unless the [[dido:public:ra:xapend:xapend.a_glossary:m:midware]] can manage the transition seamlessly, easily and transparently. |
| - | There are few major forms of redundancy that DDS can help with: | + | There are a few major forms of redundancy DDS can help with: |
| - | ^ **Hardware redundancy** | Means that there are multiple modules (components) that provide the same functionality available in the system at the same time. For many systems, a simple dual modular redundancy is sufficient to accomplish the job (i.e., two components). However, life critical systems, some systems rely on a triple modular redundancy. These systems should have zero to minimum loss from downtime. | | + | ^ **Hardware redundancy** | Means that there are multiple modules (components) that provide the same functionality available in the system at the same time. For many systems, a simple dual modular redundancy is sufficient to accomplish the job (i.e., two components). However, for life critical systems, some systems rely on a triple modular redundancy. These systems should have zero to minimum loss from downtime. | |
| - | ^ **Information redundancy** | Occurs when there are multiple information sources available, so modules can use either if there is an interruption in information. In a system that has only one network available to it, the information redundancy is of little use if the network needs maintenance. | | + | ^ **Information redundancy** | Occurs when there are multiple information sources available, so that modules can use whichever source is active if there is an interruption in information. In a system that has only one network available to it, the information redundancy is of little use if the network needs maintenance. | |
| /**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | /**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | ||
dido/public/ra/1.4_req/2_nonfunc/20_maintainability.1609965335.txt.gz · Last modified: 2021/01/06 15:35 by nick
