A bekötött relék és az elszigetelt PLC-k korai gyökereitől az intelligens gyártást ösztönző nyílt, interoperábilis architektúrákig az ipari kommunikációs protokollok fejlődési pályája mélyreható átalakuláson ment keresztül. Az üzemi automatizálás első évtizedeiben a szabályozási hurkok digitális szigetekként működtek. A vezérlők helyben hajtották végre a determinisztikus logikát, a folyamatok közötti telemetria megosztásához azonban kiterjedt pont-pont közötti vezetékezésre vagy egyedi interfészkártyákra volt szükség.

Ahogy a modern feldolgozóipar egyre összetettebbé vált, a valós idejű diagnosztika, a rendszerek közötti összehangolás és a vállalati szintű átláthatóság iránti operatív igény meghaladta az elszigetelt terepi vezérlők képességeit. Az összekapcsolt környezetek felé történő elmozdulás nem pusztán a bitek vezetéken keresztüli továbbításáról szólt; az ipari adatok strukturálásának, kontextus szerinti leképezésének és a terepi eszközökön, peremvezérlőkön, valamint vállalati analitikai hálózatokon keresztüli továbbításának alapvető újratervezését jelentette.

Az üzemi hálózatépítés alapjai: Modbus, a korai PLC-k és a protokolltöredezettség

Amikor a programozható logikai vezérlők az 1960-as évek végén megjelentek a gyártóüzemekben, a komplex relészekrényeket szoftveralapú létradiagram-logikával váltották fel. Ahogy azonban az üzemek bővültek, és a feldolgozósorokon több tucat önálló PLC-t telepítettek, a mérnököknek szabványosított fizikai és logikai közegre volt szükségük, amely lehetővé tette, hogy a vezérlők köztes relés jelátvitel nélkül cseréljék ki belső regisztereiket.

1979-ben a Modicon (ma Schneider Electric) bevezette a Modbus szabványt, alapjaiban megváltoztatva az ipari kommunikációt. A soros interfészeken, például RS-485-ön működő master/slave (ma kliens/szerver) architektúrára épülő Modbus nyílt, jogdíjmentes protokollt kínált, amely leegyszerűsítette a regiszterszintű adatok lekérését. Egyszerűsége és könnyű megvalósíthatósága mindenütt elterjedt szabvánnyá tette — ezt a státuszát ma is több millió működő végpont esetében őrzi.

Történelmi sikerei ellenére a Modbus strukturális korlátokba ütközik adatintenzív automatizálási környezetekben. A Modbus nem támogat natív adattípusokat, környezeti metaadatokat, időbélyegzést és közzététel/feliratkozás képességet. Egy analóg érték lekéréséhez a mastervezérlőnek folyamatosan le kell kérdeznie a meghatározott tartóregisztereket. Ahogy a vezérlőhálózatok több ezer I/O-pontig bővültek, a rendszeres lekérdezés súlyos sávszélesség-torlódást és késleltetési problémákat okozott.

E korlátok leküzdése és a nagy sebességű, determinisztikus vezérlés megvalósítása érdekében a vezető automatizálási beszállítók saját, szabadalmaztatott terepibusz-architektúrákat és teljesítményorientált protokollkiterjesztéseket fejlesztettek ki:

• A Siemens a PROFIBUS-t, majd a PROFINET-et alkalmazta a bemeneti/kimeneti adatok nagy sebességű ciklikus cseréjének és az összetett diagnosztikai jelzők támogatására az olyan elosztott terepi állomásokon, mint a Siemens SIMATIC vezérlők.
• Az Allen-Bradley / Rockwell Automation bevezette a Data Highway Plus (DH+) és a ControlNet technológiát, amelyek később a Common Industrial Protocol (CIP) révén EtherNet/IP-vé fejlődtek.
• A Mitsubishi Electric a CC-Linket vezette be, hogy nagy sebességű, determinisztikus vezérlést biztosítson dedikált, zajvédett fizikai rétegeken keresztül.

Bár ezek a terepi busztechnológiák sikeresen biztosították a determinisztikus ciklusvégrehajtást, „beszállítói függőséget” hoztak létre. Egy Allen-Bradley PLC és egy Siemens hajtás, illetve egy harmadik féltől származó energiamérő összekapcsolása összetett protokollátalakítókat, testreszabott memóriatérképezést és sérülékeny átjáróhardvert igényelt, ami növelte az életciklus alatti karbantartási költségeket.

A beszállítói függőség megszüntetése: az OPC Classic-tól a platformfüggetlen OPC UA-ig

