cz
Občas se přihodí, že sběrnice M-Bus je s řídicím systémem propojitelná pouze po síti typu Ethernet. Projektant – nebo v horším případě až projektmanažer – pak shání „nějaký převodník z M-Busu na Ethernet“. Podívejme se, jak by se tento problém dal řešit vůči PLC Domat a jaké má toto řešení výhody a rizika.
Firma PaPouch na český trh dodává převodníky M-Bus/Ethernet švédské firmy PiiGAB. Můžeme si vybrat z modelů PiiGAB 820 pro 5 až 250 M-Bus zařízení. Převodníky pracují tak, že sériové telegramy M-Bus/Ethernet, zaslané klientem, „rozbalí“ z TCP nebo UDP paketu a pošlou na sběrnici M-Bus. Odpověď od měřiče pak opět „zabalí“ do TCP nebo UDP paketu a komunikují po síti Ethernet s protistranou – TCP nebo UDP klientem.
Nastavení převodníku PiiGAB je velmi jednoduché: kromě standardního síťového nastavení (IP adresa, maska sítě, výchozí brána) je nutné jen nastavit rychlost na rozhraní M-Bus a zkontrolovat, který transportní protokol pro přenos použijeme – UDP nebo TCP. Jednodušší je nespojovaný protokol UDP, číslo UDP portu můžeme zvolit libovolně, ale v rámci standardizace nechme výchozí, 10001:
Zajímavější je nastavení na klientské straně, v převodníku R035.
V první řadě musíme v základním nastavení vybrat funkční profil UDP Sockets. Tím se otevře nastavení na obrázku. Dále musíme zajistit, aby se data, která přijdou po sériové lince (RS485) z PLC, poslala po síti protokolem UDP na převodník PiiGAB. To zajistí směrovací tabulka v sekci UDP Client Settings. V našem případě má PiiGAB adresu 192.168.1.142 a tomu odpovídá i záznam v tabulce. Jako další parametr v záznamu se také zadává UDP port (zde 10001), na který se mají data posílat – a na kterém PiiGAB naslouchá.
Nastavení M-Bus kanálu v PLC je standardní, PLC vlastně ani neví, že data nejsou přímo po sériové lince, ale putují část cesty po síti Ethernet. Rychlost a další komunikační parametry musí odpovídat nastavení v R035. S ohledem na servis doporučujeme nastavit sériové parametry vč. parity stejně, jako je tomu na M-Bus straně převodníku PiiGAB, i když teoreticky na tom nezáleží.
Jak vidíme na výpisu ethernetové komunikace, převodník R035 (s adresou 192.168.1.99) přeposílá M-Bus dotazy na IP adresu PiiGAB, port 10001. Wireshark nám prozradí, že M-Busový dotaz (5 bajtů) je jediným datovým obsahem v UDP paketu, žádná jiná data do telegramu doplňována nejsou. Odpověď se vrací zpět do R035 na UDP port 2101. Komunikaci můžeme snadno vyzkoušet i bez PLC, libovolným M-Bus klientem, připojeným z počítače přes sériový port na rozhraní RS485 převodníku R035. Funguje i detekce měřičů – snímek obrazovky byl pořízen při komunikaci programem MBCONF (ke stažení na www.relay.de).
Po importu měřičů do Domat IDE pak vidíme hodnoty z vodoměrů, elektroměrů či kalorimetrů, jako při přímém připojení sériového převodníku M-Bus na sériový port PLC.
Na co si dát pozor z hlediska kyberbezpečnosti? UDP ani TCP spojení není nijak šifrované, převodníky neřeší, jaké zařízení se na ně připojuje. Je proto nutné zařízení provozovat v uzavřené síti, do které je přístup pouze ideálně pomocí VPN. Při použití spravovatelných switchů se doporučuje omezit přístup na zařízení pouze z nutných IP adres (protější převodník, konfigurační PC) a zablokovat přístup na konfigurační weby převodníků. U převodníku PiiGAB doporučujeme vypnout rozhraní NFC.
Proč je nutné použít převodník R035? Nešlo by komunikovat po UDP rovnou z PLC – to má přece také síťovou kartu? Toto bohužel dnes není možné, v runtimu není zatím přenos protokolu M-Bus po TCP či UDP implementován.
Šlo by připojit do sítě více M-Bus/Ethernet převodníků a data z jejich měřičů načítat přes jeden R035? Teoreticky ano, stačí rozšířit tabulku v nastavení R035 o další destinace. Dotazy pak budou rozesílány na více převodníků PiiGAB zároveň, ale odpověď se vrátí jen z toho, k němuž je připojen měřič s příslušnou adresou.
Umožňuje přechod na Ethernet vyčítání dat z měřičů více klienty? Data se přece na síti serializují a vyřešil by se tím častý problém sdílení dat z měřičů mezi více systémy! Teoreticky ano, ale museli bychom zajistit, aby frekvence vyčítání byla natolik nízká, aby nemohlo dojít k zahlcení M-Bus sběrnice, resp. zajistit, aby jeden klient několik minut odečítal například v celou hodinu a jiný v celou + 30 minut. V případě TCP je převodník schopen obsloužit max. 2 spojení, u UDP toto není relevantní a řešíme jen časovou kolizi, resp. propustnost sběrnice M-Bus. Každopádně více klientů představuje možný hazard, který by mohl vést k výpadkům komunikace a proto je potřeba každé takové řešení dobře promyslet z pohledu všech komunikačních vrstev.