Routování protokolu Modbus 1. část

Sponzorováno

Při projektování a oživování sériových sběrnic komunikujících po protokolu Modbus občas narazíme na situace, kdy by bylo výhodné přejít ze sériové linky na ethernetovou síť a data dále přenášet po ní. Jde zejména o tyto případy:

síť Ethernet propojuje dvě místa, mezi kterými již nelze vést další sériovou linku
koncové zařízení (počítač nebo PLC) již nemá volný sériový port a potřebujeme připojit modbusové zařízení, komunikující sériovou linkou
zatím není známo, kde koncové zařízení bude umístěno, zatímco strukturovaná kabeláž je a bude dostupná všude
síť chceme využít jako páteřní vedení.

Zařízení na sériové lince, kterým může být třeba klimatizační jednotka nebo regulátor fancoilu, budeme říkat slave (v síťovém prostředí také server), protože na modbusový dotaz poskytuje data. Dotaz je vysílán masterem (v síťovém prostředí se obvykle nazývá klient), tedy například procesní podstanicí (PLC), grafickým terminálem (HMI) nebo vizualizačním programem (SCADA) v počítači.

Převodníků s dvěma rozhraními – Ethernet a RS485 – existuje na trhu bohatá nabídka. Otázkou ale je, jakým způsobem vlastně data na síti přenášejí. Při bližším zkoumání zjistíme, že jich je více a liší se tím, jak jsou data ze sériové linky „zabalena“ do síťových paketů a jak jsou na druhém konci interpretována. I k „rozbalení“ je totiž potřebný nějaký hardware nebo software, který musí být v zařízení na druhém konci linky podporován. Nejčastěji používané módy jsou tyto:

Terminal server (virtuální COM port), např. v převodníku Domat R035 zvaný RealPort
Serial bridge
Modbus router, v převodníku Domat R035 zvaný Industrial Automation.

V dalším textu se podíváme na jednotlivé módy podrobněji a ukážeme si konkrétní příklady topologií a jejich výhody a nevýhody.

Virtuální COM port a terminal server

Virtuální COM port je vlastně softwarový driver, který se nainstaluje na počítač. Driver je dodáván výrobcem převodníku, kterému dále budeme říkat terminal server. Po instalaci se v systému objeví další sériový port, na který mohou programy přistupovat stejně jako na klasické hardwarové sériové porty. Na obrázku se port nainstaloval automaticky na COM1, instalátor zřejmě vybere první volný port. Číslo portu jde později změnit.

Výrobců terminal serverů je celá řada a vždy je k převodníku nutné použít driver, který dodává jeho výrobce. Komunikační protokoly mezi virtuálním COM portem a terminal serverem se mohou lišit.

Obr. 1: Virtuální COM port v nastavení operačního systému (s převodníkem Domat R035)

Virtuální sériový port je dále nutné nakonfigurovat: musíme mu určit alespoň to, na jaké IP adrese najde hardwarový převodník, aby s ním mohl navázat spojení. Důležité jsou ale i další parametry sériové komunikace (rychlost, parita, počet stop bitů...), které se pak přenášejí do převodníku a nastavují sériový port. K tomu slouží buď webové rozhraní převodníku, nebo menu ve Správci zařízení – viz výše na obrázku, Sériové adaptéry s více porty.

Driver na síti najde převodník ze sériové linky na Ethernet, spojí se s ním a otevře kanál pro přenos dat. Všechno, co programy v PC zapíší na virtuální port, driver pošle do převodníku a převodník data zapíše na sériový port. Data příchozí na sériový port jsou naopak převodníkem poslána po síti do PC, kde je driver zapíše na virtuální COM port. Paket je obvykle uzavřen a odeslán po nějaké době neaktivity na lince, tento čas bývá nastavitelný. Celý systém vůbec neřeší, jaká data jsou po lince posílána, tedy co jednotlivé bajty znamenají. To je v podstatě výhoda, terminal server lze teoreticky použít na přenos libovolného komunikačního protokolu. Je zde ale pár háčků, jak uvidíme dále.

