Problémem řady aplikačních inženýrů v posledních letech je přechod od průmyslových komunikací typu linek RS-485 k síti Ethernet, bez hlubších znalostí počítačových sítí a principů, na kterých fungují. Z toho vyplývá mnohdy nevhodný způsob používání síťových technologií. Proto se pokusím v dalším textu přehledně odlišit tři základní filozofie návrhu systému. Pro větší názornost začněme jednoduchým příkladem, na kterém popíšeme na praktickém případě praktickou realizaci podobného systému.

Provozovatel veřejného koupaliště (městský úřad) vybudoval nový bazén a chce na svých webových stránkách uveřejnit webovou kameru na toto koupaliště a aktuální teploty vzduch u vody.

Aplikaci lze na první pohled řešit samostatným PC s připojenou USB kamerou a měřením teploty na některém ze sériových portů. Toto řešení je ale v praxi problematické vzhledem k programům, které jsou pro podobné věci k dispozici a spojení s čidlem teploty, ale hlavní kámen úrazu tohoto řešení je v tom, že pokud by všichni uživatelé přistupovali na server na koupališti, muselo by být koupaliště na Internet připojeno na Internet po připojení, které předpokládá velký datový tok, které by se nezaplatilo.

Značnou nevýhodou také je, že obrázek bude v „externím okně“ a nebude jej snadno možné vložit do hlavní stránky radnice. V tomto případě je to kosmetická vada, ale pokud potřebuji data zpracovávat a ukládat např. do SQL databáze, je to celkem podstatný problém.

Naopak velmi elegantním řešením je umístit na koupaliště pouze technologii a data vyčítat a zpracovávat na serveru, kde běží ostatní webové stránky. Na běžném PHP nebo ASP serveru poběží aplikace, která každých cca 10 minut stáhne aktuální obrázek z koupaliště a teploty. Tyto údaje uloží do databáze a uživatel WWW stránek pak tyto údaje načítá již z databáze, což je podstatně rychlejší.

Obr.1 - Příklad aplikace, kde jsou technologická data zobrazena přes PHP

Schéma popsaného příkladu vidíte na obrázku 1. Podstatné zde je, že návštěvník se ze zobrazeného notebooku přes GPRS připojuje na server a data stahuje pouze z tohoto serveru, nikoliv přímo na „technologii“ v areálu koupaliště. Ta mu je skryta a komunikuje s ní pouze script na serveru, data jsou předávána databází na serveru.

Měření teplot lze realizovat jednoduchými teploměry, které komunikují po RS- 485 a jsou připojeny do převodníku, který se tváří jako TCP Server. Pravidelně spouštěný script na WWW serveru pošle na RS-485 dotaz a dostane zpět odpověď s teplotou, kterou uloží do databáze.

Ačkol, rs-iv to možná vypadá na první pohled složitě, jedná se o kód na několik řádek, protože poslední verze scriptovacích jazyků běžících na serveru (PHP pro Linux a ASP pro MS platformu) umožňují otevírat spojení s vnější IP adresou a vyčítat z nich data. Podobná aplikace je tedy pro jakéhokoliv návrháře WWW stránek práce na několik málo hodin.

Naproti tomu, kdybychom chtěli číst hodnoty teplot samostatně = místo jednoduchého převodníku RS-485 / Ethernet použít malý WWW server a zobrazení teploty z RS-485 čidel programovat do tohoto vestavného (embedded) převodníku, zabralo by to podstatně víc času, protože vývojář by se musel naučit pracovat s úplně novou platformou, zatímco v PHP umí.

Zásadní problém ale je, že zadavatel potřebuje data zobrazovat na svojí WWW stránce, ve svém designu, takže malý WWW server s výstupem technologie na koupališti je mu zcela k ničemu.

Obdobným způsobem si lze představit zpětné ovládání (například natáčení webové kamery) z WWW stránky, realizované zase pomocí PHP scriptů, které již předávají data technologii.

Porovnání způsobů přístupů k ethernetovému zařízení

V zásadě lze tedy hovořit o třech způsobech připojení a komunikace ethernetových zařízení. Každý tento způsob má nějaké výhody, či nevýhody a hodí se k něčemu jinému.

Přímé propojení – Technologie <–> Technologie

Pokud potřebujete propojit binární signalizaci, případně komunikační linky (RS-232, 485) po síti Ethernet bod proti bodu = data jen po Ethernetu „prodloužit“ použijete uvedené schéma. Zařízení spolu komunikují proprietárním protokolem. Pro vyšší komfort zde může být použito WWW nastavování zařízení, ale pro samotnou funkci není podstatné.
 

