IAP tworzy lepsze rozwiązanie LoRaWAN dla inteligentnych budynków

Użytkownicy budynków komercyjnych oczekują pewnego poziomu inteligencji i automatyzacji w swoich obiektach, a właściciele nieruchomości ścigają się, aby zapewnić to za pośrednictwem IoT. Być może to wyjaśnia, dlaczego oczekuje się, że skumulowana roczna stopa wzrostu rynku automatyki budynkowej i sterowania wzrośnie ponad 21 procent do 2028. W końcu infrastruktura IoT to sposób na dotarcie do obiecanego biura przyszłości — a ostatnie trendy sprawiają, że inteligentne budynki są bardziej wymogiem niż dodatkiem. 

Firmy mają cele energetyczne; IoT pomaga im sprostać dzięki automatycznemu sterowaniu HVAC, oświetleniem i nie tylko. Rozwój pracy zdalnej doprowadził do powstania wielu niewykorzystanych przestrzeni w obiektach; IoT może identyfikować te przestrzenie, personalizować je dla tymczasowych użytkowników i dostarczać danych o tym, jak zoptymalizować każdy metr kwadratowy.  

Biorąc pod uwagę te siły rynkowe, pytanie nie brzmi, czy inwestować w technologię inteligentnego budynku, ale jak to zrobić w sposób, który zapewni wysoki zwrot z tej inwestycji i obsługuje urządzenia korzystające zarówno z komunikacji przewodowej, jak i bezprzewodowej. Protokół Long Range Wide Area Network (LoRaWAN) to obiecujące rozwiązanie dla urządzeń bezprzewodowych, które wymagają mniej energii niż urządzenia WIFI, ale mają większy zasięg niż urządzenia Bluetooth. Administrowane przez otwarte, non-profit Sojusz LoRa, LoRaWAN tworzy tanie, energooszczędne połączenia bezprzewodowe o dużym zasięgu między urządzeniami inteligentnego budynku a platformami, z którymi współpracują. 

Problem polega na tym, że integratorzy mają trudności z podłączeniem urządzeń LoRaWAN do starszych przewodowych systemów automatyki i sterowania budynkami (BACS). Nowy protokół IoT Access Protocol (IAP) rozwiązuje ten problem. Oto jak.    

Walka o połączenie urządzeń LoRaWAN ze starszymi systemami BACS

Każdy średniej wielkości lub większy budynek najprawdopodobniej ma BACS z urządzeniami korzystającymi z komunikacji przewodowej – i ten system BACS nie jest zaprojektowany, aby nadążać za tempem innowacji w IoT. Przez dziesięciolecia operatorzy używali tych starszych platform BACS do zarządzania wszystkimi technologiami w budynku: HVAC, oświetleniem, kontrolą dostępu, bezpieczeństwem, windami — wszystkimi systemami, które zyskują znaczną użyteczność po dodaniu IoT. 

Jeśli chcesz rozszerzyć automatykę budynku, musisz przesyłać dane z każdego dyskretnego urządzenia IoT do systemu BACS. Istnieje jednak niezgodność między standardem LoRaWAN a popularnymi protokołami sieciowymi BACS. Protokoły łączności, które rozumie system BACS — BACnet i LON, żeby wymienić tylko kilka — to bardzo rozbudowane standardy. Dysponują bogatymi modelami danych, określają usługi sieciowe i zapewniają możliwości dowodzenia i kontroli — a wszystko to jest ściśle zdefiniowane w architekturze BACS. 

LoRaWAN nie jest natywnie zgodny ze wszystkimi tymi definicjami BACS, więc trudno jest stworzyć silną integrację. Do niedawna integratorzy inteligentnych budynków łączyli urządzenia LoRaWAN ze starszym systemem BACS, stosując jedno z dwóch podejść, z których żadne nie jest idealne: 

