plik

Mirosław PAROL

, Łukasz MICHALSKI

, Łukasz MOLIK

Politechnika Warszawska, Instytut Elektroenergetyki(1),

Politechnika Warszawska, Wydział Elektryczny, Studia Doktoranckie kierunek Elektrotechnika (2)

Monitoring i zdalne sterowanie instalacjami KNX

za pośrednictwem Internetu

Streszczenie.

Artykuł ten jest poświęcony inteligentnym instalacjom typu KNX, a w szczególności zagadnieniu monitoringu i zdalnego sterowania

tymi instalacjami za pośrednictwem Internetu. Przedstawione zostały problemy dotyczące tworzenia aplikacji wizualizacyjnej funkcjonującej jako
strona internetowa. Omówione zostały problemy związane z komunikacją między instalacją KNX, a siecią Ethernet. Scharakteryzowano stosowany
sprzęt, protokoły sieciowe oraz niezbędne oprogramowanie. Przedstawiono praktyczne uwagi dotyczące prób nawiązywania łączności oraz
użytkowania aplikacji wizualizacyjnej za pośrednictwem Internetu.

Abstract

. This paper concerns intelligent installations type KNX, especially the topic of monitoring and remote control of the installations via Internet.

Some problems dealt with creation of visualization software operated as Internet website have been presented. Problems concerned communication
between installation KNX and Ethernet network have been described. Applied hardware, network protocols and required software have been also
characterized. Practical remarks concerning the tries to establish communication and exploitation of visualization software via Internet have been
presented. (Monitoring and remote control of installations KNX via Internet).

Słowa kluczowe: instalacje inteligentne KNX, monitoring i zdalne sterowanie, Internet, oprogramowanie wizualizacyjne.
Keywords: intelligent installations KNX, monitoring and remote control, Internet, visualisation software.

Wprowadzenie

Niniejszy artykuł poświęcony jest projektowaniu i

tworzeniu aplikacji internetowej, której celem jest zdalne
sterowanie urządzeniami zainstalowanymi w systemie KNX
(dawniej nazywanym EIB) oraz monitoring stanu pracy tych
urządzeń. Zasady działania instalacji KNX (EIB) zostały
szczegółowo przedstawione w [1, 2, 3, 4]. System KNX
spełnia wymagania norm europejskich [5, 6, 7].

Należy zaznaczyć,

że zbudowanie aplikacji

wizualizacyjnej wymaga zainstalowania na komputerze
niezbędnego oprogramowania. Wymagane jest m.in.
oprogramowanie służące do tworzenia i obsługi aplikacji
napisanych w języku Java (np. JBuilder), do tworzenia baz
danych – może to być np. MySQL oraz serwer http –
Apache. Narzędzia te są wystarczające do zbudowania i
późniejszej obsługi wspomnianej aplikacji.

Zagadnieniem wymagającym rozwiązania jest także

wybór odpowiedniego urządzenia (bramki), które pozwala
na pobieranie odpowiednich danych z magistrali systemu
KNX (podczas monitoringu) i przesyłanie ich do sieci
Ethernet, jak również na przesyłanie informacji z sieci
Ethernet do systemu KNX – podczas zdalnego sterowania.
Należy w tym miejscu wspomnieć, że oprócz podejścia
sprzętowego (hardware’owego) istnieje także możliwość
podejścia software’wego, pozwalającego na
dwukierunkową transmisję danych między siecią Ethernet a
systemem KNX, za pośrednictwem odpowiedniego
oprogramowania oraz łącza szeregowego RS232/KNX.

Zainstalowanie modułu internetowego (bramki) wymaga

określenia sposobu połączenia tego urządzenia z
komputerem. Połączenie to można wykonać za pomocą
routera lub za pośrednictwem dwóch kart sieciowych.

W dalszej części artykułu przedstawia się kolejne fazy

tworzenia internetowej aplikacji wizualizacyjnej oraz metody
rozwiązania wymienionych problemów.

