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
Za mało wiedzy? Znacznie więcej znajdziesz w poradnikach. Kliknij tu i poznaj je!
Chcesz wiedzieć więcej o nowoczesnych instalacjach? Zapisz się na darmowy poradnik.
Dodaj komentarz:
Komentarze: