May 2013
Interview

AutomatedBuildings.com

[an error occurred while processing this directive]
(Click Message to Learn More)



 

Steve JonesEMAIL INTERVIEW Steve Jones and Ken Sinclair

Steve Jones, Managing Partner, The S4 Group, Inc

The S4 Group is a developer of gateway technology to integrate disparate technologies and systems in the building automation industry and other non-IT vertical markets.



Building Automation Systems Integration to the Cloud

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.


Articles
Interviews
Releases
New Products
Reviews
[an error occurred while processing this directive]
Editorial
Events
Sponsors
Site Search
Newsletters
[an error occurred while processing this directive]
Archives
Past Issues
Home
Editors
eDucation
[an error occurred while processing this directive]
Training
Links
Software
Subscribe
[an error occurred while processing this directive]

Sinclair: The number of posts in the discussion you started continues to rise. There are now in excess of 90 postings for a discussion moved to the open discussion group about a month ago. Can you explain the continued interest?

Jones: It’s 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.

Sinclair: Does this mean that everyone is starting to agree on a protocol for integrating BAS systems to cloud-based applications?

Jones: No, but that might be a good thing. If you read the postings you’ll 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.

Sinclair: What did you find?

Jones: Even though the industry has not converged on a single protocol I see three basic trends happening.

1) Utilize, or enhance, existing BAS protocols. BACnet IP, BACnet WS, oBIX, and OPC UA were all suggested. As a result of these discussions the oBIX 2.0 efforts received more visibility and 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.

3) Develop proprietary protocols. Those who I have spoken with are reconsidering their approach and are migrating towards one of the above approaches. This is a very positive sign.

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.

Sinclair: Do you think we will ever get to one standard?

Jones: No. 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. And, 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. We made those mistakes years ago and both customers and manufacturers paid for those decisions dearly. We should learn from history and not make the mistakes over again.

Sinclair: It sounds like you are promoting limiting choices for building owners. Why is that a good thing?

Jones: Actually, just the opposite will happen. 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.

Sinclair: What else needs to be done?

Jones: Wow, that’s a loaded question. 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.

[an error occurred while processing this directive]Sinclair: How are we going to fill that hole?

Jones: 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.

Sinclair: Does this mean we need a new protocol to convey building model information between a building and cloud-based services?

Jones: Probably not. I would 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 stand-alone protocol whose only purpose in life is to convey the building model to cloud based services when legacy, or proprietary, data protocols are involved.

Sinclair: It sounds like there is still a lot of work to be done. Where to from here?

Jones: I agree, but it is pretty 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’ve tried to summarize the discussions while adequately representing the issues, recommendations, and 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.


  footer

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

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

Events

Want Ads

Our Sponsors

Resources