Öt megbízhatósági technika az ipari hibatűrés elemzéséhez

Miért van szükség a hibatűréshez többre a redundáns hardvernél

Minden ipari rendszerben előbb-utóbb meghibásodások következnek be. Az érzékelők elállítódnak, a tápegységek leromlanak, a kommunikációs kapcsolatok instabillá válnak, a mechanikus komponensek pedig ismételt terhelés hatására elhasználódnak. A hibatűrő tervezés célja ezért nem olyan berendezések létrehozása, amelyek soha nem hibásodhatnak meg. A cél annak biztosítása, hogy az előre jelezhető hibák ne váljanak azonnal irányítatlan rendszermeghibásodásokká.

Egy hibatűrő rendszer akkor is képes elfogadható funkciót nyújtani, ha egy vagy több komponens elérhetetlenné válik. Egyes alkalmazásokban a rendszernek fenn kell tartania a teljes termelést. Más esetekben elfogadható a csökkentett kapacitás mindaddig, amíg a karbantartás helyre nem állítja a meghibásodott csatornát. A biztonságkritikus rendszerek ehelyett szabályozott biztonságos állapotba léphetnek, ha a folyamatos működés elfogadhatatlan kockázatot teremtene.

A redundáns komponensek gyakran részét képezik ennek a stratégiának, de a puszta megkettőzés önmagában nem bizonyítja a hibatűrést. Két vezérlő továbbra is függhet egyetlen tápegységtől, egyetlen hálózati kapcsolótól vagy egyetlen szoftverkonfigurációtól. Két távadó ugyanahhoz a nyomásérzékelő impulzusvezetékhez tartozhat, és ugyanazon eltömődés miatt hibásodhat meg. A megbízhatósági elemzésnek ezért a teljes architektúrát kell vizsgálnia, beleértve a berendezéslistán közvetlenül nem látható függőségeket is.

Öt módszer különösen hasznos ehhez a munkához. A hibafaelemzés azt vizsgálja, hogy a meghibásodások milyen kombinációi idézhetnek elő egy meghatározott kiinduló eseményt. A hibamód- és hatáselemzés azt tanulmányozza, hogy az egyes komponensek hogyan hibásodhatnak meg, és ezek a meghibásodások miként hatnak a teljes rendszerre. A Monte Carlo-szimuláció számos lehetséges üzemelési és meghibásodási forgatókönyvön keresztül vizsgálja a bizonytalanságot, míg a gyökérok-elemzés azt tárja fel, hogy egy tényleges esemény miért következett be. A Markov-modellek azt írják le, hogyan lépnek a javítható rendszerek az idő múlásával az egészséges, leromlott, meghibásodott és helyreállított állapotok között.

1. ábra. Az ipari rendszerek nem tudnak minden hibát elkerülni, de a fegyelmezett megbízhatóságtechnika számos hiba teljes meghibásodássá válását megakadályozhatja.

A megbízhatóság, a rendelkezésre állás, a biztonság és a karbantarthatóság nem ugyanaz

A megbízhatósági terminológiát gyakran pontatlanul használják, ami zavart okozhat a tervfelülvizsgálatok során. A megbízhatóság annak valószínűségét jelenti, hogy a berendezés egy meghatározott időtartamon keresztül ellátja az előírt funkcióját. A rendelkezésre állás azt jelzi, hogy a berendezés üzemkész-e, amikor a folyamatnak szüksége van rá. Egy rendszer időnként meghibásodhat, mégis magas rendelkezésre állást tarthat fenn, ha a javítás gyors, és a pótalkatrészek azonnal elérhetők.

A karbantarthatóság azt írja le, hogy egy meghibásodott rendszer milyen hatékonyan diagnosztizálható és állítható helyre. A biztonság azt jelzi, hogy a meghibásodások a személyzet, a környezet és a berendezések szempontjából elfogadható kockázati határokon belül maradnak-e. Ezek a tulajdonságok hatással vannak egymásra, de az egyik javítása nem javítja automatikusan mindegyiket. Egy védelmi leállás csökkentheti a termelés rendelkezésre állását, miközben jelentősen javítja az üzem biztonságát.

A hibatűrés mindezeken a területeken átível. A redundanciától, a diagnosztikától, az elkülönítéstől, a javíthatóságtól és a szabályozott teljesítménycsökkenéstől függ. Emellett a szükséges funkció egyértelmű meghatározását is igényli. A mérnökök mindaddig nem tudják meghatározni, hogy egy rendszer hibatűrő-e, amíg nem ismerik, milyen teljesítménynek kell fennmaradnia minden hihető hiba után.

Egy kompresszorvédelmi rendszernek például egy érzékelő meghibásodása után is meg kell őriznie a vészlekapcsolási képességet. Egy folyamatirányító rendszernek csak arra lehet szüksége, hogy stabil működést tartson fenn, miközben az egyik szabályozót kicserélik. Egy villamosvédelmi rendszer független csatornákat igényelhet annak biztosítására, hogy egyetlen közös hiba se legyen képes kiiktatni az elsődleges és a tartalék védelmet egyaránt. A megbízhatósági technikák segítenek a mérnököknek ezeket a követelményeket tesztelhető tervekké alakítani.

Módszerválasztás a mérnöki kérdés alapján

Az öt megbízhatósági technika ugyanannak a problémának különböző részeit kezeli. Az FTA egy nemkívánatos rendszereseményből indul ki, és visszafelé halad az azt előidéző lehetséges meghibásodások felé. Az FMEA komponensekből vagy funkciókból indul ki, és előrefelé vizsgálja az egyes meghibásodási módok következményeit. A Monte Carlo-szimuláció a bizonytalanság hatását vizsgálja úgy, hogy a rendszermodellt számos véletlenszerűen generált körülmény mellett ismételten lefuttatja.

Az RCA rendszerint egy tényleges esemény után kezdődik, és bizonyítékok segítségével különíti el a látható tüneteket a mögöttes műszaki és szervezeti okoktól. A Markov-modellezés a rendszerállapotokra és a rendszer közötti átmenetelek sebességére összpontosít. Különösen hasznos, amikor a javítás, a készenléti üzem, a csökkent teljesítmény és a diagnosztikai lefedettség jelentősen befolyásolja a rendelkezésre állást.

A megfelelő választás a felteendő kérdéstől függ. Az a csapat, amely azt vizsgálja, hogyan következhet be a hűtés teljes elvesztése, általában az FTA-val kezdi. Az a tervezőcsapat, amely minden lehetséges távadó-, szabályozó- és szelephibát áttekint, többet profitál az FMEA-ból. A bizonytalan karbantartási időközöket összehasonlító eszközmenedzser Monte Carlo-szimulációt használhat, míg az a megbízhatósági mérnök, aki egy redundáns szabályozópár hosszú távú rendelkezésre állását számítja, előnyben részesítheti a Markov-modellt.

Ezek a módszerek kiegészítik egymást, nem pedig felcserélhetők. Az FMEA azonosíthat olyan meghibásodási módokat, amelyek később egy hibafán belül alapeseményekké válnak. Az RCA megállapításai korrigálhatják a Markov-modellben szereplő irreális meghibásodási feltételezéseket. A Monte Carlo-szimuláció vizsgálhatja, hogy a bizonytalan valószínűségek miként befolyásolják az FTA-ból vagy a karbantartástervezésből levont következtetéseket.

A hibafaelemzés a következménnyel kezdődik

A hibafaelemzés olyan deduktív módszer, amely egyértelműen meghatározott nemkívánatos eseménnyel kezdődik. Ezt az eseményt csúcseseménynek nevezzük. Megfelelő példák lehetnek a kazántápvíz teljes elvesztése, a turbina-lekapcsolási funkció meghibásodása, a szabályozóval való kommunikáció teljes megszakadása vagy a reaktoron belüli szabályozatlan nyomásemelkedés. A meghatározásnak kellően konkrétnak kell lennie ahhoz, hogy érdemi elemzést tegyen lehetővé.

A pusztán „rendszerhiba” néven leírt legfelső esemény általában túl homályos. Nem határozza meg, mely funkció hibásodott meg, meddig tartott a meghibásodás, vagy mely üzemállapot volt érvényben. Pontosabb meghatározás lehet például: „a teljes hűtővíz-áramlás megszűnése normál termelés közben több mint hatvan másodpercre”. Ez a megfogalmazás egyértelmű határt biztosít az elemzés számára.

A legfelső esemény meghatározása után a csapat azonosítja azokat a közvetlen feltételeket, amelyek előidézhetik azt. Ezeket a feltételeket alacsonyabb szintű eseményekre bontják mindaddig, amíg az elemzés el nem jut az alapvető alkatrész-meghibásodásokhoz, külső zavarokhoz vagy emberi cselekvésekhez. A logikai kapuk összekapcsolják az eseményeket, és leírják, hogyan együttesen idézik elő egymást. A VAGY-kapuk azt jelzik, hogy a felsorolt események bármelyike előidézheti a magasabb szintű eseményt, míg az ÉS-kapuk több esemény együttes bekövetkezését követelik meg.

Az elkészült fa vizuálisan ábrázolja a meghibásodási logikát. Lehetővé teszi, hogy az elektromos, gépészeti, műszerezési, technológiai, karbantartási és biztonsági szakemberek ugyanazt a rendszert közös szemlélet alapján vizsgálják. Ez a közös modell az FTA egyik legnagyobb gyakorlati előnye. Megkönnyíti a rejtett feltételezések megkérdőjelezését, mielőtt azok beépülnének a tervbe.

