To achieve the Holy Grail where our buildings receive a signal and respond appropriately is a very complex set of problems, indeed. Standards, protocols, and custom applications have historically produced some successes at the facility level. To truly reach the tipping point where DR has a significant impact, our buildings need to evolve to a higher intelligence. To reference some concepts from Building 2.0: it’s about evolving from integration to interoperability, and it’s about evolving from facilities-centric applications to applications that combine the resources of the entire enterprise.

For those in the building automation industry, integration is nothing new. For the last decade we have been able to get a device from one manufacturer to talk to a device from a different manufacturer through the use of gateways or software interfaces. In fact, standards like BACNet,® LonWorks®, and Modbus have gone a long way to bridging the data gap between HVAC systems and energy meters, for example. Integration at the building level and interoperability at the device level can be achieved, but at the high cost of custom system integration programming.

The Framework In A Nutshell

Imagine if all the heads of state at the United Nations had to understand and translate to every language spoken there. It would be a very inefficient environment to conduct business in. What really happens is that a translator provides a common language for each ambassador, independent of the source. To the ambassador it all looks and sounds the same. Now apply this to DR where, say, a pricing or shed signal gets normalized to one common language that all the systems can interoperate with independent of their native protocols. In this common language and object-oriented environment, DR applications can be quickly and easily created.

Since the framework handles the details of the lower level communications, the integrator is free to concentrate on the value-added applications. They no longer have to worry about how to get a LON SNVT talking to a BACNet AI or to a Modbus memory address. In this environment, a pricing signal can come from an ESCO via oBIX, a response strategy can then decide to change control setpoints, which will then change the cooling setpoints on a LonWorks VAV or a BACNet AHU in their corresponding native protocol.

Now take this concept beyond the systems of a building, to the occupants within that building who can play an important role in DR, too. Let’s talk about interoperability with the people, and how we can make them smarter. At the enterprise level, there are company-wide systems for business, HR, and communications. These are new opportunities to touch the human occupants, and to create the human interface. The framework could create a personalized webpage to give an occupant a dashboard for controlling their environment.

Imagine a message broadcast through the phone system alerting them on their local phone display of an upcoming demand event. They could then use their phone as an interface to raise their cooling setpoint or lower their light level. A “green message” could also be sent to digital signage that could broadcast how much energy was saved and the environmental benefits that have been realized today because of their actions. This interoperability with the enterprise systems adds the human interface to the intelligence of the building.

To summarize, a framework approach removes the complexity, and frees us to create the vision of Building 2.0, right now! We can have smart buildings where the DR strategies are a fundamental part of the enterprise environment. This interoperability will enable the occupants to be smarter with their energy usage, and to do the right thing because it’s as simple as common sense. GIB