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

Miért igényel a hibatűrés többet redundáns hardvernél

Minden ipari rendszerben előbb-utóbb meghibásodások lépnek fel. Az érzékelők elállítódnak, a tápegységek állapota romlik, a kommunikációs kapcsolatok instabillá válnak, a mechanikai komponensek pedig az ismételt terhelés hatására kopnak. A hibatűrő mérnöki tervezés célja ezért nem az, hogy soha meg nem hibásodó berendezéseket hozzon létre. Hanem annak biztosítása, hogy az előre jelezhető meghibásodások ne váljanak azonnal irányítatlan rendszerhibákká.

A hibatűrő rendszer akkor is képes elfogadható funkciót biztosítani, 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ökkent kapacitás addig, 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 üzem elfogadhatatlan kockázatot jelentene.

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ó ugyanazon impulzusvezetéken osztozhat, é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.

Ehhez a munkához öt módszer különösen hasznos. 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 milyen hatással vannak a teljes rendszerre. A Monte Carlo-szimuláció számos lehetséges üzemeltetési és meghibásodási forgatókönyvön keresztül tárja fel a bizonytalanságot, míg a gyökérok-elemzés azt vizsgálja, miért következett be egy tényleges esemény. A Markov-modellek leírják, hogyan mozognak a javítható rendszerek az idő múlásával a működőképes, leromlott, meghibásodott és helyreállított állapotok között.

1. ábra. Az ipari rendszerek nem tudnak minden meghibásodást elkerülni, de a fegyelmezett megbízhatóságmérnökség számos meghibásodást megakadályozhat abban, hogy teljes körű üzemzavarrá váljon.

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 írja le, hogy a berendezés egy meghatározott időszakon keresztül ellátja az előírt funkcióját. A rendelkezésre állás azt írja le, hogy a berendezés készen áll-e, amikor a folyamatnak szüksége van rá. Egy rendszer időnként meghibásodhat, és mégis magas rendelkezésre állást tarthat fenn, ha a javítás gyors, a pótalkatrészek pedig 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 jelenti, hogy a meghibásodások a személyzet, a környezet és a berendezések tekintetében 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ítá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 szakterü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ól is függ. A mérnökök addig nem tudják megállapítani, hogy egy rendszer hibatűrő-e, amíg nem tudják, milyen teljesítménynek kell fennmaradnia minden egyes 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ás képességét. Egy folyamatirányító rendszernek csak arra lehet szüksége, hogy stabil működést tartson fenn, amíg az egyik vezérlőt kicserélik. Egy villamos védelmi rendszer megkövetelheti a független csatornákat, hogy egyetlen közös hiba se iktathassa ki az elsődleges és a tartalék védelmet is. 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észeivel foglalkozik. Az FTA egy nem kívánt rendszereseményből indul ki, és visszafelé halad azokhoz a meghibásodásokhoz, amelyek azt okozhatják. Az FMEA komponensekből vagy funkciókból indul ki, és előre halad az egyes meghibásodási módok következményein keresztül. A Monte Carlo-szimuláció az ismételten, sok véletlenszerűen generált feltétel mellett lefuttatott rendszer modellen keresztül vizsgálja a bizonytalanság hatását.

Az RCA rendszerint egy tényleges esemény után kezdődik, és bizonyítékok segítségével választja 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öttük történő átváltásának 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 feltett kérdéstől függ. Egy csapat, amely azt vizsgálja, hogyan következhet be a hűtés teljes megszűnése, általában az FTA-val kezdi. Egy tervezőcsapat, amely minden lehetséges távadó-, vezérlő- és szelephibát áttekint, többet profitálhat az FMEA-ból. Egy eszközmenedzser a bizonytalan karbantartási időközök összehasonlítására Monte Carlo-szimulációt használhat, míg egy redundáns vezérlőpár hosszú távú rendelkezésre állását számító megbízhatósági mérnök inkább Markov-modellt választhat.

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ában alapeseményekké válnak. Az RCA megállapításai kijavíthatják a Markov-modell irreális meghibásodási feltételezéseit. 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 deduktív módszer, amely egyetlen, egyértelműen meghatározott nem kívánt eseményből indul ki. Ezt az eseményt csúcseseménynek nevezzük. Megfelelő példák többek között a kazán teljes tápvízvesztése, a turbina-lekapcsolási funkció meghibásodása, a vezérlő kommunikációjának teljes megszűnése vagy a reaktorban bekövetkező szabályozatlan nyomásemelkedés. A meghatározásnak kellően konkrétnak kell lennie ahhoz, hogy érdemi elemzést tegyen lehetővé.

A kizárólag „rendszerhiba” formában megadott csúcsesemény általában túl homályos. Nem határozza meg, hogy melyik funkció hibásodott meg, mennyi ideig tartott a hiba, vagy melyik üzemállapot volt érvényben. Jobb meghatározás lehet például: „a teljes hűtővíz-áramlás kiesése normál termelés közben több mint hatvan másodpercre”. Ez a megfogalmazás világos határt ad az elemzésnek.

