dido:public:ra:1.4_req:2_nonfunc:14_reliability
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision | |||
|
dido:public:ra:1.4_req:2_nonfunc:14_reliability [2021/06/11 14:52] char |
dido:public:ra:1.4_req:2_nonfunc:14_reliability [2021/08/09 14:34] (current) murphy |
||
|---|---|---|---|
| Line 16: | Line 16: | ||
| [[dido:public:ra:xapend:xapend.a_glossary:r:ram|Reliability, maintainability, and availability (RAM)]] are three system attributes that are of great interest to systems engineers, logisticians, and users. Collectively, they affect both the utility and the life-cycle costs of a product or system. The origins of contemporary reliability engineering can be traced to World War II. The discipline’s first concerns were electronic and mechanical components (Ebeling, 2010) /* Need to add the reference to this article -- missing */. However, current trends point to a dramatic rise in the number of industrial, military, and consumer products with integrated computing functions. Given the rapidly increasing integration of computers into products and systems used by consumers, industry, governments, and the military, reliability must consider both hardware and software. | [[dido:public:ra:xapend:xapend.a_glossary:r:ram|Reliability, maintainability, and availability (RAM)]] are three system attributes that are of great interest to systems engineers, logisticians, and users. Collectively, they affect both the utility and the life-cycle costs of a product or system. The origins of contemporary reliability engineering can be traced to World War II. The discipline’s first concerns were electronic and mechanical components (Ebeling, 2010) /* Need to add the reference to this article -- missing */. However, current trends point to a dramatic rise in the number of industrial, military, and consumer products with integrated computing functions. Given the rapidly increasing integration of computers into products and systems used by consumers, industry, governments, and the military, reliability must consider both hardware and software. | ||
| - | Maintainability models present some interesting challenges. The time to repair an item is the sum of the time required for evacuation, diagnosis, assembly of resources (parts, bays, tool, and mechanics), repair, inspection, and return. Administrative delay (such as holidays) can also affect repair times. Often these sub-processes have a minimum time to complete that is not zero, resulting in the distribution used to model maintainability having a threshold parameter. | + | [[dido:public:ra:xapend:xapend.a_glossary:m:maintainability|Maintainability]] models present some interesting challenges. The time to repair an item is the sum of the time required for evacuation, diagnosis, assembly of resources (parts, bays, tool, and mechanics), repair, inspection, and return. Administrative delay (such as holidays) can also affect repair times. Often these sub-processes have a minimum time to complete that is not zero, resulting in the distribution used to model maintainability having a threshold parameter. |
| A threshold parameter is defined as the minimum probable time to repair. Estimation of maintainability can be further complicated by queuing effects, resulting in times to repair that are not independent. This dependency frequently makes the analytical solution of problems involving maintainability intractable and promotes the use of simulation to support analysis. | A threshold parameter is defined as the minimum probable time to repair. Estimation of maintainability can be further complicated by queuing effects, resulting in times to repair that are not independent. This dependency frequently makes the analytical solution of problems involving maintainability intractable and promotes the use of simulation to support analysis. | ||
dido/public/ra/1.4_req/2_nonfunc/14_reliability.1623437537.txt.gz · Last modified: 2021/06/11 14:52 by char
