Mi történik, amikor egy ipari vezérlőpanel már azelőtt érzékeli a 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 akkor válnak karbantartási problémává, amikor riasztás, kioldás vagy leállás történik.

Az intelligensebb vezérlési architektúrák korábban is képesek reagálni.

Képesek érzékelni a rendellenes állapotokat, elszigetelni bizonyos hibákat, a funkciókat redundáns berendezésekre átkapcsolni, valamint részletes diagnosztikai információkkal ellátni a karbantartó személyzetet.

Ezt a koncepciót néha öngyógyító vezérlőpanelnek is nevezik.

A kifejezést nem szabad szó szerint értelmezni. Egy vezérlőpanel önmagában nem tud megjavítani egy sérült mágneskapcsolót, kiégett kapcsot vagy meghibásodott hajtást.

Amit képes megtenni, az bizonyos hibák 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 elszigetelés és az összehangolt 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ütt működnek a kiszámítható működési sorrend fenntartásában.

Ezért egyetlen kis alkatrész meghibásodása 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 kiesésre kényszeríthet. Egy kommunikációs probléma miatt a vezérlő számára elérhetetlenné válhatnak az egyébként megfelelően működő berendezések.

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 hibafelismerés elsősorban egy gép leállására vagy arra támaszkodik, hogy a kezelő észrevesz egy riasztást, a folyamat már rendellenes működési állapotba került.

A modern vezérléstervezés egyre inkább arra törekszik, hogy még ezt megelőzően felismerje 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 hibafelismerés, a hibaelszigetelés és az automatikus helyreállítás kombinációjaként értelmezhető.

Egy gyakorlatias architektúra több funkciót is elláthat.

Először a rendszer érzékeli a rendellenes jelet vagy működési állapotot.

Másodszor, a diagnosztikai logika meghatározza, melyik eszköz, áramkör vagy folyamatterület érintett.

Harmadszor, a vezérlőrendszer – amennyiben az architektúra lehetővé teszi – leválasztja az érintett funkciót.

Végül a 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 kiküszöbölése. Hanem annak megakadályozása, hogy minden egyes meghibásodás automatikusan az egész üzem leállásává váljon.

A moduláris architektúra praktikussá teszi a hibaelkülönítést

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 elkülöníteni, amikor egy komponens meghibásodik.

A moduláris architektúra egyértelműbb funkcionális határokat hoz létre.

Az energiaelosztá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 rendelhető. 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 komponenst kártyaszintig hibaelhárítanának, a technikusok azonosított modulokat cserélhetnek, és egy kialakított karbantartási eljárás szerint állíthatják helyre az üzemet.

A feszültség alatt cserélhető hardver javíthatja ezt a megközelítést ott, ahol az adott vezérlőplatform és alkalmazás támogatja a feszültség alatti cserét.

A hot swapping azonban soha nem tekinthető magától értetődőnek pusztán azért, mert egy rendszer moduláris.

A vezérlőnek, az I/O-platformnak, a villamos tervezésnek é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.

Itt válik fontossá az IIoT-alapú érzékelés és a prediktív karbantartás.

A modern felügyeleti rendszerek képesek figyelni 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.

A trend gyakran hasznosabb.

A fokozatosan melegedő sorkapocs-csatlakozás olyan villamos állapotra utalhat, amely vizsgálatot igényel.

Egy fokozódó rezgési trendet mutató motornak még azelőtt lehet szüksége mechanikai beavatkozásra, hogy az állapot nem tervezett leállást okozna.

Az ismétlődő áramaszimmetria szintén hasznos diagnosztikai bizonyítékot szolgáltathat, ha a megfelelő villamos és mechanikai összefüggések között értékelik.

Az edge computing 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ést továbbítana egy távoli szerverre, egy peremhálózati eszköz helyben kiértékelheti a kiválasztott jeleket, és eseményeket generálhat a meghatározott feltételek észlelésekor.

Ez csökkentheti a válaszadási késleltetést, és mérsékelheti a szükségtelen adatforgalmat.

A diagnosztikának többet kell magyaráznia a „hibánál”

Az általános hibajelző korlátozott értéket képvisel, ha a termelés már leállt.

A hatékony diagnosztikának azonosítania kell, hol történt a probléma, és elegendő kontextust kell biztosítania ahhoz, hogy a karbantartó személyzet kivizsgálhassa azt.

A modern vezérlők és intelligens eszközök a komponensszintű diagnosztikai információkat a vezérlőhálózaton keresztül is elérhetővé tehetik.

A HMI- vagy SCADA-réteg ezután részletesebb riasztási információkat jeleníthet meg.

Ahelyett, hogy csak általános hajtáshibát jelezne, 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ényesemények abban is segítenek a mérnököknek, hogy meghatározzák, mi történt közvetlenül a leállás előtt.

Ez különösen fontossá válik, amikor egy kezdeti hiba több másodlagos riasztást idéz elő.

A képernyőn megjelenő első riasztás nem feltétlenül a kiváltó ok.

A helyesen időbélyegzett eseménysorok segítenek a mérnököknek rekonstruálni a történteket.

A hiba leválasztása megakadályozza egy probléma továbbterjedését