A csúcsesemény meghatározása után a csapat azonosítja azokat a közvetlen feltételeket, amelyek előidézhetik. Ezeket a feltételeket alacsonyabb szintű eseményekre bontják mindaddig, amíg az elemzés el nem ér az alapvető komponensmeghibásodásokhoz, külső zavarokhoz vagy emberi cselekvésekhez. A logikai kapuk összekapcsolják az eseményeket, és leírják, hogyan kombinálódnak. 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 egyidejű 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, folyamatirányítási, karbantartási és biztonsági szakemberek ugyanazt a rendszert közös nézőpontból tekintsék át. 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 csúcseseményből visszafelé haladva azonosítja az alacsonyabb szintű meghibásodások azon kombinációit, amelyek azt előidézhetik.

A 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 kiterjedhet a szivattyúkra, szelepekre, energiaelosztásra, műszerezettségre és a vezérlési logikára. 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 csúcseseményt.

A csapat ezután azonosítja a közvetlen okokat. A teljes hűtéskiesés bekövetkezhet azért, mert valamennyi szivattyú elérhetetlenné válik, mert a közös betápláló gyűjtővezeték elzáródik, vagy mert a leválasztó szelepek helytelenül zárnak. 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 megszűné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ítaná a döntést. A legalacsonyabb szintű eseményeket alapvető eseményekként kezelik, és meghibásodási valószínűségek vagy ráták rendelhetők hozzájuk. A logikai struktúra ezt követően minőségileg vagy mennyiségileg is kiértékelhető. Még pontos numerikus adatok hiányában is feltárhat a fa egyedi 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. Két esemény nem teljesen független, ha ugyanazon tápforrástól, környezettől, karbantartási tevékenységtől vagy szoftverhibától függ. E kapcsolatok figyelmen kívül hagyása miatt egy redundáns kialakítás lényegesen biztonságosabbnak tűnhet a valóságosnál.

A minimális vágathalmazok mutatják meg 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 értékesek 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 izolálá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. Egy gyakran fellépő meghibásodásokat magában foglaló kételemű kombináció jelentősebb lehet, mint egyetlen, rendkívül ritka külső esemény. Az észlelés és a javítás időtartama szintén befolyásolja a jelentőséget. Egy hónapokig észrevétlenül fennmaradó rejtett meghibásodás sokkal hosszabb kitettségi időt eredményez, mint egy azonnal észlelt és kijavított hiba.

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 berendezést. Az elemzés során mindvégig 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 olyan 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 képes elviselni egy szivattyú meghibásodását. Az egyszerű berendezésszámolás teljes redundanciára utal. A közös függőségek figyelembevételével azonban a hibafa-elemzés 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ú egy közös szívógyűjtőből szívhat, ugyanattól a vezérlőrendszertől függhet, vagy egyetlen szintmérés alapján kaphat parancsokat. Ezért egyetlen sínhiba, elzáródott szívógyűjtő vagy hibás közös jel egyszerre mindkét szivattyút működésképtelenné teheti. A látszólagos két szivattyús redundancia nem védene az ilyen közös meghibásodások ellen.

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

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

A hibafaelemzés alkalmazási területei – és korlátai

Az FTA különösen hatékony biztonsági funkciók, védelmi rendszerek, villamosenergia-elosztás, kommunikációs hálózatok és más, egyértelműen meghatározott nemkívánatos 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ény meghatározása nem megfelelő. A karbantartása akkor is nehézzé válhat, amikor a hibafa több ezer eseményre bővül. A dinamikus szekvenciák, a karbantartási viselkedés é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 beavatkozásokat szintén körültekintően kell kezelni. A kezelő reakciójának valószínűsége függ a riasztások minőségétől, az eljárások kialakításától, a képzéstől, a munkaterheléstől, a rendelkezésre álló időtől és a kezelő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 beavatkozás központi szerepet játszik a kimenetelben, a komoly elemzésekbe humán tényezőkkel foglalkozó szakértőket is be kell vonni.

Az FTA ezért akkor a leghatékonyabb, ha egy átfogóbb megbízhatósági program részeként alkalmazzák. Az FMEA részletes információt nyújthat az alkatrészek meghibásodási módjairól, 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 rendszerműködést teljes körűen leíró modellnek.

A hibamód- és hatáselemzés az alkatrésszel kezdődik

A hibamód- és hatáselemzés (FMEA) induktív megközelítést alkalmaz. A csapat nem egy kiinduló eseménnyel kezdi, hanem egy elemből, funkcióból vagy folyamatlépésből indul ki. Ezután azt vizsgálja, hogyan hibásodhatna 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ések felülvizsgálata során.