2. ábra. A hibafa egy meghatározott legfelső eseményből kiindulva visszafelé halad, és azonosítja azokat az alacsonyabb szintű meghibásodások kombinációit, amelyek előidézhetik azt.

Hibafa kidolgozása lépésről lépésre

Az első gyakorlati feladat a rendszerhatár meghatározása. A mérnököknek el kell dönteniük, hogy mely berendezések, közművek, szoftverek, kezelők és külső szolgáltatások tartoznak az elemzés hatókörébe. Egy hűtőrendszer vizsgálata magában foglalhatja a szivattyúkat, szelepeket, energiaelosztást, műszerezést és a vezérlési logikát. Szükség lehet továbbá a vízforrás, a környezeti feltételek és a kezelői beavatkozás figyelembevételére is, ha ezek a tényezők befolyásolhatják a legfelső eseményt.

A csapat ezt követően azonosítja a közvetlen okokat. A teljes hűtéskiesés azért következhet be, mert az összes szivattyú elérhetetlenné válik, a közös tápvezeték eldugul, vagy a leválasztó szelepek helytelenül zárnak. Ezután minden közvetlen okot tovább bontanak. A szivattyú elérhetetlenségét okozhatja a motor meghibásodása, a csapágy megszorulása, a szívóoldali ellátás elvesztése, a vezérlő meghibásodása vagy az elektromos tápellátás kiesése.

A folyamat addig folytatódik, amíg a további felbontás már nem javítja a döntést. A legalacsonyabb szintű eseményeket alap-eseményekként kezelik, és hozzájuk meghibásodási valószínűségek vagy ráták rendelhetők. A logikai struktúra ezt követően kvalitatívan vagy kvantitatívan értékelhető. Még pontos numerikus adatok hiányában is feltárhat a fa egyetlen meghibásodási pontokat és váratlan közös függőségeket.

A kvantitatív FTA az események valószínűségeit a kapustruktúrának megfelelően kombinálja. A számítás egyszerűnek tűnhet, de a függetlenségi feltételezéseket gondosan felül kell vizsgálni. Az azonos energiaforrástól, környezettől, karbantartási tevékenységtől vagy szoftverhibától függő események nem teljesen függetlenek. E kapcsolatok figyelmen kívül hagyása miatt egy redundáns kialakítás lényegesen biztonságosabbnak tűnhet a ténylegesnél.

A minimális vágathalmazok mutatják a legveszélyesebb kombinációkat

A vágathalmaz olyan alapesemények kombinációja, amely előidézi a csúcseseményt. A minimális vágathalmaz nem tartalmaz szükségtelen eseményt, vagyis bármelyik esemény eltávolítása megakadályozná a csúcsesemény bekövetkezését. Ezek a kombinációk segítenek a mérnököknek azonosítani a legrövidebb és legfontosabb meghibásodási útvonalakat. Különösen hasznosak akkor, amikor egy nagy hibafa több száz eseményt tartalmaz.

Az egyetlen eseményből álló minimális vágathalmaz azt jelzi, hogy egyetlen meghibásodás közvetlenül előidézheti a csúcseseményt. Az ilyen megállapítások általában azonnali tervezési figyelmet érdemelnek. A csapat növelheti a redundanciát, javíthatja az elkülönítést, külön tápellátást biztosíthat, vagy további védelmi réteget vezethet be. A két- és háromeseményes vágathalmazok gyakran redundáns architektúrákon belüli meghibásodásokat képviselnek.

Nem minden rövid vágathalmaz jelent azonos kockázatot. A gyakori meghibásodásokat magában foglaló két eseményből álló kombináció jelentősebb lehet, mint egyetlen, rendkívül ritka külső esemény. Az észleléshez és javításhoz szükséges idő szintén befolyásolja a jelentőséget. A hónapokig észrevétlenül fennmaradó rejtett hiba sokkal hosszabb kitettségi időt eredményez, mint egy azonnal észlelt és kijavított meghibásodás.

Az FTA-szoftverek a számított hozzájárulás alapján rangsorolhatják a vágathalmazokat. A mérnököknek azonban továbbra is meg kell vizsgálniuk a számok mögött rejlő fizikai jelentést. Egy matematikailag kicsi valószínűség gyenge feltételezéseken vagy olyan általános adatokon alapulhat, amelyek nem tükrözik a tényleges telepítést. Az elemzés teljes folyamata során szükség van mérnöki megítélésre.

Példa: nem valóban független kazántápvíz-szivattyú-redundancia

Vegyünk egy erőművet, amelyben két kazántápvíz-szivattyú üzemel. Bármelyik szivattyú képes fenntartani a minimálisan szükséges térfogatáramot, ezért a rendszer látszólag elvisel egy szivattyúhibát. Az egyszerű berendezésszámolás teljes redundanciára utal. A közös függőségek figyelembevétele után azonban a hibafa más valóságot tárhat fel.

Mindkét szivattyúmotor ugyanarról az elektromos sínről kaphat tápellátást. Mindkét szivattyú ugyanahhoz a szívógyűjtőhöz csatlakozhat, ugyanattól a vezérlőrendszertől függhet, vagy ugyanazon szintmérés alapján kaphat parancsot. Ezért egyetlen sínhiba, elzáródott szívógyűjtő vagy hibás közös jel egyszerre mindkét szivattyút leállíthatja. A látszólagos két szivattyús redundancia nem védene ezekkel a közös hibákkal szemben.

Az elemzés több gyakorlati fejlesztéshez is vezethet. A külön villamos táplálások csökkenthetik a közös tápellátás-kiesés kockázatát. A különböző elven működő szintmérések mérsékelhetik az egyetlen távadótechnológiától való függést. A független vezérlési utak, a továbbfejlesztett kézi működtetés és a jobb szívóoldali felügyelet megerősíthetik az architektúrát anélkül, hogy szükségszerűen egy újabb komplett szivattyút kellene hozzáadni.

Ez a példa megmutatja, miért hasznosabb az FTA, mint a redundáns eszközök egyszerű megszámolása. Azt értékeli, hogy az eszközök valós üzemeltetési körülmények között is függetlenek maradnak-e. Azt is azonosítja, hol nyújt valódi védelmet a további összetettség, és hol kelti csupán a védelem látszatát.

Ahol a hibafaelemzés jól működik – és ahol nem

Az FTA különösen hatékony biztonsági funkciók, védelmi rendszerek, villamosenergia-elosztó rendszerek, kommunikációs hálózatok és más, világosan meghatározott nem kívánt eseménnyel jellemezhető alkalmazások esetén. Vizuális felépítése támogatja a tervezési felülvizsgálatokat és a hatósági egyeztetéseket. Alkalmazható kvalitatív módon a gyenge pontok feltárására, illetve kvantitatív módon a kiinduló esemény valószínűségének becslésére.

A módszer kevésbé hatékony, ha a kiinduló eseményt nem határozták meg megfelelően. A karbantartása akkor is nehézzé válhat, amikor a fa több ezer eseményre bővül. A dinamikus folyamatok, a karbantartási tevékenységek és a változó üzemállapotok speciális kapukat vagy további modellezési technikákat tehetnek szükségessé. A statikus hibafa természeténél fogva nem ír le minden időfüggő kapcsolatot.

Az emberi műveletek szintén körültekintő kezelést igényelnek. A kezelő válaszának valószínűsége függ a riasztás minőségétől, az eljárás kialakításától, a képzettségtől, a munkaterheléstől, a rendelkezésre álló időtől és a felület körülményeitől. Egyetlen általános emberi hibavalószínűség hozzárendelése elfedheti ezeket a különbségeket. Ha a kezelői művelet központi szerepet játszik az eredményben, a komoly elemzésekbe humán tényezőkkel foglalkozó szakembereket is be kell vonni.

Az FTA ezért akkor a leghatékonyabb, ha egy szélesebb körű megbízhatósági program részeként alkalmazzák. Az FMEA részletes komponenshibákat tárhat fel, míg a Markov- vagy Monte Carlo-módszerek a javítást, a sorrendiséget és a bizonytalanságot kezelhetik. Egyetlen hibafa sem tekinthető minden rendszerviselkedés teljes reprezentációjának.

A hibamód- és hatáselemzés a komponenssel kezdődik

A hibamód- és hatáselemzés induktív megközelítést alkalmaz. A csapat nem egy kiinduló eseménnyel kezdi, hanem egy elemmel, funkcióval vagy folyamatlépéssel. Ezután azt vizsgálja, hogyan hibásodhat meg az adott elem, és az egyes meghibásodások milyen helyi, illetve rendszerszintű hatással járnának. Ez a megközelítés különösen hasznossá teszi az FMEA-t a tervezés és a berendezés-felülvizsgálat során.

Egy nyomástávadó többféleképpen is meghibásodhat. A kimenete eltolódhat magasabb vagy alacsonyabb érték felé, egyetlen értéken befagyhat, instabillá válhat vagy teljesen megszűnhet. Mindegyik mód eltérő üzemeltetési következménnyel jár. A magas érték szükségtelen leállást okozhat, míg az alacsony érték elrejthet egy veszélyes nyomásállapotot.

