Képesek-e az irányítópanelek önjavításra? Intelligensebb hibatűrő rendszerek tervezése
Az öngyógyító vezérlőpanelek fizikailag nem tudják megjavítani a meghibásodott hardvert, de a modern diagnosztika, a moduláris kialakítás, a redundancia és a peremhálózati intelligencia számos hibá...
Mi történik, amikor egy ipari vezérlőpanel még azelőtt észlel egy kialakuló hibát, hogy a kezelő felismerné a látható problémát?
Egy motorhajtás szabálytalan áramot kezdhet felvenni. Egy teljesítménymodul a normálisnál melegebben kezdhet működni. Időszakosan kommunikációs hibák jelentkezhetnek a vezérlőeszközök között.
Hagyományos rendszerben ezek az állapotok gyakran csak riasztás, kioldás vagy leállás bekövetkezése után válnak karbantartási problémává.
Az intelligensebb vezérlési architektúrák korábban is képesek reagálni.
Képesek észlelni a rendellenes állapotokat, elkülöníteni bizonyos hibákat, a funkciókat redundáns berendezésekre átkapcsolni, és részletes diagnosztikai információkkal ellátni a karbantartó személyzetet.
Ezt a koncepciót néha öngyógyító vezérlőpanelként írják le.
A kifejezést nem szabad szó szerint értelmezni. Egy vezérlőpanel önmagától nem tud megjavítani egy sérült kontaktort, megégett csatlakozót vagy meghibásodott hajtást.
Amit képes tenni, az bizonyos meghibásodások felismerése és előre meghatározott helyreállítási stratégiák alkalmazása a termelésre gyakorolt hatásuk korlátozására.
1. ábra. A moduláris ipari vezérlőpanelek biztosítják a diagnosztika, az elkülönítés és a strukturált alkatrészcserék alapját.
A gyenge pont gyakran nem maga a gép
A vezérlőpanelek a modern ipari berendezések jelentős részét koordinálják.
A PLC-k, tápegységek, relék, hajtások, kommunikációs modulok és I/O-eszközök együttműködve tartják fenn a kiszámítható működési sorrendet.
Egyetlen kis alkatrész meghibásodása ezért egy sokkal nagyobb folyamatot is érinthet.
Egy sérült relé megakadályozhatja a motor indítását. Egy meghibásodott tápegység egyszerre több vezérlőáramkört is kiiktathat. Egy kommunikációs probléma a vezérlő számára elérhetetlenné teheti az egyébként megfelelően működő berendezést.
A hagyományos karbantartási stratégiák ellenőrzésekkel, pótalkatrészekkel, megelőző cserével és a kezelő beavatkozásával kezelik ezeket a kockázatokat.
Ezek a gyakorlatok továbbra is szükségesek.
A korlátozó tényező a reakcióidő.
Ha a hibaészlelés elsősorban egy gép leállásától vagy attól függ, hogy a kezelő észrevesz-e egy riasztást, a folyamat már rendellenes üzemi állapotba került.
A modern vezérléstervezés egyre inkább arra törekszik, hogy még ezt megelőzően észlelje a romlást.
Mit jelent valójában az öngyógyítás?
Mérnöki értelemben az öngyógyítás inkább a hibaészlelés, a hibaelkülönítés és az automatizált helyreállítás kombinációjaként értelmezhető.
Egy praktikus architektúra több funkciót is elláthat.
Először a rendszer rendellenes jelet vagy üzemi állapotot észlel.
Másodszor, a diagnosztikai logika meghatározza, melyik eszköz, áramkör vagy folyamatterület érintett.
Harmadszor, a vezérlőrendszer, ahol az architektúra lehetővé teszi, elkülöníti az érintett funkciót.
Végül redundáns hardver vagy egy alternatív vezérlési útvonal a folyamat egy részét fenntarthatja, amíg a karbantartás beavatkozik.
A kezelő továbbra is riasztásokat, naplókat és diagnosztikai információkat kap.
A cél nem a meghibásodások megszüntetése. Hanem annak megakadályozása, hogy minden egyes hiba automatikusan az egész üzem leállásához vezessen.
A moduláris architektúra praktikussá teszi a hiba leválasztását
A hibatűrő működés a fizikai kialakítással kezdődik.
Az egyetlen, szorosan összekapcsolt villamos szerelvényként kialakított kapcsolószekrényt nehéz leválasztani, amikor egy alkatrész meghibásodik.
A moduláris architektúra egyértelműbb funkcionális határokat hoz létre.
A tápelosztás, a vezérlés, a kommunikáció, a hajtások és az I/O azonosítható szakaszokra osztható, megfelelő védelemmel és diagnosztikai hozzáféréssel.
Ez számos üzemeltetési előnnyel jár.
A hiba gyakran egy kisebb funkcionális területhez kapcsolható. A karbantartó személyzet gyorsabban azonosíthatja az érintett hardvert, a csere pedig strukturáltabbá válik.
A modularitás a szabványosított pótalkatrész-stratégiákat is támogatja.
Ahelyett, hogy minden alkatrészt kártyaszintig hibaelhárítanának, a technikusok az előre meghatározott modulokat kicserélhetik, és egy kialakított karbantartási eljárás szerint helyreállíthatják az üzemelést.
A feszültség alatt cserélhető hardver javíthatja ezt a megközelítést, ha az adott vezérlőplatform és alkalmazás támogatja a feszültség alatti cserét.
A feszültség alatti cserét azonban soha nem szabad pusztán azért feltételezni, mert egy rendszer moduláris.
A vezérlőnek, az I/O-platformnak, a villamos kialakításnak és a biztonsági eljárásnak kifejezetten támogatnia kell ezt.
A cserélhető vezérlőhardverre épülő rendszerek esetében az egyértelműen kategorizált I/O-modulok az életciklus-karbantartást és a pótalkatrész-tervezést is egyszerűsíthetik.
A prediktív felügyelet a meghibásodás előtti változásokat keresi
Az önmenedzselő vezérlési stratégiának információra van szüksége a berendezés állapotáról.
Ekkor válik fontossá az IIoT-alapú érzékelés és a prediktív karbantartás.
A modern felügyeleti rendszerek figyelemmel kísérhetik a villamos terhelést, a hőmérsékletet, a rezgést, a kommunikáció minőségét és más üzemi változókat.
Egyetlen mérés nem feltétlenül jelez problémát.
Gyakran a trend hasznosabb.
A fokozatosan melegedő kapocscsatlakozás olyan villamos állapotra utalhat, amely ellenőrzést igényel.
Egy fokozódó rezgési trendet mutató motor mechanikai ellenőrzést igényelhet, mielőtt az állapot nem tervezett leállást okozna.
Az ismétlődő áramkiegyenlítetlenség szintén hasznos diagnosztikai bizonyítékot szolgáltathat, ha a megfelelő villamos és mechanikai összefüggésekben értékelik.
A peremhálózati számítástechnika lehetővé teszi, hogy az elemzés egy része a gép közelében történjen.
Ahelyett, hogy minden nyers mérési adatot távoli szerverre továbbítana, egy peremhálózati eszköz helyben kiértékelheti a kiválasztott jeleket, és eseményeket generálhat az előre meghatározott feltételek észlelésekor.
Ez csökkentheti a válaszidőt, és korlátozhatja a szükségtelen adatforgalmat.
A diagnosztikának többet kell magyaráznia a „hibánál”
Az általános hiba kijelzése korlátozott értéket képvisel, ha a termelés már leállt.
A hatékony diagnosztikának meg kell határoznia, hol történt a probléma, és elegendő összefüggést kell biztosítania ahhoz, hogy a karbantartó személyzet kivizsgálhassa azt.
A modern vezérlők és intelligens eszközök a vezérlőhálózaton keresztül komponensszintű diagnosztikai információkat tehetnek hozzáférhetővé.
A HMI- vagy SCADA-réteg ezután konkrétabb riasztási információkat jeleníthet meg.
Ahelyett, hogy csak egy általános hajtáshibát jelentené, a rendszer azonosíthatja, melyik hajtás generálta a riasztást, és rögzítheti a kapcsolódó üzemi értékeket.
Az előzményként tárolt események abban is segítenek a mérnököknek, hogy meghatározzák, mi történt közvetlenül a lekapcsolás előtt.
Ez különösen fontossá válik, amikor egy kezdeti hiba több másodlagos riasztást okoz.
A képernyőn elsőként megjelenő riasztás nem feltétlenül a kiváltó ok.
A helyes időbélyeggel ellátott eseménysorozatok segítenek a mérnököknek rekonstruálni a történteket.
A hiba leválasztása megakadályozza egyetlen probléma továbbterjedését
Az önmagában vett észlelés nem hoz létre hibatűrést.
Az architektúrának azt is meg kell határoznia, mi történik a hiba felismerése után.
Egyes alkalmazásokban az érintett modul logikailag eltávolítható a működési sorrendből.
Más esetekben a folyamat redundáns berendezésre állhat át.
A tápegységek, a hálózati útvonalak, a vezérlők, a kommunikációs interfészek és a technológiai berendezések mind alkalmazhatnak redundanciát, ha az alkalmazás indokolja a többletkomplexitást.
A redundancia nem automatikusan előnyös.
A rosszul megtervezett redundáns rendszer további hibamódokat vezethet be, és megnehezítheti a hibakeresést.
Ezért a helyreállítási stratégiát a hibaészlelési stratégiával együtt kell megtervezni.
2. ábra. A hibatűrő folyamat észleli a rendellenes állapotot, leválasztja az érintett funkciót, és ahol rendelkezésre áll redundancia, átadja a működést.
Egy hajtás meghibásodása megmutatja, hogyan működik az elv
Vegyünk egy palackozósort, amely változtatható frekvenciájú hajtásokat használ a szállítószalag sebességének szabályozására.
Az egyik hajtásnál rendellenes áramviselkedés és növekvő hőmérséklet kezd jelentkezni.
Hagyományos architektúrában a hajtás addig működhet, amíg a védelmi funkciói lekapcsolási parancsot nem adnak.
A szállítószalag leáll.
A karbantartás ezután megkezdi a meghibásodott szakasz hibakeresését, miközben a termelés továbbra is szünetel.
Egy nagyobb hibatűrésű architektúra másképpen reagálhatna.
Az állapotfelügyelet észleli először a rendellenes elektromos és hőmérsékleti mintázatot.
A vezérlőrendszer karbantartási figyelmeztetést generál, mielőtt a folyamat elérné a lekapcsolási feltételt.
Ha az alkalmazás tartalmaz tervezetten beépített készenléti hajtást vagy redundáns mechanikai útvonalat, az érintett funkció ezután előre meghatározott logika szerint átadható.
Az eredeti hajtás leválasztásra kerül, a karbantartás pedig részletes hiba-információkat kap.
A termelés a folyamat kialakításától függően teljes vagy csökkentett kapacitással folytatódhat.
Ez a példa egy fontos korlátozást szemléltet.
A vezérlőrendszer nem tud olyan redundanciát létrehozni, amelyet a gép tervezésekor nem alakítottak ki.
Az automatizált helyreállítás csak akkor lehetséges, ha az elektromos, mechanikai és szoftveres architektúra alternatív utat biztosít.
Fordulatszám-szabályozás esetén a megfelelő VFD- és AC-hajtásarchitektúrák egy szélesebb karbantartási és redundanciastratégia részét képezhetik.
A kommunikáció a helyreállítási architektúra része
A modern diagnosztika nagymértékben az ipari kommunikációs hálózatokra támaszkodik.
A vezérlőknek állapotinformációkra van szükségük a hajtásoktól, a távoli I/O-egységektől, a védelmi eszközöktől és más intelligens komponensektől.
Az EtherNet/IP, a PROFINET és más ipari protokollok ilyen diagnosztikai rálátást biztosíthatnak, ha ezt a berendezés támogatja.
Egy ipari Ethernet-protokoll használata azonban önmagában nem teszi hibatűrővé a hálózatot.
A rugalmasság a hálózati architektúrától függ.
A menedzselhető kapcsolók, a redundáns utak, a vezérlők képességei, a topológia és a helyreállítási mechanizmusok mind befolyásolják, mi történik kommunikációs hiba után.
A mérnököknek ezért két kérdést kell elkülöníteniük.
Jelezni tudja-e az eszköz a hibát?
Működhet-e tovább a hálózat a hiba után?
Ezek összefüggő, de műszakilag eltérő képességek.
A biztonság és az automatikus helyreállítás határai legyenek egyértelműek
Az automatikus helyreállítás soha nem írhatja felül egy gép vagy folyamat biztonsági funkcióját.
Egyes meghibásodásoknak automatikus folytatás helyett szabályozott leállást kell eredményezniük.
A vészleállítást, a biztonsági reteszelést vagy a veszélyes elektromos állapotot nem lehet egyszerűen megkerülni csak azért, mert kívánatos a termelés fenntartása.
A helyreállítási logikának különbséget kell tennie a működés folytatását lehetővé tevő hibák és a berendezés biztonságos állapotba lépését igénylő hibák között.
Ez különösen fontos redundáns vezérlési utak esetén.
A mérnököknek tudniuk kell, mely jelek tartoznak a szabványos automatizáláshoz, és melyek a biztonsági vonatkozású architektúrához.
Az öngyógyító koncepció ezért akkor működik a legjobban, ha a hibák elszigetelését meghatározott funkcionális és biztonsági zónák köré tervezik.
A digitális ikrek újabb tesztelési réteget adnak
A digitális ikrek a hibatűrő tervezést a fizikai panelen túlra is kiterjeszthetik.
A vezérlőrendszer virtuális reprezentációja lehetővé teszi a mérnökök számára a működési folyamatok tanulmányozását, mielőtt módosításokat hajtanának végre az üzemben működő berendezéseken.
A modellbe hibaállapotok vezethetők be annak vizsgálatára, hogyan reagál a vezérlési logika.
A mérnökök értékelhetik, hogy a megfelelő riasztások jelennek-e meg, megfelelően történik-e a redundancia átkapcsolása, illetve fellépnek-e nem szándékos kölcsönhatások a folyamatban.
Ez különösen akkor hasznos, amikor a helyreállítási logika összetetté válik.
Az üzemelő gyártóberendezéseken minden lehetséges meghibásodás tesztelése nem feltétlenül megvalósítható vagy biztonságos.
A szimulációs környezet újabb lehetőséget biztosít a működés élesítés előtti ellenőrzésére.
3. ábra. A digitális szimuláció segíthet a mérnököknek a hibaesemények sorrendjének és a helyreállítási logikának az értékelésében, mielőtt a módosítások elérnék az üzemben működő berendezéseket.
Az edge-intelligencia kiterjeszti a helyi döntéshozatalt.
Egy másik fejlemény a közvetlenül a gépen elérhető feldolgozási kapacitás növekedése.
A hagyományos vezérlési architektúrák gyakran központi szerverekre küldik a magasabb szintű elemzési feladatokat.
Az edge-platformok lehetővé teszik, hogy bizonyos diagnosztikai funkciók helyben maradjanak.
Ez hasznos lehet olyan alkalmazásoknál, amelyekben a hibákról gyorsan kell dönteni, vagy nem feltételezhető folyamatos felhőkapcsolat.
A helyi analitika azonosíthatja a rendellenes mintázatokat, és csak a releváns eseményeket küldheti el a felügyeleti vagy vállalati rendszereknek.
A PLC továbbra is determinisztikus vezérlést végez.
Az elemzési réteg további információkat biztosít, amelyek befolyásolhatják a karbantartási döntéseket vagy az előre definiált helyreállítási logikát.
Fontos, hogy ezeket a funkciókat egyértelműen elkülönítsük.
A gépvezérlés nem válhat egy olyan átláthatatlan elemzőmodelltől függővé, amelynek viselkedése nem validálható.
A mérnökök által felteendő kérdések a panel tervezése során
A hibatűrő panel tervezési kérdésekkel kezdődik, nem egy szoftverfunkcióval.
A mérnököknek meg kell állapítaniuk, hogy az egyes hibazónák egyértelműen definiálhatók-e az elektromos architektúrán belül.
Azonosítaniuk kell, hogy mely meghibásodások szigetelhetők el a teljes gép leállítása nélkül.
Az eszközöknek elegendő diagnosztikai visszajelzést kell biztosítaniuk a karbantartási stratégiához.
A kritikus funkciókat felül kell vizsgálni annak megállapítására, hogy a redundancia műszakilag és gazdaságilag indokolt-e.
A tervezőcsapatnak azt is el kell döntenie, hogy az egyszerű üzemórákon túl mely állapotváltozókat szükséges folyamatosan figyelni.
A távdiagnosztika hasznos lehet, de a hálózatbiztonságot és a működtetési jogosultságokat már a kezdetektől figyelembe kell venni.
A helyreállítási logikát reális meghibásodási forgatókönyvek alapján is tesztelni kell, nem csupán normál üzemelési szekvenciák szerint.
A cél a szabályozott teljesítménycsökkenés, nem a törhetetlen panel
Az ipari berendezések továbbra is meg fognak hibásodni.
Az alkatrészek öregszenek. A csatlakozások romlanak. A hálózatok elveszítik a kommunikációt. A hajtások leoldanak. A tápegységek elérik élettartamuk végét.
A mérnöki cél ezért nem egy lehetetlen, soha meg nem hibásodó vezérlőpanel létrehozása.
A jobb cél a fokozatos teljesítménycsökkenés.
A rendszernek lehetőség szerint már korán fel kell ismernie az állapotromlást.
Meghibásodás esetén annak hatását az architektúra lehetőségei szerint korlátozni kell.
A kezelőknek általános riasztások helyett hasznos diagnosztikai információkat kell kapniuk.
A kritikus folyamatokat szükség esetén tervezett tartalékfunkciókra kell átirányítani.
A karbantartó személyzetnek ezután elegendő információval kell rendelkeznie az érintett hardver szükségtelen vizsgálódás nélküli javításához.
Ez az öngyógyító vezérlőpanel gyakorlati jelentése.
Nem javítja meg önmagát.
Úgy tervezték, hogy jobban megértse saját állapotát, intelligensen reagáljon az előre jelezhető meghibásodásokra, és a lehető legtovább fenntartsa a biztonságos működést, amíg az emberek elvégzik a fizikai javítást.