Egy nyomástávadó többféle módon is meghibásodhat. Kimeneti jele eltolódhat felfelé vagy lefelé, egyetlen értéken befagyhat, instabillá válhat, vagy teljesen megszűnhet. Mindegyik meghibásodási mód eltérő üzemeltetési következménnyel jár. A túl magas érték szükségtelen leállást okozhat, míg a túl alacsony érték elfedhet egy veszélyes nyomásállapotot.

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

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

Mit kell tartalmaznia egy hatékony FMEA-munkalapnak?

Egy hasznos FMEA-munkalap az elemmel és annak előírt funkciójával kezdődik. A hibamód azt írja le, hogyan veszíthető 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 szélesebb körű ü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 hiba bekövetkezik. Az észlelési kontrollok feltárják a hibát, mielőtt az elfogadhatatlan következményt okozna. Ilyenek 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 az előrejelző karbantartás.

Számos szervezet súlyossági, előfordulási és észlelhetőségi értékelést alkalmaz. Ezeket az értékeket néha összeszorozzák a kockázati prioritási szám kiszámítá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 azonos pontszámot eredményezhetnek akkor is, ha a következményeik alapvetően eltérnek.

Egy ritka, katasztrofális hiba nagyobb figyelmet érdemelhet, mint egy gyakori, kisebb kellemetlenség, még akkor is, ha a számított pontszámuk hasonló. Ezért a súlyosságot külön kell felülvizsgálni. A csapatoknak azokat az intézkedéseket is előnyben kell részesíteniük, amelyek megszüntetik a hibamechanizmust 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

Vegyü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 viselkedést.

A lehetséges hibamódok közé tartozik a szakadás, a rövidzár, a behegesztett érintkező, a magas szinten beragadt csatorna, az alacsony szinten beragadt csatorna, illetve a közös bemeneti tápellátás kiesése. Az elemzés azt is vizsgálja, hogy érzékelik-e a csatornák közötti eltérést. Ha mindkét csatorna egy közös terepi érintkezőn és egy kábelen osztozik, számos hiteles hibaforgatókönyv egyidejűleg érintheti mindkét csatornát.

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

Védelmi architektúrák esetében a mérnökök áttekinthetik a diagnosztikai lefedettségre, redundanciára és szabályozott hibaviselkedésre tervezett megfelelő ipari biztonsági modulokat is. A hardverkiválasztásnak 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, komponensek, anyagok és vezérlési funkciók képesek-e rendeltetésszerűen működni. A módszert általában 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, amikor a terv módosítása még nem válik költségessé.

A folyamat-FMEA a gyártási, összeszerelési, telepítési, üzembe helyezési vagy karbantartási tevékenységeket vizsgálja. Egy kapcsolószekrény elektromos kialakítása lehet helyes, a telepítési folyamat mégis laza sorkapcsokat, felcserélt polaritást, nem megfelelő biztosítékértékeket vagy hibás vezetékazonosítást okozhat. A karbantartási tevékenység nem megfelelő firmware-t, alkalmatlan pótalkatré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 kialakítását vizsgáljuk, számos életciklus-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 próbatesztelési eljárás módosítása új hibamódokat vezethet be. A korábbi munkalapok nem maradhatnak változatlanok, miközben az üzem körülöttük fejlődik.

Az FMECA formálisabb kritikussági értékelést tesz lehetővé

A hibamód-, hatás- és kritikusságelemzés (FMECA) a formális kritikussági számítások hozzáadásával bővíti az FMEA-struktúrát. A módszer alkalmazhat komponensenkénti meghibásodási rátákat, üzemeltetési kitettséget, küldetési szakaszokat, súlyossági kategóriákat és feltételes valószínűségeket. Akkor hasznos, amikor egy nagy rendszer számos hibamódot tartalmaz, és a mérnöki erőforrásokat a legjelentősebb hozzájárulókra kell összpontosítani.

A kritikussági számítások nagymértékben az adatok minőségétől függenek. Az általános meghibásodási ráta-adatbázisok kiindulópontot jelentenek, de nem feltétlenül tükrözik a valós telepítést. A hőmérséklet, a rezgés, a szennyeződés, az elektromos igénybevétel, a karbantartás minősége és az üzemciklus mind befolyásolja a tényleges teljesítményt. Ha elegendő üzemtörténet áll rendelkezésre, az üzemspecifikus bizonyítékoknak kell felváltaniuk az általános feltételezéseket.

Az elemzésnek különbséget kell tennie az azonnal észlelt, valamint a rejtve maradó meghibásodások között. Egy tartalék rendszer lappangó meghibásodása mindaddig nem befolyásolhatja a termelést, amíg egy másik alkatrész meg nem hibásodik, vagy igénybe nem kerül. A hosszú ideig fennálló rejtett kitettség egy viszonylag ritka meghibásodást is kiemelkedően fontossá tehet. Ezért az észlelési időközöket és a bizonyító tesztek 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ázatnak csekély az értéke, ha nem befolyásolja a rendszerarchitektúrát, a pótalkatrészeket, 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 magyará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 fordíthatnak a csekély értékű meghibásodási módok dokumentálására, miközben figyelmen kívül hagyják a rendszerek közötti kölcsönhatásokat. A hagyományos FMEA emellett jellemzően egyszerre egy meghibásodást vizsgál. Több egyidejű meghibásodás és a sorrendtől függő események nem mindig jelennek meg egyértelműen.