Az FMEA arra kényszeríti a csapatot, hogy ezeket a különbségeket írja le, ahelyett hogy csupán „távadó-meghibásodást” rögzítene. A meglévő megelőzési és felismerési kontrollokat is vizsgálja. Az elemzés olyan diagnosztikát, összehasonlító logikát, működési próbákat, riasztásokat, áthidalásokat vagy kezelői ellenőrzéseket azonosíthat, amelyek csökkentik a következményt. A gyenge felismerés gyakran ugyanolyan fontossá válik, mint az eredeti meghibásodási mód.

3. ábra. Az FMEA az egyes meghibásodási módokat, azok hatásait, súlyosságát, valamint a megelőzésükre vagy felismerésükre rendelkezésre álló kontrollokat értékeli.

Mit kell tartalmaznia egy hatékony FMEA-munkalapnak?

A hasznos FMEA-munkalap az elemmel és annak előírt funkciójával kezdődik. A meghibásodási mód azt írja le, hogyan veszhet el, romolhat le vagy hajtható végre helytelenül a funkció. A helyi hatás azt írja le, mi történik komponensszinten, míg a rendszerszintű hatás a tágabb üzemeltetési vagy biztonsági következményt mutatja be. Az okokat és a mechanizmusokat a hatásoktól elkülönítve rögzítik.

A munkalap a meglévő kontrollokat is dokumentálja. A megelőző kontrollok csökkentik annak valószínűségét, hogy a meghibásodás bekövetkezik. A felismerési kontrollok még az elfogadhatatlan következmény kialakulása előtt feltárják a meghibásodást. Ilyen például az öndiagnosztika, a redundáns jelek összehasonlítása, a riasztási határértékek, a működési próbák, az ellenőrzések és a prediktív karbantartás.

Sok szervezet súlyossági, előfordulási és felismerhetőségi értékeléseket rendel hozzá. Ezeket az értékeket néha összeszorozzák a kockázati prioritási szám meghatározásához. A szám segítheti a rangsorolást, de soha nem helyettesítheti a műszaki megítélést. Különböző kombinációk ugyanazt a pontszámot eredményezhetik, miközben a következményeik alapvetően eltérnek.

Egy ritka, katasztrofális meghibásodás nagyobb figyelmet érdemelhet, mint egy gyakori, kisebb kellemetlenség, még akkor is, ha a számított pontszámaik hasonlónak tűnnek. Ezért a súlyosságot külön is felül kell vizsgálni. A csapatoknak emellett azokat az intézkedéseket kell előnyben részesíteniük, amelyek megszüntetik a meghibásodási mechanizmust vagy csökkentik a következményt, ahelyett hogy kizárólag további ellenőrzésekre támaszkodnának.

Példa: redundáns PLC-bemenetek közös gyenge ponttal

Tekintsünk két digitális bemeneti csatornát, amelyek egy vészleállító terepi kapcsolót figyelnek. Az architektúra redundánsnak tűnik, mivel a jelet két PLC-bemenet fogadja. Az FMEA azt vizsgálja, hogy a teljes jelút valóban független-e. Figyelembe veszi a terepi érintkezőt, a vezetékezést, a bemeneti tápellátást, a sorkapocsszerelvényeket, a modulokat, a logikát és a diagnosztikai működést.

A lehetséges meghibásodási módok közé tartozik a szakadás, a rövidzárlat, a beragadt érintkező, a magas szinten beragadt csatorna, az alacsony szinten beragadt csatorna vagy a közös bemeneti tápellátás kiesése. Az elemzés azt is vizsgálja, hogy érzékelhető-e a csatornák közötti eltérés. Ha mindkét csatorna ugyanahhoz a terepi érintkezőhöz és ugyanahhoz a kábelhez csatlakozik, számos reális meghibásodás egyidejűleg mindkét csatornát érintheti.

A felülvizsgálat kimutathatja, hogy a megkettőzött bemeneti modulok csak korlátozott további védelmet nyújtanak. Különálló érintkezőkre, felügyelt terepi áramkörökre, független tápellátási útvonalakra vagy különböző érzékelési elvekre lehet szükség. A működési próba eljárásának a teljes jelátviteli láncot is ellenőriznie kell, nem csupán a PLC-modult.

Védelmi architektúrák esetében a mérnökök megfelelő, ipari biztonsági modulokat is vizsgálhatnak, amelyeket diagnosztikai lefedettségre, redundanciára és szabályozott meghibásodási viselkedésre terveztek. A hardver kiválasztásának továbbra is a teljes biztonsági életciklust kell követnie, és nem helyettesítheti az alkalmazásspecifikus elemzést.

A tervezési FMEA és a folyamat-FMEA eltérő kockázatokat kezel

A tervezési FMEA a megtervezett terméket vagy rendszert vizsgálja. Azt elemzi, hogy a kiválasztott architektúra, alkatrészek, anyagok és vezérlési funkciók képesek-e a rendeltetésüknek megfelelően működni. A módszert jellemzően a koncepció kidolgozása, a részletes tervezés és a tervezési módosítások során alkalmazzák. Akkor a legértékesebb, mielőtt a terv módosítása költségessé válna.

A folyamat-FMEA a gyártási, összeszerelési, telepítési, üzembe helyezési vagy karbantartási tevékenységeket vizsgálja. Egy szekrény elektromos kialakítása lehet megfelelő, de a telepítési folyamat így is okozhat laza sorkapcsokat, felcserélt polaritást, nem megfelelő biztosítékértékeket vagy hibás vezetékazonosítást. A karbantartási tevékenység helytelen firmware-t, nem megfelelő cserealkatrészeket, letiltott riasztásokat vagy aktívan hagyott áthidalásokat vezethet be.

Az FMEA e két formájának támogatnia kell egymást. A tervezési intézkedések csökkenthetik a telepítés érzékenységét, míg a folyamatirányítás megakadályozhatja azokat a végrehajtási hibákat, amelyeket a tervezés nem tud kiküszöbölni. Ha csak a berendezés tervezését vizsgáljuk, számos életciklusbeli kockázat feltáratlan marad. Ha csak a munkafolyamatot vizsgáljuk, rejtve maradhatnak az eredeti architektúrába beépített gyengeségek.

Kritikus automatizálási rendszerek esetében mindkét elemzést frissíteni kell jelentős módosítások után. Egy vezérlő cseréje, hálózati migráció, szoftverfrissítés vagy a működési próba eljárásának megváltoztatása új meghibásodási módokat vezethet be. A korábbi munkalapokat nem szabad változatlanul hagyni, miközben az üzem körülöttük folyamatosan fejlődik.

Az FMECA formálisabb kritikussági értékelést ad

A meghibásodási módok, hatások és kritikusság elemzése a formális kritikussági számítások hozzáadásával bővíti az FMEA-struktúrát. A módszer felhasználhatja az alkatrészek meghibásodási arányát, az üzemeltetési kitettséget, a küldetésfázisokat, a súlyossági kategóriákat és a feltételes valószínűségeket. Akkor hasznos, amikor egy nagy rendszer számos meghibásodási módot tartalmaz, és a mérnöki erőforrásokat a legjelentősebb hozzájárulásokra kell irányítani.

A kritikussági számítások nagymértékben függnek az adatok minőségétől. Az általános meghibásodási rátákat tartalmazó adatbázisok kiindulópontot jelentenek, de nem feltétlenül tükrözik a tényleges telepítési körülményeket. A hőmérséklet, a rezgés, a szennyeződés, az elektromos terhelés, a karbantartás minősége és az üzemelési ciklus mind befolyásolja a tényleges teljesítményt. Ha elegendő üzemeltetési előzmény áll rendelkezésre, az általános feltételezéseket az adott üzemre jellemző bizonyítékokkal kell felváltani.

Az elemzésnek különbséget kell tennie az azonnal észlelt, illetve a rejtve maradó meghibásodások között is. Egy készenléti rendszer lappangó meghibásodása addig nem befolyásolhatja a termelést, amíg egy másik alkatrész meg nem hibásodik, vagy amíg igénybevétel nem történik. A hosszú ideig fennálló rejtett kitettség miatt egy viszonylag ritka meghibásodás is kiemelkedően fontossá válhat. Ezért a felderítési időközöket és a bizonyító teszt hatékonyságát is figyelembe kell venni.

Az FMECA akkor a leghasznosabb, ha eredményei tervezési vagy karbantartási intézkedésekhez vezetnek. Egy összetett rangsorolási táblázat kevés értéket képvisel, ha nem befolyásolja a rendszerarchitektúrát, a pótalkatrész-ellátást, a diagnosztikát, a tesztelést vagy az üzemeltetési eljárásokat. A cél továbbra is a gyakorlati kockázatcsökkentés, nem pedig a számítás önmagáért.

Ahol az FMEA jól működik — és ahol félrevezető lehet

Az FMEA fegyelmezett, alkatrészenkénti felülvizsgálatot biztosít. Viszonylag könnyen elmagyarázható, és támogatja a mérnöki, üzemeltetési, karbantartási, minőségügyi és biztonsági szakemberek részvételét. Az így létrejövő intézkedési nyilvántartás közvetlenül összekapcsolható a tervezési módosításokkal, az ellenőrzésekkel, a diagnosztikával és a karbantartás fejlesztésével.

A módszer nagyon nagy rendszerek esetén ismétlődővé válhat. A csapatok túl sok időt tölthetnek az alacsony értékű meghibásodási módok dokumentálásával, miközben figyelmen kívül hagyják a rendszerszintű kölcsönhatásokat. A hagyományos FMEA emellett általában egyszerre egy meghibásodást vizsgál. Több egyidejű meghibásodás és a sorrendtől függő események nem feltétlenül jelennek meg egyértelműen.

A pontozási rendszerek újabb kockázatot jelentenek. A csapatok módosíthatják a minősítéseket egy kívánt prioritás elérése érdekében, vagy a végső számot objektívebbnek tekinthetik, mint az alapjául szolgáló szakmai megítélést. Az alacsony pontszám nem bizonyítja, hogy egy meghibásodás elfogadható. A nagy súlyosságú eseményeket, a közös okú meghibásodásokat és a hatósági követelményeket külön felülvizsgálatnak kell alávetni.

Az FMEA minősége az azt elvégző személyektől függ. Egyetlen tervező által összeállított munkalapból hiányozhatnak az üzemeltetők és a technikusok által ismert gyakorlati tapasztalatok. A jó elemzések a tervezési ismereteket a tényleges karbantartási előzményekkel és az üzemeltetési tapasztalatokkal ötvözik.

A Monte Carlo-szimuláció az bizonytalanságot eloszlássá alakítja

Az ipari megbízhatósági számítások gyakran bizonytalan bemenetekkel dolgoznak. Az alkatrészek élettartama változó, a javítás időtartama módosulhat, a pótalkatrészek szállítása kiszámíthatatlan, a környezeti terhelés pedig befolyásolja a meghibásodási viselkedést. Egyetlen átlagérték nem mindig képes reprezentálni ezeket az eltéréseket. A Monte Carlo-szimuláció ismételt véletlenszerű mintavételezéssel kezeli ezt a problémát.

A mérnök először felépíti a rendszer modelljét, és valószínűségi eloszlásokat rendel a bizonytalan változókhoz. Ezután a szimuláció számos lehetséges kombinációt generál. Az egyik futtatásban előfordulhat, hogy egy szivattyú 8000 üzemóra után meghibásodik, és négy órán belül megjavítják. Egy másik futtatás későbbi meghibásodást, de sokkal hosszabb javítást eredményezhet, mert a szükséges tartalékalkatrész nem áll rendelkezésre.

Több ezer vagy akár több millió futtatás után a kimenetek eloszlást alkotnak. A modell képes megbecsülni a várható állásidőt, a termeléskiesést, a rendszer rendelkezésre állását, a feladat sikerének valószínűségét, a tartalékalkatrész-igényt vagy a karbantartási költséget. Megmutathatja a szélsőséges kimenetek valószínűségét is, amelyek egyetlen átlagos értékben elvesznének.

4. ábra. A Monte Carlo-szimuláció számos véletlenszerűen generált meghibásodási és javítási forgatókönyvet értékel a lehetséges kimenetek tartományának becsléséhez.

Megbízható Monte Carlo-megbízhatósági modell létrehozása

A szimuláció minősége a rendszer modellen múlik. A modellnek reprezentálnia kell az alkatrészeket, az üzemeltetési szabályokat, a meghibásodási eloszlásokat, a javítási viselkedést, a függőségeket, a készenléti logikát és a karbantartási erőforrásokat. Tartalmazhatja az időjárást, a termelési igényt, a logisztikai késéseket és az emberi reakciókat is, ha ezek a tényezők befolyásolják a rendszer teljesítményét.

Minden szimulált futtatás időben követi a rendszert. Az alkatrészek a mintavételezett eloszlások szerint hibásodnak meg, a javítások akkor kezdődnek, amikor az erőforrások elérhetővé válnak, a modell pedig rögzíti, hogy a rendszer üzemképes, csökkentett teljesítményű vagy üzemképtelen marad-e. A folyamat megismétlése különböző teljesítménymutatók becslését teszi lehetővé.

Az érvényesítés elengedhetetlen. A csapatnak össze kell vetnie a modellt egyszerűsített számításokkal, ismert üzemeltetési esetekkel és a korábbi üzemi eredményekkel. A váratlan kimeneteket ki kell vizsgálni, nem pedig elfogadni csak azért, mert szoftver eredményei. Egy látványos szimuláció is lehet hibás, ha az alapjául szolgáló logika hiányos.

Az érzékenységvizsgálat segít azonosítani, mely feltételezések befolyásolják leginkább az eredményt. Ha a javítási idő sokkal nagyobb hatással van, mint a meghibásodási ráta, a vezetőség nagyobb értéket teremthet a tartalékalkatrészek elérhetőségének és a diagnosztika sebességének javításával. Ha a közös okú meghibásodás valószínűsége dominál, több azonos alkatrész hozzáadása csekély előnnyel járhat.

A meghibásodási mechanizmushoz illeszkedő valószínűségi eloszlások kiválasztása

Az exponenciális eloszlás állandó meghibásodási rátát feltételez. Egyes elektronikus alkatrészek hasznos üzemideje alatt megfelelő lehet. A Weibull-eloszlás rugalmasabb, és képes reprezentálni a korai meghibásodásokat, a véletlenszerű meghibásodásokat vagy az elhasználódási viselkedést. A lognormális eloszlások gyakran hasznosak javítási időtartamok és több szorzótényező által befolyásolt folyamatok esetén.

A választásnak a fizikai mechanizmust kell tükröznie, nem pedig a szoftveres kényelmet. Egy kopás okozta csapágyhiba természeténél fogva nem ugyanazt a viselkedést követi, mint egy véletlenszerű kommunikációs hiba. Ha mindkettőre állandó meghibásodási rátát alkalmazunk, az torzíthatja a hosszú távú előrejelzéseket. A megbízhatósági mérnököknek a valószínűségi eloszlás kiválasztása előtt meg kell vizsgálniuk az üzemeltetési előzményeket és a meghibásodási mechanizmusokat.

A korábbi adatok gyakran tisztítást igényelnek. A karbantartási rendszerek összetéveszthetik a tervezett cserét a funkcionális meghibásodással. A meghibásodás dátumát rögzíthetik a munkamegrendelés megnyitásakor, nem pedig a hiba bekövetkezésekor. Az eszköznevek, az üzemórák és a hibakódok telephelyenként is eltérhetnek.

A korlátozott adatmennyiség nem akadályozza meg az elemzést, de a bizonytalanságnak láthatónak kell maradnia. A korai becsléseket szakértői vélemények, beszállítói információk és iparági adatbázisok is támogathatják. A modellnek reális tartományt kell vizsgálnia ahelyett, hogy egy bizonytalan feltételezést pontos tényként mutatna be.

Példa: Egy háromkompresszoros állomás rendelkezésre állása

Vegyünk egy három gázkompresszorral rendelkező állomást. A teljes termeléshez két egység szükséges, míg a harmadik tartalékkapacitást biztosít. Mindegyik gép eltérő üzemórával, karbantartási előzményekkel és hűtési teljesítménnyel rendelkezik. Egyszerre csak egy jelentős javítás végezhető, mivel az állomásnak egyetlen specialista karbantartócsapata van.

A tartalék csapágyak kiszállítása több napot vesz igénybe, a hűtőrendszer meghibásodásai pedig magas környezeti hőmérséklet esetén gyakoribbá válnak. Ezeket a kölcsönhatásokat nehéz egyetlen egyszerű rendelkezésreállási egyenlettel ábrázolni. Egy Monte Carlo-modell mintavételezheti a kompresszorhibákat, a javítási időtartamokat, az időjárási időszakokat, a technikusok rendelkezésre állását és a logisztikai késedelmeket.

Az eredmények megmutathatják a teljes kapacitás rendelkezésre állását, a csökkentett kapacitású működést és az állomás teljes kiesését. A vezetőség összehasonlíthatja az alternatív beruházásokat. További csapágyak készletezése hatékonyabban csökkentheti a szélsőséges állásidőt, mint egy újabb általános karbantartó technikus felvétele. A hűtés megbízhatóságának javítása nagyobb értéket teremthet, mint egy egyébként megfelelően működő kompresszor cseréje.

A modell a karbantartási intervallumokat is vizsgálhatja. A rövidebb megelőző karbantartási intervallumok csökkenthetik a meghibásodások számát, ugyanakkor növelhetik a tervezett leállási időt és a karbantartás által előidézett hibák számát. A szimuláció lehetővé teszi mindkét hatás értékelését ugyanazon működési modellen belül.

A Monte Carlo-szimuláció alkalmazási területei és korlátai

A Monte Carlo-módszerek akkor hatékonyak, amikor számos bizonytalan változó kölcsönhatásban áll egymással. Képesek modellezni az összetett logisztikai folyamatokat, javítási várólistákat, időjárási hatásokat, termelési igényt és karbantartási döntéseket. Az így kapott eloszlás több információt nyújt, mint egyetlen átlagérték. A kockázatalapú döntéshozatalt is támogatja azáltal, hogy megmutatja a súlyos, de ritkán bekövetkező kimenetelek valószínűségét.

A legfőbb gyengeség a modell hitelessége. Egy összetett szimuláció hamis magabiztosságot kelthet, mert a kimenete számszerűen pontosnak tűnik. A program csak a szakértő által megadott feltételezések következményeit számítja ki. A hiányzó függőségek vagy a valószerűtlen eloszlások félrevezető eredményekhez vezethetnek.

A szimulációhoz elegendő számú futtatásra is szükség van a stabil becslések eléréséhez. A ritka események valószínűségei speciális mintavételi technikákat igényelhetnek, mert a hagyományos véletlen szimulációhoz gyakorlatilag megvalósíthatatlanul sok futtatásra lenne szükség. Konfidenciaintervallumokat kell közölni, hogy a felhasználók megértsék a statisztikai bizonytalanságot.

