info@ipesoft.com
+421 907 703 854
Obchodná 9076/3D
010 08 Žilina
Slovensko
SK
22.11.2024
Komunikácia - Generic User Protocol
Dnes si povieme niečo o protokole, ktorý nerobí v podstate nič :-). Dozviete sa, k čomu sa dá použiť a z akého dôvodu bol vytvorený.
Generic User Protocol bol v D2000-ke implementovaný v roku 2015. Predstava použitia je veľmi priamočiara. Predstavme si jeden z jednoduchých protokolov, ktoré výrobcovia rôznych jednoúčelových zariadení navrhnú na komunikáciu s týmto zariadením. A predstavme si ďalej, že toto zariadenie potrebujeme nakomunikovať do D2000-ky.
Aké máme možnosti?
Prvou je implementácia priamo vývojármi D2000-ky. Druhou je napísanie protokolu ako dynamickej knižnice s použitím rozhrania KomApi. A nakoniec, treťou je implementácia protokolu v prostredí D2000 Event v jazyku ESL alebo Java.
Aké sú výhody a nevýhody jednotlivých možností?
Implementácia protokolu priamo v procese D2000 je z pohľadu OEM partnerov asi najmenej flexibilná. Na druhú stranu je táto možnosť najlepšie integrovaná a dokáže využiť všetky možnosti, ktoré D2000 KOM proces ponúka.
Implementácia protokolu ako dynamickej knižnice (OEM protokolu) umožňuje použiť rôzne jazyky (napr. C alebo C++). Autormi pritom môžu byť programátori OEM partnera, takže nie je nutné čakať na vývojárov D2000-ky. Programátori OEM protokolu musia zvládnuť rozhranie KomApi.
Tretiu možnosť umožnil práve protokol Generic User Protokol. Základom je nakonfigurovanie objektov typu linka, stanica a merané body. Generic User Protokol podporuje širokú paletu liniek – sériové (jednoduché, linkovo redundantné aj systémovo redundantné), SerialOverUDP (opäť, varianty s redundantnými zariadeniami, linkovo redundantné aj systémovo redundantné), MOXA IP Serial Library a TCP (jednoduché aj redundantné). V prípade TCP je zatiaľ podporený iba klientsky mód (pripájanie sa na špecifikovanú IP adresu/adresy).
Konfigurácia komunikačnej stanice je jednoduchá – v zásade sa nastaví iba protokol Generic User. Na jednej linke by mala byť iba jedna stanica.
Merané body môžu byť vstupné a výstupné. V základnej konfigurácii sú použité dva merané body – jeden vstupný s adresou IN a jeden výstupný s adresou OUT. Oba tieto merané body sú textové (typu TxtI a TxtO).
Ako teda Generic User Protocol funguje? Textový reťazec zapísaný do meraného bodu s adresou OUT je poslaný na do komunikácie – cez sériovú linku, ako UDP paket, prípadne TCP dáta – podľa typu linky.
Hodnoty prijaté z komunikácie sú zapísané do vstupného meraného bodu s adresou IN – takže je možné vytvoriť serverovský skript s použitím ON CHANGE alebo trigger skript spustený na základe zmeny hodnoty vstupného meraného bodu.
Použitie Generic User Protocolu je teda jednoduché – skript do meraného bodu OUT zapisuje výzvy a z meraného bodu IN číta odpovede komunikačného partnera. Autor skriptu musí vo vlastnej réžii ošetriť timeouty (napr. žiadna alebo nekompletná odpoveď na výzvu) a korektnosť prijatých dát ako aj ich ďalšie spracovanie.
Pre redundantné linky podporuje Generic User Protocol aj redundantné vstupné a výstupné body. Tieto majú adresy IN_A a IN_B pre redundantné linky (Serial Line Redundant, SerialOverUDP Line Redundant, TCP/IP-TCP Redundant), prípadne IN_A, IN_B, IN_C a IN_D pre systémovo a linkovo redundantné linky (Serial System&Line Redundant, SerialOverUDP System&Line Redundant). Podobne je možné riadiť zapisovanie do jednotlivých redundantných liniek cez výstupné merané body s adresami OUT_A a OUT_B, prípadne pre systémovo a linkovo redundantné linky aj OUT_C a OUT_D.
V konfigurácii komunikačnej linky je možné nakonfigurovať niekoľko parametrov, ktoré ovplyvňujú chovanie protokolu.
Parameter Read Wait Timeout (RT) určuje čakanie medzi jednotlivými čítaniami z komunikácie. Pokiaľ boli už prijaté nejaké dáta, ale po dobu RT žiadne ďalšie dáta neprišli, prijaté dáta sú zverejnené do vstupného meraného bodu. Ak prišli dáta, sú pridávané do vstupného buffra, kým nedôjde k timeoutu RT alebo kým sa vstupný buffer nenaplní. Veľkosť vstupného buffra udáva ďalší parameter – Read Size. Ak je prijatých viac vstupných dát, sú zverejnené na viac krát. V ESL skripte je následne možné dáta pospájať.
Parameter Log Each Read spôsobí vypnutie popísaného mechanizmu. Dáta sú zverejnené (a prípadne vypísané do logu linky) hneď po prijatí.
Zvyšné parametre ovplyvňujú iba spôsob logovania. Je možné nastaviť textový alebo hexadecimálny formát výpisu prijatých dát v logoch (parameter Log Format) a pre redundantné linky jemožné zapnúť logovanie všetkých dát do jedného súboru (parameter Single Log). Štandardne sa vytvára samostatný logovací súbor pre primárnu linku a pre sekundárnu, prípadne pre systémovo redundantné linky samostatný logovací súbor pre primárnu/sekundárnu linku systému A/B.
Príkladom použitia je parsovanie dát prijatých od GPS prijímača Garmin. Garmin komunikuje textovo orientovaným protokolom NMEA-0183, ktorý sa skladá z „viet“ oddelených znakmi CR a LF (sekvencia pre nový riadok). Garmin posiela vety za sebou a automaticky, bez potreby výzvy (takže nie je nutný meraný bod OUT).
V príklade bola použitá linka typu SerialOverUDP Device Redundant, stanica s komunikačným protokolom Generic User Protocol a jediný meraný bod typu TxtI (textový vstup) s adresou IN.
Dáta prijaté KOM procesom a zverejnené pomocou hodnoty vstupného meraného bodu s menom M.GENUSR_IN boli v skripte schémy kopírovaného do vstupného buffra. Následne boli v buffri hľadané kompletné vety (oddelené sekvenciou CR LF, tj. hexadecimálne 13 a 10). Každá vstupná veta bolo analyzovaná. Pokiaľ sa jednalo o vetu typu GRPMC, boli z nej vyextrahované údaje o zemepisnej polohe a aktuálnom čase a dátume. Pokiaľ sa jednalo o vetu typu GPCGA, boli z nej vyextrahované údaje o počte viditeľných satelitov. Jednotlivé údaje boli následne zobrazené v schéme.
Skript bol implementovaný priamo v schéme kvôli ukážke analýzy. V produkčnom prostredí by sa schéma použila iba na zobrazovanie dát a analýzu by vykonával serverový skript v rámci EVH procesu spusteného priamo na serveri (aby bežal stále). Získané údaje by boli ukladané do užívateľských premenných, prípadne do položiek štruktúrovaných premenných.
Navyše by bolo nutné ošetriť korektnosť vstupu (napr. prevod dát na čísla) a indikovať rozpad komunikácie (niekoľko sekúnd nebola prijatá žiadna hodnota).
V prípade komunikácie s viacerými zariadeniami (t.j. ak by existovalo viacero liniek, každá so stanicou a meraným bodom) by bolo vhodné napojiť merané body do položiek štruktúrovaných premenných do stĺpca typu Objekt a prerobiť skript na štruktúrovaný, aby nebolo nutné vytvárať kópie skriptu, ktoré by sa líšili iba použitými meranými bodmi. Pokiaľ by to intenzívna komunikácia vyžadovala, je možné spustiť viacero inštancií serverového skriptu pomocou akcie OPENEVENT, pričom každá inštancia by obsluhovala jeden riadok štruktúry.
Výhodou takto implementovaného protokolu je rýchlosť implementácie, ľahkosť ladenia priamo prostriedkami ESL (pripojenie k bežiacemu skriptu a krokovanie) a možnosť implementácie bez potreby znalosti programovania v C či C++ a bez znalosti rozhrania KomApi.
Pri použití linky typu TCP/IP-TCP je dokonca možné z ESL pracovať so zariadeniami podporujúcimi telnet protokol a ovládať ich, prípadne meniť ich konfiguráciu. Vypnutie komunikácie na stanici tell príkazom STSTAT spôsobí ukončenie komunikácie a zatvorenie TCP spojenia.
Čo dodať na záver? Možno iba perličku, že prvé použitie protokolu bolo v pasívnom móde na odchytávanie a logovanie sériovej komunikácie s použitím viacerých portov Moxa NPort servera. A ďalším bola práca s USB čítačkou čiarových kódov LS2208 od Symbol Technologies v prostredí Linuxu.
3.6.2018, Ing. Peter Humaj, www.ipesoft.com
Iné blogy