A pontozási rendszerek további kockázatot jelentenek. A csapatok módosíthatják az értékeléseket egy előnyben részesített prioritás elérése érdekében, vagy a végső számot objektívebbnek tekinthetik, mint az alapjául szolgáló 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 szabályozási követelményeket külön felül kell vizsgálni.

Az FMEA minősége az azt elvégző személyektől függ. Egyetlen tervező által összeállított munkalap nem feltétlenül veszi figyelembe az üzemeltetők és technikusok által ismert gyakorlati körülményeket. A megalapozott vizsgálatok a tervezési ismereteket a tényleges karbantartási előzményekkel és ü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 bemeneti értékeket tartalmaznak. Az alkatrészek élettartama változó, a javítás időtartama eltérhet, a pótalkatrészek szállítása kiszámíthatatlan, a környezeti igénybevételek pedig befolyásolják a meghibásodási viselkedést. Egyetlen átlagérték nem mindig képes ezeket az eltéréseket reprezentálni. A Monte Carlo-szimuláció ismételt véletlen mintavétellel kezeli ezt a problémát.

A mérnök először rendszer-modellt készít, és valószínűségi eloszlásokat rendel a bizonytalan változókhoz. A szimuláció ezután számos lehetséges kombinációt generál. Egy futtatás feltételezheti például, 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 jóval hosszabb javítást eredményezhet, mert a szükséges pótalkatré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 megbecsülheti a várható állásidőt, a termeléskiesést, a rendszer rendelkezésre állását, a küldetés sikerének valószínűségét, a tartalékalkatrész-igényt vagy a karbantartási költséget. Megmutathatja az olyan szélsőséges kimenetek valószínűségét is, amelyek egyetlen átlagértékben eltűnné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.

Hiteles Monte Carlo-megbízhatósági modell készítése

A szimuláció minősége a rendszermodelltől függ. 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ésedelmeket és az emberi reakciót is, ha ezek a tényezők befolyásolják a rendszer teljesítményét.

Minden szimulált futtatás végigköveti a rendszert az időben. Az alkatrészek a mintavételezett eloszlásoknak megfelelően 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 működőképes, csökkentett teljesítményű vagy üzemképtelen marad-e. A folyamat megismétlésével különböző teljesítménymérőszámokra vonatkozó becslések állíthatók elő.

Az ellenőrzés elengedhetetlen. A csapatnak össze kell vetnie a modellt egyszerűsített számításokkal, ismert üzemeltetési esetekkel és az üzem korábbi eredményeivel. A váratlan kimeneteket meg kell vizsgálni, nem pedig elfogadni pusztán azért, mert szoftverből származnak. Egy látványos szimuláció is lehet hibás, ha az alapul szolgáló logika hiányos.

Az érzékenységvizsgálat segít azonosítani, hogy mely feltételezések határozzák meg 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 előnyt érhet el 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, további azonos alkatrészek 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 élettartama alatti működésének leírására megfelelő lehet. A Weibull-eloszlás rugalmasabb, és képes reprezentálni a korai meghibásodásokat, a véletlenszerű meghibásodásokat vagy a kopás miatti elhasználódást. A lognormális eloszlások gyakran hasznosak a javítási idők és a több szorzó tényező által befolyásolt folyamatok esetében.

A választásnak a fizikai mechanizmust kell tükröznie, nem pedig a szoftveres kényelmet. A kopás által okozott csapágyhiba természeténél fogva nem ugyanúgy viselkedik, 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 az 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 adatokat gyakran meg kell tisztítani. A karbantartási rendszerek összetéveszthetik a tervezett cserét a funkcionális meghibásodással. A meghibásodás dátumát esetleg a munkamegrendelés megnyitásakor rögzítik, nem pedig a hiba bekövetkezésekor. Az eszközök nevei, 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 egy 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

Tekintsünk egy három gázkompresszorral rendelkező állomást. A teljes termeléshez két egységre van szükség, míg a harmadik tartalékkapacitást biztosít. Az egyes gépek üzemórái, karbantartási előzményei és hűtési teljesítménye eltérő. Egyszerre csak egy nagyobb javítás végezhető, mivel az állomásnak egyetlen szakosodott karbantartó csapata van.

A tartalék csapágyak szállítása több napot vesz igénybe, a hűtőrendszer meghibásodásai pedig magas környezeti hőmérsékleten gyakoribbá válnak. Ezeket a kölcsönhatásokat nehéz egyetlen egyszerű rendelkezésreállási egyenlettel ábrázolni. A Monte Carlo-modell mintavételezheti a kompresszorok meghibásodásait, a javítások időtartamát, 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 melletti rendelkezésre állást, a csökkentett kapacitású üzemelést és az állomás teljes leállását. A vezetőség összehasonlíthatja az alternatív beruházásokat. További csapágyak készleten tartása 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 időközöket is vizsgálhatja. A rövidebb megelőző karbantartási időközök csökkenthetik a meghibásodások számát, ugyanakkor növelhetik a tervezett leállási időt és a karbantartás által okozott hibák számát. A szimuláció lehetővé teszi mindkét hatás értékelését ugyanazon üzemelteté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ó lép kölcsönhatásba egymással. Összetett logisztikai folyamatokat, javítási várakozási sorokat, időjárási hatásokat, termelési igényt és karbantartási döntéseket is képesek modellezni. Az így kapott eloszlás több információt nyújt, mint egyetlen átlagérték. Emellett támogatja a kockázatalapú döntéshozatalt azáltal, hogy megmutatja a súlyos, de ritkán bekövetkező kimenetelek valószínűségét.

A fő gyengeség a modell hitelessége. Egy összetett szimuláció hamis magabiztosságot kelthet, mivel a kimenete számszerűen pontosnak tűnik. A program csak az elemző á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ényeket adhatnak.

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égeihez speciális mintavételi technikákra lehet szükség, mivel a hagyományos véletlenszerű szimuláció gyakorlati szempontból megvalósíthatatlanul nagy számú futtatást igényelne. A konfidenciaintervallumokat is fel kell tüntetni, 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 grafikonra alapozni, amelynek feltevései nem magyarázhatók el az üzemeltetési és mérnöki 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. Túlmutat a sérült alkatrész azonosításán. Egy motor leállhat például azért, mert megszorult egy csapágy, de a csapágy cseréje csak helyreállítja a működést. A vizsgálatnak meg kell állapítania, 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, szerelési 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 szüntettek meg, a pótalkatrészek nem voltak megfelelőek, vagy a termelési nyomás késleltette a korrekciós munkálatokat.

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 tartós megoldásnak tekintsen. 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 a 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 alaphelyzetbe á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 leselejtezhetik. Ezért a fegyelmezett RCA-folyamat a bizonyítékok megőrzésével kezdődik.

A csapatnak össze kell gyűjtenie a historizáló rendszer trendjeit, a riasztási listákat, a vezérlő eseménynaplóit, a relérekordokat, 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ői megfigyeléseket. Minden tételt azonosítani kell a forrása és az időpontja alapján. 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 vizsgálatra.

Az időszinkronizálás különös figyelmet igényel. Egy vezérlő, egy historizáló rendszer, egy védelmi relé, egy szerver és egy karbantartási rendszer eltérő időbélyegeket rögzíthet. A vizsgálóknak ezeket az eltéréseket korrigálniuk kell, mielőtt felépítik az eseménysort. Ellenkező esetben egy későbbi riasztás tévesen kezdeményező eseményként jelenhet meg.

A kezelőkkel folytatott interjúkat gyorsan, 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ényidővonal összeállítása a „Miért?” kérdés feltevése előtt

A jó idővonal elkülöníti az igazolt 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 az ellentmondásoknak láthatónak kell maradniuk.

A kezelőnél 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 sorrend megértése után a csapat olyan eszközöket használhat, mint az ötszörös „Miért?”, 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ó műszaki és szervezeti körülményt foglalnak magukban.

A vizsgálat nem érhet véget egyetlen valószínű magyarázat megtalálásával. Az alternatív hipotéziseket össze kell vetni a bizonyítékokkal. A nem alátámasztott feltételezéseket továbbra is feltételezésként kell megjelölni, nem pedig igazolt okként bemutatni.

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

Egy üzemben ismételten meghibásodik 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 visszaáll a normál működésre. Néhány hónappal később egy újabb hajtás meghibásodik. Az ismételt csere arra utal, hogy magával a hajtással valószínűleg nem teljes a probléma.

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 az ajánlott 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ül felgyülemlett nagy mennyiségű port tár fel.

A karbantartási előzmények azt mutatják, hogy 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 meghajtó a meghibásodott alkatrész, de a szekrény túl magas hőmérséklete a közvetlen fizikai ok. A korlátozott szellőzés és a hiányzó karbantartási feladat hozzájáruló, illetve szervezeti okok.

A helyesbítő intézkedésnek ezért túl kell mutatnia egy újabb hajtáscserén. Az üzem visszaállíthatja a szűrők karbantartását, hőmérséklet-riasztásokat telepíthet, javíthatja a szekrény hűtését, és felülvizsgálhatja a burkolat kialakítását. A hatékonyságot a következő magas hőmérsékletű időszakban kell igazolni.

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

Számos RCA-jelentés a helyesbítő intézkedések tervezése során gyengül el. A csapatok további képzést javasolhatnak anélkül, hogy bizonyítanák: a tudás elégtelen volt. Felülvizsgálhatják az eljárásokat, miközben a valódi probléma a berendezés gyenge kialakítása. Olyan ellenőrzéseket vezethetnek be, amelyek nem képesek észlelni a tényleges meghibásodási mechanizmust.

Minden intézkedésnek egy igazolt okot vagy hozzájáruló körülményt kell kezelnie. Felelőst, befejezési határidőt és meghatározott ellenőrzési módszert kell hozzárendelni. A szervezetnek különbséget kell tennie az ideiglenes kockázatcsökkentés, a helyesbítő intézkedés és a hosszú távú megelőző intézkedés között. A termelés helyreállítása nem azonos a megismétlődés megelőzésével.

A hatékonyságot a megvalósítás után is felül kell vizsgálni. Egy befejezett intézkedés nem feltétlenül 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 újabb kockázatot. Ez a visszacsatolás zárja le a megbízhatóság javításának körét.

A súlyos vizsgálatokhoz független felülvizsgálatra lehet szükség. Az eseményben szorosan érintett csapatokra hatással lehetnek a korábbi feltételezések vagy a szervezeti nyomás. Külső vagy több szakterületet bevonó felülvizsgálattal megkérdőjelezhető az elemzés, mielőtt a végső következtetéseket elfogadnák.

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 azt írják le, 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 interfészek, eljárások, létszámviszonyok, termelési elvárások, képzési rendszerek és berendezéstervek keretei 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őobjektum szinte teljesen egyformának tűnik. Egy technikus azért szerelhet be nem megfelelő alkatrészt, mert az azonosítás nem következetes. Egy vezető 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 is ugyanabba a hibába sodorjon. A hibáztatásközpontú 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ésekhez vezetnek, mint az, ha egyszerűen arra utasítjuk az embereket, hogy legyenek körültekintőbbek.

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

A gyökérok-elemzés a valós üzemeltetési tapasztalatokat megelőző tudássá alakítja. Feltárhatja azokat a tervezési hiányosságokat, karbantartási elmaradásokat, eljárásbeli problémákat és szervezeti nyomásokat, amelyeket a prediktív 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 hibákból való tanulásra. Továbbra is szükség van proaktív módszerekre, például az FMEA-ra és az FTA-ra. Az RCA-nak ezeket kell kiegészítenie azáltal, hogy a tényleges működésből származó bizonyítékokkal 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ő, odaillő magyarázatot részesítsék előnyben. A hiányzó bizonyítékok miatt a következtetések bizonytalanok maradhatnak. A jó jelentések világosan elkülönítik a megerősített okokat, a közreható tényezőket, a hipotéziseket és a még tisztázatlan kérdéseket.

Az RCA értéke a nyomon követéstől függ. Egy műszakilag 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 a változó állapotokon keresztül követik a rendszert

A Markov-modellezés a rendszert meghatározott működési állapotokon keresztül ábrázolja. Egy egyszerű rendszer mindössze 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 rendszert teljesen működőképes állapotból leromlott állapotba juttathatja. Egy újabb meghibásodás leromlott állapotból elérhetetlen állapotba juttathatja. 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 egyes állapotokban tartózkodik az idő folyamán.

Ez a struktúra 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 az első meghibásodás után mennyi ideig maradhat sérülékeny.

6. ábra. A Markov-modellek leírják, hogyan mozognak a rendszerek az egészséges, leromlott, meghibásodott és megjaví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 a működőképes állapotból a meghibásodott állapotba való átmenetet. A javítási ráta szabályozza a működőképes állapotba való visszatérést. Ezen átmenetek alapján a modell meg tudja becsülni a rendelkezésre állást egy meghatározott időszakban vagy állandósult állapotban.

Ez a modell hasznos egyszerű, javítható berendezések esetén, 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 továbbra is működőképes, de elveszíti redundanciáját. Ekkor leromlott állapotba kerül, és nagyobb mértékben van kitéve egy második meghibásodásnak.

A leromlott állapot bevezetésével 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 fontossá válik. Egy megbízható komponensekből álló rendszer is túl sok időt tölthet leromlott állapotban, ha a hibadiagnosztika, a pótalkatrész szállítása vagy a karbantartás jóváhagyása lassú.

A modell a felismert és a fel nem ismert meghibásodásokat is meg tudja különböztetni. Egy felismert csatornahiba azonnali javítást válthat ki. 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, és ezáltal a számított rendelkezésre állást és kockázatot is.

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

Vegyünk két, redundáns párba rendezett vezérlőt. Az első állapot azt jelenti, hogy mindkét vezérlő üzemképes. A második állapot azt jelenti, hogy az egyik vezérlő meghibásodott, miközben a második fenntartja a szabályozást. A harmadik állapot mindkét vezérlő kiesését és a szabályozás teljes elérhetetlenségét jelenti.

