Modele obiektów aplikacji w systemie KNX/EIB

Standardy współpracy EIS określają różne wyspecjalizowane obiekty dla wszystkich dziedzin automatyki budynku:

• oświetlenia
• HVAC (kontrola temperatury pokojowej, temperatury wody)
• zarządzanie czasem i zdarzeniami (harmonogram, obsługa zdarzeń)

Standardy KNX/EIB ObIS rozszerzają specyfikacje formatów danych zawarte w EIS o model obiektowy dla aplikacji rozproszonych i ich komponentów.

Ogrzewanie.kontrola temperatury pokojowej.pozycja zaworu.ustaw wartość – ten przykład ilustruje strukturę rozproszonych aplikacji zobrazowaną w hierarchii standardów ObSI.

Domeny aplikacji są ograniczone do poszczególnych obszarów (np.ogrzewanie). System nie musi wiedzieć wszystkiego o całej domenie. Jest więc to w pewnym stopniu nieformalna (meta)koncepcja składająca się z kilku rozproszonych aplikacji takich jak kontrola temperatury pokojowej.

Prosty model obiektu aplikacji (AOM).

Własności obiektów mogą być konfigurowane poprzez połączenia utworzone na czas działania przez adresowanie grupowe lub wstawiane jako lokalne parametry

Hierarchia koncepcji związanych ze współpracą w KNX/EIB przedstawia się następująco:

• modele obiektów aplikacji
• typy obiektów
• typy własności

Standardy ObIS ujmują aplikację rozproszoną w model obiektu aplikacji AOM (Application Object Model). AOM pokazuje sposób rozproszenia funkcjonalności systemu oraz sposób połączenia poszczególnych obiektów.

Każdy z tych obiektów jest indywidualnie określony przez definicję typu obiektu OTD (Obiect Type Definition). OTD wymienia przed wszystkim indywidualne własności, które razem tworzą obiekt. Te własności zazwyczaj definiują interfejs komunikacji i kontroli dla odpowiadających im funkcji lokalnej aplikacji. Taki interfejs komunikacyjny jest całkiem pozbawiony znaczenia bez przynajmniej podstawowego związku z rzeczywistymi funkcjami, które spełniają części rzeczywistego urządzenia.

Definicje typów własności określają formaty danych dla poszczególnych własności obiektów. Warto podkreślić, że własności mogą być również udostępniane jako zmienne współdzielone i tym samym wykorzystywane w adresowaniu grupowym. Wśród typów własności zdefiniowanych dla KNX/EIB, znajdują się:

 

boolean	(1 bit)
(un)signed short integer	(16 bitów)
(un)signed long integer	(32 bity)
short float	(16 bitów)
IEEE float	(32 bity)
Date	(24 bity)
Time	(24 bity)
Control	(4 bity)

Dla prawie każdej z wielkości fizycznych jak temperatura, długość prędkość, siła pola, energia, moc itd. zdefiniowane są specjalne identyfikatory.

Informacje o typach wykorzystywane są przeważnie podczas konfiguracji. Nie są one przesyłane w czasie normalnego funkcjonowania systemu. Osiąga się w ten sposób lepszą wydajność i unika nakładania niepotrzebnych ograniczeń jeśli chodzi o kombinacje urządzeń. Wiadomości o tych podstawowych typach danych są zgrupowane w obiektach rozproszonych, udostępnionych w sieci.

Rozproszony system operacyjny KNX/EIB nie tylko udostępnia odległe nieraz urządzenia podłączone do sieci ale też pełni rolę serwera komunikacyjnego i serwera zarządzenia dla aplikacji lokalnych. Każda z takich aplikacji może korzystać z zasobów udostępnianych przez podłączone do lokalnego urządzenia urządzenie dostępowe BAU. Jest to tzw. hosting. BAU udostępnia aplikacji zasoby CPU, pamięci itp. Aplikacja działa faktycznie w BAU. Zaawansowane implementacje pozwalają na asynchroniczne działanie do trzech wątków aplikacyjnych.

Unikalną cechą KNX/EIB, która usprawnia funkcje hostingu dla urządzeń określonych aplikacji lub zasobów zewnętrznych jest znormalizowany zewnętrzny fizyczny interfejs PEI (Physical External Interface). PEI definiuje usługi zarówno elektromechaniczne jak i programowe, służące do podłączania zewnętrznego modułu aplikacji do portu magistralnego (BAU). Moduł aplikacji, poprzez rezystor typu, sygnalizuje swoje możliwości aplikacjom działającym w porcie magistralnym. Port może obsługiwać do 20 typów aplikacji (łącznie z binarnym, analogowym i szeregowym wejściem i wyjściem).

Zewnętrzny interfejs fizyczny (PEI), warstwa użytkownika oraz hosting w typowym urządzeniu dostępu do magistrali (BAU)

KNX/EIB definiuje ponadto, dla szeregowych PEI, zewnętrzny interfejs wiadomości EMI (External Message Interface). Serwer EMI pozwala zarówno lokalnym jak i zdalnym klientom uzyskiwać dostęp do zewnętrznych zasobów CPU i pamięci. Inne zastosowanie EMI umożliwia zewnętrznym aplikacjom wykorzystywanie lokalnego stosu komunikacyjnego jako serwera komunikacji KNX/EIB. To umożliwia tworzenie i wykorzystywanie urządzeń o dwuprocesorowej strukturze. Serwer EMI może być opcjonalnie zaimplementowany w KNX/EIB BAU.

Obecnie cecha ta może być wykorzystana jako ogólny mechanizm interfejsu szeregowego do zewnętrznych systemów. Typowe przykłady to oparte na BCU interfejsy RS-232 dla KNX/EIB oferowane przez różnych producentów.

Jako część abstrakcyjnej warstwy użytkownika KNX/EIB określa API biblioteki narzędziowej (Utility/User Library API), który dostarcza aplikacji dalszej infrastruktury. Włączone są w to zegary, arytmetyka, logika bitowa, obsługa wiadomości itd. Poprzez API, aplikacja może także uzyskiwać dostęp do urządzeń zewnętrznych.

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