Síťová komunikace mezi virtuálním COM portem a terminal serverem je specifická pro výrobce. Nikde není standardizováno, jak má přenos dat vypadat; kromě vlastních sériových dat se po síti také komunikují řídicí signály, povely pro nastavení terminal serveru atd. Výhodou terminal serveru je, že přenos dat bývá šifrovaný, takže po síti není možné odposlechnout komunikaci mezi programem a sériovými zařízeními. Doporučuje se také – pokud je to možné – terminal server nastavit tak, aby přijímal připojení jen z IP adresy virtuálního COM portu (nebo v zapojení serial bridge z IP adresy protilehlého terminal serveru), což zvyšuje síťovou bezpečnost.

Obr. 2: Topologie pro terminal server

Toto řešení vypadá jednoduše a univerzálně, má však vlastnosti, které mohou jeho použití výrazně omezit:

Při přenosu dochází ke zpoždění. U přímého propojení dvou sériových zařízení je zpoždění paketu dáno pouze rychlostí šíření signálu kabelem. U terminal serveru ovšem musíme počítat s časem nutným pro zpracování dat v driveru i terminal serveru, čekáním na konec paketu (viz výše), ale zejména se zpožděním přenosu v síťové infrastruktuře. Celkové zpoždění může činit až stovky milisekund. To může klientský program vyhodnotit jako timeout – chybu komunikace, což vede k výpadkům a chybovým hlášením.

Je fakt, že při provozu v místní síti problém se zpožděním obvykle nenastává: reakční doba v síti se pohybuje v řádu ms, zatímco tolerance na timeout bývá nastavitelná ve stovkách ms. Předpokladem ale je, že jde o komunikaci dotaz – odpověď, jako například u protokolu M-Bus pro odečty měřičů energií. Pokud bychom zkoušeli tímto způsobem propojit dvě části sériové sběrnice, která například využívá nějaký komunikační protokol s detekcí kolizí pro přístup na linku, s vysokou pravděpodobností to nebude fungovat správně.

Jde o komunikaci bod-bod. Na jeden terminal server je možné navázat jen jeden virtuální COM port nebo protějšek v zapojení serial bridge. Má to samozřejmě svou logiku. Pokud bychom chtěli na server přistupovat ze dvou klientů, musí to umožňovat i komunikační protokol, jak uvidíme dále. Zde se jedná opravdu jen o tunel pro přenos dat mezi dvěma sériovými porty.

Klientem musí být PC s vhodným operačním systémem, aby na ně šel nainstalovat virtuální COM port. Pokud máme PLC nebo jiné zařízení, na které driver instalovat nelze, můžeme využít následující mód – serial bridge. Terminal server tedy obvykle neřeší situaci, kdy nám na PLC chybí sériový port, protože „není jak dostat data přes ethernetový port PLC na sériový driver protokolu v runtime PLC“.

Serial bridge (též Sériový tunel)

U zařízení, které má volný sériový port, je možné zapojit dva terminal servery „zády k sobě“ a nakonfigurovat je tak, aby vytvořily přenosový kanál. Této konfiguraci se říká serial bridge, protože sériová linka „přemosťuje“ síť a sériová zařízení mohou s PLC komunikovat podobně, jako by byla propojena sériovou linkou napřímo. Problém s časováním popsaný výše to však ještě zhoršuje. Navíc jsou zde dvojnásobné náklady na hardware.

Takže konečně se dostáváme k plnohodnotnému routování:

Modbus router

Tento mód na aplikační úrovni již pracuje s nám známým protokolem, převádí Modbus TCP na Modbus RTU a zpět. Na rozdíl od módu Terminal Server, v němž by na straně Ethernetu stále byl Modbus RTU, byť zabalen (a případně i zašifrován) v TCP paketech, v případě Modbus routeru na síťovém rozhraní najdeme Modbus TCP. Převodník tudíž řeší i konverzi protokolů a pracuje s daty na úrovni protokolu Modbus. Musí tedy Modbusu rozumět, už to není jen „přehazování anonymních dat“.

Jak to celé funguje?

