Projektowanie urządzeń pomiarowo-sterujących zintegrowanych z systemem KNX

Michał Porzeziński

Politechnika Gdańska, Wydział Elektrotechniki i Automatyki

Streszczenie: W artykule przedstawiono zagadnienia dotyczące projektowania urządzeń automatyki budynków zgodnych ze standardem KNX. Opisano strukturę wewnętrzną urządzeń KNX i dokonano przeglądu specjalistycznych podzespołów służących do ich budowy. Przedstawiono również wymagania dotyczące certyfikacji urządzeń KNX oraz niezbędne narzędzia programistyczne. Na końcu podsumowano doświadczenia zdobyte podczas projektowania i testowania prototypu prostego mikroprocesorowego urządzenia pomiarowo-sterującego zintegrowanego z systemem KNX.

Słowa kluczowe: System KNX, projektowanie urządzeń KNX, automatyka budynków

1. Wprowadzenie

Duże zainteresowanie inwestorów rozproszonymi systemami automatyki budynków spowodowało pojawienie się na rynku wielu rozwiązań tego typu systemów. W większości są to jednak standardy zamknięte, cechujące się tym, że specyfikacja protokołu komunikacyjnego jest znana tylko producentowi. Na przeciwnym biegunie znajdują się standardy otwarte, których specyfikacja jest opublikowana w postaci międzynarodowych norm. Umożliwia to wielu producentom projektowanie i produkowanie współpracujących ze sobą urządzeń. Nad rozwojem standardów otwartych czuwają najczęściej specjalnie do tego celu powołane organizacje, których zadaniem jest również weryfikacja zgodności nowo produkowanych urządzeń ze standardem i przyznawanie odpowiednich certyfikatów zgodności. Otwartość standardów umożliwia projektowanie i wdrażanie nowych, często innowacyjnych rozwiązań przyczyniając się do ich szybkiego rozwoju [1]. Przykładem może być standard KNX wspierany przez organizację o tej samej nazwie, która obecnie skupia ponad 300 partnerów z 35 krajów będących przeważnie producentami urządzeń zgodnych z KNX oraz kilkudziesięciu partnerów naukowych [2].

Opracowanie nowego urządzenia zgodnego ze standardem KNX jest procesem złożonym wymagającym nie tylko znajomości samego standardu KNX, ale również specjalistycznych narzędzi programistycznych oraz podzespołów wykorzystywanych m.in. do budowy certyfikowanego stosu komunikacyjnego KNX. Wiedza z tym związana jest rozproszona i może być trudno dostępna dla osób i organizacji niebędących członkami organizacji KNX. W celu jej przybliżenia przedstawiono doświadczenie zdobyte podczas budowy prototypu prostego urządzenia pomiarowo-sterującego zintegrowanego z systemem KNX. Prace zrealizowano w Laboratorium Zarządzania i Integracji Systemów Automatyki Budynków na Wydziale Elektrotechniki i Automatyki Politechniki Gdańskiej, który jest również jednym z partnerów naukowych KNX. Zrealizowany projekt stanowi punkt wyjścia do budowy zgodnego ze standardem KNX czujnika zapewniającego bezpieczną transmisję danych na potrzeby systemu zdalnego nadzoru [3].

2. Zasady projektowania urządzeń zgodnych ze standardem KNX

2.1. System KNX

System KNX, znany wcześniej jako EIB (ang. European Installation Bus) jest rozproszonym systemem sterowania umożliwiającym realizację podstawowych funkcji systemu automatyki budynku, takich jak: sterowanie oświetleniem, żaluzjami, klimatyzacją oraz monitoring stanu urządzeń i wybranych wielkości fizycznych. KNX stanowi międzynarodowy standard ISO/IEC 14543-3 [4] spełniający również wymagania polskiej/europejskiej normy PN-EN 50090 [5], który jest rozwijany przez organizację KNX z siedzibą w Brukseli. Aktywne elementy systemu KNX komunikują się ze sobą za pomocą tzw. telegramów przesyłanych przez łączącą je dedykowaną sieć komputerową. Medium komunikacyjnym może być skrętka dwuparowa (TP1), sieć Ethernet (KNX/IP), sieć bezprzewodowa (KNX/RF) lub istniejąca linia elektroenergetyczna niskiego napięcia (PL). Obecnie najtańszym i najbardziej niezawodnym sposobem komunikacji jest TP1 i w taki interfejs jest wyposażana większość dostępnych na rynku urządzeń.

Konfiguracja urządzeń KNX pracujących w trybie systemowym (S-mode), a obecnie taki tryb posiada zdecydowana większość dostępnych na rynku modułów, odbywa się zdalnie przez tę samą sieć komunikacyjną, która służy do wymiany danych w trakcie normalnej pracy systemu. Do konfiguracji służy specjalny program ETS (ang. Engineering Tool Software) rozwijany i dystrybuowany przez organizację KNX, który pozwala na wgranie do wybranego modułu programu aplikacyjnego oraz powiązanie tzw. obiektów komunikacyjnych, odpowiadających m.in. fizycznym wejściom i wyjściom modułu, z obiektami komunikacyjnymi innych urządzeń. Z kolei oprogramowanie aplikacyjne jest opracowywane przez projektanta urządzenia i dostarczane w formie tzw. katalogu, który może zostać zaimportowany do bazy danych programu ETS i wykorzystany w projektach.

2.2. Urządzenie KNX

Podstawą działania każdego urządzenia KNX jest program aplikacyjny oraz stos komunikacyjny KNX wraz z odpowiednim systemem operacyjnym. System operacyjny realizuje określone w standardzie KNX usługi umożliwiające zdalne zarządzanie danym węzłem sieci KNX oraz zapewnia komunikację z programem aplikacyjnym za pośrednictwem tzw. obiektów komunikacyjnych będących zmiennymi odzwierciedlającym m.in. zadane wielkości sterujące oraz wielkości mierzone. Program aplikacyjny obsługuje z kolei interfejs pomiarowo-sterujący specyficzny dla danego urządzenia i wiąże zewnętrzne sygnały pomiarowo-sterujące z wartościami wewnętrznych obiektów komunikacyjnych (rys. 1).

Rys. 1. Struktura wewnętrzna typowego urządzenia KNX
Fig. 1. The internal structure of the typical KNX device

Rys. 2. Tablice konfiguracyjne urządzenia KNX
Fig. 2. The KNX device configuration tables

Tab. 1. Wirtualne modele urządzeń KNX z interfejsem TP1
Tab. 1. Virtual models of the KNX devices with TP1 interface

Model

Maska

Uwagi

System 1

0010, 0011, 0012

Stosowany w modułach BCU1, ograniczone zasoby, maksymalnie 12 obiektów komunikacyjnych.
Nie jest stosowany w nowych urządzeniach

System 2

0020, 0021, 0025

Stosowany w BCU2 oraz BIM M13X (0025) możliwość obsługi ok. 64 obiektów komunikacyjnych

System 7

0701, 0705

Stosowany m.in. w modułach BIM M112, możliwość obsługi ok. 255 obiektów komunikacyjnych.

System B

07B0

Zalecany do urządzeń o bardzo dużej złożoności, możliwość obsługi do 65 536 obiektów komunikacyjnych

Program aplikacyjny, wraz z zestawem obiektów komunikacyjnych, może być wgrany dopiero podczas zdalnej konfiguracji urządzenia, natomiast system operacyjny wraz ze stosem KNX stanowią część oprogramowania, która jest na stałe wbudowana w urządzenie. Od chwili powstania standardu KNX system operacyjny wciąż ewoluuje, co wiąże się z powstawaniem nowych tzw. wirtualnych modeli urządzeń, które definiują m.in. wielkość i miejsce umieszczenia w pamięci niezbędnych dla działania urządzenia KNX struktur danych. Wyznacznikiem wersji systemu jest tzw. „maska” – czterocyfrowy kod, który może być odczytany z urządzenia za pośrednictwem np. programu ETS (tab. 1).

Punktem styku między systemem operacyjnym KNX, a opracowywanym przez projektanta programem aplikacyjnym są zdefiniowane standardem KNX struktury danych. Zawierają one m.in. informacje o obiektach komunikacyjnych oraz ich powiązaniach z adresami grupowymi wykorzystywanymi podczas transmisji telegramów. Większość tych struktur jest wypełniana wartościami dopiero podczas procesu konfiguracji urządzenia dokonywanej zdalnie za pomocą programu ETS.

Do najważniejszych struktur danych można zaliczyć: tablicę adresów, tablicę powiązań oraz tablicę obiektów komunikacyjnych (rys. 2). Szczegółowy opis budowy tablic można znaleźć w pracy [6].

Tablica obiektów komunikacyjnych zawiera informacje o typie i priorytecie danego obiektu komunikacyjnego oraz o ustawieniach jego znaczników (prawo do odczytu, prawo do zapisu, prawo do informowania o zmianie stanu itd.). Zawiera również wskazania do pamięci RAM systemu mikroprocesorowego, w której znajdują się struktury danych przechowujące aktualne wartości poszczególnych obiektów.

Tablica adresów jest strukturą zawierającą adres fizyczny modułu oraz adresy grupowe przypisane obiektom komunikacyjnym. Powtarzające się adresy grupowe zapisywane są tylko jeden raz, ponadto adresy muszą być posortowane w kolejności rosnącej.

Tablica powiązań służy z kolei do powiązania poszczególnych adresów grupowych z obiektami komunikacyjnymi, do których zostały przypisane w procesie konfiguracji całości systemu. W tablicy umieszczone jest zestawienie powiązań w postaci par: numer (offset) adresu z tablicy adresów oraz numer obiektu komunikacyjnego z tablicy obiektów.

Tablice te są podstawą działania systemu KNX. Przykładowo, w chwili zmiany wartości danego obiektu komunikacyjnego, który ma uprawnienia do transmisji (ustawiona flaga T) przeszukiwana jest tablica powiązań, znajdowany jest pierwszy adres grupowy związany z tym obiektem i na ten adres wysyłany jest telegram z nowym stanem obiektu.

W przypadku odebrania telegramu następuje sytuacja odwrotna. Przeszukiwana w pierwszej kolejności jest tablica adresów grupowych, a w przypadku znalezienia zgodnego adresu aktualizowane są stany wszystkich wewnętrznych obiektów powiązanych z danym adresem grupowym i posiadających zgodę na zapis nowej wartości (ustawiona flaga W).

Jak już wspomniano zawartość tablic jest przygotowywana przez program ETS na podstawie całości projektu i jest przesyłana w postaci binarnej podczas operacji wgrywania programu aplikacyjnego. Dzięki umieszczeniu ich w pamięci nieulotnej typu Flash, zapisane dane są pamiętane również po zaniku napięcia zasilania. W pamięci Flash umieszczony jest również wgrany kod maszynowy aplikacji oraz czytane przez tą aplikację dodatkowe parametry konfiguracyjne. Struktura binarna bloku zawierającego parametry konfiguracyjne jest dowolna i jest tworzona przez programistę projektującego daną aplikację. Musi być jednak znana w programie ETS, aby możliwie było ustawienie tych parametrów przez integratora systemu.

Kod maszynowy aplikacji wraz z wszystkimi informacjami o miejscu umieszczenia w pamięci wspomnianych struktur danych jest dostarczany przez producentów w postaci wpisu w tzw. katalogu (pliki *.knxprod lub *.vdx, gdzie x oznacza numer wersji), nazywanego dawniej wirtualnym urządzeniem KNX.

2.3. Program KNX Manufacturer Tool

Do utworzenia katalogu zawierającego programy aplikacyjne urządzeń oraz informacje potrzebne do ich konfiguracji niezbędny jest program KNX Manufacturer Tool. Program ten jest rozwijany przez organizację KNX i aktualnie jest dostępny tylko dla jej członków oraz partnerów naukowych. Początkowo był zintegrowany z programem ETS, a od wersji 4.0 stanowi niezależną aplikację bazującą na środowisku Microsoft Visio. Program stanowi narzędzie umożliwiające wyspecyfikowanie obiektów komunikacyjnych, obszarów zawierających dane konfiguracyjne oraz parametrów, które są prezentowane integratorowi systemu w oknach dialogowych programu ETS podczas procesu konfiguracji urządzenia. Przygotowanie programu aplikacyjnego w postaci pliku wirtualnego urządzania wymaga zdefiniowania dostępnych obiektów komunikacyjnych i parametrów konfiguracyjnych oraz określenia ich adresów w pamięci mikrokontrolera (rys. 3). Konieczne jest również dostarczenie obrazu pamięci Flash z kodem maszynowym aplikacji w formacie S-Record oraz zdefiniowanie procedur ładowania dla programu ETS opisujących jakie bloki danych powinny być przesłane i w jakich miejscach pomięci przesłane bloki powinny zostać umieszczone.

Rys. 3. Widok okna programu KNX Manufacturer Tool
Fig. 3. View of the KNX Manufacturer Tool window

Należy zaznaczyć, że wygenerowanie pełnowartościowego katalogu zawierającego wirtualne urządzenie, które może zostać zaimportowane do programu ETS jest możliwe dopiero po przejściu procedury certyfikacji i cyfrowym podpisaniu katalogu przez KNX. Ponadto, od momentu uzyskania certyfikatu nie jest już możliwe dokonywanie zmian mających wpływ na funkcjonalność urządzenia bez konieczności ponownej certyfikacji produktu. Do celów testowych możliwe jest natomiast wygenerowanie projektu programu ETS zawierającego opracowywane urządzenie. Stanowi to furtkę umożliwiającą skonfigurowanie urządzenia i przetestowanie poprawności jego działania przed rozpoczęciem procedury uzyskania certyfikatu.

2.4. Procedura certyfikacji

Poprawność współdziałania modułów systemu KNX opracowanych i produkowanych przez różnych producentów wymaga ich pełnej zgodności ze standardem. Zgodność tą można potwierdzić przez uzyskanie w organizacji KNX odpowiedniego certyfikatu, który uprawnia m.in. do umieszczenia na produkowanym module logo KNX. Jak wcześniej wspomniano, uzyskanie certyfikatu jest również niezbędne do cyfrowego podpisania opracowanego pliku urządzenia wirtualnego przez organizację KNX.

Zgodnie z wytycznymi KNX [2] procedura certyfikacji składa się z następujących faz: fazy wstępnej, rejestracji, testowania i certyfikacji.

Faza wstępna wiąże się z uzyskaniem statusu członka KNX, podpisaniem odpowiednich dokumentów dotyczących korzystania z własności intelektualnej i ewentualnym uzyskaniem certyfikatu jakości ISO-9001, jeżeli producent jeszcze go nie posiada.

Faza rejestracji polega na zarejestrowaniu nowego produktu. Pozwalana na tymczasowe używanie logo KNX oraz wygenerowanie katalogu produktu w programie KNX Manufacturer Tool. Umożliwia to wprowadzenie produktu na rynek, a producent ma 6 miesięcy na udowodnienie zgodności ze standardem. Jeżeli tego nie uczyni traci prawo używania logo KNX i jest zobligowany do wycofania produktu z rynku.

Faza testowania sprowadza się do uzyskania formalnego potwierdzenia zgodności produktu z wymaganiami standardu. Testowanie można przeprowadzić w jednym z akredytowanych laboratoriów. Aktualna lista uprawnionych laboratoriów dostępna jest na stronie organizacji KNX [2].

Ostatnia faza polega na dostarczeniu do organizacji KNX dokumentacji przeprowadzonych testów i pozwala na ostateczne uzyskanie certyfikatu. Okresowo KNX ma prawo uzyskiwać próbki produktu i weryfikować ich zgodność ze standardem.

2.5. Certyfikowane podzespoły KNX

Projektując urządzenie KNX można wszystkie jego elementy składowe opracować od podstaw. W większości wypadków jest to jednak nieopłacalne, nie tylko ze względu na bardzo duże koszty samego projektu, ale również ze względu na wysokie koszty certyfikacji urządzenia. W przypadku prototypów i małych serii produkcyjnych dużo tańszym i szybszym rozwiązaniem jest użycie dostępnych certyfikowanych podzespołów i skupienie się na warstwie funkcjonalnej urządzenia. Przy takim podejściu podczas procesu certyfikacji szczegółowo badana jest tylko nowo dodana funkcjonalność.

Obecnie, w większości rozwiązań wykorzystuje się sprzętowy zintegrowany układ transceivera KNX, którego przykładem może być układ TP-UART [7]. Ten układ scalony, w zależności od trybu pracy, może realizować obsługę tylko warstwy fizycznej protokołu KNX lub także warstwy łącza danych odpowiedzialnej za wysyłanie ramek i weryfikację sum kontrolnych. Pozostałe warstwy protokołu są obsługiwane przeważnie na drodze programowej. Obecnie dostępne są gotowe stosy KNX w postaci oprogramowania na mikrokontrolery z rodziny: ATmega, MSP430, Nec78k0, ARM 7 oraz Cortex M0 i M3 [8]. Można również spotkać mikrokontrolery z fabrycznie wbudowanym stosem KNX oraz kompletne moduły wyposażone w mikrokontroler oraz transceiver KNX, takie jak np. BIM M13x, przeznaczone do wbudowania w docelowe urządzenie [7]. Niezależnie od przyjętego rozwiązania, za każdym razem konieczne jest opracowanie własnego programu aplikacyjnego i przygotowanie katalogu urządzenia dla programu ETS.

Alternatywą jest wykorzystanie podzespołów wyposażonych w już gotowy uniwersalny program aplikacyjny, którego funkcjami można sterować za pośrednictwem poleceń wydawanych z poziomu nadrzędnego układu mikroprocesorowego. Przykładem takiego rozwiązania jest moduł SIM-KNX [9], który komunikuje się z systemem nadrzędnym za pomocą prostych komend tekstowych wysyłanych za pośrednictwem interfejsu RS-232 lub USB. Wbudowany program aplikacyjny, w zależności od wersji modułu SIM-KNX obsługuje odpowiednio 128 lub 255 predefiniowanych obiektów różnych typów. Komendy umożliwiają konfigurację oraz zmianę stanu wybranych obiektów, co skutkuje wysłaniem odpowiednich telegramów do sieci KNX. W podobny sposób moduł informuje o zmianie stanu wewnętrznych obiektów na skutek odebrania telegramu z sieci KNX.

Moduł może być konfigurowany również z poziomu programu ETS (przez magistralę KNX). Konfiguracja ta jest jednak bardzo ograniczona i sprowadza się do aktywowania/dezaktywowania predefiniowanych obiektów komunikacyjnych, ustawienia ich właściwości oraz powiązania ich z wybranymi adresami grupowymi. Moduł może również pracować w trybie transparentnym. Wówczas nie wystawia obiektów komunikacyjnych, pozwala natomiast na odbieranie i wysyłanie telegramów KNX, które są sygnalizowane systemowi nadrzędnemu w postaci odpowiednich komend tekstowych. Podobną do trybu transparentnego funkcjonalność można uzyskać również za pomocą gotowego modułu interfejsu RS-232/KNX obsługującego zdefiniowany w standardzie KNX protokół FT1.2.

2.6. Etapy projektowania urządzenia KNX

Proces projektowania urządzenia zgodnego ze standardem KNX można przedstawić w formie tabeli opisującej jego kolejne etapy (tab. 2). Opis dotyczy urządzeń budowanych od podstaw tzn. takich, dla których konieczne jest opracowanie dedykowanego programu aplikacyjnego. Należy zaznaczyć, że ostatni etap, jakim jest certyfikacja urządzenia, może być przeprowadzony tylko przez członków organizacji KNX, a przejście tego etapu ma sens dopiero przy wdrażaniu zaprojektowanego urządzenia do produkcji.

Tab. 2. Etapy projektowania urządzenia KNX
Tab. 2. KNX device development stages

Etap

Wymagane narzędzia / zasoby

Rezultat

Wybór sprzętu oraz systemu operacyjnego KNX

Dostawcy zewnętrzni

Określony model urządzenia determinujący m.in. max. liczbę obiektów komunikacyjnych i adresów grupowych.

Opracowanie programu aplikacyjnego

Kompilator języka C dla wybranego mikrokontrolera oraz pliki nagłówkowe i biblioteki stosu KNX

Plik binarny zapisany w formacie S-Record zawierający
kod maszynowy aplikacji i wymagane struktury danych.

Opracowanie katalogu urządzenia

Program KNX Manufacturer Tool, program ETS

Projekt programu ETS (*.pr5) zawierający już zaprojektowane urządzenie i umożliwiający jego
pełne przetestowanie.

Certyfikacja urządzenia

Certyfikowane laboratoria, program KNX Manufacturer Tool

Katalog urządzenia w postaci docelowej (plik *.vd5
lub *.knxprod) importowanej przez program ETS.

3. Prototyp urządzenia pomiarowo-sterującego

Głównym celem budowy prototypu było przedstawienie procesu projektowania urządzenia pomiarowo-sterującego zintegrowanego z systemem KNX, które byłoby w pełni funkcjonalnym węzłem KNX oraz ocena związanych z tym procesem trudności i ograniczeń. Dlatego, aby zachować przejrzystość projektu, przyjęto, że prototyp będzie bardzo prostym układem pomiarowo-sterującym wyposażonym w dwa wejścia binarne oraz dwa wyjścia binarne. Założono, że projektowanie bardziej skomplikowanego układu będzie się opierało na tych samych zasadach.

Schemat poglądowy urządzenia przedstawiono na rys. 4. Urządzenie to, jak każdy moduł standardu KNX, oprócz linii pomiarowo-sterujących ma przycisk serwisowy (PS) oraz diodę serwisową (SL), które są wykorzystywane w trakcie konfiguracji do nadania adresu fizycznego oraz do celów diagnostycznych. Urządzenie w całości zasilane jest z magistrali komunikacyjnej KNX.

Przyjęto, że z punktu widzenia systemu KNX moduł będzie zawierał cztery jednobitowe obiekty komunikacyjne typu DPT 1, z których pierwsze dwa będą powiązane z wejściami modułu, a pozostałe dwa z wyjściami. Stany wyjść powinny odzwierciedlać stan związanych z nimi obiektów komunikacyjnych i zmieniać się w chwili odebrania telegramu zmieniającego ich stan. Z kolei zmiana stanu każdego z wejść powinna skutkować wysłaniem telegramu informującego o nowym stanie. Telegramy o stanie każdego z wejść powinny być również wysyłane okresowo co zadany okres czasu.

Dodatkowo założono, że z poziomu programu ETS będzie istniała możliwość ustawienia następujących parametrów: włączenia/wyłączenia negacji stanu dla każdego z wejść i wyjść, określenie okresu wysyłania stanu dla każdego z wejść modułu oraz domyślny stan każdego z wyjść ustawiany po zaniku i ponownym włączeniu zasilania.

Po przeanalizowaniu możliwości układu SIM-KNX budowę prototypu ostatecznie oparto na zestawie ewaluacyjnym BIM M13x Evaluation Board, który pozwala na zbudowanie w pełni funkcjonalnego urządzenia KNX. Zestaw zawiera w sobie odpowiednik modułu BIM M132 (mikrokontroler NEC 78F0537 wraz z układem TP-UART) oraz dodatkowe złącza umożliwiające wgrywanie i śledzenie wykonywania programu za pomocą interfejsu NEC Minicube. Zestaw uzupełniono prostym modułem wejść/wyjść w postaci przycisków i diod święcących podłączonych do interfejsu pomiarowo-sterującego umożliwiającym testowanie poprawności działania układu (fot. 1). Na fotografii wyróżniono podłączenie magistrali KNX TP1 (A), układ TP-UART wraz z niezbędnymi elementami dyskretnymi (B) oraz mikrokontroler obsługujący system operacyjny KNX wraz z programem aplikacyjnym (C). Elementy te stanowią urządzenie pomiarowo-sterujące z rys. 4, do którego dołączono zadajnik/sygnalizator stanu linii interfejsu pomiarowo-sterującego (D).

Do opracowania programu aplikacyjnego wykorzystano środowisko programistyczne IAR Embedded Workbench zawierające m.in. kompilator języka C dla mikrokontrolerów z rodziny NEC 78K. Posłużono się również pakietem oprogramowania BIM-Tools zawierającym narzędzia pomocnicze umożliwiające m.in. wygenerowanie szablonu programu aplikacyjnego i ułatwiającym integrację z systemem operacyjnym KNX.

W oparciu o powyższe narzędzia opracowano w języku C aplikację realizującą założone funkcje. W ramach tej aplikacji w obszarze pamięci Flash zdefiniowano określone standardem KNX tablice danych konfiguracyjnych oraz dodatkową tablicę parametrów określających sposób działania aplikacji. Przewidziano w niej miejsce na określone w założeniach parametry konfiguracyjne (6 pól bitowych reprezentujących dane binarne oraz dwa pola 8-bitowe reprezentujące liczby całkowite z zakresu 0–255).

Rys. 4. Schemat prototypu urządzenia KNX
Fig. 4. Schematic of the prototype of the KNX device

Opracowany program został skompilowany i zapisany do pliku w formacie S-record. W programie Manufacturer Tool utworzono katalog urządzenia zawierający utworzony program oraz definicje parametrów konfiguracyjnych aplikacji i obszarów struktur danych wypełnianych danymi przez program ETS. Urządzenie zostało, z zadowalającym wynikiem, przetestowane pod kątem poprawności działania oraz poprawności współpracy z programem ETS. Widok okna konfiguracji zaprojektowanego urządzenia widocznego w programie ETS pokazano na rys. 5.

Rys. 5. Widok okna konfiguracji urządzenia w programie ETS
Fig. 5. View of the device configuration window in ETS program

Fot. 1. Widok prototypu urządzenia
Phot. 1. View of the device prototype

Największą trudnością na jaką napotkano podczas projektowania i uruchamiania układu było zapewnienie poprawnego przenoszenia parametrów konfiguracyjnych ustawianych w programie ETS do pamięci urządzenia. Trudność ta wynikała z konieczności precyzyjnego określenia miejsca umieszczenia zdefiniowanych danych (często rozmiarze 1 bitu) w pamięci mikrokontrolera, co z kolei wymagało bardzo dobrej znajomości wpływu ustawień kompilatora oraz linkera na strukturę binarną wynikowego programu.

4. Podsumowanie i wnioski

Analiza wymagań standardu KNX, dostępnych na rynku podzespołów i narzędzi oraz doświadczenie zdobyte podczas budowy prototypu urządzenia KNX pokazały, że możliwe są dwie zasadnicze metody integracji urządzenia pomiarowo-sterującego z siecią KNX.

Najprostsza metoda polega na użyciu gotowego modułu sprzętowego z wbudowanym uniwersalnym programem aplikacyjnym, który komunikuje się z częścią pomiarowo-sterującą układu za pomocą odpowiednich poleceń przesyłanych np. łączem szeregowym.

