Megbízhatósági tervezés
A megbízhatósági tervezés a rendszertervezés egy altudománya, ami arra helyezi a hangsúlyt, hogy a berendezések meghibásodás nélkül működjenek. A megbízhatóság a rendszer vagy komponens azon képessége, mikor adott körülmények között vagy meghatározott időtartamon belül működőképes.[1] A megbízhatóság szorosan kapcsolódik az elérhetőséghez, melyet általában úgy határoznak meg, mint a rendszer vagy komponens működőképessége adott pillanatban, vagy adott időintervallumban.
A megbízhatósági függvényt elméletileg a t időpontban történő siker valószínűségeként definiálják, amit R(t)-vel jelölnek. A gyakorlatban viszont különböző technikákkal számítják, értéke pedig mozoghat 0 és 1 között, ahol a 0 a siker valószínűségének hiányát, míg az 1 a biztos sikert jelenti. Ezt a valószínűséget részletes (hibafizikai) elemzésekből, korábbi adatbázisokból vagy megbízhatósági tesztelésekből és modellezésekből becsülik meg. Az elérhetőség, tesztelhetőség, karbantarthatóság és karbantartás gyakran a "megbízhatósági tervezés" részeként van meghatározva a megbízhatósági programokban. A megbízhatóság gyakran kulcsszerepet játszik a rendszerek költséghatékonyságában.
A megbízhatósági tervezés foglalkozik a magas szintű "élettartam" mérnöki bizonytalanságának és meghibásodási kockázatának előre jelzésével, megelőzésével és kezelésével. Bár a sztochasztikus paraméterek meghatározzák és befolyásolják a megbízhatóságot, a megbízhatóság nem csak matematikai és statisztikai úton érhető el.[2][3] "Szinte az összes oktatási és irodalmi anyag ezen aspektusokra helyezi a hangsúlyt, figyelmen kívül hagyva, hogy a bizonytalanság mértéke nagymértékben érvényteleníti az előrejelzés és mérés kvantitatív módszereit."[4] Például könnyű szimbólumként vagy értékként ábrázolni egy egyenletben a "meghibásodás valószínűségét", de a gyakorlatban szinte lehetetlen megjósolni annak valós nagyságát, mivel számos változótól függ, így az egyenlet megléte nem egyenlő a megbízhatóság pontos előre jelzésével.
A megbízhatósági tervezés szorosan kapcsolódik a minőségtervezéshez, biztonságtervezéshez és rendszerbiztonsághoz, melyekben az elemzések során közös módszereket alkalmaznak, és szükségük lehet az egymástól származó inputra. Úgy is mondhatjuk, hogy egy rendszernek megbízhatóan biztonságosnak kell lennie.
A megbízhatósági tervezés a rendszer leállásából adódó meghibásodások, pótalkatrészek, javítóberendezések, személyzet és garanciális igények költségeire koncentrál.[5]
Története
[szerkesztés]A „megbízhatóság” szó egészen az 1816-os évekre nyúlik vissza, ekkor jelent meg elsőnek Samuel Taylor Coleridge költészetében.[6] A második világháború előtt a kifejezés főként az ismétléssel volt összefüggésben; egy teszt (bármely tudományágban) "megbízhatónak" számított, ha az eredmények ugyanúgy ismétlődtek. Az 1920-as években a Bell Labs-nél dolgozó Dr. Walter A. Shewhart támogatta a termékfejlesztést a statisztikai folyamatszabályozás használatával, míg Waloddi Weibull a kimeríthetetlen statisztikai modelleken dolgozott.[7] A megbízhatósági tervezés fejlődése párhuzamosan zajlott a minőséggel. A "megbízhatóság" modernkori használatát az amerikai hadsereg határozta meg az 1940-es években egy termék jellemzésénél, amely a várakozásoknak megfelelően működött, meghatározott ideig.
A második világháborúban főként az akkori elektronikus berendezések megbízhatatlanságából eredtek a problémák. 1945-ben M.A. Miner "Cumulative Damage in Fatigue" címmel adott ki egy cikket az ASME folyóiratban. A megbízhatósági tervezés egyik fő használata a hadseregben a vákuumcsövekre irányult, melyek radarrendszerekben és más elektronikákban voltak megtalálhatóak, megbízhatóságuk pedig nagyon problémás és költséges volt. Az IEEE 1948-ban megalapította a Megbízhatósági Társaságot. 1950-ben az Amerikai Védelmi Minisztérium létrehozott egy csoportot „Advisory Group on the Reliability of Electronic Equipment" (AGREE) néven azért, hogy kivizsgálja a katonai berendezések megbízhatósági módszereit.[8] Ez a csoport három fő módszert ajánlott:
- A komponensek megbízhatóságának javítása.
- Minőségi és megbízhatósági követelmények megállapítása a beszállítók számára.
- Mezőadatok gyűjtése és a meghibásodások okainak feltárása.
Az 1960-as években nagyobb hangsúlyt fektettek a komponens-és rendszer szintű megbízhatóság tesztelésre. Ebben az időszakban jött létre a híres katonai szabvány, a MIL-STD-781, továbbá ekkor jelent meg az RCA által kiadott katonai kézikönyv 217 elődje, amelyet elektronikus komponensek meghibásodási rátáinak előrejelzésére használtak. A komponens megbízhatóságára és empirikus kutatásokra (pl. Mil Std 217) helyezett hangsúly elkezdett fokozatosan csökkenni és inkább olyan pragmatikus megközelítéseket alkalmaztak, mint a fogyasztói iparágakban. Az 1980-as években a televíziókat egyre inkább szilárdtest-félvezetők alkották. Az autók gyorsan növelték a félvezetők használatát különféle mikroszámítógépekkel a motorháztető alatt és a műszerfalon. A nagy légkondicionáló rendszerek elektronikus vezérlőket fejlesztettek, akárcsak a mikrohullámú sütők és számos más háztartási gép. A kommunikációs rendszerek elkezdték alkalmazni az elektronikát a régi mechanikus kapcsolórendszerek helyett. A Bellcore kiadta az első fogyasztói előrejelzési módszertant a távközlés számára, és az SAE hasonló dokumentumot adott ki SAE870050 néven az autóipari alkalmazásokhoz. Az előrejelzések természete az évtized során változott, és nyilvánvalóvá vált, hogy a die komplexitás nem az egyetlen tényező, amely meghatározza az integrált áramkörök (IC) meghibásodási rátáit. Kam Wong publikált egy cikket, amely megkérdőjelezte a kádgörbét.[9] Ebben az évtizedben sok komponens meghibásodási rátája tízszeresére csökkent. Az 1990-es évekre az IC fejlesztésének üteme felgyorsult. Az önálló mikroszámítógépek szélesebb körű használata általánossá vált és a PC-piac segített az IC sűrűségének Moore törvénye szerinti követésében, amely körülbelül 18 havonta megduplázódott. A megbízhatósági tervezés átalakulóban volt, ahogy a meghibásodás fizikájának megértésére helyeződött a hangsúly. A komponensek meghibásodási rátái tovább csökkentek, de a rendszer szintű problémák egyre kiemelkedőbbé váltak. A rendszerszemlélet egyre fontosabbá vált. A szoftver esetében kifejlesztették a CMM (Capability Maturity Model) modellt, amely egy kvalitatívabb megközelítést adott a megbízhatósághoz. Az ISO 9000 részeként a tervezés és fejlesztés részeként megbízhatósági intézkedéseket vezettek be a tanúsítás során. A Világháló terjedése új kihívásokat hozott a biztonság és a bizalom terén. A régi probléma, miszerint túl kevés megbízható információ áll rendelkezésre, más lett, mivel sok kérdéses értékű információlátott napvilágot. A fogyasztói megbízhatósági problémák most valós időben tárgyalhatók online adatok felhasználásával. Az új technológiák, mint például a mikro-elektromechanikai rendszerek (MEMS), kézi GPS, és olyan kézi eszközök, amelyek kombinálják a mobiltelefonokat és a számítógépeket, mind kihívást jelentenek a megbízhatóság fenntartásában. A termékfejlesztési idő tovább rövidült az évtized során, és amit három év alatt elértek, azt most 18 hónap alatt végezték el. Ez azt jelentette, hogy a megbízhatósági eszközöket és feladatokat szorosabban kellett kapcsolni a fejlesztési folyamathoz. Sok szempontból a megbízhatóság a mindennapi élet és a fogyasztói elvárások részévé vált.
Áttekintés
[szerkesztés]A megbízhatóság annak valószínűsége, hogy egy termék a meghatározott használati időszakon és működési feltételeken belül az előírt módon működik, és megfelel vagy meghaladja az ügyfél elvárásait.[10]
Célok
[szerkesztés]A megbízhatósági tervezés céljai, csökkenő fontossági sorrendben:[11]
- Mérnöki ismeretek és speciális technikák alkalmazása a meghibásodások valószínűségének vagy gyakoriságának csökkentése érdekében.
- Azon meghibásodások okainak azonosítása és javítása, amelyek minden erőfeszítés ellenére bekövetkeznek.
- Olyan módszerek meghatározása, amelyekkel kezelni lehet a bekövetkező meghibásodásokat, ha azok okait nem sikerült kijavítani.
- Módszerek alkalmazása új tervek megbízhatóságának becslésére és megbízhatósági adatok elemzésére.
Azért helyezünk nagy hangsúlyt a fontossági sorrendre, mivel a költségek minimalizálása és megbízható termékek előállítása szempontjából ez a leghatékonyabb módszer. Éppen ezért van szükség arra, hogy a meghibásodások lehetséges okait megértsük és tudjuk előre jelezni, esetleg megelőzni őket. Szükséges továbbá a tervek és adatok tekintetében az elemzési módszerek ismerete is.
Hatókör és technikák
[szerkesztés]A "komplex rendszerek" megbízhatósági tervezése eltérő, bonyolultabb rendszerszemléletet igényel, mint a nem komplex rendszerek esetében. A megbízhatósági tervezés magában foglalhatja:
- Rendszer elérhetőség és missziókészség elemzése, továbbá a kapcsolódó megbízhatósági és karbantartási követelmények meghatározása
- Funkcionális rendszer meghibásodás elemzése illetve az ebből adódó követelmények specifikálása
- Beépített (rendszer) tervezés megbízhatósági elemzése és az ebből származó követelmények meghatározása, mind a hardver, mind a szoftver szempontjából
- Rendszerdiagnosztikai tervezés
- Hibaközpontú rendszerek (pl. redundanciával)
- Előrejelző és megelőző karbantartás (pl. megbízhatóság-központú karbantartás)
- Emberi tényezők / emberi interakciók / emberi hibák
- Gyártási és összeszerelési hibák (hatása az észlelt "0-órás minőségre" és megbízhatóságra)
- Karbantartás által okozott hibák
- Szállítás által okozott hibák
- Tárolás által okozott hibák
- Használati (terhelési) vizsgálatok, komponens terhelési elemzések illetve a követelmények specifikálása
- Szoftver (rendszeres) hibák
- Meghibásodás / megbízhatósági tesztelés (követelményekből származó)
- Mezőbeli meghibásodások nyomon követése és javítása
- Alkatrészek felhalmozása (elérhetőség ellenőrzése)
- Műszaki dokumentáció, óvintézkedés és figyelmeztető elemzés
- Adatok és információk beszerzése / szervezése (általános megbízhatósági fejlesztési veszélynapló és FRACAS rendszer létrehozása)
- Káosz tervezés
A hatékony megbízhatósági tervezés megköveteli a meghibásodási mechanizmusok alapjainak megértését, melyhez szükséges tapasztalat, széles mérnöki készség és sok különböző mérnöki szakterület alapos ismerete, például:[12]
- Tribológia
- Feszültség (mechanika)
- Törésmechanika / fáradtság
- Hőmérnökség
- Áramlástan / sokkterhelési mérnökség
- Villamosmérnökség
- Vegyészmérnökség (pl. korrózió)
- Anyagtudomány
Meghatározások
[szerkesztés]A megbízhatóságot az alábbi módokon lehet meghatározni:
- Annak a gondolata, hogy a termék idővel megfelel egy célnak
- Egy tervezett, gyártott vagy karbantartott termék idővel képes lesz a megfelelő teljesítmény elérésére
- Egy tervezett, gyártott vagy karbantartott termékek jelentős része idővel megfelelően működik.
- Egy termék időtállósága
- Annak a valószínűsége, hogy a termék meghatározott módon és ideig ellátja a szükséges funkcióit
- Egy termék tartóssága
Megbízhatósági értékelés alapjai
[szerkesztés]Számos mérnöki technikát alkalmaznak a megbízhatósági kockázatértékelések során, ilyen például a megbízhatósági blokk diagram, veszélyelemzés, hibamód-és hatáselemzési módszer (FMEA),[13] hibafa-elemzés (FTA), megbízhatóság központú karbantartás, terhelési, anyagfeszültségi és kopási számítások, fáradtság- és kúszásanalízis, emberi hiba elemzés, gyártási hiba elemzés, megbízhatósági tesztelés stb. Ezeket az elemzéseket pontosan, nagy figyelemmel kell elvégezni ahhoz, hogy hatékonyak legyenek. A megbízhatósági technikák nagy száma, költsége továbbá a különböző szituációkból adódó eltérő megbízhatóság miatt a legtöbb projekthez megbízhatósági programtervet dolgoznak ki, amiben meghatározzák az adott rendszer számára a végrehajtandó feladatokat (munkaleírásokat (SoW)).
A biztonsági esetek létrehozásával összhangban, mint például az ARP4761-nél, a megbízhatósági értékelések célja, hogy robusztus mennyiségű és minőségű bizonyítékokat biztosítsanak arról, hogy a komponens vagy rendszer használata nem jár elfogadhatatlan kockázatokkal.[14] Az alapvető lépések a következők:
- A releváns, megbízhatatlan "veszélyek" alapos azonosítása elemzéssel vagy teszteléssel, például potenciális feltételek, események, emberi hibák, meghibásodási módok, kölcsönhatások, meghibásodási mechanizmusok gyökérokok.
- Kapcsolódó rendszerkockázat értékelése konkrét elemzéssel vagy teszteléssel.
- Javasolt enyhítési intézkedések meghatározása, például követelmények, tervezési változtatások, észlelési logika, karbantartás és képzés, amelyekkel a kockázatok csökkenthetők és ellenőrizhetők.
- A legjobb enyhítés meghatározása, megegyezés az elfogadható kockázati szintekről, esetleg költség/haszon elemzés alapján.
Itt a kockázatot a meghibásodási esemény (forgatókönyv) bekövetkezésének valószínűsége és súlyosságának kombinációja okozhatja. Biztonsági szempontból a megbízhatóságra eltérően tekintünk a rendszer elérhetőségének megbízhatóságához képest. Az elérhetőség és a biztonság dinamikusan létezik egymás mellett, mivel a túlságosan elérhető rendszer veszélyeket vonzz maga után. Ha egy mérnöki rendszert túl gyorsan kényszerítünk biztonsági állapotba, hamis riasztásokat idézhet elő, ezzel akadályozva a rendszer elérhetőségét.
Egyik definíció szerint a meghibáésodás súlyossága magába foglalja a pótalkatrészek, munkaórák, logisztika, károk (másodlagos meghibásodások) illetve a gépek leállásának költségeit, amelyek termeléskiesést okozhatnak. Egy másik definíció magába foglalja a rendszerben lévő emberek sérüléseitt, esetleges halálukat (lásd bányabalesetek, ipari balesetek, űrrepülőgép-meghibásodások) ugyanez vonatkozik a lakosságra is (lásd Bhopal, Love Canal, Csernobil vagy Sendai lakossága, vagy a 2011-es Tóhoku földrengés és cunami áldozatait) — ebben az esetben a megbízhatósági tervezés rendszerbiztonsággá válik. Az, hogy mi az elfogadható azt a hatóság, az ügyfelek vagy az érintett közösségek határozzák meg. A maradék kockázat pedig az a kockázat, amely az összes elvéhzett tevékenység befejezése után marad, és magába foglalja az azonosítatlan kockázatot is, ezért nem számszerűsíthető.
A technikai rendszerek összetettsége, mint például a tervezés és anyagok javítása, a tervezett ellenőrzések, a hibatűrő tervezés és a redundáns tartalék csökkenti a kockázatot és növeli a költségeket. A kockázat csökkenthető ALARA (as low as reasonably achievable) vagy ALAPA (as low as practically achievable) elvekre.
Megbízhatósági és elérhetőségi programterv
[szerkesztés]A megbízhatósági program bevezetése nem csupán egy szoftvervásárlás; nem csak egy lista elemeinek teljesítése, amelyek biztosítják, hogy megbízható termékekkel és folyamatokkal rendelkezzünk. A megbízhatósági program egy komplex, tanuláson és tudáson alapuló rendszer, amely a termékekre és folyamatokra nézve egyedi. A vezetőség támogatja, a csapaton belül kifejlesztett készségekre épít, integrálódik az üzleti folyamatokba, és bizonyított standard munkagyakorlatok követésével hajtják végre.[15]
A megbízhatósági programterv célja pontosan dokumentálni, hogy milyen „legjobb gyakorlatok” (feladatok, módszerek, eszközök, elemzések és tesztek) szükségesek egy adott (al)rendszer számára, valamint tisztázni az ügyfél megbízhatósági értékelésre vonatkozó követelményeit. Nagy léptékű, összetett rendszerek esetében a megbízhatósági programtervnek külön dokumentumnak kell lennie. A munkaerő és költségvetés meghatározása a teszteléshez és egyéb feladatokhoz kritikusan fontos egy sikeres programhoz. Általában a hatékony programhoz szükséges munka mennyisége jelentős az összetett rendszerek esetében.
A megbízhatósági programterv elengedhetetlen a magas szintű megbízhatóság, tesztelhetőség, karbantarthatóság és a rendszerek rendelkezésre állásának eléréséhez, és a rendszerfejlesztés korai szakaszában fejlesztik ki, majd a rendszer életciklusa során finomítják. Meghatározza nemcsak azt, hogy mit csinál a megbízhatósági mérnök, hanem az egyéb érdekelt felek által végzett feladatokat is. Egy hatékony megbízhatósági programtervet a legfelsőbb programvezetésnek kell jóváhagynia, amely egyben felelős az elegendő erőforrások kiosztásáért.
A megbízhatósági programtervet arra is lehet használni, hogy értékelje és javítsa a rendszer rendelkezésre állását azáltal, hogy a tesztelhetőség és karbantarthatóság növelésére összpontosítanak, nem pedig a megbízhatóságra. A karbantarthatóság javítása általában könnyebb, mint a megbízhatóságé. A karbantarthatósági becslések (javítási arányok) is pontosabbak. Azonban mivel a megbízhatósági becslések bizonytalanságai a legtöbb esetben nagyon nagyok, valószínűleg dominálni fogják a rendelkezésre állási számítást (előrejelzési bizonytalansági probléma), még akkor is, ha a karbantarthatósági szintek nagyon magasak. Ha a megbízhatóság nincs ellenőrzés alatt, bonyolultabb problémák is felmerülhetnek, mint például a munkaerő (karbantartók/ügyfélszolgálati képesség) hiánya, alkatrészellátási problémák, logisztikai késedelmek, javító létesítmények hiánya, kiterjedt átalakítási és összetett konfigurációkezelési költségek és egyéb problémák. Az üzembiztonság hiányának problémáját fokozhatja a javítás utáni karbantartás okozta hibák „dominóhatása” is. Ezért nem elegendő csak a karbantarthatóságra összpontosítani. Ha a meghibásodásokat megelőzik, a problémák nagxrésze nem válik jelentőssé, ezért a megbízhatóságot általában a rendelkezésre állás legfontosabb részének tekintik. A megbízhatóságot mind a rendelkezésre állás, mind a teljes birtoklási költség (TCO) tekintetében értékelni és javítani kell a pótalkatrészek, karbantartási munkaórák, szállítási költségek, tárolási költségek, alkatrész elavulási kockázatok stb. költségei miatt. Azonban, ahogy a GM és a Toyota később rájöttek, a TCO magában foglalja az utólagos felelősségi költségeket is, amikor a megbízhatósági számítások nem megfelelően vagy pontatlanul kezelték az ügyfelek testi kockázatait. Gyakran szükséges egy kompromisszum a kettő között. Lehet, hogy van egy maximális arány a rendelkezésre állás és a birtoklási költség között, ettől függetlenül a rendszer tesztelhetőségét is kezelni kell a tervben, mivel ez a kapcsolat a megbízhatóság és a karbantarthatóság között. A karbantartási stratégia befolyásolhatja a rendszer megbízhatóságát (pl. megelőző és/vagy előrejelző karbantartással), bár soha nem hozhatja azt a veleszületett megbízhatóság fölé.
A megbízhatósági tervnek egyértelműen meg kell határoznia a rendelkezésre állás ellenőrzésének stratégiáját. Az, hogy csak a rendelkezésre állás vagy a birtoklási költség fontosabb-e, az a rendszer használatától függ. Például egy olyan rendszer esetében, amely kritikus láncszem egy termelési rendszerben – például egy nagy olajplatform – általában megengedett, hogy nagyon magas birtoklási költséggel rendelkezzen, ha ez a költség még egy kisebb rendelkezésre állás növekedéséhez is vezet, mivel a platform elérhetetlensége hatalmas bevételkiesést eredményezhet, amely könnyen meghaladhatja a magas birtoklási költséget. Egy megfelelő megbízhatósági tervnek mindig teljes kontextusában kell kezelnie a RAMT elemzést. A RAMT jelentése megbízhatóság, rendelkezésre állás, karbantarthatóság/karbantartás és tesztelhetőség az ügyfél igényeinek kontextusában.
Megbízhatósági követelmények
[szerkesztés]Bármilyen rendszer esetében a megbízhatósági tervezés egyik első feladata, hogy megfelelően meghatározza a megbízhatósági és karbantarthatósági követelményeket, amelyek az elérhetőségi igényekből, a tervezési hibaanalízisekből vagy a kezdeti prototípus teszteredményekből származnak. A tervezőket konkrét követelmények korlátozzák azért, hogy ne tudjanak megbízhatatlan elemeket / konstrukciókat / interfészeket / rendszereket tervezni. Csak rendelkezésre állási, megbízhatósági, tesztelhetőségi vagy karbantarthatósági követelmények (pl. max. meghibásodási arányok) kitűzése nem megfelelő. Ez mindig félreértést okoz a megbízhatósági követelmények mérnöki tervezésében. A megbízhatósági követelmények magát a rendszert célozzák meg, beleértve a tesztelési és értékelési követelményeket, valamint a kapcsolódó feladatokat és dokumentációkat. A megbízhatósági követelményeket be kell építeni a megfelelő rendszer vagy alrendszer követelményspecifikációjába, teszttervébe és szerződési nyilatkozatába. Alacsonyabb szintű követelmények létrehozása kritikus lehet.[16] Minimális vagy kevés cél (pl. meghibásodások között átlagosan eltelt idő (MTBF) értékek vagy meghibásodási arányok) meghatározása nem elegendő több okból sem. Főleg azért, mert egy mennyiségi megbízhatósági allokáció (követelményspecifikáció) teljes validációja (helyesség és időbeli ellenőrizhetőség) összetett rendszerek esetén gyakran nem lehetséges, mivel (1) a követelmények valószínűségi jellegűek, (2) rendkívül magas bizonytalansági szint kapcsolódik az összes ilyen valószínűségi követelmény bemutatásához, és mivel (3) a megbízhatóság az idő függvénye, és egy elem (valószínűségi) megbízhatósági számának pontos becslései csak nagyon későn állnak rendelkezésre a projekt során, néha még évekig tartó használat után sem. Hasonlítsuk össze ezt a problémát azzal, amikor egy repülőgép fejlesztése során folyamatosan (újra) egyensúlyozzák az alacsonyabb szintű rendszer tömegkövetelményeit, ami már önmagában is nagy feladat. Ilyenkor észrevehető, hogy nem az idő függvényei, hanem a tömegek különböznek néhány százalékkal és az adatok már CAD modellekben rendelkezésre állnak. A megbízhatóság esetében a megbízhatatlanság szintjei (meghibásodási arányok) évtizedekkel (10-szeresével) változhatnak a tervezésben, folyamatban vagy bármi másban bekövetkezett apró eltérések miatt. Az információ gyakran hatalmas bizonytalanságokkal áll rendelkezésre a fejlesztési szakaszban. Éppen ezért ezt az allokációs problémát szinte lehetetlen hasznosan, praktikusan, vagy érvényes módon kezelni, és masszív túl- vagy alulspecifikációt eredményezhet. Így szükség van egy pragmatikus megközelítésre – például: általános szintű / kvantitatív követelmények használatára, amelyek csak a meghibásodási hatások súlyosságától függenek. Az eredmények validálása sokkal szubjektívebb feladat, mint bármely más típusú követelmény. A (kvantitatív) megbízhatósági paraméterek – az MTBF értelmében – messze a legbizonytalanabb tervezési paraméterek bármilyen tervezés során.
Továbbá, a megbízhatósági tervezési követelményeknek a(rendszer vagy rész) tervezését olyan jellemzőkkel kell vezérelnünk, amelyek megakadályozzák a meghibásodásokat vagy korlátozzák azok következményeit. Nem csak a becslésekben segítene, hanem megakadályozná, hogy a mérnöki munka egyfajta számviteli tevékenységgé váljon. A tervezési követelménynek elég pontosnak kell lennie ahhoz, hogy a tervező „megtervezhesse” és bizonyíthassa – elemzés vagy tesztelés révén –, hogy a követelmény teljesült. Bármilyen típusú megbízhatósági követelménynek részletesnek kell lennie, származhat hibaanalízisből (megbízhatósági kockázatelemzés, FTA, FMEA, humán faktor elemzés, funkcionális kockázatelemzés stb.) vagy bármilyen típusú megbízhatósági tesztelésből. Emellett szükséges a verifikációs teszt követelményei (pl. szükséges túlterhelési stresszek) és a tesztidő. Ezeknek a követelményeknek hatékony meghatározásához rendszermérnöki alapú kockázatértékelési és kockázatcsökkentési logikát kell használni. Nagyméretű veszélynapló rendszereket kell létrehozni, amelyek részletes információkat tartalmaznak arról, hogy miért és hogyan hibásodhatnak vagy hibásodtak meg rendszerek. Ezek a gyakorlati tervezési követelmények irányítják a tervezést, és nem csak verifikációra használják őket. Ezeket a követelményeket (gyakran tervezési korlátokat) hibaanalízisből vagy előzetes tesztelésekből származtatják. Ennek a különbségnek a megértése és a tisztán kvantitatív (logisztikai) követelményspecifikáció (pl. meghibásodási arány / MTBF cél) szükséges a sikeres (összetett) rendszerfejlesztéshez.[17]
A karbantarthatósági követelmények a javítások költségeit és idejét célozzák meg. A tesztelhetőségi (nem tévesztendő össze a tesztkövetelményekkel) követelmények biztosítják a kapcsolatot a megbízhatóság és a karbantarthatóság között. Meg kell határozniuk a meghibásodási módok észlelhetőségét (egy adott rendszer szinten), izolációs szinteket és diagnosztikai eljárások létrehozását. A megbízhatósági tervezésnél foglalkozni kell a különböző megbízhatósági feladatok és dokumentációk követelményeivel a rendszer fejlesztése, tesztelése, gyártása és működtetése során. Ezeket a követelményeket általában a szerződés munkanyilatkozatában határozzák meg, és attól függnek, hogy az ügyfél mennyi mozgásteret kíván biztosítani a vállalkozónak. A megbízhatósági feladatok különböző elemzéseket, tervezéseket és meghibásodás-jelentési feladatokat tartalmaznak. A feladatok kiválasztása a rendszer bonyolultságától és költségétől függ. Egy biztonságkritikus rendszer esetében formális meghibásodás-jelentési és felülvizsgálati folyamatra lehet szükség a fejlesztés során, míg egy nem kritikus rendszer esetében elegendő lehet a végső tesztjelentés. A leggyakoribb megbízhatósági programfeladatok dokumentálva vannak a megbízhatósági programszabványokban, mint például a MIL-STD-785 és az IEEE 1332. A meghibásodás-jelentési elemzés és a helyesbítő intézkedések rendszerei közös megközelítést jelentenek a termék/feldolgozási megbízhatóság monitorozásában.
Megbízhatósági kultúra / emberi hibák / humán faktorok
[szerkesztés]Gyakorlatilag a legtöbb meghibásodás visszavezethető valamilyen emberi hibára, például:
- Menedzsment döntések (pl. költségvetés, időzítés és szükséges feladatok)
- Rendszertervezés: Használati tanulmányok (terhelési esetek)
- Rendszertervezés: Követelményanalízis/beállítás
- Rendszertervezés: Konfigurációs vezérlés
- Feltételezések
- Számítások/szimulációk/FEM analízis
- Tervezés
- Tervezési rajzok
- Tesztelés (pl. helytelen terhelési beállítások vagy meghibásodás mérés)
- Statisztikai elemzés
- Gyártás
- Minőségellenőrzés
- Karbantartás
- Karbantartási kézikönyvek
- Képzés
- Információ osztályozása és rendszerezése
- Mező információ visszajelzése (pl. helytelen vagy túl homályos) stb.
Az emberek azonban nagyon jók a hibák észlelésében, kijavításában és improvizálásában, amikor rendellenes helyzetek adódnak. Ezért azon szabályozások, amelyek teljesen kizárják az emberi cselekvéseket a tervezési és gyártási folyamatokból a megbízhatóság javítása érdekében, nem biztos, hogy hatékonyak. Néhány feladatot jobban végeznek az emberek, míg másokat jobban végeznek a gépek.[18]
Azonban, az emberi hibák a menedzsmentben, az adatok és információk szervezésében vagy az elemek helytelen használatában vagy visszaélésében szintén hozzájárulhatnak a megbízhatatlansághoz. Ez az alapvető oka annak, hogy a komplex rendszerek magas megbízhatósági szintjét csak egy robusztus rendszermérnöki folyamat követésével lehet elérni, megfelelő tervezéssel és validációs, verifikációs feladatok végrehajtásával. Ez magában foglalja az adatok és információk megosztásának gondos megszervezését és a "megbízhatósági kultúra" kialakítását is, ugyanúgy, ahogy a "biztonsági kultúra" létfontosságú a biztonságkritikus rendszerek fejlesztésében.
Megbízhatósági előrejelzés és javítás
[szerkesztés]A megbízhatósági előrejelzés magába foglalja:
- Megfelelő megbízhatósági modell létrehozása (lásd bővebben ezen az oldalon)
- Bemeneti paraméterek becslése (és igazolása) ehhez a modellhez (pl. meghibásodási arányok adott meghibásodási mód vagy esemény esetében, valamint az átlagos javítási idő a rendszer adott meghibásodása esetén)
- Kimeneti megbízhatósági paraméterek becslése rendszer vagy részszinten (pl. rendszer rendelkezésre állása vagy egy adott funkcionális meghibásodás gyakorisága). A kvantifikációra és célkitűzésre (pl. MTBF) helyezett hangsúly azt sugallhatja, hogy van egy korlát az elérhető megbízhatóságra, viszont, a nagyobb megbízhatóság fejlesztése nem feltétlenül költségesebb. Továbbá történelmi adatok alapján a megbízhatóság előrejelzése nagyon félrevezető tud lenni, mivel az összehasonlítások csak azonos tervezésekre, termékekre, gyártási folyamatokra és karbantartásra érvényesek, azonos működési terhelésekkel és használati környezetekkel. Ezek bármelyikének kisebb változása is nagy hatással lehet a megbízhatóságra. A legmegbízhatatlanabb és legfontosabb elemeket (azaz a megbízhatósági vizsgálatok legérdekesebb jelöltjeit) valószínűleg újra fogják módosítani és tervezni, mivel a standard (reaktív vagy proaktív) statisztikai módszerek, folyamatok amelyeket például az orvosi vagy biztosítási iparban is használnak, kevésbé hatékonyak. Egy másik meglepő, de logikus érv az, hogy ahhoz, hogy pontosan előre lehessen jelezni a megbízhatóságot a tesztelés révén, ismerni kell a meghibásodás pontos mechanizmusait. Ezért – a legtöbb esetben – meg lehetne akadályozni! A helytelen út követése, amikor egy összetett megbízhatósági tervezési problémát MTBF-el próbálunk megoldani helytelen – például reaktív – megközelítéssel, az Barnard szerint "Playing the Numbers Game", továbbá rossz gyakorlatnak tekinthető.[19]
A meglévő rendszerek esetében vitatható, hogy bármilyen kísérlet egy felelősségteljes program által felfedezett meghibásodások gyökérokainak kijavítására érvénytelenné teheti a kezdeti MTBF becslést, mivel új feltételezéseket kell tenni ennek a kijavításnak a hatásáról (amelyek maguk is magas hibaszinteknek vannak kitéve). Egy másik gyakorlati probléma a részletes meghibásodási adatok általános hiánya, amelyek gyakran ellentmondásos információkat tartalmaznak a meghibásodási (visszajelzési) adatokról, és figyelmen kívül hagyják a statisztikai hibákat (amelyek nagyon magasak a ritka események, például a megbízhatósággal kapcsolatos meghibásodások esetén). Nagyon világos irányelveknek kell jelen lenniük a különböző típusú gyökérokokhoz kapcsolódó meghibásodások számolására és összehasonlítására (pl. gyártási, karbantartási, szállítási, rendszer okozta vagy inherent tervezési meghibásodások). A különböző típusú okok összehasonlítása helytelen becslésekhez és üzleti döntésekhez vezethet.
A rendszerek megfelelő kvantitatív megbízhatósági előrejelzése nehéz és nagyon költséges lehet, ha teszteléssel végezzük. Egyedi részegység szinten a megbízhatósági eredmények gyakran viszonylag magas megbízhatósággal érhetők el, mivel sok minta részegység tesztelése lehetséges a rendelkezésre álló tesztköltségvetéssel. Azonban ezek a tesztek rendszer szinten sajnos gyakran valótlanok a részegység szintű teszteléseknél tett feltételezések miatt. Ezek a szerzők hangsúlyt fektettek a kezdeti részegység- vagy rendszer szintű tesztelés fontosságára a meghibásodásig, illetve az ezekből a meghibásodásokból származó tapasztalatszerzés fontosságára. Az általános következtetés az, hogy egy pontos és abszolút előrejelzésnél – akár terepi adatok összehasonlításával, akár teszteléssel – a megbízhatóság legtöbb esetben nem garantált. Kivétel lehet a kopási probléma, mint például a fáradási meghibásodás. A MIL-STD-785 bevezetőjében az olvasható, hogy a megbízhatósági előrejelzéseket nagy óvatossággal kell használni, ha nem kizárólag összehasonlításra használják a kompromisszumos tanulmányokban.
Megbízhatóságra való tervezés
[szerkesztés]A Megbízhatóságra való tervezés (Design for Reliability, DfR) egy folyamat, amely magában foglalja azokat az eszközöket és eljárásokat, amelyek biztosítják, hogy egy termék megfeleljen a követelményeknek élettartama során. A DfR a termék tervezési szakaszában valósul meg, hogy proaktívan javítsa a termék megbízhatóságát.[20] A DfR-t gyakran egy általános Kiválóságra való tervezés (Design for Excellence, DfX) stratégia részeként is alkalmazzák.
Statisztika alapú megközelítés (azaz MTBF)
[szerkesztés]A megbízhatósági tervezés egy (rendszer) modell kifejlesztésével kezdődik. A megbízhatósági és elérhetőségi modellek blokkdiagramokat és hibafa-elemzést használnak a rendszer különböző részei közötti kapcsolatok grafikus ábrázolásához. Ezek a modellek tartalmazhatnak előrejelzéseket is, amelyek a történelmi adatokból származó meghibásodási rátákon alapulnak. Bár az (input adat) előrejelzések gyakran nem pontosak, értékesek a tervezési alternatívák relatív különbségeinek értékeléséhez. Karbantarthatósági paraméterek, például az átlagos javítási idő (MTTR) szintén felhasználható ilyen modellek bemeneteként.
Az alapvető, legfontosabb kiváltó okokat és meghibásodási mechanizmusokat mérnöki eszközökkel kell azonosítani és elemezni. A tervezők számára különféle gyakorlati útmutatást kell nyújtani a teljesítmény és megbízhatóság terén, hogy alacsony terhelésű terveket és termékeket hozzanak létre, amelyek védve vannak a károsodástól és túlzott kopástól. A bemeneti terhelések (követelmények) megfelelő validálására, valamint a megbízhatósági "teljesítmény" teszteléssel történő ellenőrzésére is szükség lehet.
Az egyik legfontosabb tervezési technika a redundancia. Ez azt jelenti, hogy ha a rendszer egyik része meghibásodik, van egy alternatív sikerút, például egy tartalékrendszer. Ennek az az oka, hogy az új alkatrészek vagy rendszerek magas bizalmi szintű megbízhatósági bizonyítéka gyakran nem áll rendelkezésre, vagy rendkívül drága beszerezni. A redundancia magas szintű meghibásodás-figyeléssel kombinálva, és a közös hibák elkerülésével egy rendszer még viszonylag rossz egycsatornás (alkatrész) megbízhatóság mellett is nagy megbízhatóságúvá tehető rendszerszinten (akár missziókritikus megbízhatóságig). Ehhez nem szükséges megbízhatósági tesztelés. A redundanciával együtt a különböző tervezések vagy gyártási folyamatok (például hasonló alkatrészek különböző beszállítói általi szállítása) alkalmazása csökkentheti a minőségi problémákra való érzékenységet (például egyetlen beszállítónál fellépő korai élettartam hibák), lehetővé téve nagyon magas megbízhatósági szintek elérését a fejlesztési ciklus minden pillanatában (a korai élettől a hosszú távig). A redundancia a rendszertervezésben is alkalmazható a követelmények, adatok, tervek, számítások, szoftverek és tesztek kettős ellenőrzésével a szisztematikus hibák leküzdésére.
Egy másik hatékony módja a megbízhatósági problémák kezelésének a degradáció előrejelzése, amely lehetővé teszi a nem tervezett leállási események/meghibásodások megelőzését. Erre az RCM (Reliability Centered Maintenance) programok használhatók.
Hibafizikai alapú megközelítés
[szerkesztés]Az elektronikai szerelvények esetében egyre inkább előtérbe kerül a hibafizika alapú megközelítés. Ez a technika a fizikai statikus és dinamikus meghibásodási mechanizmusok megértésén alapul. Figyelembe veszi a terhelés, az erősség és a feszültség változását, amelyek meghibásodáshoz vezetnek, mélyreható részletességgel, amit a modern véges elem módszer (FEM) szoftverprogramok tesznek lehetővé, amelyek képesek kezelni az összetett geometriai és mechanikai jelenségeket, mint például a feszültség relaxáció, fáradás és a valószínűségi tervezés (Monte Carlo módszerek/DOE). Az anyagot vagy komponenst újra lehet tervezni a meghibásodás valószínűségének csökkentése és az ilyen változásokkal szembeni robusztusság növelése érdekében. Egy másik általános tervezési technika a komponens terheléscsökkentése: azaz olyan alkatrészek kiválasztása, amelyek specifikációi jelentősen meghaladják a várható terhelési szinteket, például vastagabb elektromos vezeték használata a várható elektromos áramhoz képest.
Gyakori eszközök és technikák
[szerkesztés]Számos feladat, technika és elemzés, amelyet a megbízhatósági tervezésben használnak, egyes iparágakra és alkalmazásokra specifikusak, de általánosan tartalmazhatják:
- Hibafizika (PoF)
- Beépített önteszt (BIT vagy BIST) (tesztelhetőségi elemzés)
- Hibamód és hatáselemzés (FMEA)
- Megbízhatósági veszélyelemzés
- Megbízhatósági blokkdiagram elemzés
- Dinamikus megbízhatósági blokkdiagram elemzés[21]
- Hibafa-elemzés
- Gyökér-ok elemzés
- Statisztikai tervezés, kísérlettervezés – például szimulációk / FEM modellek vagy tesztelés
- Rejtett áramkör elemzés
- Gyorsított tesztelés
- Megbízhatósági növekedési elemzés (reaktív megbízhatóság)
- Weibull elemzés (tesztelésre vagy főleg "reaktív" megbízhatóságra)
- Hypertabastic túlélési modellek
- Termikus elemzés véges elem módszerrel (FEA) és/vagy méréssel
- Hő által kiváltott, sokk- és rezgéskimerülés elemzés FEA és/vagy méréssel
- Elektromágneses elemzés
- Egypontos meghibásodás (SPOF) elkerülése
- Funkcionális elemzés és funkcionális meghibásodási elemzés (például funkció FMEA, FHA vagy FFA)
- Előrejelző és megelőző karbantartás: megbízhatóság központú karbantartási (RCM) elemzés
- Tesztelhetőségi elemzés
- Hibadiagnosztikai elemzés (általában az FMEA-ba is beépítve)
- Emberi hiba elemzés
- Üzemi veszélyelemzés
- Megelőző/tervezett karbantartás optimalizálása (PMO)
- Kézi szűrés
- Integrált logisztikai támogatás
Ezeknek a módszereknek az eredményeit az alkatrész vagy rendszer tervezési és logisztikai felülvizsgálatai során mutatják be. A megbízhatóság csak egy követelmény a sok közül, egy összetett alkatrész vagy rendszer esetében. Mérnöki kompromisszumos tanulmányokat használnak az optimális egyensúly meghatározására a megbízhatósági követelmények és más korlátok között.
Nyelv fontossága
[szerkesztés]A megbízhatósági tervezés, akár kvantitatív, akár kvalitatív módszerekkel írja le a meghibásodásokat vagy veszélyeket, a nyelvre támaszkodnak a kockázatok pontos meghatározásában és a problémák megoldásában. Az alkalmazott nyelvnek segítenie kell a funkció / tétel / rendszer és annak összetett környezetének rendezett leírását, amik összefüggenek a meghibásodással . A rendszertervezés nagyrészt arról szól, hogy megtalálják a helyes szavakat a probléma (és a kapcsolódó kockázatok) leírására, hogy azokat mérnöki megoldásokkal könnyen megtudják oldani. Jack Ring szerint a rendszermérnök munkája a "projekt nyelvezése" (Ring et al. 2000).[22] Az alkatrész/rendszer meghibásodása esetén a megbízhatósági mérnököknek inkább a "miért és hogyan" kérdésekre koncentrálnak, mintsem a "mikor" előrejelzésére. Annak megértésével, hogy "miért" történt egy meghibásodás (például túlterhelt alkatrészek vagy gyártási problémák miatt), sokkal valószínűbb, hogy javulást eredményezhet a tervekben és a használt folyamatokban,[4] mint annak számszerűsítése, hogy "mikor" valószínű a meghibásodás (például az MTBF meghatározása révén). Ehhez először a rész/rendszer meghibásodási veszélyeit kell osztályozni és rendezni (lehetőleg valamilyen kvalitatív és kvantitatív logika alapján), hogy lehetővé váljon a hatékonyabb értékelés és a végső javítás. Ez részben tiszta nyelv és propozíciós logika alapján történik, de hasonló tételekkel szerzett tapasztalatok alapján is. Ez például látható a hibafa-elemzés, FMEA elemzés és veszély (nyomkövetési) naplók eseményleírásaiban. Ebben az értelemben a nyelv és a megfelelő nyelvtan (a kvalitatív elemzés része) fontos szerepet játszik a megbízhatóság tervezésében, csakúgy, mint a biztonsági tervezésben vagy általában a rendszertervezésben.
A nyelv helyes használata kulcsfontosságú lehet az emberi hibák kockázatának azonosításában vagy csökkentésében is, amely gyakran sok meghibásodás gyökéroka is. Ez magába foglalhatja a karbantartási kézikönyveket, üzemeltetési kézikönyveket, vészhelyzeti eljárásokat és mások megfelelő utasításait is, ezáltal meg tudjuk előzni azokat a szisztematikus emberi hibákat, amelyek rendszer meghibásodásokhoz vezethetnek. Ezeket képzett vagy tapasztalt műszaki szerzőknek kell írniuk úgynevezett egyszerűsített angol vagy Egyszerűsített Műszaki Angol nyelven, ahol a szavak és a szerkezetek kifejezetten úgy vannak kiválasztva és létrehozva, hogy csökkentsék a kétértelműséget vagy a félreértés kockázatát (például a "replace the old part" [cserélje ki a régi alkatrészt] kétértelműen utalhat arra, hogy egy elhasználódott alkatrészt cseréljenek egy nem elhasználódott alkatrészre, vagy egy alkatrészt egy újabb és remélhetőleg javított tervezésű alkatrészre).
Megbízhatósági modellezés
[szerkesztés]A megbízhatósági modellezés az a folyamat, amely során előrejelzik vagy megértik egy alkatrész vagy rendszer megbízhatóságát a bevezetése előtt. Két gyakran használt elemzés létezik a rendszer elérhetőség viselkedésének modellezésére, beleértve a logisztikai kérdéseket is, mint például a pótalkatrész-beszerzés, szállítás és munkaerő hatásait, a hibafa-elemzés és a megbízhatósági blokkdiagramok. Alkatrész szinten ugyanezek az elemzések használhatók másokkal együtt. A modellek bemeneti adatai számos forrásból származhatnak, beleértve a tesztelést, korábbi üzemeltetési tapasztalatokat, terepi adatokat, valamint hasonló vagy kapcsolódó iparágak adatkönyveit. Függetlenül a forrástól, minden bemeneti adatot nagy óvatossággal kell használni, mivel az előrejelzések csak akkor érvényesek, ha ugyanazt a terméket ugyanabban a kontextusban használták. Ezért az előrejelzéseket gyakran csak az alternatívák összehasonlítására használják.
Az alkatrész szintű előrejelzésekhez két külön terület vizsgálata gyakori:
- A hibafizikai megközelítés a fizikai meghibásodási mechanizmusok megértésére támaszkodik, mint például a mechanikai repedésnövekedés vagy a kémiai korrózió romlása vagy meghibásodása;
- Az alkatrész terhelésmodell-megközelítés egy empirikus módszer, amely a rendszer alkatrészeinek számán és típusán, valamint az üzemelés során fellépő terhelésen alapul.
Megbízhatóságelmélet
[szerkesztés]A megbízhatóság annak a valószínűségét jelenti, hogy egy eszköz a megadott időtartam alatt meghatározott körülmények között ellátja a neki szánt funkciót. Matematikailag ez így fejezhető ki:ahol a meghibásodás valószínűségi sűrűségfüggvénye és t az időtartam hossza (amely idő nulla pillanatától indul).
Ennek a definíciónak néhány kulcseleme:
- A megbízhatóság az "szándékolt funkción" alapul: Általában ez a meghibásodás nélküli működés. Azonban, ha a rendszer egyetlen része sem hibásodik meg, mégsem teljesíti a kívánt funkciót a rendszer, akkor ez is a rendszer megbízhatóságának rovására írható. A rendszerkövetelmény-specifikáció az a kritérium, amely alapján a megbízhatóságot mérik.
- A megbízhatóság egy meghatározott időtartamra vonatkozik. Gyakorlati szempontból ez azt jelenti, hogy a rendszernek meghatározott esélye van arra, hogy meghibásodás nélkül működjön a idő előtt. A megbízhatósági tervezés biztosítja, hogy az alkatrészek és anyagok megfeleljenek a követelményeknek a megadott időtartam alatt. Megjegyzendő, hogy néha az időn kívül más egységeket is használhatnak (például "küldetés", "működési ciklusok").
- A megbízhatóság adott (vagy kifejezetten meghatározott) körülmények közötti működésre korlátozódik. Ez a korlátozás szükséges, mert lehetetlen egy rendszert korlátlan körülményekhez tervezni. Egy Mars-rover más megadott körülményekkel rendelkezik, mint egy családi autó. Az üzemeltetési környezetet figyelembe kell venni a tervezés és tesztelés során. Ugyanaz a rover eltérő körülmények között történő működésre is kötelezhető, ami további vizsgálatokat igényel.
- Két jelentős hivatkozás a megbízhatóságelmélet és annak matematikai és statisztikai alapjairól: Barlow, R. E. és Proschan, F. (1982) és Samaniego, F. J. (2007).
Kvantitatív rendszermegbízhatósági paraméterek – elmélet
[szerkesztés]A kvantitatív követelményeket megbízhatósági paraméterekkel határozzák meg. A leggyakoribb megbízhatósági paraméter az átlagos meghibásodási idő (MTTF), amelyet meghibásodási ráta formájában is meg lehet adni (ez gyakoriságként vagy feltételes valószínűségi sűrűségfüggvényként (PDF) van kifejezve) vagy a meghibásodások számaként egy adott időszakban. Ezek a paraméterek hasznosak lehetnek magasabb rendszer szinteken és gyakran üzemeltetett rendszereknél (azaz járművek, gépek és elektronikai berendezések esetében). A megbízhatóság növekszik, ahogy az MTTF nő. Az MTTF-t általában órában adják meg, de más mértékegységekkel is használható, például mérföld vagy ciklus. Az MTTF értékek használata alacsonyabb rendszer szinteken nagyon félrevezető lehet, különösen, ha nem adják meg a kapcsolódó meghibásodási módokat és mechanizmusokat (az F-t az MTTF-ben).[23]
Más esetekben a megbízhatóságot a küldetés sikerességének valószínűségeként határozzák meg. Például egy menetrend szerinti repülőjárat megbízhatósága dimenzió nélküli valószínűségként vagy százalékban adható meg, ahogyan azt gyakran használják a rendszerbiztonsági tervezésben.
A küldetés sikerességének egy különleges esete az egyszeri használatú eszköz vagy rendszer. Ezek olyan eszközök vagy rendszerek, amelyek viszonylag nyugalmi állapotban maradnak és csak egyszer működnek. Példák közé tartoznak az autólégzsákok, hőelemek és rakéták. Az egyszeri használatú megbízhatóságot a siker egyszeri valószínűségeként határozzák meg, vagy egy kapcsolódó paraméterbe ágyazzák. Az egyszeri használatú rakéták megbízhatóságát a találat valószínűségének követelményeként adhatják meg. Az ilyen rendszerek esetében a meghibásodási valószínűség (PFD) a megbízhatósági mérőszám – ez valójában egy "nem elérhetőségi" szám. A PFD a meghibásodási rátából (előfordulási gyakoriság) és a küldetés idejéből származik a nem javítható rendszerek esetében.
Javítható rendszerek esetében ezt a meghibásodási rátát, az átlagos javítási idő (MTTR) és a teszt intervallum alapján határozzák meg. Ez a mérőszám nem feltétlenül egyedi egy adott rendszerre, mivel a követelés típusától függ. A rendszer szintű követelmények mellett megbízhatósági követelményeket lehet meghatározni kritikus alrendszerekre. A legtöbb esetben a megbízhatósági paramétereket megfelelő statisztikai megbízhatósági intervallumokkal adják meg.
Megbízhatósági tesztelés
[szerkesztés]A megbízhatósági tesztelés vagy megbízhatóság-ellenőrzés célja, hogy minél korábban felfedezze a tervezési hibákat, és végső soron biztosítsa, hogy a rendszer megfeleljen a megbízhatóság követelményeinek. A termék megbízhatóságát minden környezetben, például a várható használat, szállítás vagy tárolás során, a megadott élettartam alatt figyelembe kell venni.[10] A terméket természetes vagy mesterséges környezeti feltételeknek teszik ki, hogy értékeljék a termék teljesítményét a valós használat, szállítás és tárolás környezeti feltételei között, és elemezzék a környezeti tényezők hatásának mértékét és mechanizmusát.[24] Különféle környezeti tesztberendezések segítségével szimulálják a magas hőmérsékletet, alacsony hőmérsékletet, magas páratartalmat és a hőmérsékletváltozásokat, hogy felgyorsítsák a termék reakcióját a használati környezetben, és ellenőrizzék, hogy elérte-e az elvárt minőséget a K+F, tervezés és gyártás során.[25]
A megbízhatóság-ellenőrzést megbízhatósági tesztelésnek is nevezik, ami modellezés, statisztika és egyéb módszerek alkalmazását jelenti a termék megbízhatóságának értékelésére a termék élettartama és várt teljesítménye alapján.[26] A piacon lévő termékek többsége megköveteli a megbízhatóság tesztelését, például az autóiparok, integrált áramkörök, nehézgépek, repülőgép-automatizáló szoftverek.[27][28]
A megbízhatóság tesztelését több szinten is el lehet végezni, és különböző típusú tesztek léteznek. A komplex rendszereket alkatrész-, áramköri lap-, egység-, összeállítás-, alrendszer- és rendszer szinten lehet tesztelni (A tesztszintek elnevezése alkalmazásonként változik).[29] Az alacsonyabb szinteken elvégzett környezeti stressz szűrővizsgálatoknál például az alkatrészeknél vagy kisebb összeállításoknál, problémát találhatnak, mielőtt azok magasabb szinteken meghibásodást okozhatnának. A tesztelés az integráció minden szintjén folytatódik a teljes rendszertesztelés, fejlesztéstesztelés és üzemeltetéstesztelés során, csökkentve a program kockázatát. Azonban a tesztelés nem csökkenti a megbízhatatlanság kockázatát.
Minden tesztnél előfordulhatnak statisztikailag I. és II. típusú hibák, a minta méretétől, a teszt időtartamától, a feltételezésektől és a szükséges diszkriminációs aránytól függően. Kockázatot jelent egy jó tervezés helytelen elutasítása (I. típusú hiba) és egy rossz tervezés helytelen elfogadása (II. típusú hiba).
Nem mindig lehet az összes rendszerkövetelményt tesztelni. Egyes rendszerek tesztelése drága; egyes meghibásodási módok megfigyelése évekbe telhet; a komplex kölcsönhatások rengeteg lehetséges tesztesetet eredményezhetnek; és egyes tesztek korlátozott tesztterületeket vagy egyéb erőforrásokat igényelhetnek. Ilyen esetekben különböző tesztelési megközelítések alkalmazhatók, például erősen gyorsított élettartam-tesztelés, kísérlettervezés és szimulációk.
A kívánt statisztikai magabiztosság is szerepet játszik a megbízhatósági tesztelésben. A statisztikai megbízhatóság növelhető a tesztidő vagy a tesztelt tárgyak számának növelésével. A megbízhatósági teszttervek úgy készülnek, hogy a meghatározott megbízhatóságot a lehető legkevesebb tesztalany és tesztidő felhasználásával érjék el a kívánt szintet. Különböző teszttervek különböző kockázati szinteket eredményeznek a gyártó és a fogyasztó számára. A kívánt megbízhatósági, statisztikai megbízhatóság és kockázati szintek mindkét fél számára befolyásolják a végső teszttervet. Az ügyfélnek és a fejlesztőnek előre meg kell állapodnia a megbízhatósági követelmények tesztelésének módjáról.
A megbízhatósági tesztelés egyik kulcseleme a "hiba" meghatározása. Bár ez nyilvánvalónak tűnhet, sok helyzetben nem egyértelmű, hogy a hiba valóban a rendszer hibája-e. A tesztfeltételek változása, az üzemeltetők közötti különbségek, az időjárás és váratlan helyzetek különbségeket okozhatnak az ügyfél és a rendszer fejlesztője között. Ennek a problémának a kezelési stratégiája a pontozási konferencia folyamat alkalmazása. A pontozási konferencián az ügyfél, a fejlesztő, a tesztszervezet, a megbízhatósági szervezet képviselői és néha független megfigyelők is részt vesznek. A pontozási konferencia folyamata a munkaköri leírásban van meghatározva. Minden tesztesetet megvizsgál a csoport, és "siker" vagy "kudarc" minősítést ad. Ez a pontozás a megbízhatósági mérnök által használt hivatalos eredmény.
A követelmény részeként meghatározzák a megbízhatósági tervet az ügyféllel. Kompromisszumot kötnek a megbízhatósági szervezet szükségletei érdekében, ezek lehetnek a lehető legtöbb adat elérése, vagy korlátozhatják a költséget, ütemtervet, rendelkezésre álló erőforrásokat. Minden megbízhatósági teszthez teszttervek és eljárások készülnek, és az eredményeket dokumentálják.
A megbízhatósági tesztelés gyakori a fotonikai iparban. A lézerek megbízhatósági tesztjeire példa az élettartam-teszt és a beégetési teszt. Ezek a tesztek lézerek csoportjának erősen gyorsított öregedését jelentik ellenőrzött körülmények között. Az ezekből az élettartam-tesztből gyűjtött adatokat a lézerek várható élettartamának előrejelzésére használják a tervezett üzemeltetési jellemzők alapján.[30]
Megbízhatósági tesztkövetelmények
[szerkesztés]Számos kritérium létezik a teszteléshez, amelyek a terméktől vagy folyamattól függenek, azonban 5 gyakori szempont létezik:[31][32]
- Termék élettartama
- Szándékolt funkció
- Üzemelési feltétel
- Teljesítmény valószínűsége
- Felhasználói elvárások[33]
A termék élettartama négy különböző elemzési időszakra osztható. A hasznos élettartam a termék becsült gazdasági élettartama, amelyet úgy határoznak meg, hogy az az idő, amíg a javítási költségek nem indokolják a termék további használatát. A szavatossági élettartam az a termék, amelynek a meghatározott időn belül el kell látnia a funkcióját. A tervezési élettartam az, amikor a termék tervezése során a tervező figyelembe veszi a versenyképes termék élettartamát és a vásárlói igényeket, és biztosítja, hogy a termék ne eredményezzen elégedetlenséget a vásárlóban.[34][35]
A megbízhatósági vizsgálati követelmények bármely elemzésből következhetnek, amelyhez a meghibásodási valószínűség, meghibásodási mód vagy hatás első becslését meg kell indokolni. Bizonyítékot bizonyos szintű megbízhatósággal a teszteléssel lehet előállítani. A megbízhatósági követelmények tesztelése több okból is problémás. Egyetlen teszt a legtöbb esetben nem elegendő ahhoz, hogy elegendő statisztikai adatot generáljon. A többszörös tesztek vagy a hosszú időtartamú tesztek általában nagyon drágák. Egyes tesztek egyszerűen kivitelezhetetlenek, és a környezeti feltételeket nehéz előre jelezni a rendszerek életciklusa során.
A megbízhatósági mérnöki tervezés olyan reális és megfizethető tesztprogram megtervezésére szolgál, amely empirikus bizonyítékot szolgáltat arra, hogy a rendszer megfelel a megbízhatósági követelményeknek. A statisztikai megbízhatósági szinteket ezen aggályok némelyikének kezelésére használják. Egy bizonyos paramétert a megfelelő megbízhatósági szinttel együtt fejeznek ki: például egy 1000 órás MTBF 90%-os megbízhatósági szint mellett. Ebből a specifikációból a megbízhatósági mérnök például megtervezhet egy tesztet, amely kifejezett kritériumokkal rendelkezik a követelmény teljesüléséig vagy meghiúsulásáig eltelt órák és meghibásodások számát illetően. Különböző típusú tesztek lehetségesek.
Az előírt megbízhatósági szint és biztonsági szint kombinációja nagymértékben befolyásolja a fejlesztési költségeket és a megrendelő, gyártó kockázatát. Gondoskodni kell a követelmények legjobb kombinációjának kiválasztásáról - pl. költséghatékonyság. A megbízhatósági vizsgálatokat különböző szinteken lehet elvégezni, például komponens, alrendszer és rendszer szintjén. A tesztelés és a működés során számos tényezőt is figyelembe kell venni, például a szélsőséges hőmérséklet és páratartalom, az ütés, a rezgés vagy más környezeti tényezők (mint például a jel, a hűtés vagy az áramellátás elvesztése; vagy más katasztrófák, mint például tűz, árvíz, túlzott hő, fizikai vagy biztonsági jogsértések vagy a károsodás). Az olyan rendszerek esetében, amelyeknek sok évig kell működniük, gyorsított élettartam-tesztekre lehet szükség.
Tesztelési módszer
[szerkesztés]A megbízhatósági tesztelés rendszeres megközelítése az, hogy először meghatározzuk a megbízhatósági célt, majd olyan teszteket végezünk, amelyek összekapcsolódnak a teljesítménnyel, és meghatározzuk a termék megbízhatóságát.[36] A megbízhatósági ellenőrzés tesztjei a modern iparágakban egyértelműen meghatározzák, hogyan kapcsolódnak össze a termék általános megbízhatósági teljesítményével, és hogyan hatnak az egyes tesztek a garancia költségére és a vevői elégedettségre.[37]
Felgyorsított tesztelés
[szerkesztés]A felgyorsított élettartam tesztelés (ALT teszt) célja, hogy a laboratóriumban sokkal gyorsabb ütemben indukálja a terepi hibát egy szigorúbb, de mindazonáltal reprezentatívabb környezet biztosításával. Egy ilyen tesztben a terméktől elvárjuk, hogy a laborban ugyanúgy hibával járjon, mint a terepen – de sokkal rövidebb idő alatt. Az egyik fő célja lehet:
- Hibamódok felfedezése
- A normál terep élettartam megjóslása a magas stresszű laboratóriumi élettartamból
Egy felgyorsított tesztelési program felbontható a következő lépésekre:
- A teszt céljának és körének meghatározása
- Szükséges információk gyűjtése a termékről
- A stressz azonosítása
- A stresszszint(ek) meghatározása
- A felgyorsított teszt végrehajtása és az összegyűjtött adatok elemzése.
A stressz-élettartam kapcsolat meghatározásának általános módjai:
- Arrhenius modell
- Eyring modell
- Inverz hatványtörvény modell
- Hőmérséklet–páratartalom modell
- Hőmérséklet modellje
Rendszer megbízhatóság
[szerkesztés]A szoftver megbízhatósága a megbízhatósági tervezés egy speciális aspektusa. Olyan alapokra és technikákra összpontosít, amelyekkel a szoftverek megbízhatóbbá, azaz a hibákkal szemben ellenállóbbá tehetők. A rendszer megbízhatósága definíció szerint magában foglalja a rendszer minden részét, beleértve a hardvert, a szoftvert, a támogató infrastruktúrát (beleértve a kritikus külső interfészeket), az üzemeltetőket és az eljárásokat. A megbízhatósági tervezés hagyományosan a rendszer kritikus hardveres részeire összpontosít. A digitális integrált áramköri technológia széles körű elterjedése óta a szoftver egyre kritikusabb része lett a legtöbb elektronikai rendszernek, és így szinte minden mai rendszernek. Ezért a szoftver megbízhatósága egyre nagyobb hangsúlyt kap a rendszerek megbízhatóságának területén belül.
A szoftver és a hardver viselkedésében azonban jelentős különbségek vannak. A legtöbb hardver megbízhatatlansága egy alkatrész vagy anyaghiba következménye, amely azt eredményezi, hogy a rendszer nem teljesíti a tervezett funkcióját. A hardverkomponens javítása vagy cseréje visszaállítja a rendszer eredeti működési állapotát. A szoftver azonban nem ugyanabban az értelemben hibásodik meg, mint a hardver. Ehelyett a szoftver megbízhatatlansága a szoftverműveletek nem várt eredménye. Még viszonylag kis szoftverprogramok is rendelkezhetnek a bemenetek és állapotok nagy kombinációival, amelyek tesztelése kivitelezhetetlen. A szoftver eredeti állapotának visszaállítása csak addig működik, amíg a bemenetek és állapotok kombinációja nem vezet ugyanahhoz a nem várt eredményhez. A szoftver megbízhatósági tervezésnek ezt figyelembe kell vennie.
A szoftver és a hardver hibaforrása közötti különbség ellenére számos, statisztikán alapuló szoftvermegbízhatósági modellt javasoltak annak számszerűsítésére, amit a szoftverekkel kapcsolatban tapasztalunk: minél hosszabb ideig fut egy szoftver, annál nagyobb a valószínűsége annak, hogy végül teszteletlenül használják, és látens hibát mutat, amely hibát eredményez (Shooman 1987), (Musa 2005), (Denney 2005).
A hardverekhez hasonlóan a szoftverek megbízhatósága is a jó követelményektől, tervezéstől és megvalósítástól függ. A szoftvermegbízhatósági tervezés nagymértékben támaszkodik a fegyelmezett szoftverfejlesztési folyamatra, amely előre látja és tervezi a nem szándékolt következmények elleni védelmet. A szoftverminőség- és a szoftvermegbízhatósági tervezés között nagyobb az átfedés, mint a hardverminőség és a megbízhatóság között. A jó szoftverfejlesztési terv a szoftvermegbízhatósági program kulcsfontosságú szempontja. A szoftverfejlesztési terv leírja a szoftverfejlesztés során alkalmazandó tervezési és kódolási szabványokat, szakértői értékeléseket, egységteszteket, konfigurációkezelést, szoftvermetrikákat és szoftvermodelleket.
Egy gyakori megbízhatósági mérőszám a kódsoronkénti szoftverhibák száma (FLOC), amelyet általában ezer kódsoronkénti hibaként fejeznek ki. Ez a mérőszám a szoftver végrehajtási idejével együtt a legtöbb szoftver megbízhatósági modell és becslés kulcsa. Az elmélet szerint a szoftver megbízhatósága a hibák számának (vagy a hibasűrűségnek) a csökkenésével nő. A hibasűrűség és a meghibásodások közötti átlagos idő közötti közvetlen kapcsolat megállapítása azonban nehéz, mivel a szoftverhibák eloszlása a kódban, azok súlyossága és a hibával való találkozáshoz szükséges bemenetek kombinációjának valószínűsége miatt. Mindazonáltal a hibasűrűség hasznos mutató a megbízhatósági mérnök számára. Más szoftvermetrikákat, például a komplexitást is használnak. Ez a mérőszám továbbra is ellentmondásos, mivel a szoftverfejlesztési és ellenőrzési gyakorlatok változásai drámai hatással lehetnek az általános hibaarányra.
A szoftvertesztelés a szoftver megbízhatóságának fontos szempontja. Még a legjobb szoftverfejlesztési folyamat is eredményez olyan szoftverhibákat, amelyek a tesztelésig szinte észrevehetetlenek. A szoftvert több szinten tesztelik, kezdve az egyes egységekkel, az integráción és a teljes rendszer tesztelésén keresztül. A tesztelés minden fázisában a szoftverhibákat felfedezik, kijavítják és újra tesztelik. A megbízhatósági becsléseket a hibasűrűség és más mérőszámok alapján frissítik. Rendszerszinten a meghibásodások közötti átlagos időre vonatkozó adatok gyűjthetők és használhatók a megbízhatóság becslésére. A hardverrel ellentétben, ha pontosan ugyanazt a tesztet pontosan ugyanazon a szoftverkonfiguráción végezzük el, az nem nyújt nagyobb statisztikai megbízhatóságot. Ehelyett a szoftver megbízhatósága más mérőszámokat használ, például a kódlefedettséget.
A Software Engineering Institute képességi érettségi modellje a szoftverfejlesztési folyamat megbízhatósági és minőségi célú értékelésének általános eszköze.
Szerkezeti megbízhatóság
[szerkesztés]A szerkezeti megbízhatóság vagy a szerkezetek megbízhatósága a megbízhatósági elmélet alkalmazása a szerkezetek viselkedésére. A különböző típusú szerkezetek, köztük beton- és acélszerkezetek tervezésénél és karbantartásánál egyaránt alkalmazzák.[38][39] A szerkezeti megbízhatósági vizsgálatokban mind a terhelések, mind az ellenállások valószínűségi változóként modellezhetők. Ezzel a megközelítéssel számítják ki egy szerkezet meghibásodásának valószínűségét.
Összehasonlítás a biztonságtechnikával
[szerkesztés]A biztonságot szolgáló megbízhatóság és a rendelkezésre állást szolgáló megbízhatóság gyakran szorosan összefügg. Egy mérnöki rendszer elveszett rendelkezésre állása pénzbe kerülhet. Ha egy metrórendszer nem áll rendelkezésre, a metróüzemeltető minden egyes órában, amikor a rendszer nem működik, pénzt veszít. A metróüzemeltető még több pénzt veszít, ha a biztonság sérül. A megbízhatóság meghatározása a meghibásodás elkerülésének valószínűségéhez kötődik. A meghibásodás okozhatja a biztonság, a rendelkezésre állás vagy mindkettő elvesztését. Egy kritikus rendszerben nem kívánatos a biztonság vagy a rendelkezésre állás elvesztése.
A megbízhatósági tervezés azon meghibásodások általános minimalizálásával foglalkozik, amelyek a felelős szervezet számára pénzügyi veszteségeket okozhatnak, míg a biztonságtechnika azon meghibásodások egy meghatározott csoportjának minimalizálására összpontosít, amelyek általában véve életek elvesztéséhez, sérülésekhez vagy a berendezések károsodásához vezethetnek.
A megbízhatósági veszélyek olyan eseményekké alakulhatnak át, amelyek a vállalat vagy az ügyfél számára bevételkiesést eredményeznek, például a következő közvetlen és közvetett költségek miatt: a rendszer nem rendelkezésre állása miatti termeléskiesés; a tartalék alkatrészek iránti váratlanul magas vagy alacsony igény; javítási költségek; munkaórák; újratervezés vagy a normál termelés megszakítása.[40]
A biztonságtechnika gyakran nagyon specifikus, és csak bizonyos szigorúan szabályozott iparágakra, alkalmazásokra vagy területekre vonatkozik. Elsősorban azokra a rendszerbiztonsági veszélyekre összpontosít, amelyek súlyos balesetekhez vezethetnek, beleértve a következőket: életek elvesztése; berendezések megsemmisülése; vagy környezeti károk. Ennek megfelelően a kapcsolódó rendszer funkcionális megbízhatósági követelményei gyakran rendkívül magasak. Bár a megbízhatósági tervezéssel azonos értelemben foglalkozik a nem kívánt meghibásodásokkal, azonban kevésbé összpontosít a közvetlen költségekre, és nem foglalkozik a meghibásodás utáni javítási intézkedésekkel. Egy másik különbség a meghibásodások társadalomra gyakorolt hatásának mértéke, ami a kormányok vagy szabályozó szervek szigorú ellenőrzésére való hajlamot eredményez (pl. nukleáris, repülőgépipar, védelmi, vasúti és olajipar).[40]
Hibatűrés
[szerkesztés]A biztonság növelhető 2oo2 keresztellenőrzött redundáns rendszerrel. A rendelkezésre állás növelhető „1oo2” (1-ből 2) redundancia alkalmazásával alkatrész- vagy rendszerszinten. Ha mindkét redundáns elem nem felel meg, akkor a megengedőbb elem maximalizálja a rendelkezésre állást. Az 1oo2 rendszerre soha nem szabad támaszkodni a biztonság szempontjából. A hibatűrő rendszerek gyakran támaszkodnak további redundanciára (pl. 2oo3 szavazási logika), ahol több redundáns elemnek kell megállapodnia egy potenciálisan nem biztonságos műveletről, mielőtt az végrehajtásra kerülne. Ez rendszerszinten növeli mind a rendelkezésre állást, mind a biztonságot. Ez általános gyakorlat a folyamatos rendelkezésre állást igénylő, hibabiztos üzemmóddal nem rendelkező űrhajózási rendszerekben. A repülőgépek például háromszoros moduláris redundanciát alkalmazhatnak a fedélzeti számítógépek és a vezérlőfelületek (beleértve esetenként különböző üzemmódokat, pl. elektromos/mechanikus/hidraulikus) esetében, mivel ezeknek mindig működőképesnek kell lenniük, mivel a repülőgép repülése közben nincsenek „biztonságos” alaphelyzetek az olyan vezérlőfelületek számára, mint a kormánylapátok vagy a kormánylapátok.
Alapvető megbízhatóság és a küldetés megbízhatósága
[szerkesztés]A fenti példa egy 2oo3 hibatűrő rendszerre növeli mind a küldetés megbízhatóságát, mind a biztonságot. A rendszer „alapvető” megbízhatósága azonban ebben az esetben is alacsonyabb lesz, mint egy nem redundáns (1oo1) vagy 2oo2 rendszeré. Az alapvető megbízhatósági mérnöki tervezés minden hibára kiterjed, beleértve azokat is, amelyek nem feltétlenül vezetnek a rendszer meghibásodásához, de többletköltséget okoznak a következők miatt: karbantartási javítási műveletek; logisztika; pótalkatrészek stb. Például egy 2oo3 szavazórendszer 1 hibás csatornájának cseréje vagy javítása (a rendszer még működik, bár egy hibás csatornával valójában 2oo2 rendszerré vált) hozzájárul az alapvető megbízhatatlansághoz, de nem a küldetés megbízhatatlanságához. Példaként: egy repülőgép hátsó lámpájának meghibásodása nem akadályozza meg a repülőgép repülését (és így nem tekinthető küldetéshibának), de meg kell javítani (amihez kapcsolódó költségekkel jár, és így hozzájárul az alapvető megbízhatatlansági szintekhez).
Felismerhetőség és közös okú meghibásodások
[szerkesztés]Hibatűrő (redundáns) rendszerek vagy védelmi funkciókkal felszerelt rendszerek alkalmazása esetén a hibák észlelhetősége és a közös okból bekövetkező hibák elkerülése kiemelkedő fontosságúvá válik a biztonságos működés és/vagy a küldetés megbízhatósága szempontjából.
Megbízhatóság kontra minőség (Six Sigma)
[szerkesztés]A minőség gyakran a gyártási hibákra összpontosít a garanciális fázisban. A megbízhatóság a termék vagy a műszaki rendszer teljes élettartama során a hibák intenzitását vizsgálja az üzembe helyezéstől a leszerelésig. A Hat Szigma a gyártás minőségének statisztikai ellenőrzésében gyökerezik. A megbízhatósági tervezés a rendszertechnika speciális része. A rendszertechnikai folyamat egy felfedező folyamat, amely gyakran eltér a gyártási folyamattól. Egy gyártási folyamat gyakran olyan ismétlődő tevékenységekre összpontosít, amelyek minimális költséggel és idővel magas minőségű kimenetet érnek el.[41]
A hétköznapi szóhasználatban a „termék minősége” kifejezés laza értelemben a termékben rejlő kiválósági fokot jelenti. Az iparban a minőség pontosabb meghatározását használják: „a követelményeknek vagy előírásoknak való megfelelés a használat kezdetén”. Feltételezve, hogy a végső termékleírás megfelelően rögzíti az eredeti követelményeket és a vevői/rendszeri igényeket, a minőségi szint a specifikációknak megfelelő szállított termékegységek hányadaként mérhető.[42] A gyártott termékek minősége gyakran a jótállási időszak alatt felmerülő garanciális igények számával foglalkozik.
A minőség egy pillanatfelvétel az életciklus kezdetétől a garanciális időszakon keresztül, és az alacsonyabb szintű termékleírások ellenőrzéséhez kapcsolódik. Ide tartoznak az időnullás hibák is, azaz amikor a gyártási hibák elkerülik a végső minőségellenőrzést. Elméletileg a minőségi szintet a hibás termékek egyetlen frakciójával lehet leírni. A megbízhatóság, mint a rendszertechnika része, inkább a meghibásodási arányok több éven át tartó folyamatos értékelését jelenti. Elméletileg minden elem végtelen hosszú idő alatt meghibásodik.[43] Az idővel megjelenő hibákat megbízhatósági kiesésnek nevezzük. A megbízhatósági kiesés leírásához olyan valószínűségi modellre van szükség, amely leírja a töredék kiesést az idő múlásával. Ez az úgynevezett élettartam-eloszlási modell.[42] A megbízhatósági problémák egy része eredendő tervezési problémákból adódhat, amelyek akkor is fennállhatnak, ha a termék megfelel a specifikációknak. Még a tökéletesen gyártott elemek is meghibásodnak idővel egy vagy több meghibásodási mechanizmus miatt (pl. emberi hiba vagy mechanikai, elektromos és kémiai tényezők miatt). Ezeket a megbízhatósági problémákat a kezdeti gyártás során előforduló elfogadható szintű eltérések is befolyásolhatják.
A minőség és a megbízhatóság tehát összefügg a gyártással. A megbízhatóság inkább az olyan ügyfelekre irányul, akik a termék teljes élettartama során fellépő meghibásodásokra összpontosítanak, mint például a hadsereg, a légitársaságok vagy a vasutak. A termékleírásnak nem megfelelő termékek általában rosszabbul teljesítenek a megbízhatóság szempontjából (alacsonyabb MTTF-jük van), de ez nem mindig kell, hogy így legyen. Ennek a kombinált kapcsolatnak a teljes matematikai számszerűsítése (statisztikai modellekben) általában nagyon nehéz, sőt gyakorlatilag lehetetlen. Azokban az esetekben, amikor a gyártási varianciák hatékonyan csökkenthetők, a hat szigma eszközei hasznosnak bizonyultak a minőséget és a megbízhatóságot növelő optimális folyamatmegoldások megtalálásában. A hat szigma segíthet olyan termékek tervezésében is, amelyek ellenállóbbak a gyártás okozta hibákkal és a mérnöki rendszerek és a gyártott termék csecsemőhalálozási hibáival szemben.
A Hat Szigmával ellentétben a megbízhatósági mérnöki megoldásokat általában a megbízhatósági vizsgálatokra és a rendszertervezésre összpontosítva találják meg. A megoldások különböző módon találhatók meg, például a rendszer egyszerűsítésével, hogy jobban meg lehessen érteni az érintett meghibásodási mechanizmusokat; az anyagterhelési szintek részletes számításával, amely lehetővé teszi a megfelelő biztonsági tényezők meghatározását; a lehetséges rendellenes rendszerterhelési feltételek feltárásával és ennek felhasználásával a tervezés robusztusságának növelésével a gyártási eltérésekkel kapcsolatos meghibásodási mechanizmusokkal szemben. A megbízhatósági tervezés továbbá rendszerszintű megoldásokat alkalmaz, például redundáns és hibatűrő rendszerek tervezését a nagy rendelkezésre állási igényű helyzetekben (lásd a fenti Megbízhatósági tervezés vs. Biztonságtechnikai tervezés című részt).
Megjegyzés: A „hiba” a hat szigma/minőségi szakirodalomban nem azonos a „meghibásodással” (Field failure | pl. törött elem) a megbízhatóságban. A hat-szigma/minőségi hiba általában egy követelménynek (pl. alapvető funkcionalitás vagy egy kulcsfontosságú dimenzió) való meg nem felelésre utal. A tételek azonban idővel akkor is meghibásodhatnak, ha ezek a követelmények mind teljesülnek. A minőség általában nem foglalkozik azzal a döntő kérdéssel, hogy „a követelmények valóban helyesek-e?”, míg a megbízhatóság igen.
Megbízhatósági működési értékelés
[szerkesztés]A rendszerek vagy alkatrészek gyártása után a megbízhatósági mérnökség megpróbálja nyomon követni, értékelni és kijavítani a hiányosságokat. A felügyelet magában foglalja a hibafaelemzés tervezési szakaszában azonosított kritikus paraméterek elektronikus és vizuális felügyeletét. Az adatgyűjtés nagymértékben függ a rendszer jellegétől. A legtöbb nagy szervezetnek vannak minőségellenőrző csoportjai, amelyek a járművek, berendezések és gépek meghibásodási adatait gyűjtik. A fogyasztói termékek meghibásodását gyakran a visszavételek száma alapján követik nyomon. A nyugalmi állapotban lévő vagy készenléti állapotban lévő rendszerek esetében hivatalos felügyeleti programot kell létrehozni a szúrópróbaszerűen vett minták ellenőrzésére és tesztelésére. A rendszer bármilyen módosítása, például helyszíni frissítések vagy visszahívásos javítások esetén további megbízhatósági vizsgálatokra van szükség a módosítás megbízhatóságának biztosítása érdekében. Mivel nem lehet előre látni egy adott rendszer összes hibamódját, különösen az emberi tényezőt tartalmazó rendszerek esetében, előfordulnak hibák. A megbízhatósági program magában foglal egy szisztematikus gyökér okelemzést is, amely azonosítja a meghibásodásban szerepet játszó ok-okozati összefüggéseket, hogy hatékony korrekciós intézkedéseket lehessen végrehajtani. Ha lehetséges, a rendszerhibákat és a korrekciós intézkedéseket jelentik a megbízhatósági mérnöki szervezetnek.
A megbízhatósági operatív értékelésben alkalmazható leggyakoribb módszerek közül néhány a hibabejelentő, -elemző és -javító intézkedési rendszerek (FRACAS). Ez a szisztematikus megközelítés a megbízhatósági, biztonsági és logisztikai értékelést a hibák/események jelentése, kezelése, elemzése és a javító/megelőző intézkedések alapján alakítja ki. A szervezetek manapság elfogadják ezt a módszert, és olyan kereskedelmi rendszereket (például webalapú FRACAS-alkalmazásokat) használnak, amelyek lehetővé teszik számukra, hogy hiba-/eseményadattárat hozzanak létre, amelyből statisztikákat lehet levezetni a pontos és valódi megbízhatósági, biztonsági és minőségi mérőszámok megtekintéséhez.
Rendkívül fontos, hogy egy szervezet az összes végtermékre vonatkozóan közös FRACAS-rendszert alkalmazzon. Emellett lehetővé kell tennie a teszteredmények gyakorlatias módon történő rögzítését. Ha nem fogadnak el egy könnyen használható (a terepen dolgozó mérnökök és a javítóműhelyek mérnökei számára az adatbevitel megkönnyítése szempontjából) és könnyen karbantartható integrált rendszert, az valószínűleg magának a FRACAS-programnak a kudarcához vezet.
A FRACAS-rendszer néhány gyakori kimenete a következők: a terepi MTBF, MTTR, tartalék alkatrészfogyasztás, megbízhatóság növekedése, meghibásodások/események megoszlása típus, hely, alkatrészszám, sorozatszám és tünet szerint.
A múltbeli adatok felhasználása az új, összehasonlítható rendszerek/elemek megbízhatóságának előrejelzésére félrevezető lehet, mivel a megbízhatóság a felhasználási környezet függvénye, és a tervezésben/gyártásban bekövetkező apró változások befolyásolhatják.
Megbízhatósági szervezetek
[szerkesztés]Bármilyen jelentős összetettségű rendszert emberekből álló szervezetek fejlesztenek, például egy kereskedelmi vállalat vagy egy kormányzati ügynökség. A megbízhatósági mérnöki szervezetnek összhangban kell lennie a vállalat szervezeti felépítésével. Kisebb, nem kritikus rendszerek esetében a megbízhatósági tervezés informális lehet. A bonyolultság növekedésével egyre inkább szükségessé válik egy formális megbízhatósági funkció. Mivel a megbízhatóság fontos a megrendelő számára, a megrendelő akár meg is határozhatja a megbízhatósági szervezet bizonyos szempontjait.
A megbízhatósági szervezeteknek több gyakori típusa létezik. A projektvezető vagy a főmérnök közvetlenül alkalmazhat egy vagy több megbízhatósági mérnököt. A nagyobb szervezetekben általában van egy termékbiztosítási vagy speciális mérnöki szervezet, amely magában foglalhatja a megbízhatóságot, a karbantarthatóságot, a minőséget, a biztonságot, az emberi tényezőket, a logisztikát, stb. Ilyen esetben a megbízhatósági mérnök a termékbiztosítási vezetőnek vagy a speciális mérnöki vezetőnek jelent.
Bizonyos esetekben a vállalat független megbízhatósági szervezetet kíván létrehozni. Ez azért kívánatos, hogy a gyakran költséges és időigényes rendszer megbízhatósága ne szenvedjen indokolatlanul csorbát a költségvetés és az ütemterv nyomása miatt. Ilyen esetekben a megbízhatósági mérnök nap mint nap a projektnek dolgozik, de valójában a vállalaton belül egy külön szervezet alkalmazza és fizeti.
Mivel a megbízhatósági mérnöki munka kritikus fontosságú a korai rendszertervezés szempontjából, a megbízhatósági mérnökök számára - bárhogyan is épül fel a szervezet - általánossá vált, hogy egy integrált termékcsapat részeként dolgoznak.
Oktatás
[szerkesztés]Egyes egyetemek megbízhatósági mérnöki diplomát kínálnak. Más megbízhatósági szakemberek jellemzően egyetemi vagy főiskolai programban szerzett fizikai diplomával rendelkeznek. Számos mérnöki program kínál megbízhatósági kurzusokat, és egyes egyetemek teljes megbízhatósági mérnöki programmal rendelkeznek. A megbízhatósági mérnöknek az állam vagy a tartomány törvénye szerint hivatásos mérnökként kell bejegyeztetnie magát, de nem minden megbízhatósági szakember mérnök. Megbízhatósági mérnökökre olyan rendszerekben van szükség, ahol a közbiztonságot veszélyezteti. A megbízhatósági mérnökök számára számos szakmai konferencia és ipari képzési program áll rendelkezésre. A megbízhatósági mérnökök számára több szakmai szervezet is létezik, köztük az American Society for Quality Reliability Division (ASQ-RD),[44] az IEEE Reliability Society, az American Society for Quality (ASQ)[45] és a Society of Reliability Engineers (SRE).[46]
Lásd még
[szerkesztés]Jegyzetek
[szerkesztés]- ↑ Institute of Electrical and Electronics Engineers (1990) IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York, NY ISBN 1-55937-079-3
- ↑ RCM II, Reliability Centered Maintenance, Second edition 2008, pages 250–260, the role of Actuarial analysis in Reliability
- ↑ „Why You Cannot Predict Electronic Product Reliability”. 2012 ARS, Europe.
- ↑ a b O'Connor, Patrick D. T. (2002), Practical Reliability Engineering (Fourth Ed.), John Wiley & Sons, New York. ISBN 978-0-4708-4462-5.
- ↑ Aven, Terje (2017. június 1.). „Improving the foundation and practice of reliability engineering” (angol nyelven). Proceedings of the Institution of Mechanical Engineers, Part O: Journal of Risk and Reliability 231 (3), 295–305. o. DOI:10.1177/1748006X17699478. ISSN 1748-006X.
- ↑ Saleh, J.H. and Marais, Ken, "Highlights from the Early (and pre-) History of Reliability Engineering", Reliability Engineering and System Safety, Volume 91, Issue 2, February 2006, pages 249–256
- ↑ Juran, Joseph and Gryna, Frank, Quality Control Handbook, Fourth Edition, McGraw-Hill, New York, 1988, p.24.3
- ↑ Reliability of military electronic equipment;report.. Washington: United States Department of Defense (1957. június 4.)
- ↑ Wong, Kam, "Unified Field (Failure) Theory-Demise of the Bathtub Curve", Proceedings of Annual RAMS, 1981, pp 402–408
- ↑ a b (2013. március 1.) „Exploration on process design, optimization and reliability verification for natural gas deacidizing column applied to offshore field” (angol nyelven). Chemical Engineering Research and Design 91 (3), 542–551. o. DOI:10.1016/j.cherd.2012.09.018. ISSN 0263-8762.
- ↑ Practical Reliability Engineering, P. O'Conner – 2012
- ↑ Articles – Where Do Reliability Engineers Come From? – ReliabilityWeb.com: A Culture of Reliability
- ↑ Using Failure Modes, Mechanisms, and Effects Analysis in Medical Device Adverse Event Investigations, S. Cheng, D. Das, and M. Pecht, ICBO: International Conference on Biomedical Ontology, Buffalo, NY, July 26–30, 2011, pp. 340–345
- ↑ Federal Aviation Administration. System Safety Handbook. U.S. Department of Transportation (2013. március 19.)
- ↑ Reliability Hotwire – July 2015
- ↑ Reliability Maintainability and Risk Practical Methods for Engineers Including Reliability Centred Maintenance and Safety – David J. Smith (2011)
- ↑ System Reliability Theory, second edition, Rausand and Hoyland – 2004
- ↑ The Blame Machine, Why Human Error Causes Accidents – Whittingham, 2007
- ↑ Barnard, R.W.A.: What is wrong with Reliability Engineering?. Lambda Consulting, 2008 (Hozzáférés: 2014. október 30.)
- ↑ http://www.dfrsolutions.com/hubfs/DfR_Solutions_Website/Resources-Archived/Presentations/2016/Design-for-Reliability-Best-Practices.pdf?t=1505335343846 Sablon:Bare URL PDF
- ↑ Salvatore Distefano, Antonio Puliafito: Dependability Evaluation with Dynamic Reliability Block Diagrams and Dynamic Fault Trees. IEEE Trans. Dependable Sec. Comput. 6(1): 4–17 (2009)
- ↑ The Seven Samurais of Systems Engineering, James Martin (2008) Archiválva 2023. december 1-i dátummal a Wayback Machine-ben
- ↑ Practical Reliability Engineering, O'Conner, 2001
- ↑ A system approach to reliability verification test design, 2016 Annual Reliability and Maintainability Symposium (RAMS), 1–6. o.. DOI: 10.1109/RAMS.2016.7448014 (2016. január 1.). ISBN 978-1-5090-0249-8
- ↑ (2015. január 2.) „Reliability modelling and verification of manufacturing processes based on process knowledge management”. International Journal of Computer Integrated Manufacturing 28 (1), 98–111. o. DOI:10.1080/0951192X.2013.834462. ISSN 0951-192X.
- ↑ Reliability Verification for AI and ML Processors - White Paper (angol nyelven). www.allaboutcircuits.com . (Hozzáférés: 2020. december 11.)
- ↑ (2005. július 1.) „Enhancing software safety by fault trees: experiences from an application to flight critical software” (angol nyelven). Reliability Engineering & System Safety 89 (1), 57–70. o. DOI:10.1016/j.ress.2004.08.007. ISSN 0951-8320.
- ↑ (2020. január 1.) „Design of a Large-Scale Piezoelectric Transducer Network Layer and Its Reliability Verification for Space Structures” (angol nyelven). Sensors 20 (15), 4344. o. DOI:10.3390/s20154344. PMID 32759794. PMC 7435873.
- ↑ Ben-Gal I., Herer Y. and Raz T. (2003). „Self-correcting inspection procedure under inspection errors”, Kiadó: IIE Transactions on Quality and Reliability, 34(6), pp. 529–540.. [2013. október 13-i dátummal az eredetiből archiválva]. (Hozzáférés: 2024. június 5.)
- ↑ Yelo Reliability Testing. (Hozzáférés: 2014. november 6.)
- ↑ Matheson, Granville J. (2019. május 24.). „We need to talk about reliability: making better use of test-retest studies for study design and interpretation”. PeerJ 7, e6918. o. DOI:10.7717/peerj.6918. ISSN 2167-8359. PMID 31179173. PMC 6536112.
- ↑ Pronskikh, Vitaly (2019. március 1.). „Computer Modeling and Simulation: Increasing Reliability by Disentangling Verification and Validation” (angol nyelven). Minds and Machines 29 (1), 169–186. o. DOI:10.1007/s11023-019-09494-7. ISSN 1572-8641.
- ↑ (2019. december 7.) „Hardware Testing of Electric Hot Water Heaters Providing Energy Storage and Demand Response Through Model Predictive Control”. IEEE Access 7, 139047–139057. o. DOI:10.1109/ACCESS.2019.2932978. ISSN 2169-3536.
- ↑ (2019. február 19.) „A metamorphic testing approach for event sequences” (angol nyelven). PLOS ONE 14 (2), e0212476. o. DOI:10.1371/journal.pone.0212476. ISSN 1932-6203. PMID 30779769. PMC 6380623.
- ↑ (2020. január 1.) „Organizational Reliability Model Verification in the Crisis Escalation Phase Caused by the COVID-19 Pandemic” (angol nyelven). Sustainability 12 (10), 4318. o. DOI:10.3390/su12104318.
- ↑ Towards Multidimensional Verification: Where Functional Meets Non-Functional, 2018 IEEE Nordic Circuits and Systems Conference (NORCAS): NORCHIP and International Symposium of System-on-Chip (SoC), 1–7. o.. DOI: 10.1109/NORCHIP.2018.8573495 (2018. október 1.). ISBN 978-1-5386-7656-1
- ↑ Rackwitz, R. (2000. február 21.). „Optimization — the basis of code-making and reliability verification” (angol nyelven). Structural Safety 22 (1), 27–60. o. DOI:10.1016/S0167-4730(99)00037-5. ISSN 0167-4730.
- ↑ (2017. január 9.) „A mathematical programming model for solving cost-safety optimization (CSO) problems in the maintenance of structures”. KSCE Journal of Civil Engineering 21 (6), 2226–2234. o. DOI:10.1007/s12205-017-0531-z.
- ↑ Okasha, N. M., & Frangopol, D. M. (2009). Lifetime-oriented multi-objective optimization of structural maintenance considering system reliability, redundancy and life-cycle cost using GA. Structural Safety, 31(6), 460–474.
- ↑ a b Reliability and Safety Engineering – Verma, Ajit Kumar, Ajit, Srividya, Karanki, Durga Rao (2010)
- ↑ INCOSE SE Guidelines
- ↑ 8.1.1.1. Quality versus reliability
- ↑ The Second Law of Thermodynamics, Evolution, and Probability
- ↑ American Society for Quality Reliability Division (ASQ-RD)
- ↑ American Society for Quality (ASQ)
- ↑ Society of Reliability Engineers (SRE)
- N. Diaz, R. Pascual, F. Ruggeri, E. López Droguett (2017). „Modeling age replacement policy under multiple time scales and stochastic usage profiles”. International Journal of Production Economics 188, 22–28. o. DOI:10.1016/j.ijpe.2017.03.009.
További olvasmányok
[szerkesztés]- Barlow, R. E. and Proscan, F. (1981) Statistical Theory of Reliability and Life Testing, To Begin With Press, Silver Springs, MD.
- Blanchard, Benjamin S. (1992), Logistics Engineering and Management (Fourth Ed.), Prentice-Hall, Inc., Englewood Cliffs, New Jersey.
- Breitler, Alan L. and Sloan, C. (2005), Proceedings of the American Institute of Aeronautics and Astronautics (AIAA) Air Force T&E Days Conference, Nashville, TN, December, 2005: System Reliability Prediction: towards a General Approach Using a Neural Network.
- Ebeling, Charles E., (1997), An Introduction to Reliability and Maintainability Engineering, McGraw-Hill Companies, Inc., Boston.
- Denney, Richard (2005) Succeeding with Use Cases: Working Smart to Deliver Quality. Addison-Wesley Professional Publishing. ISBN. Discusses the use of software reliability engineering in use case driven software development.
- Gano, Dean L. (2007), "Apollo Root Cause Analysis" (Third Edition), Apollonian Publications, LLC., Richland, Washington
- Holmes, Oliver Wendell Sr. The Deacon's Masterpiece
- Horsburgh, Peter (2018), "5 Habits of an Extraordinary Reliability Engineer", Reliability Web
- Kapur, K.C., and Lamberson, L.R., (1977), Reliability in Engineering Design, John Wiley & Sons, New York.
- Kececioglu, Dimitri, (1991) "Reliability Engineering Handbook", Prentice-Hall, Englewood Cliffs, New Jersey
- Trevor Kletz (1998) Process Plants: A Handbook for Inherently Safer Design CRC ISBN 1-56032-619-0
- Leemis, Lawrence, (1995) Reliability: Probabilistic Models and Statistical Methods, 1995, Prentice-Hall. ISBN 0-13-720517-1
- Lees, Frank. Loss Prevention in the Process Industries, 3rd, Elsevier (2005). ISBN 978-0-7506-7555-0
- MacDiarmid, Preston; Morris, Seymour; et al., (1995), Reliability Toolkit: Commercial Practices Edition, Reliability Analysis Center and Rome Laboratory, Rome, New York.
- Modarres, Mohammad; Kaminskiy, Mark; Krivtsov, Vasiliy (1999), Reliability Engineering and Risk Analysis: A Practical Guide, CRC Press, ISBN 0-8247-2000-8.
- Musa, John (2005) Software Reliability Engineering: More Reliable Software Faster and Cheaper, 2nd. Edition, AuthorHouse. ISBN
- Neubeck, Ken (2004) "Practical Reliability Analysis", Prentice Hall, New Jersey
- Neufelder, Ann Marie, (1993), Ensuring Software Reliability, Marcel Dekker, Inc., New York.
- O'Connor, Patrick D. T. (2002), Practical Reliability Engineering (Fourth Ed.), John Wiley & Sons, New York. ISBN 978-0-4708-4462-5.
- Samaniego, Francisco J. (2007) "System Signatures and their Applications in Engineering Reliability", Springer (International Series in Operations Research and Management Science), New York.
- Shooman, Martin, (1987), Software Engineering: Design, Reliability, and Management, McGraw-Hill, New York.
- Tobias, Trindade, (1995), Applied Reliability, Chapman & Hall/CRC, ISBN 0-442-00469-9
- Springer Series in Reliability Engineering
- Nelson, Wayne B., (2004), Accelerated Testing—Statistical Models, Test Plans, and Data Analysis, John Wiley & Sons, New York, ISBN 0-471-69736-2
- Bagdonavicius, V., Nikulin, M., (2002), "Accelerated Life Models. Modeling and Statistical analysis", CHAPMAN&HALL/CRC, Boca Raton, ISBN 1-58488-186-0
- Todinov, M. (2016), "Reliability and Risk Models: setting reliability requirements", Wiley, 978-1-118-87332-8.
Amerikai szabványok, specifikációk és kézikönyvek
[szerkesztés]- Aerospace Report Number: TOR-2007(8583)-6889 Reliability Program Requirements for Space Systems, The Aerospace Corporation (10 July 2007)
- DoD 3235.1-H (3rd Ed) Test and Evaluation of System Reliability, Availability, and Maintainability (A Primer), U.S. Department of Defense (March 1982).
- NASA GSFC 431-REF-000370 Flight Assurance Procedure: Performing a Failure Mode and Effects Analysis, National Aeronautics and Space Administration Goddard Space Flight Center (10 August 1996).
- IEEE 1332–1998 IEEE Standard Reliability Program for the Development and Production of Electronic Systems and Equipment, Institute of Electrical and Electronics Engineers (1998).
- JPL D-5703 Reliability Analysis Handbook, National Aeronautics and Space Administration Jet Propulsion Laboratory (July 1990).
- MIL-STD-785B Reliability Program for Systems and Equipment Development and Production, U.S. Department of Defense (15 September 1980). (*Obsolete, superseded by ANSI/GEIA-STD-0009-2008 titled Reliability Program Standard for Systems Design, Development, and Manufacturing, 13 Nov 2008)
- MIL-HDBK-217F Reliability Prediction of Electronic Equipment, U.S. Department of Defense (2 December 1991).
- MIL-HDBK-217F (Notice 1) Reliability Prediction of Electronic Equipment, U.S. Department of Defense (10 July 1992).
- MIL-HDBK-217F (Notice 2) Reliability Prediction of Electronic Equipment, U.S. Department of Defense (28 February 1995).
- MIL-STD-690D Failure Rate Sampling Plans and Procedures, U.S. Department of Defense (10 June 2005).
- MIL-HDBK-338B Electronic Reliability Design Handbook, U.S. Department of Defense (1 October 1998).
- MIL-HDBK-2173 Reliability-Centered Maintenance (RCM) Requirements for Naval Aircraft, Weapon Systems, and Support Equipment, U.S. Department of Defense (30 January 1998); (superseded by NAVAIR 00-25-403).
- MIL-STD-1543B Reliability Program Requirements for Space and Launch Vehicles, U.S. Department of Defense (25 October 1988).
- MIL-STD-1629A Procedures for Performing a Failure Mode Effects and Criticality Analysis, U.S. Department of Defense (24 November 1980).
- MIL-HDBK-781A Reliability Test Methods, Plans, and Environments for Engineering Development, Qualification, and Production, U.S. Department of Defense (1 April 1996).
- NSWC-06 (Part A & B) Handbook of Reliability Prediction Procedures for Mechanical Equipment, Naval Surface Warfare Center (10 January 2006).
- SR-332 Reliability Prediction Procedure for Electronic Equipment, Telcordia Technologies (January 2011).
- FD-ARPP-01 Automated Reliability Prediction Procedure, Telcordia Technologies (January 2011).
- GR-357 Generic Requirements for Assuring the Reliability of Components Used in Telecommunications Equipment, Telcordia Technologies (March 2001).
- http://standards.sae.org/ja1000/1_199903/ SAE JA1000/1 Reliability Program Standard Implementation Guide
Brit szabványok
[szerkesztés]Az Egyesült Királyságban naprakészebb szabványok vannak érvényben. A releváns szabványok a következők:
DEF STAN 00-40 Reliability and Maintainability (R&M)
- PART 1: Issue 5: Management Responsibilities and Requirements for Programmes and Plans
- PART 4: (ARMP-4)Issue 2: Guidance for Writing NATO R&M Requirements Documents
- PART 6: Issue 1: IN-SERVICE R & M
- PART 7 (ARMP-7) Issue 1: NATO R&M Terminology Applicable to ARMP's
DEF STAN 00-42 RELIABILITY AND MAINTAINABILITY ASSURANCE GUIDES
- PART 1: Issue 1: ONE-SHOT DEVICES/SYSTEMS
- PART 2: Issue 1: SOFTWARE
- PART 3: Issue 2: R&M CASE
- PART 4: Issue 1: Testability
- PART 5: Issue 1: IN-SERVICE RELIABILITY DEMONSTRATIONS
DEF STAN 00-43 RELIABILITY AND MAINTAINABILITY ASSURANCE ACTIVITY
- PART 2: Issue 1: IN-SERVICE MAINTAINABILITY DEMONSTRATIONS
DEF STAN 00-44 RELIABILITY AND MAINTAINABILITY DATA COLLECTION AND CLASSIFICATION
- PART 1: Issue 2: MAINTENANCE DATA & DEFECT REPORTING IN THE ROYAL NAVY, THE ARMY AND THE ROYAL AIR FORCE
- PART 2: Issue 1: DATA CLASSIFICATION AND INCIDENT SENTENCING—GENERAL
- PART 3: Issue 1: INCIDENT SENTENCING—SEA
- PART 4: Issue 1: INCIDENT SENTENCING—LAND
DEF STAN 00-45 Issue 1: RELIABILITY CENTERED MAINTENANCE
DEF STAN 00-49 Issue 1: RELIABILITY AND MAINTAINABILITY MOD GUIDE TO TERMINOLOGY DEFINITIONS
Ezek innen érhetők el: DSTAN. Számos kereskedelmi szabvány is létezik, amelyeket számos szervezet, többek között az SAE, az MSG, az ARP és az IEE állított össze.
Francia szabványok
[szerkesztés]- FIDES [1]. The FIDES methodology (UTE-C 80-811) is based on the physics of failures and supported by the analysis of test data, field returns and existing modelling.
- UTE-C 80–810 or RDF2000 [2]. The RDF2000 methodology is based on the French telecom experience.
Nemzetközi szabványok
[szerkesztés]Kiegészítő linkek
[szerkesztés]- John P. Rankin Collection, The University of Alabama in Huntsville Archives and Special Collections NASA reliability engineering research on sneak circuits.
Fordítás
[szerkesztés]Ez a szócikk részben vagy egészben a Reliability engineering című angol Wikipédia-szócikk ezen változatának fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.