Az IAP jobb LoRaWAN-megoldást hoz létre az intelligens épületekhez

A kereskedelmi épületek lakói bizonyos szintű intelligenciát és automatizálást várnak létesítményeikben, az ingatlantulajdonosok pedig versenyeznek, hogy az IoT-n keresztül teljesítsenek. Talán ez magyarázza, hogy az épületautomatizálási és -szabályozási piac összesített éves növekedési üteme miért nő majd ennél nagyobb mértékben 21 százalék 2028-ig. Végtére is, a létesítmények IoT segítségével érheti el a jövő ígért irodáját – és a közelmúlt trendjei miatt az intelligens épületek inkább követelmény, mint jutalom. 

A vállalatoknak energetikai céljaik vannak; Az IoT segít megfelelni nekik a HVAC, a világítás és egyebek automatizált vezérlésével. A távmunka térnyerése rengeteg kihasználatlan helyiséghez vezetett; Az IoT képes azonosítani ezeket a tereket, személyre szabni őket az ideiglenes felhasználók számára, és adatokat szolgáltatni minden négyzetméter optimalizálásához.  

Tekintettel ezekre a piaci erőkre, nem az a kérdés, hogy érdemes-e befektetni az intelligens épülettechnológiába, hanem az, hogyan tegyük ezt úgy, hogy a befektetés erős megtérülést biztosítson, és támogassa a vezetékes és vezeték nélküli kommunikációt egyaránt használó eszközöket. A Long Range Wide Area Network (LoRaWAN) protokoll ígéretes megoldás a vezeték nélküli eszközök számára, amelyek kevesebb energiát igényelnek, mint a WIFI-eszközök, de nagyobb a hatótávolságuk, mint a Bluetooth-eszközök. Nyílt, nonprofit szervezet kezeli LoRa Szövetség, A LoRaWAN alacsony költségű, alacsony fogyasztású, nagy hatótávolságú vezeték nélküli kapcsolatokat hoz létre az intelligens épületeszközök és az általuk használt platformok között. 

A probléma az, hogy az integrátorok nehezen tudják összekapcsolni a LoRaWAN-eszközöket az örökölt vezetékes épületautomatizálási és -vezérlőrendszerekkel (BACS). Az új IoT Access Protocol (IAP) megoldja a problémát. Itt van, hogyan.    

Harc a LoRaWAN-eszközök és a Legacy BACS összekapcsolásáért

Valószínűleg minden közepes méretű vagy nagyobb épületben van BACS vezetékes kommunikációt használó eszközökkel – és a BACS-t nem úgy tervezték, hogy lépést tartson az IoT innovációjának ütemével. Évtizedek óta az üzemeltetők ezeket az örökölt BACS platformokat használták az épületen belüli összes technológia kezeléséhez: HVAC, világítás, beléptetés, biztonság, liftek – mindezek olyan rendszerek, amelyek az IoT hozzáadásával jelentős hasznot húznak. 

Ha bővíteni kívánja az épületautomatizálást, minden egyes diszkrét IoT-eszközről adatokat kell továbbítania a BACS-hez. De eltérés van a LoRaWAN szabvány és a gyakori BACS hálózati protokollok között. A BACS által használt csatlakozási protokollok – a BACnet és a LON, hogy csak néhányat említsünk – nagyon gazdag szabványok. Gazdag adatmodellekkel rendelkeznek, hálózati szolgáltatásokat határoznak meg, és parancs- és vezérlési képességeket biztosítanak – és ezek mind szigorúan a BACS architektúrán belül vannak meghatározva. 

A LoRaWAN natív módon nem illeszkedik ezekkel a BACS-definíciókkal, ezért nehéz erős integrációt létrehozni. Egészen a közelmúltig az intelligens épületintegrátorok a LoRaWAN eszközöket a régi BACS-hez kapcsolták a két megközelítés egyikével, amelyek egyike sem ideális: 

