Az Ipar 4.0 egy olyan koncepció, amely a negyedik ipari forradalomra utal, az ipari termelés és gyártás területén bekövetkező technológiai és szervezeti változásokat jelenti, amelyek a digitális technológiák széleskörű alkalmazására épülnek. Ez a koncepció a gyártási folyamatokban, az üzleti modellekben és a termékek szolgáltatásaiban bekövetkező paradigmaváltást írja le.

‍

Az ALLWIN által nyújtott megoldások

‍

Az alábbi pontokban három olyan Ipar 4.0 belépőszintű megoldást mutatunk be, mely illeszkedik az ügyfél érettségi szintjéhez és eszközparkjának méretéhez.

Alapvetően két részből áll egy-egy megoldás, az egyik az adatok gyűjtése a gyártásban résztvevő eszközökről, a másik pedig az adatoknak a feldolgozása. Az adatok gyűjtésének módja nagy mértékben függ a már használt eszközparktól. A kommunikációra használt technológiai lehetőségek közt szerepel a Zigbee, Modbus TCP és akár a Wi-Fi is.

Adatfeldolgozásra már a lehetőségek száma sokkal nagyobb, mert itt már a hagyományos vagy a legújabb szoftverfejlesztési módszerek és technológiák használhatóak. Gondolok itt akár a mesterséges intelligencia alkalmazására on-premise környezetben vagy felhőben, vagy adattárház alapú megoldás bevezetésére.

‍

Első szint – on-premise OPC UA szerver nélkül

‍

Ahogy az alábbi ábrán is látszik, a gyártás során használt eszközök direkt kapcsolatban vannak a kliens számítógéppel, amik tudnak kiolvasni adatokat és parancsokat küldeni PLC-n keresztül a fizikai eszköznek. Főleg a költségek alacsonyan tartása és architektúra egyszerűsítés szempontjából előnyös ez a megoldás. Olyan rendszereknél ajánlott ezt az egyszerűsített felépítést használni, ahol csak néhány eszköz kapcsolódik a kliensekhez és PLC-n keresztül vagy közvetlenül az eszközről lehet adatokat küldeni MQTT protokollon keresztül egy központi szervernek, ami elérhető az adatfeldolgozó egységnek is. Másik indok lehet, hogy az adatfeldolgozó szolgáltatásokat nem szükséges különböző régiókban a világon elérhetővé tenni, vagy az egész rendszert teljesen izolálni kell és akár leválasztani az internetről.

‍

‍

Második szint – on-premise OPC UA szerverrel

‍

A fent bemutatott megoldás egy nagy gyengesége, hogy az adatgyűjtő szoftvereknek többféle driverrel kellett együttműködnie, hogyha többféle eszközzel kellett kommunikálnia. Ezt a problémát próbálták orvosolni először az OPC classic szabvánnyal, ami egy egységes interfészt szolgáltatott a hozzá csatlakozó szoftverek számára, és az OPC szerver volt a felelős a különböző driverekkel való kommunikációra.

‍

‍

A kommunikációra azonban a DCOM szabványt használja, ami a Distributed Component Object Model rövidítése, és egy Microsoft által fejlesztett technológia két alkalmazás közötti kommunikációra, amelyek akár különböző a számítógépeken futnak, de azonos hálózatban vannak. További hátrányok voltak még a DCOM-on való kommunikáció miatt a következők:

• gyakori konfigurációs problémák
• nincs konfigurálható timeout
• gyenge biztonsági mechanizmusok

‍

A Windows operációs rendszertől való függés, és a DCOM egyik nagy hiányossága, az interneten való kommunikáció hiánya hívta életre az OPC UA szabványt, ami a következő újdonságokat is hozta magával:

• a DCOM-ot leváltotta TCP/IP protokollra, így megszűnt a Windowstól való függés, és cross-platformmá vált
• a TCP/IP használata miatt a végpontok az internetre is publikálhatóak lettek, és a tűzfalakkal is könnyebben együtt tud működni
• rugalmasabb, és több információra kiterjedő adatmodellt használ, szemben az OPC classic-al, ami csak annyi adatott szolgáltatott, amennyit kapott a különböző eszközöktől
• szolgáltatás-orientált architektúrát használ
• egyszerűsített IT integráció

‍

‍

A OPC UA előnyei sokrétűek: az OPC UA egy rugalmas, átlátható, biztonságos és platformfüggetlen architektúra. Az egységes interfészek lehetővé teszik széles körű alkalmazásokhoz való könnyű hozzáférést, mint például a MES, SAP és ERP rendszerek, adatbázisok, felhő platformok. Ezt a megoldást akkor érdemes használni, hogyha az eszközök darabszáma vagy diverzitása kellően nagy, és támogatják az OPC UA-t legalább egy PLC-n keresztül, ha a rendszer teljes izolációjára van szükség (lehet, hogy nem is kapcsolódik az internethez), és így nincsenek folyamatos felhő infrastruktúra költségek.

‍

Harmadik szint – on-premise OPC UA szerver + felhős adatfeldolgozás és adatvizualizáció

‍

A bejövő adatok tárolása, feldolgozása, megjelenítése egy kellően bonyolult rendszer esetében rengeteg üzemeltetési feladatot jelent, gondoljunk csak a szerverek menedzselésére, az elegendő tárhely és a skálázhatóság biztosítására vagy a biztonsági mentések konfigurálására és szakszerű kezelésére. Ezeket a feladatokat át tudjuk ruházni egy felhőszolgáltatóra, illetve az üzemeltetési költségek is csökkenthetők, mert mindig csak annyi erőforrás után kell fizetnünk, amennyit éppen használunk.  

