AutomatedBuildings.com Review - Legacy Building Automation Systems Integration to the Cloud

This discussion is one of our very active Linkedin group discussions - over 25 comments at time of posting.

Our S4 Open Appliances have lead the legacy building integration market sector for some time. The typical applications have been migrating legacy building automation systems to new technologies or adding value added applications such as energy management or continuous commissioning. We are starting to see a demand for our appliances to act as on-site agents for cloud-based applications as an alternative to many traditionally on-site service. I'd like to know if anyone else is seeing the same trend.

From Paul: Our customers are completely fed up with proprietary manufacturers and the constant talk of yet another "open protocol." Use whatever protocol makes sense when talking from device to device. But use XML from device to third party system. That way, the client can choose whether to store it "on-premise" for use in an EDW, etc. or to send it to "the cloud."

From Toby; Even for systems that have an oBIX gateway, such as offered buy Niagara, there are integration challenges for cloud interactions. oBIX failed to have a semantic layer to describe what the points are. Tagging standards such as suggested by NREL, are not applied consistently, and are rarely a focus during commissioning. As large a problem as the as the data firehose is to cloud solutions, the integration problem of discovering which serve which functions, and where they are in a building looms larger in all but the simplest strip-mall commercial building.

John Petze; I would agree with Toby that oBix has not continued to evolve to address the potential to capture semantic information about the data from sensors and control systems. I was involved, with Toby and others in launching oBix. For those interested in solutions to address this need and streamline integration with enterprise applications and the web I would like to suggest you take a look at the Project Haystack protocol. Initially started as an effort to create a solution for semantic modeling of data, recently Haystack introduced a protocol. This protocol takes the next step beyond oBix and includes semantic information about the points and systems they are associated with. project-haystack.org is an open source initiative.

This is one of the great advantages of Haystack. The Haystack methodology is not in any way tied to any product or languages. It is a methodology that can be implemented independently of the system. Its is also extremely flexible, allowing modeling to be developed quickly by the open source community.

The use of Haystack modeling enables data from BACnet, Modbus, Niagara, OPC, or any other system to work together in enterprise applications that are haystack-aware.

Steve Jones; Thank you all for this great dialog. I think we are all learning something through the process. Let me add some additional thoughts to my original post. I see several distinct areas that need to be addressed to make cloud services successful.

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 arrises and innovators provide solutions.

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.

Data protection, ownership, archival, and retreival: Solutions are evolving in most of these areas but the issue of data ownership and retreival concerns me the most.

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.

Data collection: I'm looking at this as being akin to MtoM 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 case I was referring to it is gateway technology interfacing legacy BAS systems to cloud-based services. This is really 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?

Just as importantly we need to address the same issues going in the other direction. 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?

Some of the earlier postings were getting to these issues. I'd like to expand on those discussions with infomation 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?

There is some great insight in this discussion please read it completely and or get invloved in its evolution.

Events	Want Ads
Our Sponsors	Resources