A protokollok széttagoltsága által okozott üzemeltetési nehézségek az automatizálási ipart az egységes absztrakciós rétegek felé terelték. Ahelyett, hogy minden PLC–HMI-kapcsolathoz egyedi szoftveres illesztőprogramokat írtak volna, a mérnököknek szabványosított fordítási interfészre volt szükségük.

1996-ban automatizálási beszállítók egy csoportja együttműködött a Microsofttal az Open Platform Communications (OPC) szabvány létrehozásában, amelyet később OPC Classic néven jelöltek. A Microsoft OLE, COM és DCOM technológiáin alapuló OPC Classic szabványosított kliens-szerver interfészeket hozott létre az adat-hozzáféréshez (OPC DA), a riasztásokhoz és eseményekhez (OPC AE), valamint az előzményadatokhoz való hozzáféréshez (OPC HDA). Egy automatizálási beszállítónak csak OPC-szervert kellett biztosítania a hardveréhez; ezt követően bármely OPC-kompatibilis HMI- vagy SCADA-szoftver zökkenőmentesen olvashatta és írhatta az adatokat.

A Microsoft DCOM-ra való támaszkodás azonban sajátos üzemeltetési kihívásokat teremtett az ipari hálózatok korszerűsödésével:

• Operációsrendszer-függőség: Az OPC Classic szerverei csak Windows operációs rendszereken futhattak, így kimaradtak a beágyazott Linux-vezérlők, az RTOS-eszközök és a Unix-alapú vállalati szerverek.
• Biztonsági korlátozások: A DCOM konfigurálása tűzfalakon és alhálózati határokon keresztül közismerten nehéz volt, és olyan nyitott porttartományokat igényelt, amelyek súlyos kiberbiztonsági sebezhetőségeket okoztak.
• Szemantikai kontextus hiánya: Az adatok elsősorban nyers értékekként kerültek továbbításra, a szállítási keretbe közvetlenül beágyazott beépített kontextus, mérnöki mértékegységek vagy szemantikai metaadatok nélkül.

Ezen architekturális sebezhetőségek kiküszöbölésére az OPC Foundation 2008-ban kiadta az OPC Unified Architecture-t (OPC UA). Az OPC UA a DCOM helyett nyílt, szolgáltatásorientált architektúrát (SOA) vezetett be TCP/IP- és HTTP/HTTPS-átviteli rétegekkel. Lényeges, hogy az OPC UA platformfüggetlen, így natív integrációt tesz lehetővé közvetlenül Linux-alapú peremátjárókban, beágyazott vezérlőkben és felhőkörnyezetekben.

Az OPC UA emellett objektumorientált információs modellt is bevezetett. Egy elszigetelt lebegőpontos szám továbbítása helyett az OPC UA összetett objektumokként kapszulázza az adatokat, amelyek a mértékegységeket, a felső és alsó riasztási határértékeket, az időbélyeg pontosságát és a hozzáférési jogosultságokat is tartalmazzák. A beépített PKI-titkosítással és az x509-tanúsítvány-alapú hitelesítéssel együtt az OPC UA a biztonságos IT/OT-konvergencia egyik alappillére.

DCS-architektúrák, O-PAS és modern hibrid vezérlés

Míg a PLC-k kiválóan alkalmasak nagy sebességű diszkrét vezérlésre, a folyamatipar – például a petrolkémiai finomítás, az energiatermelés és a speciális vegyipar – történelmileg elosztott vezérlőrendszerekre (DCS) támaszkodott. A DCS a vezérlőket, az I/O-alrendszereket, az előzményadatbázisokat és a kezelői munkaállomásokat egységes mérnöki környezetbe integrálja.

A régi DCS-rendszerek nagy megbízhatóságot és redundáns vezérlőköröket biztosítottak. Ez a szoros integráció azonban a modularitás rovására ment. A saját tulajdonú vezérlőhálózatok, a zárt I/O-buszok és a speciális konfigurációs szoftverek évtizedekre egyetlen gyártó ökoszisztémájához kötötték az üzemeltetőket. Egy régi DCS bővítése vagy speciális, külső gyártótól származó alrendszerek – például online géprezgés-monitorozás – integrálása gyakran költséges mérnöki módosításokat igényelt.

1. ábra. Egy elosztott vezérlőrendszer (DCS) funkcionális szintjei, amelyek a hagyományos hierarchikus vezérlési rétegeket szemléltetik. A kép forrása: Wikipedia Commons.

E paradigma megtörésére az ExxonMobil vezetésével jelentős ipari szereplők kezdeményezték az Open Process Automation Standard (O-PAS) kidolgozását a The Open Group OPA Fórumának keretében. Az O-PAS célja hardverfüggetlen, nyílt architektúra létrehozása a folyamat-automatizáláshoz, amelyet három alapvető pillér határoz meg:

