Uniwersalny serwer do monitorowania urządzeń przemysłowych za pomocą przeglądarki internetowej 15

MARIAN HYLA

���������������� ������������������ �����������������

��������������� ����������������

W artykule przedstawiono realizację uniwersalnego serwera pośredniczącego w procesiemonitorowania urządzeń przemysłowych wykorzystujących protokół Modbus TCP. Apli-kacja udostępnia wybrane informacje za pomocą protokołu HTTP akceptowanego przezprzeglądarki internetowe. Zaprezentowano możliwość konfiguracji oprogramowaniaoraz przykładowe strony generowane przez serwer. Przedstawiono wyniki testów wydajno-ściowych połączenia Modbus TCP.

Słowa kluczowe: monitorowanie, zdalny dostęp, Modbus TCP, HTTP, WWW

MINING – INFORMATICS, AUTOMATION AND ELECTRICAL ENGINEERING No. 2 (530) 2017

�� �� !"

Nowoczesne technologie informatyczne dają szero-kie możliwości transmisji danych z wykorzystaniemkomputerowych sieci lokalnych, jak i globalnej sieciInternet. W dobie powszechnego dostępu do Inter-netu coraz więcej urządzeń przemysłowych wyposażasię w interfejsy sieciowe, wykorzystywane do zdalnegosterowania i monitorowania stanu pracy. Praktycznieprzestaje mieć znaczenie zarówno lokalizacja monito-rowanych urządzeń, jak i lokalizacja użytkownika.

Jednym z najczęściej implementowanych proto-kołów urządzeń przemysłowych z możliwością łącz-ności przez sieć Ethernet/Internet jest protokół Mod-bus TCP [13]. Od strony użytkownika powszechnymi ogólnie dostępnym narzędziem dostępu do siecisą przeglądarki internetowe wykorzystujące protokółHTTP (Hypertext Transfer Protocol) [11].

Zarówno Modbus TCP, jak i HTTP są protokołamiwarstwy aplikacji stosu protokołów TCP/IP i do trans-portu wykorzystują protokół TCP (Transmission Con-trol Protocol) oraz warstwy niższe [3–7, 11, 13, 18, 19].Aby umożliwić prezentację danych z urządzeń Mod-bus TCP za pomocą przeglądarki internetowej, ko-nieczne jest jednak zastosowanie odpowiedniego na-rzędzia (aplikacji) umożliwiającego konwersję danychpomiędzy obydwoma protokołami.

#�$ "%& &'()�*&+,��� -"

Protokół Modbus [12, 14] został opracowanyw 1979 r. przez firmę Modicon, przejętą w połowielat 90. ubiegłego wieku przez Schneider Electric. Po-mimo gwałtownego rozwoju nowych technik komuni-kacji i opracowania nowych protokołów transmisyjnychjest on w dalszym ciągu jednym z najpopularniejszychprotokołów przemysłowych i z powodzeniem stoso-wany jest do lokalnej komunikacji z urządzeniamiwyposażonymi w szeregowe asynchroniczne interfejsytransmisji danych w modelu komunikacji typu Master--Slave.

Powszechny dostęp do Internetu oraz możliwośćimplementacji stosu protokołów TCP/IP [3–6, 18, 19]w urządzeniach przemysłowych przyczyniły się doopracowania nowej wersji protokołu Modbus dlasieci pakietowych nazwanej Modbus TCP lub ModbusTCP/IP [13]. Protokół ten bazuje na odmianie proto-kołu Modbus RTU i jest jego implementacją dla sie-ci IP. Porównanie struktury ramki Modbus RTU orazModbus TCP przedstawiono na rysunku 1.

Ramka protokołu Modbus TCP (Application DataUnit) składa się z nagłówka (Modbus Application Head-er) oraz właściwej części danych (Protocol Data Unit).

Transmisja danych przez sieć datagramową wiążesię z możliwością odebrania danych przez urządzenie

16 M. Hyla

