KNX.pl

W procesie rozwoju ETSa, dla dziesięciu tysięcy dotychczasowych użytkowników tego programu kapitalne znaczenie ma fakt zapewnienia przez KNX/EIB ciągłości w zgodności logicznej na poziomie interfejsu użytkownika. Należy tez się liczyć z treningiem, doświadczeniami i przyzwyczajeniami jakie maja użytkownicy programu. Z wymienionych przyczyn rdzeń ETSa NG (Next Generation) - moduły odpowiedzialne za projektowanie i uruchamianie aplikacji - zapewniają wyżej wspomniana ciągłość. Tak więc cały system jednolitych szkoleń nie zostanie zakłócony. Z drugiej strony zostaje zoptymalizowane samo działanie programu, jego wydajność jak również podniesiona zostaje wydajność.

W kolejnych wersjach ETS NG zostanie zastosowana nowa architektura plug-in pozwalająca na dodanie kolejnych mechanizmów drag-and-drop.

Na poziomie inżynierii programowej i opracowywania samych narzędzi i bibliotek sprawa wygląda nieco inaczej. W tych dziedzinach ETS NG nastąpią radykalne zmiany. Faktem jest, że gwałtowna ewolucja technologiczna komputerów PC, systemów operacyjnych, aplikacji i sieci nie pozostawia innej drogi rozwoju.

Obecnie w przeciwieństwie do opracowywanych dotychczas monolitycznych aplikacji pakiety oprogramowania budowane są z pojedyńczych części (komponentów, segmentów). Ma to na celu łatwiejsze ich wielokrotne implementowanie i konserwację. Technologia komponentowa (component technology) oznacza, że nowy ETS składa się z elementów - można je przyrównać do klocków lego - bloków programowych bądź bibliotek. Końcowy użytkownik programu nie jest tego świadomy. Ale dla programistów opracowujących kolejne bloki programowe (wizualizacja, nadzór) jak również koordynujących tą prace integratorów ma to jednak bardzo duże znaczenie.

Microsoft opracował technologię zwaną DCOM ( Distributed Component Object Model), która stała się podstawa do prac nad pakietem eteC pod Windows NT i Windows9x.

Jeśli chodzi o dostęp do magistrali, programiści mogą stosować komponent pakietu zwany Falcon. Można przy jego pomocy wysyłać telegramy grupowe, ładować aplikacje itd. Można powiedzieć, że Falcon zastąpił program EIBLIB, który zapewniał 16bitowy dostęp do magistrali KNX/EIB za pośrednictwem DOSa i Windows3.x/9x. Wszystko co można robić na magistrali KNX/EIB za pomocą ETS nowej generacji można też robić przy pomocy aplikacji napisanych przy pomocy Falcon'a. Wersja końcowa pierwszej wersji Falcon'a pojawiła się latem 99. Jest dostępna dla Windows95/98/NT4.0.

W pewnych przypadkach bardzo ważna jest możliwość dostępu do bazy ETS. Przykładowo wtedy gdy aplikacja wizualizacyjna chce wczytać wszystkie elementy magistrali KNX/EIB zastosowane w danym budynku. W takim przypadku bez programu Eagle wszystko należy czytać "na piechotę" marnując czas. Komponent Eagle pozwala dostawcy programu wizualizacyjnego na bezkonfliktowe pobranie zintegrowanej bazy ETSa do swojego programu. Eagle będzie w następnej generacji oficjalnym komponentem pakietu ETS pozwalającym na dostęp do magistrali.