Moduł internetowy EIB IP Gateway IG/S 1.1

W celu wykonania połączenia sieci Ethernet z instalacją

inteligentną KNX został zastosowany moduł internetowy
EIB IP Gateway IG/S 1.1 firmy ABB [8]. Moduł ten oprócz
pełnienia roli interfejsu między Internetem a systemem
KNX, może być także wykorzystywany jako sprzęgło liniowe
lub sprzęgło obszarowe. Dzięki niemu można także
wykorzystywać sieć LAN do szybkiej wymiany informacji
między poszczególnymi liniami lub obszarami w instalacji
KNX. Gateway IG/S łącznie ze specjalistycznym
oprogramowaniem narzędziowym iETS lub OPC Server

pozwala także na programowanie urządzeń systemu KNX
za pośrednictwem sieci LAN.

Sposób przyłączenia modułu internetowego IG/S do

sieci Ethernet oraz instalacji KNX został przedstawiony na
rysunku 1. Możliwości funkcjonalne modułu IG/S oraz zasa-
dy jego programowania zostały szczegółowo opisane w [8].

Jak już wspomniano, moduł IG/S można połączyć z

komputerem za pomocą routera lub za pośrednictwem
dwóch kart sieciowych.

Rys. 1. Sposób instalacji modułu internetowego Gateway IG/S 1.1;
opracowano na podstawie [8]

W opisywanej pracy zastosowano ten drugi sposób.

Jedna z kart zainstalowanych w komputerze odpowiadała
za połączenie krosowe z bramką IG/S, zaś druga dała
możliwość zdalnego sterowania modelem instalacji KNX.
Przy takim sposobie połączeń pojawił się problem routingu.
Zaobserwowano, iż przy normalnej konfiguracji, telegramy
były wysyłane do niewłaściwej podsieci, co powodowało, że
nie można było „podglądać” telegramów wysyłanych przez
bramkę IG/S. Nie można było nawet korzystać z Internetu.
Rozwiązaniem tego problemu okazało się właściwe
wypełnienie tablic routingu. Po ich prawidłowym
skonfigurowaniu, obie podsieci działały bez zastrzeżeń, a
operacje realizowane na komputerze pełniącym rolę
serwera, wykonywane były bezbłędnie.

Transmisja i bezpieczeństwo danych

Głównym zagadnieniem, na które trzeba zwrócić uwagę,

jest przesył informacji. Spójrzmy najpierw na instalację
KNX. Źródłem danych w tym przypadku są przede
wszystkim sensory sterujące instalacją inteligentną. Sensor
jest urządzeniem mającym za zadanie wysłanie polecenia
do aktora, a więc urządzenia wykonawczego. Komunikacja

PRZEGLĄD ELEKTROTECHNICZNY, ISSN 0033-2097, R. 83 NR 7-8/2007

między nimi odbywa się za pomocą telegramów. Bramka
IG/S ma za zadanie przechwytywać wszystkie te telegramy
i przekształcać je w pakiety informacyjne, które są
następnie przesyłane do sieci Ethernet. Przechwytywanie
przesyłanych magistralą KNX telegramów okazało się
poważnym problemem. Pomocny okazał się w tym
przypadku program „CommView”. Program ten pokazał
dokładnie, jaki typ telegramu generuje bramka IG/S oraz
jakie dane są nim przesyłane (rys. 2). Okazało się, że nie
są to telegramy zgodne z protokołem TCP/IP lecz UDP.

Rys. 2. Zastosowanie programu CommView; opracowano na
podstawie [9]

UDP (ang. User Datagram Protocol – datagramowy

protokół użytkownika) jest jednym z podstawowych
protokołów internetowych [10, 11, 12]. Umieszcza się go w
czwartej warstwie (transportowej) modelu ISO/OSI. Jest to
protokół bezpołączeniowy, nie powodujący narzutu
(dodatkowego kosztu) na nawiązywanie połączenia i
śledzenie sesji (w przeciwieństwie do protokołu TCP). W
protokole tym nie ma też mechanizmów kontroli przepływu i
retransmisji. Dzięki temu można uzyskać większą szybkość
transmisji danych i nie ma konieczności wykonywania
dodatkowych zadań przez host’a posługującego się tym
protokołem.