Obr. 2 - Přímé propojení 2 zařízení po síti Ethernet

Nejběžnější je v této konfiguraci komunikace po UDP/IP, případně TCP/IP pokud se k jednomu zařízení připojuje víc TCP Clientů.

Pro TCP spojení jsou důležité podmínky pro timeout, protože pokud je počet současně otevřených TCP spojení na jedno zařízení výrazně omezen, mohou se za čas nahromadit neuzavřená spojení s systém bude třeba restartovat. Proto je třeba počítat s timeoutem TCP spojení a nenastavovat délku spojení na nekonečno, protože to z dlouhodobého hlediska může ohrozit stabilitu systému.

V podobných systémech je také třeba velmi dobře hlídat stav systému po restartu, nastavenou počáteční hodnotu binárních výstupů a pořadí sestavování spojení. Právě proto, že často zařízení mohou pracovat pouze v režimu „TCP Client“, nebo „TCP Server“ = jen strana „TCP Client“ umí vytvořit datové spojení po restartu se používá často režim UDP/IP.

Přímé propojení – uživatel <–> Technologie

V tomto nejběžnějším případě je třeba odlišit přenos dat (například naměřených) a vzdálené nastavení / dohled jinak autonomně běžícího zařízení. Pro případ vzdálené konfigurace a dohledu je ideální WWW server v zařízení a možnost heslem zabezpečené konfigurace nebo ověření výsledků odkudkoliv (viz Kapitola WWW server v technologii).
 

Obr.3 – Přímý přístup na technologii po síti Ethernet

Pokud ale hovoříme o průběžném přenosu dat, nebudeme, je pravděpodobně přenášet pomocí http protokolu (WWW stránek). Ethernetové zařízení přenáší data proti jednomu konkrétnímu počítači, respektive počítačům, z nichž ale v danou chvíli smí se zařízením komunikovat = ovlivňovat výstup vždy pouze jeden.

Nevýhodou je nutnost naprogramování uživatelské aplikace, která naměřená data zpracovává a vyhodnocuje, ale to lze většinou předpokládat. Pokud není třeba naměřené výsledky zpřístupnit po síti více uživatelům v uživatelsky přívětivé formě (WWW stránky), je toto řešení ideální.

Přímé propojení – WWW server v technologii

Tento případ má stejné schéma zapojení jako předchozí přímý sběr dat. Grafické rozhraní pro komunikaci je zde obsaženo v samotném ethernetovém zařízení. Může se jednat například o naprogramovanou webovou stránku, k níž má uživatel přístup prostřednictvím www prohlížeče zadáním IP adresy, jež je nastavena v zařízení.

Toto řešení je příjemné, pokud se na zařízení připojuje řada uživatelů z různých míst. Rozsah podobných aplikací v praxi, je ale velmi omezen, protože většina vestavný aplikací se používá pro komunikaci typu M2M (Mashine to Mashine), kde komunikují dvě zařízení mezi sebou. V praxi je třeba brát v úvahu omezené zdroje programovatelného Ethernetového zařízení, kde bývá značně omezen výkon a množství uložitelných dat atd.

Nevýhodou je potřeba poměrně složitého programového vybavení ethernetového zařízení, pro něž se aplikace obsahující grafické rozhraní píše nesrovnatelně hůře než v případě internetového serveru. Topologie řešení přináší také řadu komplikací s updatem firmwaru, který není vždy možný po síti a hlavně jeho odladění trvá podstatně déle než na serverovém PC. Při návrhu aplikace je také třeba počítat s tím, že grafické rozhraní zabere v zařízení značnou část paměti.

Nepřímé propojení – Uživatel - WWW server & databáze - technologie

Tento případ je podobný jako náš úvodní příklad. Data jsou vyčítána z Ethernet zařízení samostatným scriptem, který je buď přímo zobrazí uživateli na WWW stránce, nebo je vloží do databáze, ze které je načítá paralelně běžící WWW server.
 

Obr.4 – Technologie – WWW server – Uživatel

Uživatel si vyžádá WWW stránku ze serveru (1), server otevře spojení na technologii a vyžádá data (2), technologie pošle data serveru (3), server zobrazí uživateli WWW stránku s naměřenými daty (4).