odbiorcze w innej kolejności, niż zostały wysłane przezurządzenie nadawcze. Z tego względu w nagłówkuprotokołu Modbus TCP wprowadzono dwubajtowepole identyfikatora transakcji Transaction ID zawiera-jące numer transmitowanej ramki. Pozwala ono naidentyfikację polecenia urządzenia Master, na któreodebrano odpowiedź od urządzenia Slave.

Dwubajtowe pole Protocol ID zawiera identyfikatorprotokołu (dwa bajty o wartości 0).

Dwubajtowe pole Length zawierające informacjęo długości pozostałej części ramki pozwala na rozdzie-lenie poszczególnych ramek zgromadzonych w bufo-rze odbiorczym urządzenia.

Adres urządzenia podrzędnego Slave ID zastąpio-no identyfikatorem urządzenia Unit ID.

Jednostka danych protokołu Protocol Data Unit Mod-bus TCP jest zgodna z formatem PDU protokołuModbus RTU [12–14].

Ramka Modbus TCP nie zawiera sumy kontrolnej,gdyż prawidłowość dostarczenia danych gwarantująprotokoły warstw niższych [3–6, 18, 19].

.�$ "%& &'()�/ "

Protokół HTTP wykorzystywany jest do przesyłaniadokumentów hipertekstowych pomiędzy przeglądar-kami internetowymi a serwerami sieci WWW (WorldWide Web) [7, 11]. Zasoby HTTP znajdujące się w sieciidentyfikowane są przez adresy zasobów sieciowychw konwencji URI (Universal Resource Identifier). Ad-resy URI mogą wskazywać nie tylko na pliki utworzo-ne w formacie HTML (HyperText Markup Language)[2, 15, 17, 20], lecz na dowolne zasoby sieci. Do identy-fikacji przesyłanych danych używany jest podzbiórMIME (Multipurpose Internet Mail Extensions). Proto-kołem HTTP można więc przesyłać pliki o dowolnymformacie i zawartości, jeżeli tylko serwer będzie w sta-nie je udostępnić [7, 11].

Pobierane mogą być dane przechowywane na ser-werze lub wygenerowane dynamicznie na żądanieużytkownika. Dynamiczne tworzenie witryn może byćrealizowane po stronie serwera, np. skrypty CGI(Common Gateway Interface), interpretery PHP (Per-sonal Home Page), servlety, ASP (Active Server Pages)lub po stronie klienta, np. JavaScript, applety, DHTML(Dynamic HTML), technologia Flash itp. [2, 8, 15–17, 20].Zwykle łączy się wybrane technologie po stronieserwera z tymi po stronie klienta. Możliwość dyna-micznego generowania zawartości strony wyświetla-nej w przeglądarce internetowej może być wykorzystanaw systemach monitorowania. Aktualizacja zawartościokna przeglądarki zgodnie ze stanem monitorowane-go urządzenia może być realizowana bez koniecznościodświeżania strony przez użytkownika. Żądanie prze-słania aktualnych danych może być generowane przezskrypt po stronie klienta.

Komunikacja pomiędzy przeglądarką internetowąa serwerem WWW odbywa się w modelu klient--serwer. Klient otwiera połączenie, wysyła żądanie doserwera, a serwer przetwarza je, zwraca odpowiedźi zazwyczaj zamyka połączenie. Komunikaty przesyła-ne przez HTTP składają się z dwóch elementów: na-główka (header) i ciała (body) [7, 11]. Żądanie klientazawarte jest w nagłówku HTTP. W odpowiedzi serwerzwraca swój nagłówek i, jeżeli jest to wymagane, ciałokomunikatu. Na rysunkach 2 i 3 przedstawiono przy-kładową komunikację pomiędzy przeglądarką inter-netową a serwerem WWW.

Protokół HTTP używa ośmiu metod (GET, POST,HEAD, PUT, DELETE, OPTIONS, TRACE, CON-NECT) przesyłanych w nagłówkach i określającychżądane akcje [7, 11]. Aplikacja uniwersalnego serweramonitorowania wykorzystuje metodę GET, a danezwiązane ze sterowaniem przez użytkownika informa-cjami wyświetlanymi w oknie przeglądarki realizowa-ne jest przez przesyłanie parametrów z ukrytych for-mularzy zawartych na stronie.

