Commercial building occupants want their facilities to have a degree of intelligence and automation, while real estate owners are racing to deliver via ioT. Perhaps this explains why the compound annual growth rate of the building automation and control market is expected to grow by more than 21% by 2028. After all, the Internet of Facilities IoT is how you get to the promised office of the future – and recent trends have made smart buildings more of a requirement than a privilege.
Companies have energy goals; IoT helps meet their needs through automatic control of HVAC, lighting, and more. The rise of remote work has led to a large number of unused facility spaces; IoT can identify these spaces, personalize them for temporary users, and provide data on how to optimize each square foot.
Given these market forces, the question is not whether to invest in smart building technology, but how to invest in a way that can provide a good return on investment and support the use of wired and wireless communications. The Remote Wide Area Network (LoRaWAN) protocol is a promising wireless device solution that requires less power than WIFI devices but has a longer range than Bluetooth devices. LoRaWAN is managed by the open, non-profit LoRa Alliance, which creates low-cost, low-power, remote wireless connectivity between smart building devices and the platforms it works with.
The problem is that integrators struggle to connect LoRaWAN devices to traditional wired building automation and control systems (BACS). The new Internet of Things Access Protocol (IAP) solves this problem. That's it.
The struggle to connect LoRaWAN devices to traditional BACS
Any medium-sized or large building will most likely be equipped with BACS with equipment that uses wired communications, and BACS is not designed to keep up with IoT innovation. For decades, operators have been using these traditional BACS platforms to manage all the technologies within buildings: HVAC, lighting, access control, security, elevators — all of which have gained considerable utility with the addition of the Internet of Things.
If you want to extend building automation, you have to transfer data from each discrete IoT device to BACS. But there is a mismatch between the LoRaWAN standard and the common BACS network protocol. The connectivity protocols that BACS understands (to name a few) are very rich standards. They have a rich data model, specify network services, and provide command and control capabilities — all tightly defined in the BACS architecture.
LoRaWAN doesn't meet all of these BACS definitions by itself, so it's hard to create robust integrations. Until recently, smart building integrators used one of two methods to connect LoRaWAN devices to traditional BACS, neither of which was ideal:
Manual data point mapping. First, you connect your LoRaWAN device to the LoRa web server. Each data point in the server is then mapped to the corresponding point in BACS. The difficulty arises when it comes to BACS, where you have to manually configure automated algorithms – including the definition and configuration of the basic meaning of data points. For example, you must tell BACS that the temperature reading is an indoor space temperature reading and create an algorithm that tells the system how to process that data point. Building systems integrators require extensive, resource-intensive and time-consuming manual configuration.
Static Context Header Compression (SCHC) protocol. If you don't want to hard-code the data mapping on the BACS side, SCHC may help. This compression framework populates the entire BACnet message into the LoRa packet. This transfers the full end-to-end BACnet object properties from the device to BACS. The definition of a data point is built-in. There is only one problem: integrators cannot implement SCHC on their own. The protocol must be built into the device, which means that only the device manufacturer can implement it. To make matters worse, SCHC smart building devices are more complex and therefore more expensive than simple LoRaWAN sensors – assuming someone makes them first. If there are a small number of manufacturers, this scarce equipment will most likely require a delivery time of 6 to 12 months in today's supply chain disruption.
None of these methods support intelligence for IoT edge devices; all data manipulation takes place at the BACS level. They also only support BACnet, the main communication protocol in the field of building automation and control. If some of your IoT infrastructure relies on LON, Modbus, or DALI for lighting control, or industrial Ethernet protocols for your factory, you're out of luck. Fortunately, a third option is now available, which promises to make the job of a smart building integrator much simpler.
IoT Access Protocol (IAP) for LoRaWAN integration with BACS
Recently standardized through ANSI and CTA, IAP is a platform-agnostic data and service access protocol that outlines the definition of information, data models, and services for IIoT devices. More simply, it creates a data and services structure that connects all the elements of a smart building infrastructure — including a common model of information and services provided by edge devices in building automation and control networks. Install an edge server with IAP, convert and normalize data from LoRaWAN devices into systems that use BACnet, LON, Modbus, or almost any other BACS protocol, and use BACnet, LON, or OPC to access data and services from workstations to UA.
IAP creates a digital twin for your device. BACS accesses each twin through any BACS protocol of its choice, translating LoRa into a language that BACS can understand. If you set up an IAP server to include a BACnet server, your BACS will recognize the LoRaWAN device as a BACnet device; it's that simple. Eliminate the need for clunky manual integration, hard-coded, or begging device manufacturers to support SCHC. With some of today's IAP edge servers, integrators can even create LoRaWAN to BACS integrations in low-code environments with a simple user interface and drag-and-drop tools.
Even better, IAP is highly scalable. If you install it in your facility, you can use the same device and data point configuration in all your facilities, just install an IAP Edge Server. Edge servers with IAP will get results. Just ask UK furniture retailer DFS, who uses IAP edge servers to connect environmental sensors (and more) to bacs platforms across multiple facilities. The open multi-protocol system helps reduce DFS's energy use, saving typical retail stores using the system about 33 percent in electricity costs and 26 percent in natural gas costs. If you're looking for similar results and you don't want to manually configure and hard-code legacy BACS, check out IAP. It could be the LoRaWAN/BACS integration tool you've been waiting for.
We are looking farward to your following and likes. Know more products and technical literature, please visit to our official website https://www.cdebyte.com. For any technical or product inquiries, please contact our official website page to inqure!