The term ‘Building Automation System’ (BAS) often brings in an impression of heavy duty equipment, convoluted procedures and monotone grey shades in the mind of many. Unlike incredible advances in the Home Automation space, what with intelligent controllers like Nest, inviting SDKs like Apple’s HomeKit , cloud based IP surveillance solutions like DropCam and many other such innovations (not to forget the website for future promises, Kickstarter and the recent RobotBase campaign), the space has mostly kept itself out of the mainstream news.
A BAS network at it’s core is essential a system to control industrial/commercial lighting, HVAC, Chillers, Boilers, Escalators and other such equipment. From a protocol perspective as well BAS systems have evolved over time with various forms of communication, including but not limited to BACNet, LonWorks, MODBUS and other protocol stacks. As Home automation systems have ushered in alternate technologies like ZigBee and others, BAS system gateways have also incorporated these protocols to be able to connect them to their Central protocol gateway.
At the core, however, a BAS system has many analogies to a home automation system: There are sensors (thermostats, water pressure monitors, etc.) that transmit data about equipment or environmental conditions they are installed to monitor, and there are controllers that correlate information and talk to various sensors and offer a means to the administrator to control these sensors. Obviously, there are more components like gateways, access control servers and more in between the networks depending on the complexity of the networks.
The topic of this post is how the ‘Building Automation Controllers’ (BACs) are going through a software revolution and how HSC is playing in this space.
Building Automation Controllers (BACs) at their core are units that are mounted somewhere that communicate with various sensors, or other controllers. In some cases, BACs are just a plastic enclosed unit with no display that expects an external PC to connect to it to control it. In other cases, BACs support a small display using which an operator can control the sensors or network connected to it directly without external means. Yet in some other cases, controllers have a web server running inside them with Ethernet capabilities, which allows an administrator to remote log into its web interface and manage it (just like we remotely manage our home routers for example)
All of the above are what we call ‘legacy’ BACs. While some opine that running a web server inside it is relatively modern, it still is quite old technology and not comparable to responsive UX products that are the current market trends.
But before we describe how this market is evolving,lets first look at how the total BAS network is evolving.
A modern BAS network is not very different from modern application server network architectures for scalable systems. Protocols are abstracted at the core. Components interact with each other via light weight RESTful services. Many devices today have directly started supporting light weight HTTP services and IETF work like the CoAP ecosystem (Constrained Application Protocol) have helped move vendors towards end-end HTTP and reduce the need for interworking gateways. But as of today, there are still many legacy protocols that are resilient and well proven and interworking gateways are important.
However, modern BAS systems have moved to imbibe new architectural principles, with REST services exposing classic control and management functions. This makes it simple for controllers to be developed on multitude of hardware devices and become more powerful. For example, a traditional controller can now be a powerful and rich tablet mounted on a wall with fabulous UX. A controller adjunct could also be deployed in a smart phone that interfaces of WiFi to a wall mounted controller, which in turn supports the necessary protocols to talk to the internal network (as indicated earlier, a true REST only model may be a future goal, but as of today, the controller needs to communicate directly over established interfaces and protocols in the BAS space).
However this evolving BAS network has significant implications on use-cases that can be ushered in and in turn changes what administrators want from Controllers. Such use-cases include:
Given that a BAS network is evolving rapidly and administrators and users both want to benefit from the productivity of a better user experience and power, the question becomes, how does one make controllers smarter? At HSC, we are seeing this market steadily migrate towards Android powered solutions. The reasons are simple:
As a parting note, here is a generic Android Based Controller architecture – which gives you an insight on how Android can be effectively used to not just meet new UX requirements but also integrate with existing protocol stacks and use-cases. Obviously, there are many more details in addition to this illustration but we hope this gets you interested and potentially consider us for your next Android powered BAC project.
HSC works with several innovative OEMs in the BAS space to help them create innovative products in both the controller, smart application space as well as for the network side cloud based AS development (also refer to our network services for SDK design and BigData). We think this space has started seeing a lot of innovation and strongly believe Android-based controllers and cloud-hosted RESTful automation networks will soon become the norm.