Dzięki portom, UDP pozwala na identyfikację różnych

punktów końcowych (np. pracujących aplikacji, usług czy
serwisów) na jednym hos’cie. Celem UDP (opierającego się
na Internet Protocol) jest dostarczanie pojedynczych
pakietów, udostępnionych przez IP.

Pakiety UDP (zwane datagramami) zawierają m. in.

nagłówek UDP. Nagłówek datagramu użytkownika składa
się z czterech 16-bitowych pól: pola „Port Nadawcy”
(opcjonalne), pola „Port Odbiorcy”, pola „Długość” oraz pola
„Suma Kontrolna” (opcjonalne). Suma kontrolna jest liczona
na podstawie nagłówka i danych (protokół IP nie wylicza
sumy kontrolnej dla danych) i jest jedyną gwarancją, że
dane nie zostały uszkodzone.

Bardzo ważnym zagadnieniem jest przesył informacji

widziany od strony aplikacji wizualizacyjnej. Aby aplikacja ta
mogła działać poprawnie – tzn. wizualizować zmiany
dokonywane w instalacji KNX oraz wywoływać zmianę
stanu urządzeń KNX z pozycji (poziomu) strony
internetowej, należy zaopatrzyć komputer (na którym
znajduje się ta strona) w aplikację Serwera i Klienta.

Aplikacja Serwera w sposób ciągły analizuje ruch

pakietów w sieci Ethernet i jeśli wykryje jakiś telegram
pochodzący z magistrali KNX, a więc z urządzenia o
konkretnym adresie grupowym, to go przechwytuje.
Następnie przetwarza ten telegram i wydobywa z niego
niezbędne informacje (adresy i stany), które zamieszcza w
specjalnie utworzonej w tym celu tablicy. Jednocześnie
zmienia stan modelu (ikony) urządzenia w programie
wizualizacyjnym, będącego obrazem konkretnego
urządzenia w instalacji KNX.

Aplikację Klienta wykorzystuje się z kolei do określenia

sposobu działania urządzeń wykonawczych instalacji KNX.
Aplikacja ta ma za zadanie kontrolować stan modeli
urządzeń na stronie wizualizacyjnej i w chwili powstania
tam jakiejkolwiek zmiany powinna wygenerować i wysłać
telegram do rzeczywistego urządzenia w instalacji KNX.

Okazuje się jednak, że telegramy przechwytywane

przez Serwer zawierają bardzo dużą liczbę zbędnych
informacji, które nie wnoszą nic nowego w działanie
urządzeń. Dlatego zbudowano odpowiedni filtr
software’owy, który wychwytuje tylko dane użyteczne i w
drugą stronę (do sieci Ethernet) wysyła tylko te dane, które
powodują zmianę stanu urządzeń wykonawczych (aktorów).
Bramka IG/S przechwytuje je, przetwarza w telegramy KNX
i „wpycha” je do magistrali KNX (rys. 3).

Rys. 3. Poglądowy schemat działania aplikacji wizualizacyjnej;
opracowano na podstawie [9]

Na maszynie Klient/Serwer – Filtr oprócz aplikacji

Serwera i Klienta znajduje się również serwer witryny
wizualizacyjnej, a także baza danych. Wiadomo, jak
ważnym zagadnieniem w przypadku połączeń
internetowych jest zapewnienie bezpieczeństwa transmisji
danych. W przypadku aplikacji wizualizacyjnej, działającej
przez Internet, dostęp do strony www powinny mieć tylko
osoby upoważnione. Dlatego korzystając ze środowiska
MySQL została zbudowana baza danych. W jej skład
wchodzi tabela, w której przechowywane są wszystkie dane
o użytkownikach uprawnionych do korzystania ze strony
wizualizacyjnej. Jest ona zbudowana z pięciu kolumn:

login – login użytkownika,
haslo – hasło użytkownika,
imie – imię użytkownika,
nazwisko – nazwisko użytkownika,
email – adres e-mail użytkownika.

Aby zapewnić odpowiednio wysoki poziom

bezpieczeństwa, dane te są dodatkowo szyfrowane. Dostęp
do bazy danych oraz możliwość modyfikacji danych
użytkowników posiada tylko administrator z panelu
administracyjnego znajdującego się na stronie www. Dzięki
zastosowaniu takiego rozwiązania istnieje bardzo duże
prawdopodobieństwo, że nikt niepowołany nie będzie miał
możliwości manipulowania w instalacji KNX.

Aplikacja wizualizacyjna

Jednym z najistotniejszych elementów procesu budowy

aplikacji wizualizacyjnej jest stworzenie interfejsu, który w
sposób intuicyjny umożliwiałby zdalne sterowanie
urządzeniami KNX oraz monitorowałby ich stan. Zadanie to
można zrealizować przy użyciu języka Java. Opisywana w
niniejszym artykule aplikacja powstała w programie
JBuilder. Aby możliwe było powstanie strony internetowej,
działającej w sposób wcześniej opisany, wykorzystano
odpowiednie pakiety języka Java, takie jak: java.applet.*,
java.awt.*, java.io.*, java.net.* oraz java.util.* [13, 14, 15]. Z
wymienionych pakietów w dalszej części przedstawia się
krótką charakterystykę pakietu java.net.*.

PRZEGLĄD ELEKTROTECHNICZNY, ISSN 0033-2097, R. 83 NR 7-8/2007

Dzięki pakietowi java.net.* istnieje możliwość

stosowania protokołu UDP do przesyłania danych przez
sieć Ethernet. Jak już wspomniano, protokół UDP
wykorzystuje się wtedy, gdy istnieje potrzeba szybkiego i
łatwego przesyłu danych siecią za pomocą datagramów.
Podczas budowy aplikacji wizualizacyjnej wykorzystywane
są następujące klasy [14, 15]:
- klasa java.net.InetAddress; klasa ta pozwala
utworzyć obiekt reprezentujący adres IP w języku Java;
- k l a s a

j a v a . ne t . D at a g r a m P a c k e t ;

dzięki tej klasie

tworzone są obiekty zawierające dane (pojemniki danych),
będące pakietami UDP;
- k l a s a j a v a . n e t . D a t a gr a m S o c k e t ; klasa ta
umożliwia tworzenie gniazd datagramowych, przez które
można wysyłać i odbierać datagramy UDP (Datagram
Packet). Gniazda datagramowe powiązane są z lokalnym
portem, którego numer jest umieszczany w nagłówku
wychodzących datagramów. W przypadku aplikacji typu
Klient port ten może być anonimowy, natomiast dla aplikacji
typu Serwer lokalny port musi być ściśle zdefiniowany;
- k l a s a j a v a . n e t . S o c k et ; klasa ta pozwala
zdefiniować gniazdo dla aplikacji typu Klient (Client
Sockets). W

odróżnieniu od klasy DatagramSocket,

komunikacja odbywa się tu nie na zasadzie pakietów, ale w
oparciu o otwarte strumienie (InputStream, OutputStream);
- k l a s a j a v a. n e t . S er v e rSo c k e t ; dzięki tej klasie
istnieje możliwość tworzenia gniazd dla aplikacji typu
Serwer. Obiekty klasy ServerSocket oczekują pod
konkretnym numerem portu, aż zostanie nawiązane
połączenie przez obiekt klasy Socket. Jak z tego wynika,
gniazdo aplikacji typu Serwer czeka na połączenie,
natomiast inicjuje je aplikacja typu Klient. Aplikacja typu
Serwer do wysyłania danych używa zwykłego obiektu
Socket.

Rys. 4. Aplikacja wizualizacyjna uruchomiona bezpośrednio z
programu JBuilder [9]