• Kézi adatpont leképezés. Először csatlakoztasson egy LoRaWAN eszközt egy LoRa hálózati szerverhez. Ezután minden adatpontot leképez a kiszolgálón a BACS megfelelő pontjára. A nehézség a BACS oldalon jelentkezik, ahol manuálisan kell konfigurálnia az automatizálási algoritmusokat, beleértve az adatpontok alapvető jelentéseinek meghatározását és konfigurálását. Meg kell mondania a BACS-nek, hogy a hőmérséklet-leolvasás például beltéri hőmérséklet-leolvasás, és létre kell hoznia egy algoritmust, amely megmondja a rendszernek, hogy mit tegyen az adott adatponttal. Ez egy sok erőforrás- és időigényes kézi beállítás az épületrendszer-integrátorok által. 
• A statikus kontextusfejléc-tömörítés (SCHC) protokoll. Ha nem szeretné a BACS-oldali adatleképezést keményen kódolni, az SCHC segíthet. Ez a tömörítési keretrendszer egy teljes BACnet üzenetet tölt be egy LoRa csomagba. Ez egy teljes, végpontok közötti BACnet objektumtulajdonságot továbbít az eszközről a BACS-re. Az adatpont definíciója be van építve. Csak egy probléma van: az integrátorok nem tudják önállóan megvalósítani az SCHC-t. A protokollt be kell építeni az eszközbe, ami azt jelenti, hogy ezt csak az eszköz gyártója tudja megvalósítani. Ami még rosszabb, az SCHC intelligens épületgépei összetettebbek, és ezért drágábbak, mint az egyszerű LoRaWAN érzékelők – feltételezve, hogy valaki gyártja őket. Ha van néhány gyártó, akkor az ellátási lánc mai zavarai mellett nagyon valószínű, hogy az ilyen szűkös eszközöknek 6-12 hónapos átfutási ideje lesz.

E megközelítések egyike sem támogatja az intelligenciát az IoT szélső eszközökben; minden adatművelet BACS szinten történik. Ezenkívül csak a BACnetet, az épületautomatizálás és -vezérlés domináns kommunikációs protokollját támogatják. Ha az IoT infrastruktúrája egy része LON-ra, Modbusra vagy DALI-ra támaszkodik a világításvezérléshez, vagy ipari Ethernet-protokollokra a gyárak számára, akkor nincs szerencséje. Szerencsére már elérhető egy harmadik lehetőség is, amely sokkal egyszerűbbé teszi az intelligens épületintegrátorok munkáját.  

Ismerje meg az IoT Access Protocol (IAP) követelményeit a LoRaWAN integrációhoz a BACS-szel

IAP, nemrég ANSI-n és CTA-n keresztül szabványosítva, egy platform-agnosztikus adat- és szolgáltatás-hozzáférési protokoll, amely általánosítja az információk, adatmodellek és szolgáltatások definícióit az ipari IoT-eszközök számára. Egyszerűbben: olyan adat- és szolgáltatásszövetet hoz létre, amely összekapcsolja az intelligens épület infrastruktúrájának összes elemét – beleértve az épületautomatizálási és vezérlőhálózat szélső eszközei által nyújtott információk és szolgáltatások közös modelljét. Telepítsen egy szélső kiszolgálót IAP-val, hogy lefordítsa és normalizálja a LoRaWAN eszközökről származó adatokat egy rendszerré BACnet, LON, Modbus vagy gyakorlatilag bármilyen más BACS protokollal, és elérje az összes eszköz adatait és szolgáltatásait munkaállomásokról BACnet, LON vagy OPC használatával. UA. 

Az IAP létrehozza a digitális iker eszközei közül. A BACS bármelyik ikertestvért bármely választott BACS protokollon keresztül eléri, lefordítva a LoRa-t egy olyan nyelvre, amelyet a BACS megért. Ha egy IAP-kiszolgálót úgy állít be, hogy BACnet-kiszolgálót is tartalmazzon, a BACS a LoRaWAN-eszközt BACnet-eszközként ismeri fel; ez ennyire egyszerű. Nincs többé nehézkes kézi integráció, kemény kódolás vagy könyörögni az eszközgyártóknak, hogy támogassák az SCHC-t. Néhány mai IAP-serverrel az integrátorok akár LoRaWAN-BACS integrációkat is létrehozhatnak alacsony kódú környezetben, egyszerű felhasználói felülettel és drag and drop eszközökkel. 

Még jobb, hogy az IAP intenzíven skálázható. Ha valamelyik létesítményébe telepíti, ugyanazt az eszköz- és adatpont-konfigurációt használhatja minden létesítményben, csak az IAP edge szerver telepítésével. Az IAP-vel rendelkező szélső szerverek pedig eredményeket hoznak. Csak kérdezze meg az Egyesült Királyság bútorkereskedőjét, a DFS-t, aki IAP edge szervereket használt a környezeti érzékelők (és egyebek) BACS platformokhoz való csatlakoztatásához több létesítményben. A nyílt, több protokollt használó rendszer segített csökkenteni a DFS energiafelhasználását, mintegy 33 százalékos áramköltség-megtakarítást és 26 százalékos gázmegtakarítást eredményezett egy tipikus kiskereskedelmi üzlet esetében. Ha hasonló eredményeket keres – és nincs kedve manuálisan konfigurálni és keményen kódolni egy örökölt BACS-t –, nézze meg az IAP-t. Lehet, hogy ez a LoRaWAN/BACS integrációs eszköz, amire már várt.

Forrás: https://www.iotforall.com/iap-creates-a-better-lorawan-solution-for-smart-buildings