Rys. 1. Struktura ramki Modbus RTU i Modbus TCP

Uniwersalny serwer do monitorowania urządzeń przemysłowych za pomocą przeglądarki internetowej 17

Protokół HTTP jest protokołem bezstanowym, tzn.po zamknięciu połączenia serwer nie przechowujeżadnych informacji o poprzednich transakcjach [7, 11].Z tego powodu każde zapytanie traktowane jest przezserwer jako nowe i niemożliwe do powiązania z in-formacjami o poprzednio przesłanych danych. W celuzapamiętania stanów związanych z poprzednim połą-czeniem najczęściej wykorzystuje się mechanizm cia-steczek (cookies). Informacje o ciasteczkach mogą byćzawarte w nagłówkach przesyłanych komunikatów.Inną metodą jest przesyłanie ukrytych parametrówz formularzy zawartych na stronie lub umieszczenieparametrów w adresie URL zapytania. Aplikacja uni-wersalnego serwera monitorowania wykorzystuje cia-

steczka do przesyłania informacji o statusie zalogowa-nia użytkownika oraz elementach wybranych przezużytkownika do wyświetlenia w oknie przeglądarki.Ciasteczka wykorzystywane są także w zapytaniachgenerowanych automatycznie przez skrypty JavaScript[8, 15–17] aktualizujące zawartość strony monitoro-wanego urządzenia.

0�$ '&1-2"-34� �5� 2*�

Na rysunku 4 przedstawiono koncepcję systemułączności.

Rys. 2. Przykładowe zapytanie HTTP klienta

Rys. 3. Fragment przykładowej odpowiedzi HTTP serwera

��������� ������������

���������������

������������ ���!�"���#$���%��&��'��(�$)$'*(��+�"���,��-.�����������/��0���"���

�--1��� ���� ���2!11��-!������ ���3���2!11��-!��������(45��627�7(45��8

�--1��9!��:!��� 1�2���;(45���2�(45��<

�--1����-������� �12�0�!�

�������������)=

��!��!�����-!-

>!- �>��������1����- -.5�2�1��- -.5�2��������2��!��!�5�

>�������?1������ ���

>���-������=1����+

=1����+������:�5<�2��!�56<

>������9��� ���'<�

@ ���A

@ !A

@��!�- !���5B����88"6��C��A

@����A��D:��;�%�@�����A

@���.� �05B��?��-��B��?15B����-��B���5B��?�� �BA

@� !A

@D�?A

@�+�-�!��5B����BA;�%������%?@��+A

���

���

@�+�-�!��5B0����BA

@!� �05B ��1���%%%�.����.���1�����1��BA@���� ��-5B���1.!���0B�A@�!A

E-�1?(E�D�1(���'�����E�D�1(@!� �05B ��1���%%%�.����.���1�����1��BA

=�&�F��������- ��.!�EG<*'(�EG�'�(�.!@�!A

@��+A

@�D�?A

@� ���A

18 M. Hyla

Elementem pośredniczącym pomiędzy urządzenia-mi pracującymi z protokołem Modbus TCP [13]a urządzeniami wykorzystującymi przeglądarkę inter-netową jest stworzona w tym celu aplikacja serwerowawspółpracująca z bazą danych SQL Firebird [1]. Apli-kacja serwerowa pracuje ze stałym, globalnym adre-sem IP oraz otwiera dwa porty nasłuchujące: jedendo obsługi połączeń realizowanych za pomocą proto-kołu HTTP, a drugi do komunikacji z urządzeniamiModbus TCP.

Rolą aplikacji jest odczyt danych z urządzeń Mod-bus TCP oraz udostępnianie ich klientom w formieakceptowanej przez przeglądarki internetowe.

Współpraca z bazą danych pozwala na archiwizo-wanie danych odebranych z urządzeń oraz udostęp-nianie danych archiwalnych urządzeniom klienckim.

6�$ 4"78'4-34� �2%�2%4

Aplikacja serwerowa została stworzona dla systemuWindows w postaci pojedynczego pliku wykonywal-nego z możliwością uruchomienia jako usługa syste-mowa. Jest aplikacją autonomiczną, niewymagającą in-stalacji innych serwerów WWW, takich jak np. Apache,Nginx czy ISS.

Założeniem przy opracowywaniu aplikacji byłostworzenie uniwersalnego serwera współpracującegoz dowolnego typu urządzeniami Modbus TCP. Pro-tokół Modbus TCP [13] nie narzuca powiązaniainformacji zawartej w rejestrze z adresem rejestru.

Dopuszcza także różny sposób kodowania wartościzawartych w rejestrach (liczby stałoprzecinkowe zeznakiem lub bez znaku, liczby zmiennoprzecinkowe)oraz rozmiar kodowanych liczb (liczby o zakresie szer-szym niż 16 bitów mogą być umieszczane w kilku reje-strach). Dodatkowo w ramach jednego urządzeniamożliwy jest różny sposób kodowania zawartości po-szczególnych rejestrów.

Z tego względu konieczne jest udostępnienie moż-liwości określenia zakresu rejestrów i formatu danychdla każdego z wprowadzanych do systemu urządzeń.Na rysunku 5 przedstawiono okno aplikacji serwero-wej umożliwiające konfigurację rejestru urządzeniaModbus TCP. Można wprowadzić adres rejestru, na-zwę, symbol i jednostkę, typ kodowania danych, in-formację, czy odczyt rejestru ma być archiwizowanyw bazie danych oraz czy możliwa będzie edycja zawar-tości rejestru.

Rys. 5. Konfiguracja rejestru urządzenia Modbus TCP

Rys. 4. Koncepcja systemu łączności

Uniwersalny serwer do monitorowania urządzeń przemysłowych za pomocą przeglądarki internetowej 19

Rejestry grupowane są w zestawy. Zdefiniowanezestawy rejestrów można przypisać do urządzeń Mod-bus TCP wprowadzanych do systemu. Na rysunku 6przedstawiono przykładowy zestaw rejestrów.

Rys. 6. Definiowanie zestawu rejestrów

Kolejnym etapem jest zdefiniowanie urządzeńModbus TCP polegające na wprowadzeniu identyfi-katora urządzenia wykorzystywanego w polu Unit IDprotokołu Modbus TCP, przypisanie nazwy urządze-nia, zestawu rejestrów oraz określenia częstotliwościodpytywania urządzenia przez aplikację serwerową.

Po nawiązaniu przez urządzenie połączenia z serwe-rem aplikacja serwerowa automatycznie co zadany czaskomunikuje się z urządzeniem, odczytując zawartośćrejestrów zdefiniowanych w przypisanym zestawie, łą-cząc w miarę możliwości grupy rejestrów w pojedyn-cze ramki w celu optymalizacji czasu wymaganego naprzesłanie wszystkich danych [9, 10], dekoduje ich war-tość zgodnie z wprowadzonym typem oraz rejestrujeodczyt w bazie danych. Umożliwia także zapis warto-ści do rejestrów, dla których ustalono taką możliwość.

Konfiguracja serwera od strony połączeń przeglądar-ki internetowej wymaga wprowadzenia listy użytkowni-ków, haseł dostępu oraz przypisania urządzeń, do którychdany użytkownik może uzyskać dostęp. Na rysunku 7przedstawiono okno konfiguracji listy użytkowników.

Rys. 7. Okno konfiguracji listy użytkowników

W obecnej wersji aplikacja serwera generuje stro-ny WWW według jednego, wbudowanego szablonu.Umożliwia jednak konfigurację sposobu wyświetlaniawybranych elementów strony. Na rysunku 8 przed-stawiono okno konfiguracji elementów wizualnychstrony WWW generowanej przez serwer oraz formatupliku CSV (Comma-separated values) zawierającegoarchiwalne dane udostępniane przez serwer.

Rys. 8. Okno konfiguracji elementów strony WWWgenerowanej przez serwer

Po skonfigurowaniu wymaganych opcji aplikacjaserwera nie wymaga reakcji użytkownika i może byćuruchomiona w trybie usługi systemowej.

9�$ "%:2;7<+4%'4� 81 2%12 &�4

Monitorowanie stanu urządzeń Modbus TCP orazprzeglądanie danych archiwalnych możliwe jest za po-mocą przeglądarki internetowej. Dostęp do informa-cji udostępnianych przez aplikację serwera wymagalogowania użytkownika. Proces logowania zrealizowa-no za pomocą algorytmu kryptograficznego MD5(Message-Digest algorithm 5), a dane dotyczące autory-zacji sesji kontrolowane są za pomocą mechanizmuciasteczek przesyłanych w nagłówkach protokołuHTTP [7, 11].

Po weryfikacji danych logowania przesyłana jeststrona zawierająca listę urządzeń, do których przy-dzielono dostęp zalogowanemu użytkownikowi wrazz symbolem stanu połączenia (rys. 9). Stan połączeniaurządzeń Modbus TCP z serwerem aktualizowany jestautomatycznie w odstępach 10-sekundowych.

20 M. Hyla

Rys. 9. Lista urządzeń dostępnych dla zalogowanegoużytkownika wygenerowana przez aplikację serwera

Wybór urządzenia przez użytkownika powodujewygenerowanie strony z przebiegami pomiarowymizarejestrowanymi przez serwer. Na podstawie danychzawartych w bazie aplikacja serwera tworzy plik gra-ficzny w formacie PNG (Portable Network Graphics)z przebiegami czasowymi dla wybranego dnia i osadzajego URI w treści HTML strony przesyłanej do klien-ta [2, 20]. Generowany jest także skrypt JavaScript[8, 15–17] realizujący automatyczną aktualizację pli-ku PNG wyświetlanego w przeglądarce internetowejklienta, daty, czasu oraz wartości chwilowych wielkościpomiarowych podczas ostatniej aktualizacji danych,a także statusu połączenia urządzenia z serwerem.Operacje te odbywają się bez konieczności podejmo-wania dodatkowych działań przez użytkownika. Narysunku 10 przedstawiono przykładowy widok stronymonitorowania pomiarów odczytanych z urządzenia.

Ikona kalendarza umieszczona w górnej części stro-ny pozwala na uruchomienie skryptu wyświetlającegokalendarz i umożliwia pobranie z serwera danych dlainnego dnia. Pola wyboru umieszczone pod wykresempozwalają na uwzględnienie w generowanym przezserwer pliku PNG wybranych wielkości pomiarowych.

Ikona dyskietki umieszczona w górnej części stronypozwala na wysłanie do serwera żądania pobrania da-nych pomiarowych dla wybranego dnia. Aplikacja serwe-ra na podstawie żądania klienta generuje odpowiedniedane w formie pliku SCV i przesyła je do klienta. Prze-glądarka internetowa umożliwia zapis pobranych da-nych do pliku na komputerze klienta w celu dalszej ichanalizy z wykorzystaniem powszechnie dostępnychnarzędzi, np. oprogramowania Microsoft Excel.

=� 2� 5��5+431&>-8

"&)<-:2184�*&+,��� -"

W celu weryfikacji koncepcji łączenia odczytywa-nych rejestrów urządzeń Modbus TCP w ramach jed-nego pakietu warstwy ethernetowej przeprowadzonotesty porównawcze wydajności systemu. Zestaw reje-strów zdefiniowano w taki sposób, aby aplikacja ser-wera wysyłała do urządzenia trzy rozkazy odczytują-ce odpowiednio 1 rejestr, 16 rejestrów i 64 rejestry –w pierwszym przypadku wysyłając każde z zapytańosobno, a w drugim łącząc je w jeden pakiet.

Rys. 10. Strona monitorowania wielkości pomiarowych urządzenia wygenerowana przez aplikację serwera

Uniwersalny serwer do monitorowania urządzeń przemysłowych za pomocą przeglądarki internetowej 21

Na rysunku 11 przedstawiono ilustrację sposobu łą-czenia ramek protokołu Modbus TCP oraz pomiaruczasu odpowiedzi. W przypadku transmisji osobnychpakietów dla każdej z ramek następne zapytanie wysy-łane było niezwłocznie po otrzymaniu odpowiedzi napoprzedni rozkaz. Rejestrowano czas od chwili zaini-cjowania transmisji do chwili odebrania kompletnejodpowiedzi zawierającej dane wszystkich rejestrów.Sekwencja testowa była powtarzana co 200 ms. Testyprowadzone były w ramach sieci składającej się zarów-no z urządzeń warstwy Ethernet zbudowanej z wyko-rzystaniem przewodów miedzianych, jak i urządzeńwarstwy internetowej wykorzystującej światłowody.Trasa pakietów wiodła przez 11 węzłów sieciowychidentyfikowanych programem tracert. Pomiary testo-we wykonano kilkanaście razy w różnych okresachdoby, a czas pojedynczego testu wynosił 5 min. Testo-wanym urządzeniem Modbus TCP był sterownik prze-mysłowy typu STPC-09 firmy ENEL-PC.

Tabela 1

Wyniki testów wydajnościowych

Jak można zauważyć na podstawie tabeli 1 średniczas odpowiedzi przy wysyłaniu trzech osobnych pa-kietów jest dłuższy niż trzykrotna wartość czasu zmie-rzonego podczas wysyłania jednego pakietu zawiera-jącego trzy ramki protokołu Modbus TCP. Różnica tawynika ze sposobu odbierania, identyfikowania zapy-tania i zwracania odpowiedzi przez testowane urzą-dzenie Modbus. Należy również wziąć pod uwagę, żeobsługa łączności interfejsu Modbus TCP nie jest

głównym zadaniem testowanego urządzenia i prawdo-podobnie realizacja tego zadania nie jest traktowanapriorytetowo.

Na podstawie przeprowadzonych testów możnastwierdzić, że idea łączenia ramek protokołu ModbusTCP we wspólnym pakiecie warstwy Ethernet zwięk-sza wydajność systemu w wyniku skrócenia czasówuzyskania odpowiedzi na wysyłane rozkazy oraz po-zwala na zmniejszenie natężenia ruchu sieciowego.Ma to szczególne znaczenie w przypadku, gdy aplikacjaserwerowa monitoruje stan wielu urządzeń. Niezbęd-na jest jednak możliwość odbioru i prawidłowej iden-tyfikacji tego typu zapytań w urządzeniu Modbus TCP.

?�� "&+��*&�4182

Celem prac przedstawionych w artykule byłosprawdzenie koncepcji oraz wydajności uniwersalne-go serwera pośredniczącego pomiędzy urządzeniamirealizującymi transmisję danych z wykorzystaniemprotokołu Modbus TCP a przeglądarką internetową.

Dzięki możliwości konfiguracji w aplikacji ser-wera adresów rejestrów i sposobu kodowania danychniezależnie dla każdego ze zdefiniowanych urządzeńModbus TCP uzyskano uniwersalność systemu. Moż-liwa jest realizacja łączności i interpretacja danych dladowolnego urządzenia pracującego z tym protokołem.Wymagana jest jedynie możliwość zainicjowania połą-czenia do serwera przez monitorowane urządzenie.

Realizowane przez aplikację automatyczne grupowa-nie rejestrów przesyłanych w pojedynczej ramce trans-misyjnej pozwala na ograniczenie ilości przesyłanychdanych związanych z nagłówkami niższych warstw sto-su protokołów sieciowych i zwiększa wydajność systemu.

Opracowana niezależna aplikacja serwera ma po-stać pojedynczego pliku wykonywalnego, a generowa-nie stron dla przeglądarek internetowych nie wymagainstalacji zewnętrznych serwerów WWW.

Rys. 11. Ilustracja sposobu łączenia ramek oraz pomiaru czasu odpowiedzi tr

Tryb testu Maksymalny

czas odpowiedzi [ms]

����������

odpowiedzi [ms]

Trzy ramki w osobnych pakietach

132 88,6

Trzy ramki we wspólnym pakiecie

28,4 13,8

22 M. Hyla

Kolejnym etapem prac będzie wprowadzenie moż-liwości definiowania komunikatów tekstowych po-wiązanych ze stanem wybranych rejestrów. Umożliwito wyświetlenie na stronach WWW generowanychprzez serwer słownego opisu stanu pracy monitoro-wanych urządzeń.

Trwają także prace nad włączeniem do systemustarszych urządzeń z tradycyjnym protokołem Modbus,nieobsługujących połączeń w sieci IP. Transmisja danychw sieci IP możliwa jest w takim przypadku w wynikuzastosowania sprzętowego konwertera RS-232/RS-485– TCP/IP, np. urządzeń z serii NPort firmy Moxa.

Motywacją do podjęcia tematu były liczne zapyta-nia z ośrodków przemysłu dotyczące możliwości moni-torowania stanu urządzeń za pomocą przeglądarki in-ternetowej, a dotychczasowe wdrożenia potwierdzająprawidłowe działanie przyjętej koncepcji.

Literatura

[1] Borrie H.: The Firebird Book. A Reference for Database Deve-lopers, Apress 2004.

[2] Castro E.: HTML 4, Helion, Gliwice 2003.[3] Comer D.E.: Sieci komputerowe TCP/IP. Tom 1. Zasady, pro-

tokoły i architektura, WNT, Warszawa 1997.[4] Comer D.E., Stevens D.L.: Sieci komputerowe TCP/IP. Tom 2.

Projektowanie i realizacja protokołów, WNT, Warszawa 1997.[5] Comer D.E., Stevens D.L.: Sieci komputerowe TCP/IP. Tom 3.

Programowanie w trybie klient–serwer, WNT, Warszawa 1997.[6] Fall K.R., Stevens W.R.: TCP/IP od środka: protokoły, He-

lion, Gliwice 2013.[7] Gourley D., Totty B., Sayer M.: HTTP: The Definitive Guide,

O’Reilly Media 2002.

[8] Jakut T.: JavaScript: programowanie zaawansowane, Helion,Gliwice 2006.

[9] Jestratjew A., Kwiecień A.: Performance of HTTP Protocol inNetworked Control Systems, IEEE Transactions on IndustrialInformatics, 2013, 9, 1: 271–276.

[10] Joelianto E., Hosana H.: Performance of an industrial datacommunication protocol on Ethernet network, 5th IFIP Inter-national Conference on Wireless and Optical Communica-tions Networks (WOCN ’08), Surabaya 2008: 1–5.

[11] Krishnamurthy B., Rexford J.: Web protocols and practice:HTTP/1.1, networking protocols, caching, and traffic measure-ment, Addison-Wesley Professional, Boston 2001.

[12] MODBUS application protocol specification V1.1b, Modbus-IDA, 2006.

[13] MODBUS Messaging on TCP/IP Implementation GuideV1.0b, Modbus-IDA, 2006.

[14] Modicon MODBUS Protocol Reference Guide, Modicon Inc.,USA 1993.

[15] Radziszewski B.: HTML, JavaScript i Java od podstaw, Wyd.Politechniki Świętokrzyskiej, Kielce 2002.

[16] Resig J., Ferguson R., Paxton J.: Zaawansowane techniki ję-zyka JavaScript, Helion, Gliwice 2016.

[17] Romowicz W.: HTML i JavaScript, Helion, Gliwice 1998.[18] Scrimger R., LaSalle P., Leitzke C., Parihar M., Gupta M.:

TCP/IP: biblia, Helion, Gliwice 2002.[19] Siyan K.S., Parker T.: TCP/IP. Księga eksperta, Helion, Gliwi-

ce 2002.[20] Strychalski R.: HTML: tworzenie stron www i programów de-

sktopowych, Nakom, Poznań 2015.

dr inż. MARIAN HYLAWydział ElektrycznyPolitechnika Śląska

ul. B. Krzywoustego 2, 44-100 Gliwicemarian.hyla@polsl.pl