A módszer ezért akkor a leghasznosabb, ha a modell logikája, az adatforrások és a korlátok átláthatók maradnak. A megbízhatósági döntéseket nem szabad olyan diagramra alapozni, amelynek feltételezéseit nem lehet elmagyarázni az üzemeltetési és műszaki szakembereknek.

A gyökérok-elemzés az esemény után kezdődik

A gyökérok-elemzés azt vizsgálja, miért következett be egy tényleges meghibásodás, minőségi probléma vagy biztonsági esemény. Nem áll meg a sérült alkatrész azonosításánál. Egy motor leállhat azért, mert megszorult egy csapágy, de a csapágy cseréje csak a működést állítja helyre. A vizsgálatnak azt kell meghatároznia, miért jutott a csapágy ebbe az állapotba.

A mélyebb okok között szerepelhet szennyeződés, helytelen kenés, nem megfelelő tárolás, telepítés közbeni sérülés, túlzott folyamat-terhelés vagy elmulasztott ellenőrzés. Szervezeti körülmények is hozzájárulhatnak. Előfordulhat, hogy karbantartási feladatokat töröltek, a pótalkatrészek nem voltak megfelelőek, vagy a termelési nyomás késleltette a helyesbítő munkát.

Az RCA ezért elkülöníti a tüneteket, a közvetlen fizikai okokat, a közreható körülményeket és a mögöttes rendszerszintű hiányosságokat. Ez a megkülönböztetés megakadályozza, hogy a szervezet minden javítást végleges megoldásként kezeljen. Emellett olyan bizonyítékokat szolgáltat, amelyek javíthatják a jövőbeli FMEA- és FTA-elemzéseket, a karbantartás tervezését és az üzemeltetési eljárásokat.

5. ábra. Az RCA a látható tüneten túl követi nyomon a meghibásodást, és azonosítja azokat a műszaki és szervezeti körülményeket, amelyek lehetővé tették annak bekövetkezését.

A bizonyítékokat meg kell őrizni, mielőtt az üzem visszatér a normál működéshez

Az ipari bizonyítékok gyorsan eltűnhetnek. A kezelők visszaállíthatják a riasztásokat, a technikusok kicserélhetik a modulokat, a folyamat körülményei pedig megváltozhatnak. A vezérlő naplói felülírhatják a korábbi eseményeket, miközben a sérült alkatrészeket még a vizsgálat előtt kidobhatják. Ezért a fegyelmezett RCA-folyamat a bizonyítékok megőrzésével kezdődik.

A csapatnak össze kell gyűjtenie az előzményadatokat, a riasztási listákat, a vezérlő eseménynaplóit, a reléfeljegyzéseket, a munkamegrendeléseket, a fényképeket, a sérült alkatrészeket, a szoftververziókat, a konfigurációs fájlokat és a kezelők megfigyeléseit. Minden elemet a forrás és az időpont alapján kell azonosítani. A fizikai bizonyítékokat ellenőrzött körülmények között kell megőrizni mindaddig, amíg a vizsgálat meg nem állapítja, szükség van-e további elemzésre.

Az időszinkronizálás különös figyelmet igényel. A vezérlő, a történeti adatbázis, a védelmi relé, a szerver és a karbantartási rendszer eltérő időbélyegeket rögzíthet. A vizsgálóknak az eseménysor felépítése előtt korrigálniuk kell ezeket az eltéréseket. Ellenkező esetben egy későbbi riasztás tévesen kiváltó eseményként jelenhet meg.

A kezelőkkel készült interjúkat haladéktalanul, de körültekintően kell lefolytatni. Az emberek emlékezhetnek olyan sorrendre és összefüggésekre, amelyeket az automatizált rendszerek nem rögzítettek. Nyilatkozataikat bizonyítékként, nem pedig hibáztatás alapjaként kell kezelni. A cél annak megértése, hogy milyen működési környezetben születtek a döntések.

Az esemény idővonalának felépítése a „Miért?” kérdés feltevése előtt

A megbízható idővonal elválasztja az ellenőrzött tényeket az értelmezéstől. Rögzíti, mi történt a meghibásodás előtt, közben és után. Minden eseményt hozzá kell kapcsolni egy forráshoz, például egy történeti adatbázis értékéhez, riasztási rekordhoz, karbantartási művelethez, fényképhez vagy tanúvallomáshoz. A hiányosságoknak és ellentmondásoknak láthatónak kell maradniuk.

A kezelőnek elsőként megjelenő riasztás nem mindig az első fizikai esemény. A riasztásáradat több száz másodlagos üzenet alá temetheti a kiváltó állapotot. A nagy felbontású eseménysorrend-adatok megmutathatják, hogy a nyomás instabilitása, a tápellátási zavar vagy a kommunikáció megszakadása korábban kezdődött. Az idővonal segít megkülönböztetni az okot a következménytől.

A szekvencia megértése után a csapat olyan eszközöket használhat, mint az Öt Miért módszer, a halszálkadiagramok, a védelmi rétegek elemzése, a változáselemzés vagy az ok-okozati tényezők diagramjai. Az egyszerű események rövid ok-okozati lánccal is magyarázhatók. Az összetett incidensek általában több, egymással kölcsönhatásban álló műszaki és szervezeti feltételt foglalnak magukban.

A vizsgálat nem állhat meg egyetlen valószínű magyarázat megtalálásánál. Az alternatív hipotéziseket a bizonyítékok alapján ellenőrizni kell. A nem alátámasztott feltételezéseket továbbra is feltételezésként kell megjelölni, nem pedig megerősített okként bemutatni.

Példa: Ismétlődő változtatható fordulatszámúhajtás-meghibásodások

Egy üzemben ismételten meghibásodik egy, az egyik szállítószalagot vezérlő változtatható fordulatszámú hajtás. A karbantartás minden esemény után kicseréli a hajtást, a termelés pedig visszatér a normál működéshez. Néhány hónappal később egy újabb hajtás meghibásodik. Az ismételt csere arra utal, hogy önmagában a hajtás nem feltétlenül jelenti a teljes problémát.

Az RCA-csapat összeveti a meghibásodások dátumait a környezeti és karbantartási nyilvántartásokkal. A legtöbb meghibásodás a forró nyári időszakokban történt. A szekrényhőmérséklet trendjei azt mutatják, hogy a berendezés hosszabb ideig a kívánt tartomány felett üzemelt. Az ellenőrzés eltömődött szűrőket, korlátozott légáramlást és a hűtési útvonal körüli jelentős porfelhalmozódást tár fel.

A karbantartási előzmények szerint a rendszeres szűrőtisztítást a létszám változása után törölték a megelőző karbantartási ütemtervből. A meghibásodott alkatrész a hajtás, de a közvetlen fizikai ok a túl magas szekrényhőmérséklet. A korlátozott szellőzés, valamint a hiányzó karbantartási feladat hozzájáruló és szervezeti okok.

A helyesbítő intézkedésnek ezért túl kell mutatnia egy újabb frekvenciaváltó cseréjén. Az üzem helyreállíthatja a szűrők karbantartását, hőmérséklet-riasztásokat telepíthet, javíthatja a szekrények hűtését, és felülvizsgálhatja a burkolatok kialakítását. A hatékonyságot a következő magas hőmérsékletű időszakban kell ellenőrizni.

A helyesbítő intézkedéseket igazolt okokhoz kell kapcsolni

Számos RCA-jelentés a helyesbítő intézkedések megtervezésekor válik gyengévé. A csapatok további képzést javasolhatnak anélkül, hogy bizonyítanák a tudás hiányát. Módosíthatják az eljárásokat, miközben a valódi probléma a nem megfelelő berendezéskialakítás. Olyan ellenőrzéseket vezethetnek be, amelyek nem képesek felismerni a tényleges meghibásodási mechanizmust.

Minden intézkedésnek igazolt okot vagy közreható feltételt kell kezelnie. Rendelkeznie kell felelőssel, befejezési dátummal és meghatározott ellenőrzési módszerrel. A szervezetnek meg kell különböztetnie az ideiglenes elszigetelő intézkedést, a helyesbítő intézkedést és a hosszú távú megelőző intézkedést. A termelés helyreállítása nem azonos az ismételt előfordulás megelőzésével.

A hatékonyságot a bevezetés után is felül kell vizsgálni. Egy lezárt intézkedés nem automatikusan sikeres. Az üzemnek meg kell erősítenie, hogy csökkent-e a meghibásodás valószínűsége, használják-e az új ellenőrzést, és nem vezetett-e be további kockázatot. Ez a visszacsatolás zárja le a megbízhatóság javításának körét.

A komoly vizsgálatok független felülvizsgálatot tehetnek szükségessé. Az eseményben szorosan érintett csapatokat befolyásolhatják korábbi feltételezések vagy szervezeti nyomás. Külső vagy több szakterületet bevonó felülvizsgálat megkérdőjelezheti az elemzést, mielőtt elfogadnák a végső következtetéseket.

Az emberi hiba ritkán teljes körű gyökérok

