On-site Agents for Cloud-based Services A quest to determine if there is a defacto, or formal, standard for delivering building configuration information and data to a cloud-based service.

Steve Jones, Founder and Managing Partner The S4 Group Inc

The S4 Group has been receiving frequent requests for our S4 Open Appliances to act as an on-site agent for cloud-based services. That led me on a quest to determine if there is a defacto, or formal, standard for delivering building configuration information and data to a cloud-based service. If a standard was not available, then are there best practices evolving that might eventually lead to standards in this area? After all, being in the business of converting proprietary systems to open systems we need to walk the walk.

As a part of this effort I have been spending a lot of time moderating a discussion 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 wanted 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 increasing in importance. The good news is that authentication and encryption technologies are relatively mature and are being applied. It is simply a matter of paying 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?
  

4. 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. In most cases this is where the service provider delivers their value and differentiates themselves from others in the same space. Aside from this they can compete on price and service.
5. 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. It may also be the way a gateway communicates with cloud services. Gateways 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?

[an error occurred while processing this directive]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.

After Haystack Connect there will be a detailed analysis of what was learned there and through this discussion.

[an error occurred while processing this directive]
[Click Banner To Learn More]

[Home Page]  [The Automator]  [About]  [Subscribe ]  [Contact Us]