Jedná se o typickou aplikaci pro embedded zařízení, kde je pro komunikaci použito TCP/IP s tím, že technologické Ethernet zařízení většinou pracuje v režimu „TCP Server“ a hlavní server se připojuje jako „TCP Client“ . V případě urgentních událostí to může být i naopak.

Nevýhody tohoto řešení

• Nevýhodou řešení je nutnost běžícího webového serveru poskytujícího podporu pro příslušný skriptovací jazyk, jímž je obsluha realizována. Pokud je tento server mimo provoz je třeba zajistit náhradní řešení, jinak dojde ke ztrátě dat po zaplnění vyrovnávací paměti v jednotlivých zařízeních.

Výhody tohoto řešení

• Uživateli stačí vytvořit si grafické rozhraní prostřednictvím jazyka HTML a příslušného skriptovacího jazyka, který má na serveru k dispozici, aniž by se musel učit jiné technologie, které využívá ethernetové zařízení.
   
• Veškerá data, která webový server načte, lze libovolně dále zpracovávat, ukládat do souborů či SQL.
   
• WWW stránky lze snadno modifikovat v závislosti na potřebách uživatelů či samotného ethernetového zařízení.
   
• Rychlost komunikace, respektive délka spojení mezi hlavním serverem a technologickým zařízením, je dána prakticky pouze velikostí datového toku, bez zbytečné grafiky (velmi podstatne například v GPRS sítí, kde se platí za přenesený kb).
   
• Robusní řešení z hlediska bezpečnosti, neboť zabezpečení „velkého“ webového serveru proti náhodnému napadení či cílenému útoku je nesrovnatelně větší než zabezpečení embedded zařízení.
   

Příklady TCP komunikace po Ethernetu

Pokud potřebujete implementovat do Vaší technologie komunikaci s obecným Ethernetovým zařízením, mohli by Vám pomoci v začátcích řešené příklady, která najdete v rubrice Programování na HW serveru (www.HW.cz).

Borland C++ Terminál

Příklad jednoduché komunikace s obecnými TCP/IP zařízeními v Borland C++ Builder 6.00. Příklad demonstruje jednoduchý TCP Client terminál a základní příkazy NVT (Network Virtual Terminal).

Více o příkladu - Borland C++ příklad komunikace  

MS Visual Basic příklad

Velmi jednoduché rutiny pro práci s NVT příkazy a TCP/IP zařízením přes Winsock v MS Visual Basicu 5.0. Jednoduché příkazy pro vzdálené ovládání I/O Pinů jsou implementovány, TEA nikoliv.
 

Delphi Terminál

Příklad jednoduché komunikace s obecným TCP/IP zařízením v Borland Delphi 5 demonstruje jednoduchý klientský terminál vybavený základními příkazy NVT (Network Virtual Terminal) a rozšířením pro I/O funkce.
 
Více o příkladu - Delphi Charon 1 - Příklad komunikace a NVT ,
 

Delphi TCP/IP logger/server example

Příklad jednoduchého TCP/IP loggeru napsaného v Borland Delphi 6 demonstruje jednoduchý server, reagující na navázání spojení, logující všechny důležité stavy (připojení, odpojení klienta, chyby v aplikaci) a příchozí data do dvou vstupních souborů. Tento příklad zároveň demonstruje přístup k registrům Windows, práci s INI soubory apod.

Více o příkladu - Delphi TCP/IP logger/server example

Java NVT - Code Example

Velmi jednoduché ovládání vzdálených I/O pinů přes NVT s pomocí JAVA aplikace. Výhodou JAVA aplikace spuštění z WWW prohlížeče na libovolném PC, což spojuje výhody přístupu přímo na technologii, ale komunikaci technologickým protokolem.
 
 

PHP demo

Demonstrace PHP scriptu, který načte data z technologie a zobrazí je uživateli v požadovaném designu. Tento příklad umožňuje jednoduché ovládání vzdálených binárních vstupů a výstupů prostřednictvím PHP skriptu. Uživatel si vyžádá WWW stránku z PHP serveru, ten před odpovědí uživateli otevře spojení na nastavenou IP adresu a port, přečte hodnoty, zavře spojení na binární zařízení a zjištěné hodnoty zobrazí uživateli na WW stránce.
 

Veřejné demo příkladu - www.hw-group.com/products/charon1/test/
 
 
 

DOWNLOAD & Odkazy

• HW group - průmyslové aplikace - http://www.hwgroup.cz/
   
• Příklad praktické aplikace - METEX PHP Control - připojte si METEX do Ethernetu a dohlížejte jej přes WWW stránky.