Building Automation Systems Integration to the Cloud

The number of posts in the discussion on automatedbuildings.com LinkedIn Group continues to rise. There are now in excess of 90 postings since the discussion titled Legacy Building Automation Systems Integration to the Cloud moved to the open discussion group about a month ago. It is a timely topic and will become more important as the number of Cloud-based applications continues to increase and the value being unlocked by Big Data technologies and Analytics begins to produce tangible results. Both building owners and providers are seeing the initial results as well as the long-term potential and therefore are pushing the industry forward.

Not everyone can agree on a single protocol for integrating BAS systems to cloud-based applications. In fact, not everyone can even agree on what the discussion should be. If you read the postings, you will notice that several times I tried to redirect the discussions back on topic. I also received many direct emails providing additional insight into this topic. The industry is still struggling with the distinctions between a platform, a system, and a protocol. A protocol can be platform, system, and programming language independent. If it is an open protocol, it should be all of these things.

The lack of convergence to a single protocol might be a good thing. It is a sign that the major players are realizing that the BAS industry has a good base to start from and that the much larger IT world has mature technology to offer. I see three basic trends happening.

  1. Utilize, or enhance, existing BAS protocols. BACnet IP, BACnet WS, oBIX, and OPC UA were all suggested. Because of these discussions, the oBIX 2.0 efforts received more visibility and have spun off a discussion area of their own. The BAS industry has addressed some unique requirements for alarming, scheduling, and trending and we should anticipate the need to share this information with the evolving cloud-based services.
  2. Utilize protocols defined by IT oriented cloud hosting companies. This goes in several different directions depending on if you are looking at cloud-based storage, virtualized systems, or hosted computing space. Google, Amazon, and Microsoft, among others, are competing in the cloud-based storage area. IBM has adopted the OpenStack cloud operating system, Microsoft has adopted their Azure platform. There is no clear winner here so it’s a matter of which one you want to align with. <!--OpenStack: Open Source Cloud Operating System-->3. Develop proprietary protocols. Those who I have spoken with are reconsidering their proprietary approach and are migrating towards one of the above approaches. This is a very positive sign and was one of the main goals of starting this discussion.

It appears that we are not going to converge to one “standard” but it is likely that the end result will be a manageable number of options available. The success is that we, as an industry, have put bounds around the problem and are not going to repeat past mistakes.

In many cases the benefits of using what already exists far outweighs the expense of converging to a single protocol. In other cases, the exact choice of protocol chosen is being driven by the application at hand. Applications involving manufacturing or process control convergence might drive the selection to OPC UA. A cloud-based implementation of a full featured operator workstation might dictate BACnet IP or BACnet WS. Moreover, an analytical application that requires a model of the building along with the data might go with oBIX 2.0. The technical requirements of Energy Management, Demand Response, or Continuous Commissioning applications might dictate which protocol is chosen. For periodic analysis and reporting applications, the tried and true file transfer of data in a CSV file might suffice. The key is that the industry is realizing the benefits of not inventing something entirely new and proprietary. When we made those mistakes years ago both customers and manufacturers paid for those decisions dearly. We have learned from history and not making the same mistakes over again.

By converging on a small set of well-defined and supported protocols, building owners will have more choice and more competition between providers. The protocols in and of themselves do not solve business problems for building owners. They facilitate getting building data and commands to and from cloud-based applications that address business problems. Building owners will be able to subscribe to multiple services to get best-of-breed solutions that are the best match for their needs. Providers will not be able to lock building owners into their services because of proprietary interfaces and will need to differentiate themselves by the quality of service that they offer. The same benefits that BACnet brought to building owners in the BAS arena will be demonstrated here. Everyone wins.

In addition to the discussion about protocols, the critical topics of Security, data encryption and protection, identity protection, standardized programming languages, and building modeling all came up during the discussions.

The first series of items have well defined solutions that can, and should, be adopted from the IT world as quickly as possible. The more open our systems become to more diligent we need to be about protecting building owners from the associated vulnerabilities.

Standardized programming languages, or ways of expressing logic in our controllers could result in huge benefits ranging from platform portability to drastically lowering the costs associated with personnel training, cross platform integrations, and implementing and maintaining installations. It seems that the European marketplace is already benefiting from embracing the related ISO and IEC standards.

However, building modeling appears to be the biggest, and most urgent, hole that needs to be filled. In order for cloud-based services to work on data received from buildings they need to receive it in a standardized way that identifies what each data item is and how it relates to the spaces in a building and the uses of those spaces. We are well on the way to a solution IF we can put aside the “my favorite platform” biases and focus on delivering what is needed to make cloud-based services effective and viable. The focus needs to be on what information is needed, in what format, to best serve the building owner. Leveraging the work being done in the BIM community, Project Haystack, the Haystack Connect effort going on this week, and evaluating what should be applied and adopted from the IEC standards are all steps in the right direction.

I hope that we can first get everyone to agree to the content and format of the building model itself. Then, the industry can address how to transfer the model from the building to cloud-based services. In a number of cases, relatively minor extensions to existing protocols could accommodate this. However, there could be justification for a standalone protocol whose only purpose in life is to convey the building model to cloud based services when legacy, or proprietary, data protocols are involved.

There is still a lot of work to be done. However, it is amazing what this industry can accomplish when we work together. I have to point to the BACnet PlugFest events as an example. The industry pulls their best and brightest together and everyone works for their mutual benefit. That same thing can happen here.

I would like to thank everyone who participated in the discussion group to date, and those who sent me private messages. I have tried to summarize the discussions while adequately representing the issues, recommendations, and at a very high level the work to be done. I encourage continued participation in these discussions at http://lnkd.in/dKJ9k3. Every bit of information helps us to get to a solution that benefits everyone.