Klient, server, master, slave...
Při projektování a oživování inteligentních budov hraje podstatnou roli vzájemná komunikace jednotlivých systémů, jako jsou měření a regulace, chlazení, EZS, EPS, hotelové systémy a další funkční celky. Zájemci o tuto problematiku jsou zváni na školení společnosti Domat: Komunikace protokolem Modbus.
Během posledního půlroku jsem se při vyjasňování vazeb mezi jednotlivými systémy asi třikrát setkal se zajímavým nedorozuměním, a sice: „které ze dvou zařízení bude v komunikaci podřízené a které bude komunikaci řídit“. To je nutné mezi oběma dodavateli dohodnout zároveň při domlouvání na použitém komunikačním protokolu, protože některé protokoly používané v technologiích budov jsou právě na tomto principu založeny. Bohužel zde existují minimálně dva způsoby, jak tento vztah popsat, a jejich míchání vede k zmatečným diskuzím a e-mailům. Pojďme se na ně podívat a udělat si ve věci jasno.
Master a slave
Terminologie pochází ze sériové komunikace. Zařízení označované jako „master“ je řídicí zařízení na sběrnici. Master vysílá telegramy, kdy on sám potřebuje (samozřejmě při respektování podmínek jako je klid na sběrnici atd., ale to bychom se již dostávali do nižších úrovní komunikačního modelu), slave čeká, až bude adresně osloven, a pak odpoví. Zařízení typu slave může být na sběrnici jedno (pak mluvíme o spojení bod-bod), ale často jich tam najdeme až několik desítek – to záleží mimo jiné na typu komunikační sběrnice a způsobu adresování, který je dán komunikačním protokolem.
Například stále oblíbené sériové rozhraní RS232 představuje typickou komunikaci bod-bod, propojovací kabel, tzv. modemový nebo nullmodemový kabel, má dva konce – a ani o jeden více. Komunikace například mezi procesní podstanicí pro řízení topení (Domat IPLC301, master) a rozhraním pro integraci kotlů (Buderus RS232 gateway, slave) probíhá asi tímto způsobem:
Master: vysílá dotaz na slave s požadavkem 1
Slave: odpoví na požadavek 1
Master: vysílá dotaz na slave s požadavkem 2
Slave: odpoví na požadavek 2
atd.
Naproti tomu linka RS485 může hostit až několik desítek zařízení slave, kterými jsou například pokojové regulátory (Domat UC100), vstupně-výstupní moduly atd. Master je v těchto případech např. počítač s vizualizací, PLC s řídicím programem (Saia PCD) nebo nějaké další rozhraní. Komunikace pak vypadá nějak takto:
Master: vysílá dotaz na slave s adresou X a požadavkem 1
Slave s adresou X: odpoví na požadavek 1
Master: vysílá dotaz na slave s adresou Y a požadavkem 2
Slave s adresou Y: odpoví na požadavek 2
Master: nedělá nic
Slave: žádný nedělá nic
atd.
Podstatné tedy je, že master vždy vznáší dotaz (požadavek) na některé ze zařízení slave, toto zařízení pak odpoví. Pokud slave neodpoví v definovaném časovém intervalu, dochází k tzv. timeoutu, který je obvykle vyhodnocen jako chyba komunikace.
Klient a server
Toto názvosloví se rozšířilo ve výpočetní technice. Princip je podobný jako v předchozím případě. Komunikaci zahajuje klient, který se dotazuje serveru. Server, jak vyplývá z názvu, „poslouží“ odpovědí, sám od sebe komunikaci nezahajuje. Ve světě počítačových sítí je naprosto běžné, že na jeden server vznášejí dotazy stovky nebo tisíce klientů, a že na „sběrnici“, tedy v síti, je více serverů. To, že dva klienti se nezeptají ve stejný okamžik a neruší se navzájem, musí řešit nižší vrstvy sítě; představme si v roli klientů operátorské stanice s vizualizací a jako server komunikativní čidlo teploty v racku, které je přenášeno na oba dispečinky.
Klient 1: vysílá dotaz na server s požadavkem A
Server: odpovídá klientovi 1 na požadavek A
Klient 2: vysílá dotaz na server s požadavkem B
Server: odpovídá klientovi 2 na požadavek B
atd.
V prostředí sítí Ethernet, tedy například u protokolu Modbus TCP, se může stát, že odpovědi na požadavky nenásledují ihned po dotazech:
Klient 1: vysílá dotaz na server s požadavkem A
Klient 2: vysílá dotaz na server s požadavkem B
Server: odpovídá klientovi 1 na požadavek A
Klient 3: vysílá dotaz na server s požadavkem C
Server: odpovídá klientovi 2 na požadavek B
Server: odpovídá klientovi 3 na požadavek C
atd.
I takováto komunikace je v pořádku a správně, pokud odpověď na každý dotaz dorazí ke klientovi v rámci jeho timeoutu. Může dokonce dojít k tomu, že odpovědi jednomu klientovi přijdou v jiném pořadí, než v jakém klient vznášel dotazy; i to je zde v pořádku a protokol to dokáže řešit. [1]
V čem tedy spočívá problém?
V kombinování výrazů, které „nejdou do páru“. Typicky při diskuzích o komunikaci protokolem Modbus RTU probíhá telefonát takto:
Dodavatel A: „My umíme naprogramovat Modbus master.“
Dodavatel B: „Dobře, naše zařízení bude klient.“
Dodavatel A: „Počkejte, klient jsme my!“
Dodavatel B: „Ne, vy jste přece server!“
A tak dále. Potíž je nejspíš v tom, že výrazy master a server působí dojmem něčeho silnějšího, takže „je to to samé“. Jejich funkce je přitom odlišná. Shodněme se tedy na tom, že u sériových protokolů, které pracují s telegramy dotaz – odpověď, platí
master = klient, strana, která komunikaci řídí a vznáší dotazy,
slave = server, strana podřízená, která čeká na dotaz a pak odpovídá.
U běžných sériových protokolů, jako Modbus, M-Bus, firemní protokoly pro FV střídače atd. bývá serverem zařízení na „nižší“ úrovni v topologii systému:
| Systém | Master | Slave |
|---|---|---|
| PLC s distribuovanými I/O | Procesní podstanice | Vstupně-výstupní moduly |
| Integrovaná regulace pokojů | Vizualizační PC, systémový kontrolér atd. | Pokojové regulátory (termostaty) |
| Integrace klimajednotek | Vizualizační PC, procesní podstanice atd. | Rozhraní pro integraci klimajednotek |
| Monitoring fotovoltaické elektrárny | PLC pro sběr dat | Fotovoltaické střídače |
| Sběr dat z měřičů energií | Rozhraní pro sběr a záznam dat | Elektroměry, kalorimetry atd. |
U složitějších protokolů, jako je například OPC, už se používá jen terminologie server – klient; jednak proto, že se zde pohybujeme v prostředí počítačových sítí, jednak server může za určitých podmínek klientovi poslat zprávu sám od sebe (například při změně zaregistrované procesní hodnoty nad určitou mez).
Na závěr je třeba upozornit, že ne všechny systémy dovedou pracovat jako klient i jako server, nebo konfigurace jedné z rolí s sebou může nést vyšší náklady na parametrizaci a uvádění do provozu či hardware v podobě přídavných karet atd. Proto je při projektování a vyjasňování vzájemných komunikačních vazeb důležité, aby obě strany měly jasnou představu o tom, jak funguje jejich vlastní zařízení. Jedině tak bude komunikace mezi lidmi a následně i mezi systémy v pořádku.
Poznámka
[1] Zájemci o tuto problematiku jsou zváni na školení Komunikace protokolem Modbus, termíny v kalendáři akcí nebo po domluvě.
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.