A modell tartalmazza az egyes vezérlők meghibásodási arányát és az észlelés utáni javítási arányt. Tartalmazhatja továbbá az átkapcsolás sikertelenségét, a közös tápellátás kiesését és egy 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 maradhat a folyamat szabályozására, miközben jelentős számú órán csak egy üzemképes vezérlővel rendelkezik. Ez a csökkent üzemképességű állapotnak való kitettség kritikus alkalmazás esetén elfogadhatatlan lehet.

A modell össze tudja hasonlítani a fejlesztési stratégiákat. A gyorsabb tartalékalkatrész-csere hatékonyabban csökkentheti a csökkent üzemképességű állapotnak 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 kismértékű csökkentése. A Markov-elemzés mérhetővé teszi ezeket az átváltási lehetőségeket.

A készenléti berendezéshez több kell, mint egy aktív meghibásodási állapot

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. A leválasztó szelepek is meghibásodhatnak, és nem állhatnak a szükséges helyzetbe.

Egy 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 bizonyító tesztelés a rendszert egy ismeretlen alvó állapotból egy ismert állapot felé mozdítja. A tesztek közötti időköz befolyásolja, hogy a rejtett meghibásodások 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 terhelést, és további hibákat okozhatnak. A modell össze tudja hasonlítani ezeket az egymással versengő 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 tartalmaznia kell. 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édelem nélkül hagyja a rendszert, amikor az aktív egység később meghibásodik. Ezért a működési prioritások legalább annyira befolyásolják a megbízhatóságot, mint a hardver jellemzői.

A Markov-feltételezés egyszerűséget és korlátokat egyaránt teremt

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 tesz szükségessé. 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ő működik. További degradációs állapotokkal közelíthető az öregedés, míg a pontosabb ábrázoláshoz fél-Markov-modellekre vagy más modellekre lehet szükség.

Az állapottér-robbanás szintén kihívást jelent. Minden komponens állapota 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áltozatot megjelenítenie. A túlzott összetettség karbantartási és validálási problémákat okoz. A túlságosan egyszerű modell elrejti a fontos viselkedést, míg a túl részletes modell magyarázhatatlanná válik.

A Markov-modellezés alkalmazási területei és korlátai

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

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 ábrázolni, nem pedig a független komponensrátákba rejtve kezelni.

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 ráták, 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 való alkalmazása

Az öt technika akkor nyújtja a legnagyobb értéket, ha összekapcsoljuk ő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, hogy ezek mely kombinációi 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 is vizsgálhat, mint a javítás időtartama, a pótalkatrészek 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 olyan feltételezéseket is feltárhat, amelyeket az eredeti modellek figyelmen kívül hagytak. A modelleket ezt követően frissíteni kell, nem pedig történelmi dokumentumként megőrizni.

Tegyük fel, hogy egy FTA két vezérlő meghibásodását függetlennek tekinti. Az RCA később kimutatja, hogy mindkét vezérlő azután hibásodott meg, hogy 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ányt mutat a tervezéshez, az üzemi bizonyítékok próbára teszik a feltételezéseket, a vizsgálatok eredményei 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 egy teljes redundáns architektúrát is hatástalaníthatnak

A közös okú meghibásodások egyetlen mögöttes feltételen keresztül több csatornát is é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 hatástalaní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. Az eltérő berendezések vagy szoftverek más okok hatását mérsékelhetik. 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 helyes 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ápegységek kevés előnyt nyújtanak, ha ugyanabban az árvízveszélyes szekrényben maradnak. A megbízhatósági módszerek segítenek azonosítani, hogy mely diverzitási intézkedések kezelik a hihető 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 optimista eredményt ad. Az üzemi tapasztalatok és az RCA megállapításai értékes bizonyítékot nyújtanak 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 azt mutatja meg, hogy az automatikus vagy manuális ellenőrzések a releváns hibák mekkora hányadát észlelik. A magas lefedettség csökkenti a tudtunkon kívüli csökkentett üzemképességben töltött időt. Lehetővé teszi azt is, hogy a karbantartás egy újabb meghibásodás bekövetkezése előtt helyreállítsa a redundanciát.

A diagnosztikai állításokat alaposan meg kell vizsgálni. Egy vezérlő érzékelheti a processzor belső hibáit, de nem feltétlenül észleli a terepi vezetékezés minden meghibásodását. Egy kommunikációs modul érzékelheti a kapcsolat teljes megszakadását, miközben nem ismeri fel a hibás adatleképezést. Egy tápegység teljes kimeneti kiesés után riaszthat, de a fokozatos leromlásra nem feltétlenül ad figyelmeztetést.

A működési próbák olyan hibákra terjednek ki, 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 üzemeltetési 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ési pró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ő a hibatűrő rendszerekben ugyanilyen fontos lehet. Az első csatorna meghibásodása után a rendszer tovább működhet, de sérülékeny 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 diagnosztika, 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 állásidő azonban napokkal is meghosszabbodhat, ha a pótalkatrészt nemzetközi forrásból kell beszerezni.