Ebben segítenek a Platform as a Service (PaaS) szolgáltatások is, mint mondjuk az Azure IoT Hub, különböző adatbázisok, vagy az Azure Stream Analytics. Amennyiben Infrastructure as a Service (Iaas) termékeket használunk, mint pl. virtuális gépek, akkor is dinamikusan állítható, hogy a forgalomtól függően mennyire van szükségünk, és csak azért kell fizetnünk.  

On premise esetben ilyenkor a legnagyobb forgalomra kell méreteznünk a rendszereinket, amik pedig feleslegesen futnak abban az esetben, hogyha kisebb terhelés van a rendszeren. Például egy napelem-rendszer esetében éjjel nem szükséges olyan gyakorisággal adatokat küldeni, mert azok jórészt 0-k lesznek, mert a napelem nem tud termelni napsütés nélkül.  

A felhő a fent említett előnyök mellett magasabb biztonságot is tud nyújtani, mint egy on-premise rendszer köszönhetően a PaaS szolgáltatások esetében a rendszeres security patchelésnek, az infrastruktúra fizikai védelmének, illetve a felhőszolgáltató által beépített biztonsági mechanizmusoknak (tűzfalak, Microsoft Defender ajánlások). Ezen felül a hibrid-felhő megoldásoknak köszönhetően arra is van lehetőség, hogy bizonyos komponensek földi hálózaton legyenek, míg mások a cloudban, és a hálózatokat VPN gatewayen keresztül összekössük.

A felhő ezen kívül a nagyobb számítási kapacitás miatt teret tud engedni olyan funkcionalitásoknak is, amit egy on-premise rendszer esetén nagyon sok befektetett energia árán tudunk kivitelezni, mint például az adatok mesterséges intelligenciával való feldolgozása, nagymennyiségű adattárolás, illetve azok elemzése.

‍

Adatfeldolgozás

‍

Miután a kommunikációs csatornák kiépültek valamelyik fent említett architektúrával, a rendszerünk rendelkezik adatokkal melyek különböző típusú adatbázisokban tárolunk (SQL, NoSQL, TSDB). Alapvetően két féle adatfeldolgozást különböztetünk meg - valós idejű és historikus.

Valós idejű feldolgozásnál egy adatfolyamot kell feldolgozni, ami alapján a szoftver tud azonnal reagálni - azaz akár parancsokat küldeni a gyártásban levő eszközöknek, vagy értesítés küldeni a felelősöknek, ha anomáliát észlel a rendszer. Emellett a gyártásból érkező adatokat tudjuk vizualizálni - igényektől függően testreszabott dashboard-okon - mely ugyancsak segíti a humán alapú monitorozást. Az alábbi ábrán látható, egy példa állapotfelügyeleti architektúrára Azure-ban,

‍

Historikus adatfeldolgozás során egy nagyobb adathalmazt vesz alapul a rendszer a múltból és az alapján segít, pl. prediktálni anomáliákat múltbéli történések alapján vagy kimutatásokat lehet készíteni melyek alapján optimalizálni lehet a gyártást. Másik jó példa még a gyártásban résztvevő eszközök karbantartásának, illetve cseréjének előrejelzése a historikus adatokból. Innen már csak egy lépés a mesterséges intelligencia bevezetése is, mely csökkenti a humán beavatkozások számát és a sok adat feldolgozása és kiértékelése rábízható a mesterséges intelligenciára. Az alábbi ábrán egy prediktív karbantartási igény kimutatására használható architektúra, hasonlóan az előzőhöz, Azure szolgáltatásokkal.

‍

‍

Az említett példák és megoldások mind futtathatóak felhőben vagy on-premise környezetben is. A felhő alapú megoldás akkor ajánlott, ha a skálázhatóság és/vagy több régióból való elérés szempont. Felhős környezet esetén az Azure-nak egy csokornyi szolgáltatása használható, ami Ipar 4.0-hoz és IIoT-hoz köthető. Alább egy Azure szolgáltatásokon alapuló architektúra ábrája látható.

‍

‍

Konklúzió

‍

Az Ipar 4.0 megközelítés rendkívül ígéretes lehetőségeket kínál a gyártás és termelés területén a digitális technológiák széleskörű alkalmazásával, melynek általános célkitűzése a hatékonyság növelése és a gyártási folyamatok optimalizálása. Az OPC UA szabvány bevezetése, valamint az on-premise és felhős megoldások kombinációja lehetővé teszi a rugalmas kommunikációt és adatfeldolgozást, biztosítva ezzel a gyártási folyamatok hatékonyabbá tételét és a döntéshozatalhoz szükséges adatok gyors elérhetőségét.

Az adatok valós idejű és historikus feldolgozása révén a rendszerek nem csupán monitorozni tudják a gyártási folyamatokat, hanem előrejelzéseket is készíthetnek, optimalizálhatják a termelést és akár automatizálhatják a karbantartási folyamatokat is. Mindez lehetővé teszi a gyártók számára, hogy versenyképesebbek legyenek és jobban alkalmazkodjanak az üzleti környezet változásaihoz.

‍