Írta: Kun Zsuzsi
2018. december 20. 17:37:05 CET
A Modbus protokollt széles körben használják, számos automatizálási feladatban és sok helyen még mindig Modbus RTU-t alkalmaznak. Ezek az eszközök általában RS-232, vagy RS-485 vonalon kommunikálnak, és DB-9, vagy sorkapcsos csatlakozóval rendelkeznek. A Modbus RTU eszközök népszerűek, mivel implementálásuk igen egyszerű, a hibaelhárítás költsége pedig alacsony. Ám ahogy az ipari hálózatok funkciói bővülnek, egyre több ipari alkalmazás tér át az Ethernetre és egyre több rendszer használja a Modbus TCP protokollt a SCADA rendszerekben. Ez a változás pedig problémákat okozhat a Modbus RTU és Modbus TCP protokollok közötti kommunikációban. Az alábbi kérdések (GYIK) és a rájuk adott válaszok bemutatják a leggyakrabban előforduló Modbus konverziós hibákat és azok megoldási lehetőségeit.
Szükséges-e speciális protokoll konverter ahhoz, hogy a Modbus RTU eszközeimet egy Modbus TCP hálózathoz csatlakoztassam? Esetleg használhatok hagyományos soros-Ethernet konvertert is helyette?
Ha egynél több Modbus RTU eszközöm van csatlakoztatva a gateway egyes soros portjaira, hogyan tervezhetem meg a TCP kapcsolat architektúráját? Használhatok egyetlen kapcsolatot, vagy minden egyes soros porthoz külön kapcsolatra van szükség?
Hogyan használhatok egy gateway-t arra, hogy egyidőben több SCADA host is el tudja érni ugyanazt a Modbus RTU eszközt?
Két Modbus master eszközzel dolgozom (PLC vagy HMI). Hogyan bonyolíthatom le a két rendszer közötti adatcserét?
Több Modbus RTU eszközt szeretnék lekérdezni. Ha több Modbus parancsot használok az adatok lekérdezésére, rengeteg időt vesz igénybe. Van rá lehetőség, hogy a gateway aktívan gyűjtse az adatokat és tárolja egy regiszterben, így csak egy Modbus parancsot kelljen használnom?
Mielőtt választ kaphatna erre a kérdésre, tudunk kell, hogy milyen driverek érhetők el a SCADA hoston. Négy esetet különíthetünk el:
(1) SCADA host Modbus TCP driverrel
(2) SCADA host Modbus RTU driverrel – beépített soros porttal
(3) SCADA host Modbus RTU driverrel – beépített soros port nélkül
(4) SCADA host „Ethernet Encapsulation” driverrel
(1) SCADA host Modbus TCP driverrel
Ebben az esetben használjon protokollkonvertert, melynek segítségével a Modbus TCP protokoll használatával is képes kommunikálni a Modbus RTU eszközökkel. Számos hasonló megoldás érhető el az automatizálási piacon, amelyek lehetővé teszik a Modbus RTU slave eszközök csatlakozását a Modbus TCP protokollon keresztül. Amikor a konverter megkapja a Modbus TCP lekérdezést, azt átkonvertálja a Modbus RTU követelményei szerint és továbbítja a Modbus RTU protokollt használó eszközök felé.
(2) SCADA host Modbus RTU driverrel – beépített soros porttal
Válassza ezt a lehetőséget, ha egy már létező SCADA hostot és Modbus RTU eszközöket kíván csatlakoztatni egy Ethernet hálózathoz. Ha az eredeti SCADA host rendelkezik soros porttal, akkor két gateway használatával megoldható a konverzió. Ahogy az alábbi topológiai ábrán látható, a gateway képes konvertálni a Modbus RTU adatcsomagokat Modbus TCP adatcsomagokká, majd vissza Modbus RTU-ra. Azonban, ha nincs a SCADA hoston beépített soros port, ezt a megoldást nem tudja alkalmazni. Ebben az esetben válassza a (3)-as lehetőséget.
(3) SCADA host Modbus RTU driverrel – beépített soros port nélkül
Ha a már meglévő SCADA programot és eszközöket kívánja használni, de az eredeti SCADA host nem rendelkezik beépített soros porttal, akkor soros eszközszerver használatát javasoljuk, amellyel virtuális soros portot hozhat létre a SCADA szerveren. Ez a konfiguráció lehetővé teszi a soros eszközök távoli elérését a soros eszközszerveren keresztül úgy, mintha a szerver rendelkezne egy natív soros porttal.
A soros eszközsszerver használatához telepíteni kell a virtuális COM port drivert, mely létrehozza a virtuális COM portot a SCADA hoston. A virtuális COM port használatához az eszközszervert mindenképpen Real COM módra kell konfigurálni. Minden erre a virtuális COM portra küldött adat a távoli soros porton keresztül kerül továbbításra a céleszközhöz. Minden egyéb jelet és parancsot hasonlóan transzparensen kezel a rendszer. Mivel ugyanúgy használhatja a virtuális COM portot, mint egy natív COM portot, a Modbus RTU lekérdezéseit közvetlenül a portra irányíthatja, ugyanúgy, mint egy fizikai soros port esetén.
(4) SCADA host „Ethernet Encapsulation” driverrel
Ha nem áll rendelkezésére beépített soros port a SCADA hoston és nem kívánja telepíteni a virtuális COM port drivert sem, lehetőség van „Ethernet encapsulation” drivert telepítésére. A SCADA szoftverek – kevés kivétellel - többnyire támogatják ezt a megoldást. Általánosságban elmondható, hogy az Ethernet encapsulation driver telepítése akkor ideális megoldás, ha a felhasználó mélyebb ismeretekkel rendelkezik a soros kommunikáció és a TCP/IP protokollok terén.
Ehhez a megoldáshoz szükség van egy soros-Ethernet konverterre TCP vagy UDP szerver üzemmódra állítva, ami azt jelenti, hogy a host és a soros eszköz közötti kapcsolat transzparens TCP/IP vagy UDP kommunikációt használ minden egyéb protokoll nélkül arra, hogy a SCADA rendszer Modbus RTU adatcsomagokat küldjön a terepi eszközök számára. A soros-Ethernet konverter konfigurálása körültekintést igényel, mivel a Modbus RTU időközöket használ az adatcsomagok végének megállapítására, emiatt, ha a Modbus RTU adatcsomag kettő vagy több TCP/IP vagy UDP csomagra válik szét, előfordulhat, hogy a továbbítás során problémák adódnak. Ha nem szakértő a soros és Ethernet hálózatok közötti adattovábbítás kialakításában, lehet, hogy célszerűbb a gateway (2) vagy a virtuális COM port (3) megoldás használata.
Habár a soros-Ethernet konverterekkel megoldható egy soros eszköz Ethernet hálózathoz való csatlakoztatása, mégis a gateway-ek alkalmazása (2) az, amely szinte minden rendszerkövetelménynek megfelel. A hostnak elég támogatnia az elterjedt és széles körben támogatott Modbus TCP protokollt. Az alábbiakban felsorolunk néhány esetet, amelyekben speciális gateway megoldást érdemes alkalmazni.
1. Multi-master vagy redundancia
Az Ethernet kapcsolat nemcsak a távoli elérés előnyét nyújtja, hanem a többszörös kapcsolati hozzáférés lehetőségét is. A legtöbb gateway képes akár 32 egyidejű kapcsolat kezelésére, ami azt jelenti, hogy akár 32 SCADA host kérhet adatokat egyszerre a Modbus RTU eszközöktől. Ugyanezt a redundanciát és egyidejű lekérdezéseket hagyományos soros-Ethernet konverterekkel nem lehet megoldani, mivel nem támogatják több master használatát ezzel szemben a gateway-ek számára ez nem okozhat problémát.
2. Egyetlen kapcsolat több Modbus RTU eszközhöz
Előfordulhat, hogy a SCADA host-on egyetlen kapcsolatot kívánunk használni több Modbus RTU eszköz lekérdezésére, amelyek különböző távoli soros portokhoz vannak csatlakoztatva. Ebben az esetben a gateway használata az egyetlen megoldás, amely képes ellátni routolási feladatokat. Többportos gateway is használható és konfigurálható úgy, hogy a Modbus TCP lekérdezést a megfelelő soros portra továbbítja a slave azonosító alapján. A soros-Ethernet konverter nem lenne képes ilyen bonyolult feladat ellátására.
3. Szimultán eszközhozzáférés a régi Modbus RTU HMI és új Modbus TCP SCADA számára
Bár az Ethernet kapcsolatok könnyen felépíthető távoli elérést biztosítanak, előfordulhat, hogy a felhasználók mégis megtartanák a lokális HMI kapcsolatokat is. A problémát az okozza, hogy az eszköz soros portja már foglalt, mivel a gateway-hez van csatlakoztatva, így nincs szabad kapcsolódási lehetőség a HMI számára. Ebben az esetben néhány gateway soros átirányítási lehetőséget biztosít, amellyel feloldható ez a probléma. A soros átirányító hasonlít egy router-re, ezen keresztül a gateway továbbíthatja a lekérdezéseket és az adatokat a soros portok között a slave azonosító alapján.
Összefoglalás
Számos lehetőség áll rendelkezésre a soros-Ethernet kommunikáció megvalósítására. Habár ezek a megoldások lehetnek olyan egyszerűek, mint a transzparens adatátvitel a soros és Ethernet portok között, egy kimondottan a célra fejlesztett gateway sokkal jobb megoldást kínál azokban az esetekben, amikor ipari protokollokkal, pl. Modbus-szal dolgozunk. A gateway-ek talán kezdetben nagyobb beruházást jelenthetnek, de sokkal stabilabb kommunikációt tesznek lehetővé hosszú távon és képesek felismerni pontosan a Modbus adatcsomagokat is, így a teljes csomagot megfelelően tudják kezelni.
A legtöbb gateway rugalmas megoldást kínál, amely felhasználható a TCP kapcsolati architektúrák kialakítására több Modbus RTU soros porton történő eléréséhez. Általában három módszert alkalmazhatunk a routing megoldástól függően:
(1) Soros port illesztése egyedi TCP porthoz,
(2) Soros port illesztése egyedi IP címhez, és
(3) Routing tábla használata
(1) Soros port csatlakoztatása egyedi TCP porthoz
Ez a leggyakrabban alkalmazott mód gateway topológiák tervezésére. A gateway konfigurációban minden soros portot egy egyedi TCP port jelöl. Például, 4001 az 1-es soros port, 4002 a 2-es soros port, stb. Ha Modbus RTU eszközökkel kíván kommunikálni az 1-es soros porton keresztül, Modbus TCP kapcsolatot kell felépítenie a 4001-es porton. A gateway a TCP kapcsolaton keresztül, a 4001-es TCP porton érkezett Modbus adatcsomagot továbbítja az 1-es portra. Ebben az üzemmódban a SCADA driverrel több Modbus TCP kapcsolat kiépítése szükséges.
(2) Soros port csatlakoztatása egyedi IP címhez
Ez a megoldás hasonló az (1)-eshez, azzal az eltéréssel, hogy a gateway különböző IP címeket rendel az egyes soros portokhoz. Például a 192.168.2.1 az 1-es soros port címe, a 192.168.2.2 a 2-es soros porté, stb. Ha egy Modbus RTU eszközzel kíván kommunikálni az 1-es porton keresztül, egy Modbus TCP kapcsolatot kell felépítenie a 192.168.2.1-gyel az 502-es TCP porton. A gateway továbbítja a Modbus adatcsomagot a 192.168.2.1:502 és az 1-es soros port között. Ebben a topológiában a SCADA drivernek szintén többszörös Modbus TCP kapcsolatot kell kiépítenie. Habár ez a topológia több IP címet igényel, néhány Modbus TCP kliens csak az alapértelmezett 502-es TCP portot támogatja. Ebben az esetben az (1)-es megoldás nem alkalmazható, tehát érdemes ezt a módszert választani.
(3) Routing tábla használata
Ez a topológia egy kapcsolatot használva kommunikál a többi eszközzel. Hogy biztosak lehessünk abban, hogy a lekérdezéseink a megfelelő eszközökhöz jutnak el, pontosan kell konfigurálnunk a konvertert és a routing-ot. Például, az 1-es soros portra kerül az összes olyan Modbus adatcsomag, amelynek slave azonosítója 1 és 10 között van, a 2-es portra pedig a 11 és 20 közöttiek.
Mivel ez a topológia csak egy kapcsolatot használ, lassabb lesz, mint az 1-es és a 2-es megoldások. De ha alacsonyabb költségvetéssel kell gazdálkodnunk, és az alacsonyabb teljesítmény is elfogadható az alkalmazás szempontjából, ez az egykapcsolatos megoldás is megfelelő.
Ha több eszközt csatlakoztat egyetlen soros porthoz, vagy több soros portot kapcsol egy TCP kapcsolathoz, az megnövelheti a Modbus lekérdezés idejét. De, ahogy már említésre került, a lekérdezések sebességének növelése érdekében több TCP kapcsolatra lehet szükség és meg kell bizonyosodnia róla, hogy ez nem növeli meg a SCADA költségeit.
Habár a gateway alkalmas ezt a helyzetet megfelelően kezelni, fontos figyelembe venni, hogy a soros port sávszélessége nem változik meg. Tehát, ha több lekérdezés érkezik be ugyanazon a soros porton keresztül, előfordulhat, hogy késést tapasztalunk, mivel a gateway beérkezési sorrendben szolgálja ki a lekérdezéseket. Ez azt jelenti, hogy már előre érdemes a megfelelő lekérdezési időt kiszámítani, ha egyszerre több master egységnek adunk hozzáférést ugyanazon Modbus RTU eszközökhöz.
Például, ha egy lekérdezés 100ms-ig tart, öt lekérdezés esetén legalább 100 ms x (5-1) = 400 ms-ot kell várni a következő lekérdezés elküldésére. Ez azt jelenti, hogy minden SCADA hostnak 400 ms-os (+biztonsági ráhagyás) lekérdezési időközzel kell dolgoznia.
Ám a fentiekben bemutatott megoldás nem az egyetlen lehetőség. Néhány gateway támogatja az „agent” (ügynök) módot, amely aktívan és folyamatosan kérdezi a csatlakoztatott Modbus RTU eszközök megadott regisztereit. Az adatokat belső memóriában tárolja, amelyből azonnal képes válaszolni a hostoktól érkező lekérdezésekre. Habár ez a megoldás gyorsabbnak és hatékonyabbnak tűnik, fontos megjegyezni, hogy az így tárolt adatok nem lesznek valós idejűek, az adatok naprakészségét az „agent” módban beállított frissítési gyakoriság határozza meg.
Ahhoz, hogy két Modbus master eszköz között továbbítsunk adatokat, szükség lesz egy gateway-re, amely támogatja a master-master módot. Ebben az üzemmódban a gateway slave-ként dolgozik mindkét oldalon. Az egyik master beírhatja az adatokat a gateway belső memóriájába, a másik master eszköz pedig kiolvassa ezeket az adatokat onnan. A használatban lévő gateway-től függően mindkét oldalon lehet Modbus RTU vagy Modbus TCP, vagy az egyik oldalon csak Modbus RTU és a másikon csak Modbus TCP.
Ahhoz, hogy a gateway aktívan gyűjtse az adatokat több Modbus RTU eszközről, és az így nyert információkat tárolja egy regiszterében, „agent” módot támogató gateway-re van szükség. A gateway-nek lekérdezést kell küldenie egyesével minden Modbus RTU eszköz számára, majd a fogadott értékeket egy adatblokkba rendezni és tárolni a belső memóriában. Ezt követően ezek az adatok ennek az egy blokknak a lekérdezésével egyszerre érhetők el.
A „soros eszközszerver” egy önálló eszköz, amely legalább egy Ethernet porttal és egy vagy több soros porttal rendelkezik. A soros eszközszerverek beágyazott operációs rendszerrel üzemelnek, amely lehetőséget ad a számítógépeknek a soros eszközökhöz való hozzáféréshez Ethernet hálózaton keresztül. A soros eszközszerverek transzparens módon továbbítják az adatokat a soros interfész és az Ethernet hálózat között, a soros adatokat az Ethernet protokollnak megfelelően, illetve az Ethernet hálózatból érkező adatokat a soros protokoll követelményei szerint átalakítva.
A modern soros eszközszerverek „virtuális COM portokat” nyújtanak a kevés vagy fizikai soros porttal nem rendelkező host számítógépeknek, az Ethernet hálózaton keresztül. Az alapfunkciók mellett a fejlettebb soros eszközszerverek támogatják a PPP vagy Telnet protokollokat is. A soros eszközszerverek használhatók továbbá távoli konzol elérésére (ezért nevezik őket sokan konzol-szervernek) vagy távoli terminál alkalmazásokhoz régi rendszerekben (sokan pedig ezért terminál-szervereknek hívják őket).
A „virtuális COM port” nem egy valódi, fizikai COM port a host számítógépen. Hanem egy „virtuális COM port driver” program, amely host számítógépre telepített Windows vagy Linux operációs rendszer alatt fut és szimulálja egy valódi COM port működését. A driver használható a soros eszközszerveren található portok host eszközhöz való csatlakoztatására a TCP/IP hálózaton keresztül. A soros port a távoli soros eszközön ugyanazt a viselkedést mutatja, mint a valódi COM port. Ez a „virtuális COM port” egy soros eszközszerverhez csatlakoztatva hozható létre. Például, a COM3 az 1-es soros port egy távoli soros eszközszerveren, amelynek IP címe 192.168.2.1. Így, amikor adatot írunk be erre a portra, az információ a „192.168.2.1@1-es soros port”-ra lesz továbbítva a „virtuális COM port driver” által. Minden, erre a virtuális COM portra érkező adat átirányításra kerül a „192.168.2.1@1-es soros port”-ra. Mivel az újabb host számítógépek kevés, vagy nulla beépített soros porttal rendelkeznek, a „virtuális COM portok” nélkülözhetetlen eszközök a régebbi eszközök ipari automatizálási hálózatba történő csatlakoztatásához.
A „transzparens gateway” a legegyszerűbb módja a Modbus gateway használatának. Mivel a Modbus RTU és a Modbus TCP ugyanazt a PDU-t (Protocol Data Unit – Protokoll adategység) használja - az egyetlen különbség csupán a címzés és a CRC - igen egyszerű a gateway számára a Modbus RTU adatok konvertálása Modbus TCP-re. Tehát, amikor a gateway megkapja a Modbus TCP adatcsomagot az Ethernet hálózatról, egyszerűen kicseréli a címzést a Modbus RTU követelményei szerint és azonnal továbbítja a soros port felé. Amikor a gateway választ kap a Modbus RTU eszközökből, a választ hasonló módon a Modbus TCP kliensnek küldi.
Egy „agent” (ügynök) gateway” egy másik módot kínál a Modbus gateway-ek felhasználására a Modbus RTU és Modbus TCP eszközök közötti kommunikációban. Az ügynök saját belső memóriával rendelkezik az adatok időszakos tárolására, és folyamatosan lekérdezi az információkat a kapcsolt RTU eszközöktől. Amikor a SCADA driver lekérdezése megérkezik, a gateway a tárolt adatokat használja a belső memóriájából, hogy válaszoljon az adatkérésre. Ily módon a gateway ügynökként működik és aktívan gyűjti az adatokat az eszközöktől, melyet nagyon rövid idővel tud a SCADA rendszer felé küldeni igény esetén. Ez a megoldás felhasználható a protokollok konverziójában is, amikor:
(1) A két protokoll különböző adatcsomag-struktúrát használ. Például PROFIBUS és Modbus, EtherNet/IP, PROFINET, etc.
(2) A két protokoll eltérő ciklusidőket alkalmaz. Néhány protokoll – mint a PROFIBUS, a PROFINET és az Ethernet/IP – nagyon rövid ciklusidővel továbbítja az adatcsomagokat, amelyet a transzparens gateway-ek nem tudnak kezelni.
Forrás: MOXA
Kérdésével forduljon Melegh György presales & support mérnök kollégánkhoz (gymelegh@comforth.hu)