A gyenge vizsgálatokban gyakran szerepel a „kezelői hiba” és a „karbantartási hiba” kifejezés. Ezek a címkék leírják, ki hajtotta végre a végső műveletet, de nem magyarázzák meg, miért vált valószínűvé a művelet. Az emberek kezelőfelületek, eljárások, létszámkeretek, termelési elvárások, képzési rendszerek és berendezéskialakítások között dolgoznak. A vizsgálatnak mindezeket a feltételeket meg kell vizsgálnia.

Egy kezelő azért választhatja ki a rossz vezérlőelemet, mert két képernyőelem szinte teljesen egyformának tűnik. Egy technikus azért szerelheti be a rossz alkatrészt, mert az azonosítás nem következetes. Egy műszakvezető azért halaszthatja el a karbantartást, mert a szervezet a megszakítás nélküli termelést jutalmazza, miközben nem biztosít reális leállási időablakot.

E feltételek megértése nem szünteti meg az egyéni felelősséget. Megakadályozza, hogy ugyanaz a rendszer egy másik személyt ugyanabba a hibába tereljen. A hibáztatásra összpontosító vizsgálat kielégítheti a felelősségre vonás iránti azonnali igényt, miközben az alapvető hiányosság érintetlen marad.

A hatékony gyökérok-elemzés azt vizsgálja, hogyan befolyásolta a rendszer a döntést. Azt kérdezi, hogy a riasztások érthetők voltak-e, az eljárások gyakorlatiasak voltak-e, a munkaterhelés ésszerű volt-e, és rendelkezésre álltak-e a szükséges eszközök. Ezek a kérdések erősebb helyesbítő intézkedéseket eredményeznek, mint az, ha egyszerűen arra utasítjuk az embereket, hogy legyenek körültekintőbbek.

A gyökérok-elemzés mikor működik jól – és mikor nem

Az RCA a valós működési tapasztalatokat megelőző ismeretekké alakítja. Feltárhat olyan tervezési gyengeségeket, karbantartási hiányosságokat, eljárási problémákat és szervezeti nyomásokat, amelyeket az előrejelző vizsgálatok nem vettek észre. Eredményei javíthatják a megbízhatósági modelleket és a jövőbeli projektek szabványait.

A módszer reaktív, mert egy esemény után kezdődik. A súlyos következményekkel járó iparágak nem támaszkodhatnak kizárólag a meghibásodásokból való tanulásra. A proaktív módszerek, például az FMEA és az FTA, továbbra is szükségesek. Az RCA-nak ki kell egészítenie ezeket azzal, hogy a tényleges működésből származó bizonyítékok alapján frissíti a feltételezéseket.

A vizsgálatok szubjektívvé is válhatnak. A megerősítési torzítás arra késztetheti a csapatokat, hogy az első, megfelelőnek tűnő magyarázatot részesítsék előnyben. A hiányzó bizonyítékok miatt a következtetések bizonytalanok maradhatnak. Az alapos jelentések egyértelműen elkülönítik a megerősített okokat, a közreható tényezőket, a hipotéziseket és a megoldatlan kérdéseket.

Az RCA értéke a végrehajtáson múlik. Egy technikailag alapos vizsgálat kevés hasznot hoz, ha az intézkedéseket késleltetik, felhígítják vagy soha nem ellenőrzik. Ezért a vezetői elkötelezettség ugyanolyan fontos, mint az elemzési készség.

A Markov-modellek nyomon követik a rendszer változó állapotait

A Markov-modellezés a rendszert meghatározott működési állapotokon keresztül ábrázolja. Egy egyszerű rendszer csak egy működőképes és egy meghibásodott állapotot tartalmazhat. Egy hibatűrő rendszerhez általában további állapotok szükségesek, például teljes redundancia, leromlott állapot, meghibásodás, javítás alatt vagy pótalkatrészre várakozás. Az átmenetek ezeket az állapotokat kapcsolják össze.

Egy meghibásodási ráta a teljesen működőképes állapotból leromlott állapotba helyezheti a rendszert. Egy újabb meghibásodás a leromlott állapotból elérhetetlenné teheti. A javítási ráta visszaállíthatja a teljes működőképességet. A modell kiszámítja annak valószínűségét, hogy a rendszer az idő során az egyes állapotokban tartózkodik.

Ez a felépítés különösen hasznos javítható rendszerek esetén. Képes megjeleníteni a redundanciát, a készenléti berendezéseket, a diagnosztikai lefedettséget, a karbantartási reakciót és a részleges termelési kapacitást. Az egyszerű megbízhatósági képlettel ellentétben megmutatja, hogy a rendszer mennyi ideig maradhat sebezhető az első meghibásodás után.

6. ábra. A Markov-modellek leírják, hogyan mozognak a rendszerek az ép, leromlott, meghibásodott és javított állapotok között.

A kétállapotú modell biztosítja az alapelvet

A legegyszerűbb Markov-modell egy működőképes és egy meghibásodott állapotot tartalmaz. A meghibásodási ráta szabályozza az átmenetet a működőképes állapotból a meghibásodott állapotba. A javítási ráta szabályozza a visszatérést a működőképes állapotba. Ezen átmenetek alapján a modell képes megbecsülni a rendelkezésre állást egy meghatározott időszak alatt vagy stacionárius állapotban.

Ez a modell hasznos az egyszerűen javítható berendezésekhez, de nem írja le teljes körűen a legtöbb redundáns automatizálási rendszert. Egy kétcsatornás vezérlő az egyik csatorna meghibásodása után is működőképes maradhat. A rendszer működőképes marad, de elveszíti a redundanciát. Ezzel leromlott állapotba kerül, és nagyobb mértékben ki van téve egy második meghibásodásnak.

A csökkent üzemképességű állapot hozzáadásával a modell kiszámíthatja, hogy a rendszer milyen gyakran és mennyi ideig működik teljes védelem nélkül. A javítás sebessége rendkívül fontos. A megbízható komponensekből álló rendszer is túl sok időt tölthet csökkent üzemképességű állapotban, ha a hibadiagnosztika, a tartalék szállítása vagy a karbantartási jóváhagyás lassú.

A modell a felismert és a fel nem ismert meghibásodásokat is megkülönböztetheti. Egy felismert csatornahiba azonnali javítást indíthat el. Egy fel nem ismert hiba rejtve maradhat egy igény fellépéséig vagy egy másik meghibásodás bekövetkeztéig. A diagnosztikai lefedettség módosítja az átmeneti struktúrát, ezáltal pedig a számított rendelkezésre állást és kockázatot is.

Példa: Kettős redundáns vezérlőpár

Tekintsünk két, redundáns párba rendezett vezérlőt. Az első állapot azt jelenti, hogy mindkét vezérlő egészséges. A második állapot azt jelenti, hogy az egyik vezérlő meghibásodott, miközben a másik fenntartja az irányítást. A harmadik állapot mindkét vezérlő kiesését és az irányítás teljes elérhetetlenségét jelenti.

A modell tartalmazza az egyes vezérlők meghibásodási arányát és az észlelést követő javítási arányt. Tartalmazhatja az átkapcsolás sikertelenségét, a közös tápellátás kiesését és a közös szoftverhibát is. Ezek a további átmenetek megakadályozzák, hogy az elemzés tökéletes függetlenséget feltételezzen.

Az eredmények megkülönböztethetik a teljes redundancián alapuló rendelkezésre állást a funkcionális rendelkezésre állástól. A rendszer az év nagy részében képes lehet a folyamat vezérlésére, miközben jelentős számú órán keresztül csak egy egészséges vezérlővel működik. Ez a csökkent üzemképességnek való kitettség kritikus alkalmazás esetén elfogadhatatlan lehet.

A modell össze tudja hasonlítani a fejlesztési stratégiákat. A tartalék gyorsabb cseréje hatékonyabban csökkentheti a csökkent üzemképességnek való kitettséget, mint egy harmadik vezérlő hozzáadása. A jobb diagnosztika nagyobb előnyt jelenthet, mint a hardver meghibásodási arányának csekély csökkentése. A Markov-elemzés mérhetővé teszi ezeket az átváltásokat.

A készenléti berendezésekhez többre van szükség, mint egy aktív meghibásodási állapotra

A készenléti redundancia további viselkedési formákat vezet be. Egy készenléti szivattyú állhat mindaddig, amíg az üzemi szivattyú meg nem hibásodik. A készenléti egységben lehet rejtett hiba, előfordulhat, hogy nem indul el, vagy átkapcsolási logikai problémába ütközhet. Az elzárószelepek is meghibásodhatnak, és nem állnak a szükséges helyzetbe.

A Markov-modell tartalmazhat állapotokat az aktív berendezés üzemképességére, a készenléti berendezés elérhetetlenségére, az átkapcsolás sikertelenségére, a csökkent kapacitásra és a rendszer teljes kiesésére. A működéspróba a rendszert egy ismeretlen, nyugalmi állapotból egy ismert állapot felé mozdítja. A tesztek közötti időköz befolyásolja, hogy a rejtett hibák mennyi ideig maradhatnak fenn.

A karbantartási szabályzatok ugyanebben a struktúrában értékelhetők. A rövidebb tesztelési időközök javítják a rejtett hibák észlelését, de növelik a karbantartási munkaterhet, és további hibákat okozhatnak. A modell össze tudja hasonlítani ezeket az ellentétes hatásokat, ahelyett hogy azt feltételezné, hogy a gyakoribb tesztelés mindig jobb.