Modbusový dotaz a odpověď na sériové lince (tzv. Modbus RTU) vypadá například takto:

Vyčítání teploty z registru 17 funkcí F03, adresa stanice 1

Dotaz (master):
01 03 00 10 00 01 85 CF

Odpověď (slave):
01 03 02 07 9E 3B DC

Hodnoty jsou hexadecimálním vyjádřením přenášených bajtů. V této podobě nám je poskytne monitor sériového provozu, tzv. port monitor. Ten je buď funkce klientského zařízení (PLC, SCADA), nebo externí program, který sleduje provoz na sběrnici přes sériový převodník.

Pokud bychom data rozebrali podle popisu protokolu Modbus (a není to nic těžkého), zjistíme toto:

Dotaz (master):

`01`	adresa stanice – linková adresa v rozsahu 1...255, zařízení s touto adresou je masterem dotazováno na data
`03`	Modbus funkce 03 – Read multiple registers – způsob vyčítání dat
`00 10`	počáteční adresa – 16 dekadicky pro čtení registru 17 (adresy se číslují od 0, registry od 1), v němž víme, že se v konkrétním zařízení nachází aktuální teplota
`00 01`	počet registrů, které se mají číst, zde jeden
`85 CF`	na konci je CRC – kontrolní součet předchozích dat

Odpověď (slave):

`01`	adresa stanice – v odpovědi se opakuje tak, jak je v dotazu
`03`	Modbus funkce 03 – v odpovědi se opakuje tak, jak je v dotazu
`02`	počet bytů, které následují (kromě kontrolního součtu)
`07 9E`	hodnota: 079E hex = 1950 dekadicky = 19.5 °C (abychom zde získali desetinná místa, celočíselná hodnota se musí vydělit 100 – tohle a další se dozvíme z Modbusové tabulky od výrobce stanice)
`3B DC`	na konci je CRC - kontrolní součet předchozích dat

Kontrolní součet by každá strana měla použít jako kontrolu celistvosti telegramu. Pokud přijaté CRC nesouhlasí s vlastním výpočtem na základě předchozích přijatých dat, něco se přeneslo špatně a celý dotaz je potřeba opakovat.

Týž dotaz v protokolu Modbus TCP je trochu obsáhlejší. Na obrázku je komunikace zaznamenaná v programu Wireshark. Ten umí rozebrat některé protokoly až na aplikační úroveň, jak vidíme v prostřední části okna. V horní části jsou dva Modbus TCP dotazy a dvě odpovědi, níže je detail druhého z dotazů.

Obr. 3: Komunikace Modbus TCP v programu Wireshark

Modře vyznačená část telegramu je samotný Modbus TCP dotaz. Zajímá nás jen levá, hexadecimální interpretace; v pravé části jsou tatáž data jako text, což v případě Modbusu nedává smysl. Černobílá část na začátku telegramu je vlastně transportní obálka nižších vrstev komunikace včetně protokolu TCP/IP. Dalo by se říci, že po síti cestuje náklad – telegram Modbus TCP – naložený ve vagónku TCP/IP. Budeme se zabývat jen částí Modbus TCP:

Dotaz (klient):
04 B7 00 00 00 06 01 03 00 10 00 01

Odpověď (server):
04 B7 00 00 00 05 01 03 02 08 7E

Opět telegram rozebereme podle standardu Modbus TCP.

Dotaz (klient):

`04 B7`	transaction ID, obvykle vzrůstající číslo, slouží klientovi ke spárování dotazu a odpovědi
`00 00`	protocol identifier: 0 = Modbus, na těchto dvou pozicích jsou vždy nuly
`00 06`	počet bytů, které následují
`01`	adresa stanice (zde se jí říká unit identifier)
`03`	funkce (stejné jako u Modbus RTU)
`00 10`	registr; 16 dec pro reg. 17 (stejné jako u Modbus RTU)
`00 01`	počet registrů, které se mají číst

Odpověď (server):