A továbbfejlesztett diagnosztika csökkentheti a hiba helyének 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észletek, az egyértelmű eszkalációs eljárások és a távoli mérnöki támogatás mérsékelhetik a logisztikai késedelmeket. A Markov- és Monte Carlo-modellek számszerűsíthetik e fejlesztések értékét.

A megbízhatóság javítására fordított legjobb 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ényez, mint az alkatrész meghibásodási arányának csekély javulása. Az elemzésnek össze kell hasonlítania a két lehetőséget.

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űszolgáltatásokat. Minden közös elem közös függőséggé válhat.

A redundáns vezérlők használhatnak egy közös I/O-rackot. A redundáns szerverek függhetnek egyetlen hálózati kapcsolótól vagy egyetlen 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ást követő szükséges működést egyértelműen meg kell határozni. A folyamat folytatódhat a megmaradt vezérlővel, átállhat kézi üzemre, vagy szabályozott leállásba léphet. A karbantartó személyzetnek tudnia kell azonosítani a meghibásodott csatornát, és a rendszer működését a működőképes csatorna zavarása nélkül helyreállítani.

A vezérlőrendszer-frissítést tervező szervezetek áttekinthetik a folyamat-automatizálási architektúrákban használt tipikus DCS-vezérlőrendszer-összetevőket is. Az alkatrészek kiválasztásának mindig a teljes alkalmazás megbízhatósági követelményeit kell követnie, nem pedig az elszigetelt termékjellemzőket.

A megbízható modellek megbízható karbantartási adatokra épülnek

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ó megszűnt, 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 az előzményadatbázisban, 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 képvisel, míg a „kenőanyag-szennyeződést követő csapágybesülés” támogatja a későbbi modellezést és megelőzést.

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

Az adattisztítást mérnöki munkának, nem pedig adminisztratív előkészítésnek kell tekinteni. 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 áttekinteniük, mielőtt elfogadják azokat.

Gyakorlati munkafolyamat a megbízhatóság javításához

Egy megbízhatósági projektet a szükséges funkció és a rendszerhatár meghatározásával kell kezdeni. A csapatnak rögzítenie kell, hogy normál üzem közben és minden hihető hiba után milyen teljesítmény szükséges. Ö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 eseményekről készült jelentéseket.

Az FMEA ezután azonosíthatja az alkatrészszintű meghibásodási módokat és a hiányos észlelési kontrollokat. Az FTA a kritikus csúcseseményeket és a közös függőségeket vizsgálhatja. 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 eseményeket RCA keretében felül kell vizsgá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éhez. Az intézkedéseket a következmények, 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, teljesítési határidőt és hatékonyság-ellenőrzést kell rendelni. Az elemzéseket frissíteni kell jelentősebb berendezésváltoztatások, szoftverfrissítések, folyamatmódosítások vagy karbantartási stratégiai változások után. A megbízhatóság folyamatos mérnöki tevékenység, nem pedig egyszer elkészített és archivált jelentés.

A gyenge hibatűrési állításokat leleplező 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. Arra is rákérdez, hogy a redundáns csatornák fizikailag, elektromosan és logikailag függetlenek-e. Azt is meg kell vizsgálni, hogyan észlelhetők a rejtett hibák, és a rendszer mennyi ideig maradhat leromlott állapotban a javítás előtt.

A csapatnak azonosítania kell a hosszú beszerzési vagy csereidejű alkatrészeket, és meg kell határoznia, hogy egyetlen karbantartási hiba érinthet-e több csatornát. A szoftveres és konfigurációs függőségeknek ugyanolyan figyelmet kell kapniuk, mint a hardvernek. A kezelőknek érteniük kell, hogyan viselkedik a rendszer egy 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 a végrehajtás után ellenőrizni kell. A működési próbáknak a teljes védelmi funkciót kell igazolniuk, nem csupán az egyes berendezések reakciójá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égekkel.

Végső gondolatok

A hibatűrés elengedhetetlen, ha 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 meg kell érteniük a hibamódokat, a közös függőségeket, a diagnosztikai lefedettséget, a korlátozott működést, a javítási folyamatot és az üzemeltetési következményeket.

A hibafaelemzés megmutatja, hogy a hibák milyen kombinációi vezethetnek kritikus eseményhez. Az FMEA szisztematikusan vizsgálja az egyes hibamódokat és azok hatásait. A Monte Carlo-szimuláció bizonytalan forgatókönyveket értékel, míg az RCA a valós hibákat megelőző tudássá alakítja. A Markov-modellezés megmagyarázza, hogyan mozognak a javítható rendszerek az ép, leromlott, meghibásodott és helyreállított állapotok között.

Mindegyik módszernek megvannak a maga 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, a rendellenességek kivizsgálásának eredményei pedig javítsák a jövőbeli modelleket. Az eredményeknek hatással kell lenniük 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, amelyben soha nem fordul elő hiba. 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.