Zarówno Falcon jak i Eagle są częściami tak zwanego pakietu eteC (KNX/EIB Tool Environment Component Architecture", który jest szkieletem ramowym (framework) dla kolejnej generacji ETS. Ponieważ w ostatnich paru latach wymagania systemu KNX/EIB w stosunku do ETS rosły coraz bardziej (powstawały takie aplikacje jak BCU2, pojawiły się nowe media typu Powerline czy Radio Frequency, powstały sprzęgła do różnego rodzaju mediów itd.) rozmiary ETSu rosły, obrastał dodatkowymi elementami programu. Tak więc kolejna wersja ETSa jest idealna do potraktowania programu jako pakietu złożonego z wielu programów.

Podstawą programu nowej generacji jakim jest eteC, jest architektura trzypoziomowa. Środkowy poziom (KNX/EIB Domain Objects) ma za pośrednictwem warstwy fizycznej dostęp do zasobów podłączonych do magistrali lub bazy danych Ta najniższa warstwa realizowana jest przez dwa elementy: program eteC Falcon, który zawiera mechanizm dostępu on-line do sieci KNX/EIB i program eteC Eagle, który zapewnia (abstract object) model API również dla opracowujących kolejne moduły programu. Będą oni mogli włączać poszczególne człony programu eteC do swoich aplikacji.

 

telegramów i Network Mapper umożliwiający dostęp do zasobów urządzeń takich jak pamięć.

 

iETS

iETS - wersja ETS mogąca współpracować z Internetem - jest pierwszym z serii interesujących niedawno opracowanych programów. Są one częścią stworzonej przez organizację KNX architektury ANubisa (Advanced Networks for Unified Building Integration Services). Pomysł stosowania ETSa w sposób od dawna znany lecz przy połączeniu programu do instalacji nie przez zwykłe łącze RS232 lecz przez Internet daje użytkownikowi znaczące korzyści. Na przykład może on sobie zaoszczędzić podróży w wypadku konieczności zmiany parametrów w instalacji o dalekiej lokalizacji.. iETS daje również możliwość oszczędzenia czasu na budowie. Istnieje w jego przypadku również możliwość dołączenia się do Internetu za pośrednictwem radiowej sieci LANowskiej. 

iETS jest pierwszym krokiem w kierunku integracji Internetu ze standardem KNX/EIB.

iETS wygląda tak samo jak dotychczasowy ETS. Interfejs użytkownika jest taki sam. Jedyną różnicą jest sposób podłączenia PC do magistrali KNX/EIB. W wypadku konwencjonalnego ETS stosowany jest kabel szeregowy. Przy iETS można stosować również linie telefoniczną, sieci Ethernet lub dowolne inne medium transmisyjne mogące obsługiwać protokół internetowy. Tworzy to zachęcające warunki do implementowania aplikacji oszczędzających czas i pieniądze.

iETS jest bardzo pomocny w sytuacji gdy parametry aplikacji w istniejącej instalacji KNX/EIB muszą zostać zmienione. Zwłaszcza w wypadku nowej instalacji gdy parametry są często zmieniane w ciągu pierwszych kilku miesięcy działania po uruchomieniu instalacji. Technicy muszą zazwyczaj wybrać się w podróż do odległej lokalizacji. Na miejscu potrzebują kilka minut na wprowadzenie do systemu nowych parametrów. Kilka minut pracy nie usprawiedliwia wysokiego kosztu podróży.

iETS przydaje się również gdy mamy do dyspozycji internet. W dużych budynkach instalacja KNX/EIB tak czy inaczej może zostać podłączona do internetu (typowo za pośrednictwem linii dedykowanych i Ethernetu). W obszarach budownictwa mieszkalnego do podłączenia internetu korzysta się z linii telefonicznych. W tym przypadku zalecane jest direct dialing. Jest to najbezpieczniejsze i najmniej problematyczne rozwiązanie umożliwiające zdalną obsługę budynków. W każdym przypadku obie strony zyskują. Technik nie marnuje swojego czasu na stanie w korkach a właściciel budynku płaci tylko za wykonaną pracę (to znaczy za zmianę parametrów).

iETS przydaje się również w warunkach budowy instalacji KNX/EIB. Zwłaszcza gdy instalacja ma rozległy zasięg technik musi się nachodzić. Jeśli do swojego laptopa zastosuje radiową kartę sieciową będzie mógł poruszać się w budynku bez skrępowania dostępnością do gniazda interfejsu szeregowego KNX/EIB. Oszczędzi mu to sporo czasu. Jest to też wygodne dlatego, że technik na ogół nie dysponuje stołem ani biurkiem w bezpośrednim sąsiedztwie szafki rozdzielczej czy przełączników.

iETS może być również używany do zdalnego monitoringu. Tak samo można go stosować do przekazywania na odległość pomiarów odnośnie zużycia mocy (pod warunkiem, że w urządzeniach KNX/EIB na obiekcie istnieją odpowiednie obiekty komunikacyjne).

Mimo, że iETS naturalnie nie zastąpi wizualizacji jak również zdalnego monitorowania, to samo to, że można się nim posługiwać poprzez internet jest dużą pomocą w obsłudze instalacji KNX/EIB.

W celu zapewnienia użytkownikom programu Falcon możliwości współpracy z Internetem KNX/EIBA opracowała program Falcon-IP. Do napisania tego programu zastosowany został język XML (eXtensible Markup Language). Język ten ma generalnie duże znaczenie przy opracowywaniu ETSa. Na przykład komponent dostępu do bazy danych, Eagle jest w stanie wyeksportować z bazy ETSa całą interesującą część właśnie w tym języku.

Kolejnymi krokami na drodze integracji KNX/EIB z Internetem jest członkostwo organizacji KNX w OSGi (Open Service Gateway initiative), opracowanie standardowego interfejsu programowego dla Javy i opracowanie prototypu bramy KNX/EIB/Jini.

 

Serwer OPC

OPC oznacza OLE for Process Control. OLE jest skrótem Object Linking and Embending. Jest to przemysłowy standard komunikacji pomiędzy oprogramowaniem (w biurze) a urządzeniami zewnętrznymi lub sieciami. Zainstalowanie serwera OPC dla urządzenia lub magistrali umożliwia stosowanie wielu aplikacji wizualizacyjnych, sterowniczych i administracyjnych.

Serwer OPC jest w całości oparty o bibliotekę dostępu do magistrali Falcon. Program Falcon opracowano w oparciu o model COM (Component Object Model) opracowany przez Microsoft, który to model wprost idealnie pasuje do aplikacji pisanych w językach takich jak C++, Delphi, Java itp.

 

UpnP

UpnP (Universal Plug and Play) jest przedsięwzięciem, w którym zaangażowanych jest 60 wiodących firm w tym Microsoft, Siemens, IBM, HP. Celem jest ustanowienie w oparciu o protokół IP standardu komunikacyjnego do użytku we wszystkich możliwych urządzeniach zwłaszcza z usług automatyki domów i budynków. Organizacja KNX jest członkiem tej organizacji od chwili jej powstania i działa w grupie roboczej automatyki budynkowej.. Jednym z zadań tej grupy jest opracowanie definicji protokołu dla urządzeń oświetleniowych i urządzeń HVAC.

Standard UpnP opisuje usługi i typy urządzeń posługując się językiem XML (eXtensible Markup Language). Dane i dokumenty podawane są w formacie tekstowym. Specyfikacje te rozpowszechniane są w sieci przy użyciu protokołu SSDP (Simple Service Discovery Protokol) opartego o HTTP. Do wzajemnego porozumiewania się urządzeń i użytkowników stosowany jest protokół SOAP (Simple Object Acces Protokol), który również oparty jest o HTTP/XML.

Jak widać język XML staje się ustalonym formatem dla niezależnej wymiany danych przez Internet (tak jak HTML dla interfejsów użytkowników).

Standard UpnP definiuje usługi i typy urządzeń. Usługi składają się ze zmiennych stanowych (status variables) i działań (actions), które używane sa do sterowania urządzeniem. Na przykład usługa "Przełączanie" składa się ze zmiennej binarnej "Stan", która przedstawia bieżący stan urządzenia ("Włączone" lub "Wyłączone") i działania "Przełącznik Załączyć/Wyłączyć", które powoduje zmianę stanu. Usługa "Przełączanie" nie określa typu urządzenia. Z tego względu UpnP definiuje typy urządzeń nie tylko podając spis usług realizowanych przez określone urządzenie lecz również przez podanie typu urządzenia. Na przykład urządzenie typu "Lampa", mające usługę "Przełączanie" jest w rozumieniu standardu UpnP skończoną definicją oświetlenia. Należy pamiętać, ze cała komunikacja odbywa się w formie dokumentów XML. Urządzenia implementują wiec do przekazywania danych miniaturowe serwery HTTP.

Standard UpnP oparty jest o HTTP/XML co powoduje, że również o protokół IP. Jak się ma do tego standard magistrali KNX/EIB? Odpowiedzią jest "bridge'owanie". Wszystkie sieci, których protokoły nie są oparte o IP podłączane są za pośrednictwem bridge'ów, na przykład Pctów, które zabezpieczają łącze danych. W takim bridge'u usługi zamieniają format. Dla innych węzłów sieci UpnP wszystkie urządzenia KNX/EIB są widziane tak jakby posługiwały się protokołem UpnP. Bridge jest przeźroczysty.

 

mgr inż. Wojciech Wiśniewski
Politechnika Łódzka