Az észlelés önmagában nem teremt 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, hálózati útvonalak, vezérlők, kommunikációs interfészek és technológiai berendezések mind alkalmazhatnak redundanciát, ha az alkalmazás indokolja a további összetettséget.

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 hibafelismerési stratégiával együtt kell megtervezni.

2. ábra. A hibatűrő sorrend érzékeli a rendellenes állapotot, leválasztja az érintett funkciót, és ott adja át a működést, ahol redundancia áll rendelkezésre.

Egy hajtáshiba bemutatja a működés elvét

Tekintsünk egy palackozósort, amely frekvenciaváltókat használ a szállítószalag sebességének szabályozására.

Az egyik hajtás rendellenes áramfelvételt és növekvő hőmérsékletet kezd mutatni.

Hagyományos architektúrában a hajtás addig működhet, amíg a védelmi funkciói leállási jelet nem generálnak.

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 elsőként érzékeli 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 leállási feltételt.

Ha az alkalmazásban tervezetten rendelkezésre álló tartalék hajtás vagy redundáns mechanikai útvonal van, az érintett funkció előre meghatározott logika szerint átadható.

Az eredeti hajtást leválasztják, a karbantartás pedig részletes hibainformá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 eredetileg nem terveztek be a gépbe.

Az automatikus helyreállítás csak akkor lehetséges, ha az elektromos, mechanikai és szoftveres architektúra alternatív útvonalat biztosít.

A változtatható fordulatszámú vezérlés alkalmazásakor a megfelelő VFD- és AC-hajtás-architektúrák egy szélesebb körű 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ózatoktól függ.

A vezérlőknek állapotinformációkra van szükségük a hajtásoktól, a távoli I/O-któ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 a berendezés támogatja őket.

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 menedzselt 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ülön kérdést kell feltenniük.

Képes az eszköz jelenteni a hibát?

Képes a hálózat a hiba után is működni?

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ítást kell eredményezniük.

Egy vészleállító, biztonsági retesz vagy veszélyes elektromos állapot nem kerülhető meg egyszerűen 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 folyamatos működést lehetővé tevő hibák és a berendezés biztonságos állapotba helyezé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 standard 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 új 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 az üzemelé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, a redundancia megfelelően átkapcsol-e, és fellépnek-e nem kívánt folyamatkölcsönhatások.

Ez különösen akkor hasznos, amikor a helyreállítási logika összetetté válik.

Minden lehetséges meghibásodás tesztelése üzemelő gyártóberendezésen nem feltétlenül megvalósítható, illetve nem biztos, hogy biztonságos.

A szimulációs környezet egy újabb lehetőséget biztosít a működés élesítés előtti validálására.

3. ábra. A digitális szimuláció segíthet a mérnököknek a hibahelyzetek 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.

A peremintelligencia 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 magasabb szintű analitikai feladatokat küldenek központosított szerverekre.

Az edge-platformok lehetővé teszik, hogy a kiválasztott diagnosztikai funkciók helyben maradjanak.

Ez hasznos lehet olyan alkalmazásoknál, ahol a hibákról gyorsan kell dönteni, vagy ahol nem feltételezhető folyamatos felhőkapcsolat.

A helyi analitika képes felismerni a rendellenes mintázatokat, és csak a releváns eseményeket továbbítani a felügyeleti vagy vállalati rendszereknek.

A PLC továbbra is determinisztikus vezérlést végez.

Az analitikai 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 analitikai modelltől függővé, amelynek működése nem validálható.

A tervezők által felteendő kérdések a vezérlőszekrény tervezése során

A hibatűrő vezérlőszekrény tervezési kérdésekkel kezdődik, nem egy szoftverfunkcióval.

A mérnököknek meg kell határozniuk, hogy az egyes hibazónák egyértelműen definiálva vannak-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 meghatározá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 kell folyamatosan felügyelni.

A távdiagnosztika hasznos lehet, de a hálózatbiztonságot és az üzemelteté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 csak normál üzemi folyamatokkal.

A cél a szabályozott teljesítménycsökkenés, nem a törhetetlen vezérlőszekrény

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 üzemi élettartamuk végét.

A mérnöki célkitűzés tehát nem egy olyan lehetetlen vezérlőszekrény, amely soha nem hibásodik meg.

Jobb célkitűzés a szabályozott teljesítménycsökkenés.

A rendszernek lehetőség szerint korai szakaszban fel kell ismernie az állapotromlást.

Meghibásodás esetén annak hatását lehetőség szerint az architektúrán belül kell tartani.

A kezelőknek általános riasztások helyett hasznos diagnosztikai információkat kell kapniuk.

A kritikus folyamatokat megfelelő esetben át kell kapcsolni a megtervezett tartalékfunkciókra.

A karbantartó személyzetnek ezután elegendő információval kell rendelkeznie ahhoz, hogy szükségtelen vizsgálódás nélkül megjavítsa az érintett hardvert.

Ez az öngyógyító vezérlőszekrény gyakorlati jelentése.

Nem javítja meg önmagát.

Úgy tervezték, hogy többet tudjon meg saját állapotáról, intelligensen reagáljon az előre jelezhető meghibásodásokra, és a lehető legtöbb biztonságos üzemet fenntartsa mindaddig, amíg az emberek el nem végzik a fizikai javítást.