Interfejs aplikacji wizualizacyjnej powinien być tak

przygotowany, aby w prosty sposób można było znaleźć i
ustawić odpowiedni stan tego urządzenia systemu KNX,
którego poszukujemy. Jednocześnie interfejs powinien być
estetyczny. Starając się spełnić przedstawione wymagania
zbudowano aplikację (rys. 4), w której umieszczono dwa
przyciski powodujące odpowiednio załączenie i wyłączenie
wszystkich urządzeń oraz pięć „przełączników”
odpowiedzialnych odpowiednio za: załączenie/wyłączenie
lampy, ściemnienie/rozjaśnienie lampy oraz podniesie-
nie/opuszczenie rolety. Sterowanie urządzeniami w
instalacji KNX odbywa się poprzez wybór odpowiedniej
funkcji sterowniczej, a następnie kliknięcie lewym
klawiszem myszy na urządzeniu, którego stan chcemy

zmienić. Inne możliwe rozwiązanie mogłoby polegać np. na
kliknięciu myszą na dane urządzenie, co powodowałoby z
kolei rozwinięcie odpowiedniego menu z wszelkimi
potrzebnymi informacjami i opcjami sterowania dostępnymi
dla tego urządzenia.

Przedstawiona aplikacja wizualizacyjna odpowiada

konkretnej laboratoryjnej instalacji KNX, której schemat ide-
owy przedstawiono na rysunku 5, zaś widok na rysunku 6.

Rys. 5. Schemat ideowy przykładowej instalacji KNX; opracowano
na podstawie [16]

Rys. 6. Widok przykładowej instalacji KNX z zainstalowanym
modułem IG/S

Po uruchomieniu aplikacji wizualizacyjnej, napisanej w

postaci apletu Javy, bezpośrednio z poziomu programu
JBuilder, działa ona bez zastrzeżeń. Pewnym
mankamentem jest fakt, że można dokonywać zdalnych
sterowań i monitorować stan instalacji KNX jedynie z
komputera podłączonego bezpośrednio do modułu
internetowego IG/S, z zamieszczoną na nim aplikacją
wizualizacyjną. Zasada działania jest w tym przypadku
identyczna, jak przy obsłudze za pośrednictwem strony
internetowej.

Po zakończeniu prac nad aplikacją wizualizacyjną

można było przystąpić do budowy strony internetowej
służącej do zdalnego sterowania i monitoringu urządzeń
znajdujących się w rzeczywistej instalacji KNX. Strona ta
powinna być łatwa w obsłudze, tj. umożliwiać
użytkownikowi szybkie i łatwe poruszanie się po niej.

PRZEGLĄD ELEKTROTECHNICZNY, ISSN 0033-2097, R. 83 NR 7-8/2007

Próby nawiązania łączności oraz doświadczenia
wynikające z użytkowania strony internetowej

Po wykonaniu wszystkich stron, które są ładowane w

trakcie pracy aplikacji, przeprowadzono kilka prób działania
przy użyciu przeglądarki internetowej. Próby te kończyły się
początkowo niepowodzeniem, gdyż maszyna wirtualna
Javy zainstalowana na komputerze, dająca możliwość
uruchamiania apletów Javy, miała ustawione ograniczenie
dostępu do otwarcia łączy. Było to sygnalizowane za
pomocą następującego komunikatu:

java.security.AccessControlException: access denied
(java.net.SocketPermission xxx.xxx.xx.xxx connect, accept,
resolve)

Jak się okazało, problem dotyczył zawartości pliku

java.policy, którego zadaniem jest konfigurowanie ochrony
dostępu. Parametry ustawiane automatycznie w tym pliku
uniemożliwiały nawiązanie połączenia wykonanej strony
wizualizacyjnej z modułem IG/S. Prawidłowe działanie na-
stąpiło dopiero wówczas, gdy zawartość tego pliku była:

grant {permission java.net.SocketPermission "*:*", "accept,
listen, connect, resolve";};

Najistotniejszym elementem tego pliku są parametry

adresu i portu, z jakim ma nastąpić połączenie. Aby
ustawienia nie powodowały problemów w obsłudze innych
stron, które również mogą wymagać nawiązania takich
połączeń, jako parametry przyjęto „*”, która określa dowolną
wartość; tak więc z nawiązaniem połączeń z jakimkolwiek
innym adresem oraz portem, nie powinno być problemów.
Aby jeszcze bardziej zwiększyć możliwości tych łączy, jako
parametry ustawialne dla nich, wprowadzono: "accept,
listen, connect, resolve". Są to wszystkie możliwe opcje
ustawialne dla tych połączeń.

Uruchamiając gotową aplikację wizualizacyjną za

pomocą przeglądarki internetowej pojawiał się problem z
szybkością przesyłu danych. Przeglądarki internetowe
charakteryzują się m.in. tym, że z ich poziomu uruchamiane
są różnego rodzaju aplikacje - wraz z ich działaniem
pracują w tle inne programy, dające możliwość właściwej
pracy tych aplikacji. Wszystko to wpływa negatywnie na
szybkość przetwarzania danych przez przeglądarki.

Zbudowana aplikacja wizualizacyjna, pracująca za

pośrednictwem przeglądarki internetowej, daje
kilkusekundowe opóźnienie w wysyłaniu telegramów oraz w
przetwarzaniu tych telegramów, które do niej dotarły. W
wyniku tego „zapalenie się” lampy w laboratoryjnej instalacji
KNX, po wykonaniu zdalnego sterowania z poziomu
przeglądarki, następuje z kilkusekundowym opóźnieniem w
stosunku do momentu naciśnięcia odpowiedniego przycisku
(ikony) w aplikacji. Podobnie, po wykonaniu sterowania
lokalnego przyciskiem znajdującym się w laboratoryjnej
instalacji KNX, wizualizacja tego stanu na monitorze
komputera następuje również z opóźnieniem. Jest to
szczególnie widocznie w momencie, gdy chcemy ściemnić
lub rozjaśnić którąś z lamp. W zbudowanej aplikacji
polecenie to zostało zrealizowane poprzez wysyłanie dwóch
telegramów – jednego powodującego „zapalenie” i
następującego po nim w odpowiednim czasie telegramu
„stop” powodującego zatrzymanie procesu rozjaśniania.

Okazało się, że ten sposób sterowania jest bardzo

trudny do realizacji, ze względu na występujące opóźnienia
w przesyle informacji. Opóźnienia te powodują, że zanim po
pierwszym telegramie dotrze drugi telegram stopu, lampa
będzie już całkiem rozjaśniona/ściemniona. Problem ten
można rozwiązać poprzez nadanie tylko jednego telegramu,
zawierającego procentową wartość rozjaśnienia danej
lampy. Jednak tego rodzaju telegramy można wysyłać tylko
wówczas, gdy aktor załączająco-ściemniający lampy
posiada odpowiednie własności (ustawienia).

Po wykonaniu wszystkich opisanych czynności, można

sterować urządzeniami znajdującymi się w instalacji KNX

za pośrednictwem lokalnego komputera, jak również można
zdalnie sterować i monitorować stan urządzeń systemu
KNX za pośrednictwem sieci Internet.

Podsumowanie

Opisana w artykule aplikacja daje możliwość

monitoringu i sterowania urządzeniami zainstalowanymi w
systemie KNX zarówno przy użyciu Internetu, jak i lokalnie
z wykorzystaniem komputera pełniącego rolę serwera.
Zbudowana aplikacja zapewnia bezpieczeństwo
przesyłanych danych, jest przejrzysta i łatwa w obsłudze.
Użytkownik może w sposób intuicyjny sterować
urządzeniami, jak i monitorować stan tych urządzeń.

W artykule opisano sposób rozwiązywania różnych

problemów związanych z komunikacją między instalacją
KNX a siecią Ethernet. Przedstawiono także sposób
postępowania w przypadku problemów dotyczących
właściwego działania aplikacji napisanej w języku Java.

Zbudowana aplikacja wizualizacyjna obejmuje jedynie

podstawowe funkcje sterownicze w zakresie sterowania
oświetleniem i roletami. Nic nie stoi na przeszkodzie, aby ją
rozbudować o takie funkcje jak: pomiar temperatury,
sterowanie ogrzewaniem, pomiar natężenia oświetlenia,
realizacja scen świetlnych czy realizacja funkcji
bezpieczeństwa w oparciu o czujki ruchu.

Wydaje się, że opisany w niniejszym artykule sposób

tworzenia aplikacji wizualizacyjnej może pomóc w lepszym
zrozumieniu zasad jej funkcjonowania, jak również innych
podobnych aplikacji.

LITERATURA

[1] Project Engineering for EIB Installations. Basic Principles. 4

(revised) edition, EIBA sc, 1998

[2] S a u t e r T . , D i e t r i c h D . , K a s t n e r W . ( E d s . ) , EIB.

Installation Bus System. Publicis Corp. Publ, Erlangen, 2001

[3] P e t y k i e w i c z P . , EIB. Nowoczesna instalacja elektryczna w

inteligentnym budynku. COSiW SEP, Warszawa, 2001

[4] http://www.konnex.org
[5] PN-EN 50090: Domowe i budynkowe systemy elektroniczne

(HBES) – norma wieloarkuszowa

[6] PN-EN 13321-1:2006(U) Otwarta wymiana danych w systemach

automatyzacji, sterowania i zarządzania budynkami – Domowe
i budynkowe systemy elektroniczne – Część 1: Wymagania
dotyczące wyrobów i systemu

[7] PN-EN 13321-2:2006(U) Otwarta wymiana danych w systemach

automatyzacji, sterowania i zarządzania budynkami – Domowe
i budynkowe systemy elektroniczne – Część 2: Komunikacja
KNXnet/IP

[8] ABB i-bus EIB IP Gateway IG/S 1.1. Intelligent Installation

System. Product Manual. December 2003

[9] M o l i k Ł . , M i c h a l s k i Ł . , Wizualizacja pracy i zdalne

sterowanie instalacjami inteligentnymi EIB za pośrednictwem
Internetu. Praca dyplomowa magisterska. PW, 2005

[10] H a u g d a h l J . S . , Diagnozowanie i utrzymanie sieci. Helion,

Gliwice, 2000

[11] S p o r t a c k   M . , Sieci komputerowe., Helion, Gliwice, 2004
[12] T a n e n b a u m   A .   S . , Sieci komputerowe. Helion, 2004
[13] H o r s t m a n n   C .   S . ,   C o r n e l l   G . , Core Java 2. Techniki

zaawansowane. Helion, Gliwice, 2005.

[14] N i e m e y e r P . , K n u d s e n J . , Learning JAVA. Sebastopol:

O’Reilly and Associates, 2000

[15] V a n d e r L i n d e n P . , Just JAVA. Second Edition. Mountain

View: SunSoft Press, 1997

[16] S a s i n K . , Projektowanie inteligentnych instalacji

elektroenergetycznych w oparciu o system instabus EIB.
Praca dyplomowa magisterska, PW, 1999

Autorzy

: dr hab. inż. Mirosław Parol, Politechnika Warszawska,

Instytut Elektroenergetyki, ul. Koszykowa 75, 00-662 Warszawa, E-
mail: miroslaw.parol @ien.pw.edu.pl,
mgr inż. Łukasz Michalski, mgr inż. Łukasz Molik, Politechnika
Warszawska, Wydział Elektryczny, Studia Doktoranckie kierunek
Elektrotechnika, pl. Politechniki 1, 00-661 Warszawa, E-mail:
michalsl@ee.pw.edu.pl, molikl@ee.pw.edu.pl

PRZEGLĄD ELEKTROTECHNICZNY, ISSN 0033-2097, R. 83 NR 7-8/2007