• Ręczne mapowanie punktów danych. Najpierw podłączasz urządzenie LoRaWAN do serwera sieciowego LoRa. Następnie odwzorowujesz każdy punkt danych na serwerze na odpowiadający mu punkt w systemie BACS. Trudność pojawia się po stronie BACS, gdzie trzeba ręcznie konfigurować algorytmy automatyzacji – w tym definiowanie i konfigurowanie podstawowych znaczeń punktów danych. Musisz powiedzieć BACS, że odczyt temperatury jest na przykład odczytem temperatury w pomieszczeniu i stworzyć algorytm, który mówi systemowi, co zrobić z tym punktem danych. Wymaga to dużej ilości zasobów i czasochłonnej ręcznej konfiguracji przez integratorów systemów budynkowych. 
• Protokół statycznej kompresji nagłówka kontekstu (SCHC). Jeśli wolisz nie kodować mapowania danych na stałe po stronie BACS, SCHC może być w stanie pomóc. Ta struktura kompresji umieszcza całą wiadomość BACnet w pakiecie LoRa. To przenosi pełną kompleksową właściwość obiektu BACnet z urządzenia do systemu BACS. Definicja punktu danych jest wbudowana. Jest tylko jeden problem: Integratorzy nie mogą samodzielnie zaimplementować SCHC. Protokół musi być wbudowany w urządzenie, co oznacza, że ​​tylko producent urządzenia może to zrobić. Co gorsza, inteligentne urządzenia budowlane SCHC są bardziej złożone, a przez to droższe niż proste czujniki LoRaWAN — zakładając, że ktoś je w ogóle wyprodukował. Jeśli jest kilku producentów, przy dzisiejszych zakłóceniach w łańcuchu dostaw jest bardzo prawdopodobne, że takie rzadkie urządzenia będą miały czas realizacji od 6 do 12 miesięcy.

Żadne z tych podejść nie obsługuje inteligencji w urządzeniach brzegowych IoT; wszystkie operacje na danych odbywają się na poziomie BACS. Obsługują również tylko BACnet, dominujący protokół komunikacyjny w automatyce i sterowaniu budynkami. Jeśli część Twojej infrastruktury IoT opiera się na LON, Modbus lub DALI do sterowania oświetleniem lub przemysłowych protokołach Ethernet dla fabryk — nie masz szczęścia. Na szczęście dostępna jest teraz trzecia opcja, która ma znacznie ułatwić pracę integratorom inteligentnych budynków.  

Poznaj protokół IoT Access Protocol (IAP) do integracji LoRaWAN z BACS

IAP, niedawno znormalizowane przez ANSI i CTA, to niezależny od platformy protokół dostępu do danych i usług, który uogólnia definicje informacji, modeli danych i usług dla przemysłowych urządzeń IoT. Mówiąc prościej, tworzy strukturę danych i usług, która łączy wszystkie elementy infrastruktury inteligentnego budynku — w tym wspólny model informacji i usług dostarczanych przez urządzenia brzegowe w sieci automatyki budynkowej i sterowania. Zainstaluj serwer brzegowy z IAP, aby tłumaczyć i normalizować dane z urządzeń LoRaWAN do systemu z BACnet, LON, Modbus lub praktycznie dowolnym innym protokołem BACS oraz uzyskiwać dostęp do danych i usług ze wszystkich urządzeń ze stacji roboczych za pomocą BACnet, LON lub OPC UA. 

IAP tworzy cyfrowy bliźniak swoich urządzeń. BACS uzyskuje dostęp do każdego bliźniaka za pośrednictwem dowolnego wybranego protokołu BACS, tłumacząc LoRa na język zrozumiały dla BACS. Jeśli ustawisz serwer IAP tak, aby zawierał serwer BACnet, twój BACS rozpozna urządzenie LoRaWAN jako urządzenie BACnet; to takie proste. Koniec z nieporęcznymi ręcznymi integracjami, twardym kodowaniem lub błaganiem producentów urządzeń o obsługę SCHC. Dzięki niektórym dzisiejszym serwerom brzegowym IAP integratorzy mogą nawet tworzyć integracje LoRaWAN-BACS w środowisku o niskim poziomie kodu, z prostym interfejsem użytkownika i narzędziami typu „przeciągnij i upuść”. 

Co więcej, IAP jest wysoce skalowalny. Jeśli zainstalujesz go w jednym ze swoich obiektów, możesz używać tych samych konfiguracji urządzeń i punktów danych we wszystkich swoich obiektach, po prostu instalując serwer brzegowy IAP. A serwery brzegowe z IAP uzyskują wyniki. Wystarczy zapytać brytyjskiego sprzedawcę mebli DFS, który używał serwerów brzegowych IAP do łączenia czujników środowiskowych (i nie tylko) z platformami BACS w wielu obiektach. Otwarty, wieloprotokołowy system pomógł zmniejszyć zużycie energii przez DFS, oszczędzając około 33 procent kosztów energii elektrycznej i 26 procent na gazie dla typowego sklepu detalicznego wyposażonego w ten system. Jeśli szukasz podobnych wyników — a nie masz ochoty ręcznie konfigurować i kodować starszego systemu BACS — zajrzyj do IAP. Może to być narzędzie do integracji LoRaWAN/BACS, na które czekałeś.

Źródło: https://www.iotforall.com/iap-creates-a-better-lorawan-solution-for-smart-buildings