Tego typu rozwiązanie umożliwia szybkie wykonanie projektu oraz daje pełną dowolność w zakresie wyboru nadrzędnego mikrokontrolera, języka programowania oraz kompilatora. Niestety, nie pozwala na dowolność w wyborze parametrów konfiguracyjnych, które są zdeterminowane przez istniejący program aplikacyjny. Tym samym takie rozwiązanie nadaje się głownie do budowy prototypów i nietypowych urządzeń, które mogą być konfigurowane w niestandardowy sposób np. lokalnie.

Do budowy w pełni funkcjonalnego urządzenia KNX, w którym liczba i typ obiektów komunikacyjnych oraz zestaw parametrów konfiguracyjnych nie są z góry narzucone, konieczne jest użycie programowego stosu KNX i opracowanie współpracującego z nim programu aplikacyjnego. Zwykle ogranicza to znacznie możliwość wyboru mikrokontrolera, kompilatora i środowiska uruchomieniowego. Wymaga też znajomości szczegółów użytego systemu operacyjnego KNX i posiadania dodatkowych narzędzi, takich jak KNX Manufacturer Tool.

Największym ograniczeniem dla potencjalnego producenta jest jednak konieczność certyfikowania nowoopracowanego urządzenia. Dopiero wtedy uzyskuje on bowiem techniczną możliwość wygenerowania tzw. katalogu urządzenia będącego standardowym sposobem rozpowszechniania programu aplikacyjnego, który można zaimportować do bazy danych programu ETS. Dostęp do niezbędnych do tego celu narzędzi, mimo otwartości systemu, wymaga członkostwa w organizacji KNX, co wiąże się z koniecznością wnoszenia odpowiednich opłat.

Bibliografia

1. Kastner W., Neugschwandtner G., Soucek S., Newmann H.M., Communication Systems for Building Automation and Control. Proceedings of the IEEE, vol. 93, 2005, 1179–1203.

2. [www.knx.org] – oficjalna strona internetowa organizacji KNX, data odczytu 24.09.2013.

3. Porzeziński M., Koncepcja metody bezpiecznej transmisji danych w sieci KNX na potrzeby systemu nadzoru, „Pomiary Automatyka Robotyka”, nr 10/2013, 96–101.

4. ISO/IEC 14543-3: Information technology – Home Electronic Systems (HES), 2007–2013.

5. PN-EN 50090: Domowe i budynkowe systemy elektroniczne (HBES), 2002–2012.

6. Sauter T., Dietrich D., Kastner W., EIB Installation Bus System, Siemens AG, Berlin and Munich, 2001.

7. [www.opternus.com/en/opternus-components.html] – Opternuts Components, data odczytu 8.10.2013.

8. [www.weinzierl.de/index.php/en/all-knx/knx-stacks-en] – KNX Stacks, data odczytu 8.10.2013.

9. Serial interface module KNX documentation v. 1.3, Tapko Technologies GmbH, 2010.

The development of measurement and control devices integrated with KNX system

Abstract: This paper presents the issues concerning developing the building automation devices compatible with the KNX standard. The internal structure of KNX and a review of specific components used for their construction were described. The requirements for certification of KNX devices and the necessary programming tools were also presented. At the end the experiences gained during the developing and testing of the prototype of a simple control measuring device integrated with KNX system were summarized.

Keywords: KNX system, KNX device developing, building automation

Artykuł recenzowany, nadesłany 12.11.2013 r., przyjęty do druku 25.11.2013 r.

dr inż. Michał Porzeziński

Adiunkt w Katedrze Automatyki Wydziału Elektrotechniki i Automatyki Politechniki Gdańskiej. Jego zainteresowania naukowe dotyczą zagadnień związanych z projektowaniem komputerowych systemów pomiarowo-sterujących oraz rozproszonych systemów automatyki budynków ze szczególnym uwzględnieniem problemów niezawodności i bezpieczeństwa.

e-mail: mporz@ely.pg.gda.pl