IoT connectivity developer ControlBright was selected by Atrius to provide remote connectivity solutions. Atrius, part of the Intelligent Spaces Group at Acuity Brands, provides intelligent building solutions to retailers, healthcare groups, manufacturing facilities, and more.
Atrius sought a secure way to process large amounts of data generated in client buildings, according to the press release from ControlBright. Talal Siddiqui, vice president of Acuity, said in the release, “ControlBright’s approach is unlike anything else we found. It was the perfect fit for our requirements, from security, reliability, and serviceability aspects.”
Architectural SSL reached out to ControlBright CEO Chad Behling to learn more.
What were the key criteria and considerations that led Acuity Brands’ Atrius to choose ControlBright as its supplier for remote connectivity solutions?
There are a few unique features of our hardware and platform:
Our modem can be powered via 6-28v AC/DC or via a USB cable and a wall wart. This eliminates the need for special adapters for different installation scenarios.
Our modem has a built-in relay, allowing the attached controller to be power cycled remotely. Here’s a diagram of how it’s typically wired up:
Our cloud platform is unique in that IP and subnet management is not needed. In other words, every controller in the field can have the exact same IP address, eliminating the need to manually update or configure devices before they ship or when they arrive at the job site. This allows Acuity to ship their panels directly to the job site for installation, and nothing needs to be configured on the network side.
We offer a VPN API that allows users to push or pull firmware updates, patches, new configs, etc., to one or thousands of sites simultaneously, even if they all share the same IP address.
Here's a video showing how our IP addressing scheme works:
Can you share specific use cases or scenarios where Atrius will implement ControlBright's remote-access platform to enhance its intelligent building solutions?
Our solution will be utilized across their customer base to provide a secure “network air gap,” meaning their equipment will not need to reside on the customer network. This is becoming more common as large organizations do not want third-party IP equipment on their internal networks for security reasons. Customers include major retailers, hospital groups, airports [and] manufacturing facilities.
How important were security, reliability, and serviceability aspects in the decision-making process, and how did your company address these concerns?
Those three requirements (and support) were very important in the decision process.
Security — Both our platform and our hardware were reviewed by a third-party cybersecurity firm to ensure a high level of security.
Reliability — Our platform is hosted in the Amazon AWS ecosystem, and our hardware has ... few failures reported.
Serviceability and Support — Being a cloud-based platform, all updates and patches can be pushed to remote devices as needed; customers do not need to manage that aspect. This also allows us to deliver new feature updates in a seamless manner (both in our cloud platform as well as remote devices themselves). All technical support is US-based.
Is this platform IP-based?
The short answer is yes, but we also have some pretty unique non-IP features. For example, we have a remote RS232/RS485 function that tunnels serial protocols over the remote link. On the user side, we provide a browser-based serial console that allows users to send RS232/RS485 commands right from their browser to the remote device. We also offer a Windows 11 Professional Mini PC (about the size of a bookmark but 0.5” thick) that can be installed at the remote site. Also, on the user side, we provide a browser-based RDP client that enables them to access the desktop on the Windows PC. The benefit to both of these functions is that a client is not needed—everything is completely browser-based.
Any hints about what’s in the roadmap for 2024?
We are in the process of finalizing a new approach to supporting multicasting remotely. Historically, this was done by using VPN links that support layer-2 broadcasting across the entire link. This is not ideal over WAN links for a variety of reasons, and this solution does not scale very well. We have developed an approach that only uses layer-2 connectivity over part of the link, significantly reducing network chatter. Additionally, we have been able to maintain our process of only requiring a single-user VPN config to manage any number of sites under the user’s account. Ultimately this means that users can manage remote sites that require multicasting using a one-to-many approach rather than individual VPN configurations for each individual site.