1. Interoperabilitás: Szabványosított kommunikációs buszok (az OPC UA használatával), amelyek lehetővé teszik a különböző hardvergyártók komponensei számára az adatok natív cseréjét egyedi illesztőprogram-fejlesztés nélkül.
2. Modularitás: A szoftveralkalmazások leválasztása az alapul szolgáló hardverről konténerizált mikroszolgáltatások és elosztott vezérlőcsomópontok (DCN-ek) révén.
3. Biztonság: Beépített, az IEC 62443 szabványoknak megfelelő kiberbiztonság, amely minden eszközhatáron érvényesül.

Napjainkban a korszerű üzemek gyakran hibrid architektúrákat alkalmaznak. A kritikus folyamatberendezéseket olyan robusztus DCS-platformok kezelik, mint a DCS-vezérlőrendszerek, miközben a segédberendezések, a környezeti monitorok és a speciális turbógép-védelmi állványok nyílt, szabványos protokollokon keresztül közvetlenül a peremplatformokra továbbítják az eszközállapot paramétereit.

Eseményvezérelt telemetria: MQTT és kis sávszélességű peremhálózatok

Ahogy a terepi műszerezettség az egyszerű diszkrét érzékelőktől a több száz diagnosztikai paraméter jelentésére képes összetett intelligens távadókig fejlődött, nyilvánvalóvá váltak a hagyományos kliens-szerver kérés-válasz hálózatok működési korlátai.

1999-ben Andy Stanford-Clark (IBM) és Arlen Nipper (Arcom, ma Cirrus Link) a Message Queuing Telemetry Transport (MQTT) protokollt kifejezetten a távoli SCADA-alkalmazások, például a műholdas kapcsolaton keresztüli olaj- és gázvezeték-felügyelet sávszélesség- és késleltetési korlátainak megoldására fejlesztette ki. Ezekben a környezetekben a nagy késleltetésű kapcsolatokon végzett folyamatos lekérdezés költségesnek és megbízhatatlannak bizonyult.

Az MQTT ezeket a kihívásokat eseményvezérelt közzétételi/feliratkozási (Pub/Sub) architektúrával oldotta meg, amely központi üzenetbrókert használ:

• Szétválasztott kommunikáció: A peremcsomópontok (közzétevők) és a vállalati szoftverek (feliratkozók) nem hoznak létre közvetlen pont-pont kapcsolatokat. Ehelyett aszinkron módon, az MQTT-brókeren keresztül kommunikálnak.
• Minimális többletterhelés: A mindössze 2 bájtos fejlécnek köszönhetően az MQTT drasztikusan csökkenti a sávszélesség-használatot a HTTP/REST API-khoz vagy a nagy többletterhelésű RPC-protokollokhoz képest.
• Kivétel alapú jelentés (RBE): A terepi eszközök csak akkor tesznek közzé adatokat, ha egy érték egy meghatározott holtsávon vagy állapotküszöbön túl változik, így megszűnik a hálózaton zajló szükségtelen lekérdezési forgalom.
• Állapotfigyelés: Az olyan funkciók, mint a „Keep Alive” időzítők és a „Last Will and Testament” (LWT), lehetővé teszik, hogy a bróker azonnal értesítse a feliratkozókat, ha egy peremeszköz váratlanul lekapcsolódik.

2. ábra. Az MQTT-hálózati architektúra közzétételi/feliratkozási modellje, amely peremcsomópontokat kapcsol össze központi alkalmazásbrókerekkel. A kép forrása: Wikipedia Commons.

Míg a szabványos MQTT rugalmas hasznosadat-átviteli mechanizmust biztosít, nem szabványosítja a témastruktúrák vagy a hasznos adatok formázását. Ennek megoldására az ipari közösség kidolgozta a Sparkplug B specifikációt. A Sparkplug B szabványos tématerületet, tömör Google Protocol Buffer (Protobuf) hasznosadat-struktúrát és állapotkezelési mechanizmusokat határoz meg, ezáltal a nyers MQTT-t vállalati szintű ipari átviteli réteggé alakítja.

A modern ipari paradigma: egységes névtér (UNS) architektúra

Az örökölt lekérdezési protokollok, az elszigetelt OPC-szerverek és a pont-pont API-kapcsolatok felhalmozódása gyakran összetett „spagettiarchitektúrát” eredményez. Ebben a környezetben egyetlen új analitikai eszköz hozzáadásához egyedi kapcsolatokat kell létrehozni a létesítmény minden SCADA-csomópontjához, historizálójához és MES-adatbázisához.

Ezen integrációs szűk keresztmetszetek megszüntetésére a modern automatizálási mérnökök az egységes névtér (UNS) architektúráját alkalmazzák. Az egységes névtér központi, valós idejű szoftveres absztrakciós rétegként szolgál, amely a vállalaton belüli valamennyi üzemeltetési és üzleti adat „egyetlen hiteles forrását” biztosítja.

3. ábra. Az egységes névtér (UNS) struktúrája, amely a valós idejű adatáramlást vezérli az ISA-95 vállalati rétegein keresztül. A kép forrása: Wikipedia Commons.

A közzététel/feliratkozás modellen alapuló, jellemzően MQTT Sparkplug B-vel vagy eseményfolyam-platformokkal megvalósított UNS az adatokat szemantikailag szabványos fizikai hierarchiák szerint strukturálja, például az ISA-95 alapján:

Vállalat / Telephely / Terület / Gyártósor / Cella / Eszköz

Egy teljes körűen megvalósított UNS-keretrendszerben:

• Egy terepi PLC közvetlenül közzéteszi a motor állapotát ide: Enterprise/Plant_A/Line_2/Mixer/Motor_Speed állapotváltozáskor.
• A SCADA-rendszer feliratkozik a témakörstruktúrára, hogy valós idejű kezelői grafikákat jelenítsen meg.
• A vállalati eszközgazdálkodási rendszer (EAM) ugyanarra a témakörfolyamra figyel, hogy nyomon kövesse az üzemórákat, és automatikusan ütemezze a megelőző karbantartást.
• A felhőalapú gépi tanulási modellek az egységesített adatfolyamot használják fel a prediktív anomáliaészlelés végrehajtására anélkül, hogy további lekérdezési terhelést helyeznének a terepi vezérlőre.

Az adattermelők és adatfogyasztók UNS-en keresztüli szétválasztásával az ipari vállalatok újratervezés nélkül adhatnak hozzá, módosíthatnak vagy skálázhatnak szoftvereszközöket és peremhálózati érzékelőket a meglévő szabályozási hurkokban.

Terepi szintű protokollmátrix és műszaki összehasonlítás

Az optimális protokollstratégia kiválasztásához meg kell érteni az egyes hálózati rétegek műszaki teljesítményjellemzőit, adatcsomag-többletét és célalkalmazásait a működési ökoszisztéma egészében:

Valós architektúra tervezése: Az örökölt üzemi műveletek korszerűsítése

Egy működő, örökölt lekérdezési hálózatokról nyílt, eseményvezérelt architektúrára átálló, meglévő gyártóüzem mérnöki migrációjához fokozatos megközelítésre van szükség a teljes rendszerátalakítás helyett.

Vegyünk egy tipikus, folyamatos feldolgozást végző létesítményt, ahol örökölt PLC-5 vagy korai ControlLogix-rendszerek működnek önálló, forgó gépekhez tartozó védelmi hardverek mellett. Az összes örökölt hardver egyidejű cseréje elfogadhatatlan leállási kockázatokkal és tőkeköltségekkel járna. A strukturált, háromfázisú korszerűsítési ütemterv praktikus előrelépési lehetőséget biztosít:

1. 1. fázis: Peremprotokoll-fordítási réteg
   Telepítsen ipari peremátjárókat az örökölt PLC-állványok mellé. A peremátjáró soros vagy örökölt terepibusz-protokollokon keresztül lekérdezi a helyi tartóregisztereket, majd a nyers értékeket strukturált OPC UA-csomópontokká vagy MQTT Sparkplug B-témákká alakítja.
2. 2. fázis: A bróker telepítése és az UNS strukturálása
   Telepítsen magas rendelkezésre állású, redundáns MQTT-brókert helyben. Határozzon meg egységes ISA-95 tématerület-névteret az üzemi területen. Irányítsa a peremátjárók telemetriai adatait a brókerbe, ezzel azonnal lehetővé téve az eszközök valós idejű áttekintését az alapul szolgáló PLC-letapogatási idők vagy vezérlési logika módosítása nélkül.
3. 3. fázis: Fejlett analitika és hibrid vezérlés integrációja
   Csatlakoztassa a vállalati történeti adatbázisokat, a felhőalapú analitikai motorokat és a modern HMI-rendszereket közvetlenül az UNS-hez feliratkozóként. Amikor az örökölt vezérlők elérik élettartamuk végét, cserélje le őket OPC UA- és MQTT-környezetekhez natív, modern, nyílt architektúrájú PAC-okra.

Ezzel a moduláris stratégiával az ipari létesítmények megvédik a terepi hardverbe fektetett meglévő tőkét, miközben megszerzik a modern Ipar 4.0-működéshez szükséges adatkezelési rugalmasságot, kiberbiztonsági megfelelést és skálázhatóságot.