A készenléti elemzésnek a javítási logisztikát is figyelembe kell vennie. Egy meghibásodott készenléti komponens nem feltétlenül szakítja meg azonnal a termelést, ezért a javítás késhet. Ez a késedelem védelmi tartalék nélkül hagyja a rendszert, ha az aktív egység később meghibásodik. Ezért az üzemeltetési prioritások legalább annyira befolyásolják a megbízhatóságot, mint a hardver jellemzői.

A Markov-feltételezés egyszerre biztosít egyszerűséget és szab korlátokat

Az alapvető Markov-modell azt feltételezi, hogy a jövőbeli átmeneti viselkedés az aktuális állapottól, nem pedig a teljes előzménytől függ. Ez a feltételezés leegyszerűsíti a matematikát, és gyakran állandó átmeneti rátákat igényel. Egyes ipari berendezések korlátozott időszakban megfelelően közelíthetők ezzel a modellel.

Az öregedés és a felhalmozódó károsodás sértheti ezt a feltételezést. Egy erősen kopott csapágy jövőbeli meghibásodási viselkedése nem azonos egy új csapágyéval, még akkor sem, ha jelenleg mindkettő üzemel. További degradációs állapotokkal közelíthető az öregedés, míg a pontosabb ábrázoláshoz fél-Markov- vagy más modellekre lehet szükség.

Az állapottér-robbanás további kihívást jelent. Minden komponensállapot megsokszorozhatja a lehetséges rendszerállapotok számát. Egy összetett redundáns üzem rövid idő alatt több ezer vagy akár több millió kombinációt eredményezhet. Az elemzés kezelhetőségének megőrzéséhez modellredukcióra, csoportosításra vagy szimulációra lehet szükség.

A modellnek elegendő részletet kell tartalmaznia a döntés támogatásához, de nem kell minden fizikai változást megjelenítenie. A túlzott összetettség karbantartási és validálási problémákat okoz. A túl egyszerű modell elrejti a fontos viselkedést, míg a túl részletes modell magyarázhatatlanná válik.

Mikor működik jól a Markov-modellezés — és mikor nem

A Markov-modellezés jól alkalmazható javítható redundáns rendszerekre, készenléti berendezésekre, csökkentett üzemmódokra és diagnosztikai lefedettségre. Támogatja a rendelkezésre állás elemzését, és megmutatja, hogyan változtatja meg a karbantartási reakció a rendszer kitettségét. Különösen hasznos, amikor a meghibásodási és javítási állapotok sorrendje számít.

A módszer a helyes állapotdefinícióktól és átmeneti rátáktól függ. Az állandó rátákat feltételező modellek nem feltétlenül tükrözik az öregedést, a környezeti változásokat vagy a karbantartás minőségét. A közös okú meghibásodásokat explicit módon kell modellezni, nem pedig a független komponensek rátáiba rejtve.

Az eredményeket érzékenységvizsgálattal kell alátámasztani. A csapatnak meg kell vizsgálnia, hogyan változnak a következtetések a meghibásodási arányok, a javítási idők, a diagnosztikai lefedettség és a közös okú meghibásodásokra vonatkozó feltételezések változásakor. Az a kialakítás, amely csak egyetlen optimista feltételezés mellett tűnik elfogadhatónak, nem tekinthető robusztusnak.

A Markov-modellek elemzési eszközök, nem pedig fizikai bizonyítékok. A tesztelés, az üzemeltetési tapasztalatok, az FMEA és az FTA továbbra is szükségesek. A modell segít összehasonlítani a stratégiákat, de nem helyettesítheti a tényleges architektúra ellenőrzését.

Az öt módszer egyetlen megbízhatósági rendszerként

Az öt technika akkor nyújtja a legnagyobb értéket, ha összekapcsolják őket. Az FMEA a tervezés során azonosíthatja az egyes komponensek részletes meghibásodási módjait. Ezután az FTA meghatározhatja, mely kombinációk járulnak hozzá egy kritikus rendszereseményhez. A Markov-modellezés leírhatja, hogyan viselkedik a rendszer az első meghibásodás után és a javítás során.

A Monte Carlo-szimuláció olyan bizonytalan bemeneteket vizsgálhat, mint a javítás időtartama, a pótalkatrész szállítása, az időjárás és a karbantartási terhelés. Az RCA valós meghibásodások után bizonyítékot szolgáltat, és feltárhatja azokat a feltételezéseket, amelyeket az eredeti modellek figyelmen kívül hagytak. A modelleket ezután frissíteni kell, nem pedig történeti dokumentumként megőrizni.

Tegyük fel, hogy egy FTA két vezérlő meghibásodását függetlennek kezeli. Egy későbbi RCA kimutatja, hogy mindkét vezérlő azért hibásodott meg, mert egy karbantartó technikus ugyanazt a hibás konfigurációt töltötte be. A hibafának hozzá kell adnia egy közös karbantartási eseményt. A Markov- és Monte Carlo-modelleknek szintén tartalmazniuk kell az új függőséget.

Ez a visszacsatolási folyamat élő megbízhatósági programot hoz létre. A prediktív elemzés irányítja a tervezést, az üzemi bizonyítékok ellenőrzik a feltételezéseket, a vizsgálati eredmények pedig javítják a modellek következő generációját. A megbízhatósági munka az egyszeri projektkövetelmény helyett a rendszer életciklusának részévé válik.

A közös okú meghibásodások a teljes redundáns architektúrát meghiúsíthatják

A közös okú meghibásodások egyetlen mögöttes feltételen keresztül több csatornát érintenek. Gyakori példák a közös tápellátás, hűtés, hálózati infrastruktúra, szoftver, környezeti kitettség és karbantartási gyakorlatok. Ezek a meghibásodások különösen veszélyesek, mert meghiúsíthatják a papíron erősnek tűnő redundanciát.

A fizikai elkülönítés csökkent bizonyos közös okokat. A különböző berendezések vagy szoftverek más okokat mérsékelhetnek. A független ellenőrzés csökkentheti a karbantartási és konfigurációs hibákat. A diverzitás azonban növeli a képzés, a pótalkatrészek, a tesztelés és az integráció összetettségét is.

A megfelelő megoldás a kockázattól függ. Különböző vezérlőtechnológiák telepítése csökkentheti a közös szoftverhibák kockázatát, ugyanakkor új kommunikációs és karbantartási kihívásokat teremthet. A különálló tápellátások csekély előnyt nyújthatnak, ha ugyanabban az árvízveszélyes szekrényben maradnak. A megbízhatósági módszerek segítenek azonosítani, mely diverzitási intézkedések kezelik a hiteles meghibásodási mechanizmusokat.

A közös okú meghibásodásokra vonatkozó feltételezéseknek minden kvantitatív modellben láthatónak kell lenniük. A redundáns csatornák tökéletesen függetlenként való kezelése szinte mindig túlzottan optimista eredményt ad. Az üzemi tapasztalatok és az RCA megállapításai értékes bizonyítékot szolgáltatnak e függőségek becsléséhez.

A diagnosztikai lefedettség meghatározza, meddig marad sérülékeny a rendszer

Egy redundáns rendszer nem kezelhető hatékonyan, ha a meghibásodások rejtve maradnak. A diagnosztikai lefedettség az automatikus vagy manuális ellenőrzésekkel észlelt releváns hibák arányát írja le. A magas lefedettség csökkenti az öntudatlanul csökkent teljesítményű állapotban töltött időt. Emellett lehetővé teszi a karbantartás számára a redundancia helyreállítását, mielőtt újabb meghibásodás következne be.

A diagnosztikai állításokat körültekintően kell megvizsgálni. Egy vezérlő észlelheti a belső processzorhibákat, de nem feltétlenül érzékeli a terepi huzalozás minden hibáját. Egy kommunikációs modul észlelheti a kapcsolat teljes megszakadását, miközben nem ismeri fel a helytelen adatleképezést. Egy tápegység teljes kimeneti kiesés után riaszthat, de a fokozatos állapotromlásra nem feltétlenül ad figyelmeztetést.

A működéspróba azokat a hibákat fedi fel, amelyeket a folyamatos diagnosztika nem észlel. A tesztintervallum befolyásolja a kitettséget. A hosszabb intervallumok lehetővé teszik, hogy a rejtett hibák tovább fennmaradjanak, míg a nagyon rövid intervallumok növelik a karbantartási terhet és a teszt által előidézett kockázatot. Az FMEA, a Markov-elemzés és az üzemi tapasztalatok támogathatják a kiegyensúlyozott intervallum meghatározását.

A tesztelésnek a teljes funkcióra ki kell terjednie. Egy PLC-bemenet aktiválása nem bizonyítja, hogy a terepi kapcsoló, a huzalozás, a logika, a kimenet és a végrehajtó elem mind megfelelően működik. A megbízhatósági elemzésnek pontosan meg kell határoznia, hogy az egyes diagnosztikai vagy működéspróbák mely hibákat képesek feltárni.

A javítási idő gyakran ugyanolyan fontos, mint a meghibásodási arány

A megbízhatósági programok gyakran az alkatrész-meghibásodások gyakoriságának csökkentésére összpontosítanak. A javítási idő ugyanolyan fontos lehet a hibatűrő rendszerekben. Az első csatorna meghibásodása után a rendszer tovább működhet, de sebezhető marad. A hosszú javítási késedelmek növelik annak valószínűségét, hogy egy második meghibásodás teljes kiesést okoz.