`04 B7`	transaction ID, převzato z požadavku
`00 00`	protocol identifier: 00 = Modbus
`00 05`	počet bytů, které následují
`01`	adresa
`03`	funkce
`02`	počet data bytů (zdánlivě nadbytečná hodnota, viz třetí řádek, ale je zde pro plnou kompatibilitu této části telegramu s Modbusem RTU)
`08 7E`	08 7E hex = 2174 dec = 21.74 °C, teplota nám během experimentování poněkud stoupla.

Tučně vyznačené řádky jsou společné pro Modbus RTU i Modbus TCP. U Modbusu TCP chybí kontrolní součet, ten je zbytečné počítat a přenášet, neboť integritu telegramu zaručuje „obálka“ – protokol TCP. Naopak navíc jsou zde první tři řádky: Transaction ID, identifikátor protokolu a počet následujících bytů.

Při převodu dotazu z Ethernetu na sériovou linku tedy Modbus router vezme čistý obsah (přenášená data bez TCP režie) z TCP telegramu, odstraní prvních šest bytů, spočítá a přidá kontrolní součet a celé to pošle na sériovou linku. Po obdržení odpovědi odstraní ze sériového paketu kontrolní součet, přidá Transaction ID z Modbus TCP dotazu, Protocol identifier a počet bytů zbytku telegramu – a vrátí odpověď na Ethernet jako telegram Modbus TCP, tedy výše zmíněný obsah zabalený do TCP obálky.

Routování Modbus RTU na Modbus TCP (Serial Slave)

Znamená to, že „za routerem“ je sériová linka s jedním nebo více sériovými zařízeními. Přes jednu IP adresu modbusového routeru můžeme komunikovat s několika sériovými zařízeními. Je jen potřeba znát obsazení sériové sběrnice a podle toho připravit klientský program. Zařízení jsou zapojena podle obrázku topologie vlevo.

Při tvorbě topologie musíme vždy mít na vědomí, které zařízení je server a které klient. Na obrázku vpravo je zdánlivě podobné zapojení, „Modbus zařízení se sériovou linkou – Modbus router – Modbus zařízení s rozhraním Ethernet“, ale funkce routeru se podstatně liší. Zapojení podle obrázku vpravo se budeme věnovat v další části článku, nyní nás zajímá sériové zařízení ve funkci serveru (slave).

Obr. 4: Topologie pro routování Modbus

Pokud máme v systému více sériových linek s více modbusovými routery, jejich rozsahy linkových adres se mohou překrývat. Modbusové zařízení je jednoznačně určeno kombinací IP adresy routeru a linkové adresy zařízení. Modbus TCP klient prostě bude oslovovat každé Modbus TCP zařízení zvlášť přes jeho IP adresu. Oba způsoby adresování na obrázku níže jsou tedy možné.

Obr. 5: Rozsahy linkových adres na sériových linkách

V modbusovém routeru je pomocí webového rozhraní nebo konfiguračním programem možné nastavit řadu parametrů. Například u routeru Domat R035 je nejprve nutné vůbec určit, že zařízení má jako Modbus router pracovat. Převodník se musí nastavit do módu Industrial Automation a v části Industrial Automation Settings zkontrolujeme, zda aktuální protokol je Modbus RTU Serial Slave. To odpovídá topologii na obrázku nahoře vlevo, zařízení na sériové lince je slave (server). (Druhou možnost, Serial Master, si ukážeme v další části článku.)

Obr. 6: Nastavení převodníku Domat R035

Toto je kromě síťového nastavení a nastavení parametrů sériové linky (rychlost, parita...) vlastně jediná konfigurace, kterou je nutné v routeru zadat. Ostatní parametry můžeme ponechat ve výchozích hodnotách.

V další části se podíváme na několik případů složitějších topologií a jejich řešení.

Domat Control System s.r.o.

Domat Control System s.r.o. patří k evropské špičce dodavatelů řídicích systémů a regulací pro inteligentní budovy, průmysl a energetiku. Cílem této ryze české společnosti je vyvíjet, vyrábět a dodávat řídící systémy v mezinárodním měřítku.

Více o firmě Chci další informace Webové stránky