Publishing Building Automation Systems Data to Cloud-Based Services

We have been receiving frequent requests for our S4 Open Appliances to act as an on-site agent for cloud-based services and I am trying to determine if there is a defacto, or formal, standard for delivering building configuration information and data to a cloud-based service. If not, are there best practices evolving that might eventually lead to standards in this area?

As a part of this effort I have been spending a lot of time moderating a discussion that I started on the automatedbuildings.com LinkedIn group, redirecting the conversation focus, and cajoling others to get involved with the discussion. Another round of Protocol Wars and locking customers into proprietary systems is what I am trying to avoid. I saw the marketing efforts for “Cloud” services ramping up very quickly. That smelled like opportunity so I started investigating. The hype was talking about everything except how the data (and configuration information) gets from the building to the cloud application. Even, security was not being given enough visibility. Everyone was doing it in their own way. i.e. a return to proprietary systems.

From the S4 business standpoint I expected that we would need to implement a few different protocols in our gateway products. However, I want to avoid having to implement a unique one-off interface for every cloud-based service in the industry. I saw that Cloud based services, if done correctly, open up a huge amount of opportunity for S4 and our partners. Traditionally, our products have been applied to retrofits and migrations of legacy BAS systems to new open environments. The first step has always been to migrate the head end to new technology, very quickly and economically enhancing the legacy system and extending its useful life. With cloud based services the goal is typically different. The building owner or operator wants to bi-directionally exchange data with cloud-based services without impacting the operation of the existing system. It is a co-existence strategy at which the S4 Open Appliances excel.

I see several distinct areas that need to be addressed to make cloud services successful.

1. The interactive user interface for cloud-based services: This area has been standardized on the web browser for a long time. This is mature technology and is evolving through enhancements, extensions, and scripting languages as the need arises and innovators provide solutions.
2. Security: As more applications get deployed this is becoming more important. The good news is that authentication and encryption technologies are relatively mature and are being applied. It is simply a matter of applying appropriate attention to this area.
3. Data protection, ownership, archival, and retrieval: Solutions are evolving in most of these areas but the issue of data ownership and retrieval concerns me the most.

• What happens if the service provider suddenly goes out of business?

• What happens to your data if the service provider gets hacked?

  1. Algorithms, Services, and Applications: I look at this as completely a local matter to be determined by the service provider. As long as they can meet the standards for data collection interfaces and results presentation, how they get there is their internal business.
  2. Data collection: I'm looking at this as being akin to M2M communications. Not just from a building to a cloud service but in the other direction also. This may be building devices that natively know how to communicate with cloud services. In the S4 world it is gateway technology interfacing legacy BAS systems to cloud-based services. This is the area that my original post was trying to get a discussion going about. This is not to imply that a different method should be used for gateways. They should use the same standards as natively communicating devices.

• What communication protocol and data representation standards exist for a building to send data to a cloud based service?

• How is that data identified so that the building can be accurately modeled? Not just the HVAC controllers and points but the building spaces and all affiliated services like power, occupancy, lighting, etc.

• Just as importantly we need to address the same issues going in the other direction. For instance, if the cloud based application is a continuous commissioning application how are commands sent back to the building in a way that the on-site systems can take appropriate action?

It is primarily area 5 above where S4, and our partners, have a role to play. Topic 2, security, is also critical because we need to protect the building owner’s information while in transit. We need to expand on the current discussions with information on how widely are the proposed interfaces deployed? Are they used by one cloud service provider or 500? Is there a clear winner in the marketplace? How many cloud based service offerings are out there for BAS and Energy Management applications?

I’d like to invite you to join in on a discussion that I started in the automatedbuildings.com LinkedIn Group titled Legacy Building Automation Systems Integration to the cloud. Here is a link that will take you directly to that discussion. See http://lnkd.in/dKJ9k3. As the discussion evolved I realized that I narrowed the scope of the discussion too far with the original title and that, as an industry, we really needed to look at Publishing Building Automation Systems Data to cloud based services, in general.

Thank you in advance for any ideas or comments that you can add to the discussion.