A diagnózis, a jóváhagyások, a technikusok rendelkezésre állása, a pótalkatrészek, a belépési engedélyek és a termelési feltételek mind befolyásolják a helyreállítási időt. Egy alkatrész cseréje tizenöt percet vehet igénybe, miután a megfelelő pótalkatrész eljutott a szekrényhez. A tényleges kiesési idő mégis napokig tarthat, ha a pótalkatrészt nemzetközileg kell beszerezni.

A továbbfejlesztett diagnosztika csökkentheti a hibahely meghatározásához szükséges időt. A szabványosított modulok és az előre konfigurált tartalékok csökkenthetik a csere idejét. A helyi készlet, az egyértelmű eszkalációs eljárások és a távoli mérnöki támogatás csökkenthetik a logisztikai késedelmeket. A Markov- és Monte-Carlo-modellek számszerűsíthetik e fejlesztések értékét.

A legjobb megbízhatósági beruházás nem mindig az erősebb hardver. Egyes rendszerekben a javítási idő csökkentése nagyobb kockázatcsökkentést eredményezhet, mint az alkatrész-meghibásodási arány csekély javulása. Az elemzésnek mindkét lehetőséget össze kell hasonlítania.

A megbízhatósági elemzés alkalmazása DCS- és PLC-architektúrákra

A vezérlőrendszer megbízhatósága nem csak a központi processzortól függ. A mérnököknek felül kell vizsgálniuk a vezérlőket, az I/O-modulokat, a kommunikációs hálózatokat, a tápegységeket, a szervereket, a kezelőállomásokat, az időszinkronizálást, a terepi interfészeket és a támogató közműveket. Minden megosztott elem közös függőséggé válhat.

A redundáns vezérlők megoszthatnak egy I/O-rackot. A redundáns szerverek függhetnek egy hálózati kapcsolótól vagy egy tárolórendszertől. A távoli I/O-hálózatok külön kommunikációs csatornákat használhatnak, amelyek ugyanazon a fizikai útvonalon haladnak. A teljes körű elemzésnek a terepi eszköztől a végső vezérlési műveletig kell követnie a funkciót.

A meghibásodás utáni szükséges működést egyértelműen meg kell határozni. A folyamat folytatódhat a fennmaradó vezérlővel, átválthat kézi működtetésre, vagy ellenőrzött leállásba léphet. A karbantartó személyzetnek tudnia kell azonosítani a meghibásodott csatornát, és úgy helyreállítani a rendszert, hogy az épen maradt csatorna működését ne zavarja.

A vezérlőrendszer-korszerűsítést tervező szervezetek áttekinthetik a folyamatautomatizálási architektúrákban használt tipikus DCS-vezérlőrendszer-komponenseket is. Az alkatrészek kiválasztását mindig a teljes alkalmazás megbízhatósági követelményeihez kell igazítani, nem pedig az egyes termékek elszigetelt jellemzőihez.

A megbízható modellek megbízható karbantartási adatoktól függenek

A kvantitatív megbízhatósági elemzés csak annyira erős, amennyire az alapjául szolgáló adatok. A karbantartási nyilvántartásoknak meg kell különböztetniük a funkcionális meghibásodást, a tervezett cserét, az ellenőrzést és a módosítást. A meghibásodás dátumának azt az időpontot kell jelölnie, amikor a funkció kiesett, míg a helyreállítás dátumának azt, amikor az üzemeltetés ismét ténylegesen elérhetővé vált.

Az eszközazonosítóknak egységesnek kell maradniuk a historianban, a karbantartási rendszerben, a rajzokon és a pótalkatrész-adatbázisban. A hibakódoknak a mechanizmusokat, nem pedig homályos tüneteket kell leírniuk. A „Leállt” kevés elemzési értéket hordoz, míg a „kenőanyag-szennyeződést követő csapágyszorulás” támogatja a későbbi modellezést és megelőzést.

Az üzemeltetési kitettséget szintén figyelembe kell venni. Egy folyamatosan üzemelő szivattyú nem hasonlítható össze közvetlenül egy csak teszteléskor működő tartalék szivattyúval. A hőmérséklet, a páratartalom, a szennyeződés, a rezgés, az elektromos igénybevétel és a technológiai terhelés magyarázatot adhat az egyébként azonos alkatrészek közötti különbségekre.

Az adattisztítást mérnöki munkaként, nem pedig adminisztratív előkészítésként kell kezelni. A helytelen besorolások torzíthatják a meghibásodási arányokat, a javítási eloszlásokat és a modellek következtetéseit. Az elemzőknek a szokatlan eredményeket a karbantartási és üzemeltetési munkatársakkal együtt kell felülvizsgálniuk, mielőtt elfogadnák azokat.

Gyakorlati megbízhatóság-javítási munkafolyamat

Egy megbízhatósági projektnek a szükséges funkció és a rendszerhatár meghatározásával kell kezdődnie. A csapatnak rögzítenie kell, milyen teljesítmény szükséges normál üzem közben és minden hitelesen bekövetkező hiba után. Össze kell gyűjteni a rajzokat, kézikönyveket, karbantartási előzményeket, üzemeltetési eljárásokat, riasztási nyilvántartásokat és a korábbi incidensekről készült jelentéseket.

Az FMEA ezt követően azonosíthatja az alkatrészszintű meghibásodási módokat és a gyenge észlelési kontrollokat. Az FTA megvizsgálhatja a kritikus csúcseseményeket és a megosztott függőségeket. A Markov-modellezés értékelheti a leromlott állapotokat és a javítási reakciót, míg a Monte Carlo-szimuláció megjelenítheti a meghibásodásokkal, karbantartással és logisztikával kapcsolatos bizonytalanságot.

A korábbi incidenseket RCA alapján kell felülvizsgálni. A megállapításokat fel kell használni a tervezési elemzések és a kvantitatív feltételezések frissítésére. Az intézkedéseket a következmény, a valószínűség, a felismerhetőség, a kitettség, a javítási idő és a költség alapján kell rangsorolni.

Minden intézkedéshez felelőst, határidőt és hatékonyság-ellenőrzést kell rendelni. Az elemzéseket frissíteni kell jelentős berendezésmódosítások, szoftverfrissítések, folyamatmódosítások vagy a karbantartási stratégia változásai után. A megbízhatóság folyamatos mérnöki tevékenység, nem pedig egyszer elkészített és eltárolt jelentés.

A gyenge hibatűrési állításokat feltáró kérdések

Az alapos felülvizsgálat azt vizsgálja, mely funkciónak kell elérhetőnek maradnia, és mely hibákat képes a rendszer elviselni. Azt is vizsgálja, hogy a redundáns csatornák fizikailag, elektromosan és logikailag függetlenek-e. Továbbá azt, hogyan észlelik a rejtett hibákat, és a rendszer mennyi ideig maradhat leromlott állapotban a javítás előtt.

A csapatnak azonosítania kell a hosszú beszerzési vagy cseréhez szükséges átfutási idővel rendelkező komponenseket, és meg kell határoznia, hogy egyetlen karbantartási hiba érinthet-e több csatornát. A szoftver- és konfigurációfüggőségek ugyanolyan figyelmet érdemelnek, mint a hardver. A kezelőknek meg kell érteniük, hogyan viselkedik a rendszer hiba után, és mely manuális műveletek maradnak elérhetők.

A meghibásodási és javítási feltételezéseket lehetőség szerint üzemi bizonyítékokkal kell alátámasztani. A helyesbítő intézkedéseket végrehajtásuk után ellenőrizni kell. A bizonyító teszteknek a teljes védelmi funkciót kell igazolniuk, nem csupán az egyes berendezések válaszát.

Ezek a kérdések értékesebbek annál az általános kijelentésnél, hogy a rendszer redundáns. Összekapcsolják a hibatűrést a tényleges architektúrával, az üzemeltetési környezettel és a karbantartási képességgel.

Végső szempontok

A hibatűrés alapvető fontosságú, amikor az állásidő, a nem biztonságos működés vagy az irányítás elvesztése nem fogadható el. A redundancia önmagában azonban nem hoz létre megbízható rendszert. A mérnököknek ismerniük kell a hibamódokat, a közös függőségeket, a diagnosztikai lefedettséget, a leromlott üzemet, a javítási viselkedést és az üzemeltetési következményeket.

A hibafaelemzés bemutatja, hogyan vezethetnek a meghibásodások kombinációi kritikus eseményhez. Az FMEA szisztematikusan áttekinti az egyes hibamódokat és azok hatásait. A Monte Carlo-szimuláció bizonytalan forgatókönyveket értékel, míg a gyökérok-elemzés a valós meghibásodásokat megelőző tudássá alakítja. A Markov-modellezés megmagyarázza, hogyan mozognak a javítható rendszerek a működőképes, leromlott, meghibásodott és helyreállított állapotok között.

Mindegyik módszernek vannak korlátai, együtt azonban erős megbízhatósági keretrendszert biztosítanak. A tervezési vizsgálatokat az üzemeltetési tapasztalatok alapján frissíteni kell, az események feltárásának eredményei pedig javítsák a jövőbeli modelleket. Az eredményeknek hatást kell gyakorolniuk az architektúrára, a karbantartásra, a pótalkatrészekre, a tesztelésre, a képzésre és az eljárásokra.

A cél nem egy olyan rendszer létrehozása, amely soha nem hibásodik meg. A cél a hibák korai észlelése, következményeik korlátozása, a szükséges funkció fenntartása, valamint a teljes működőképesség kiszámítható helyreállítása. Ez az ipari hibatűrés gyakorlati jelentése.