Intelligent Grids need Intelligent Buildings

Two weeks ago I participated in a symposium sponsored by the Pacific Northwest National Labs (PNNL) for the GridWise Architectural Council (GridWise AC). It is a fascinating conference, and one with more chance of meeting green and environmental and conservation goals than just many other initiatives hosted by folks who wear their hearts on their sleeves. It was also grounded in good economic theory and humble enough that it might just succeed.

GridWise AC is trying to create the structures to enable rapid innovation in the power grid. The first principle of GridWise is that while the folks in the room are smart (and they were – this was no small part of the fun), they are not the only smart folks in the world. To actually address the needs of the future grid while moving to new models of energy production, we must create structures that encourage innovation. To encourage innovation, we must create means of realizing value propositions for new energy usage patterns and for non-traditional power sources.

Current market structures are a boat anchor on innovation. If you invent a gizmo that talks to the power grid and somehow saves energy in the house, today, you can only sell it to around 30 customers – all big power companies. Each of them will be required to run an extensive pilot before they can get anything through their local Utilities Commission. This means your initial sale will have to be, say, 50,000 units warranted for 10 years. Then after a year installing those units, the power company can propose a rate structure for them The Utilities Commission may nix the whole project, or ask for more research.

GridWise AC makes no assumptions about the structure of the future markets for power. It does not assume that consumers will interact with monolithic power companies. It hopes to enable power users to adopt their own technologies, to let innovators sell product directly, and to attain a higher quality power while it does this.

If we pull this off correctly, there will be whole new industries around the now nimble market. As each home or business can buy from whatever power generator they please, different power sources will get different prices based upon what consumers want. You may have an in-home agent running on your PC, and talking to your home systems. You may have someone else, talking to your home over your internet connection and buying power for you. In either case, you will be buying the power which meets your wants, whether they be driven by economy, or reliability or a whole range of green concerns that might range far beyond the simple “Zero Carbon”.

I am fascinated by the technologies and markets this will engender. Somehow there will have to be a continent-wide NASDAQ of power. Instead of balance sheets, there will be an ontology of power generation to enable our computerized agents to execute our will. Who will audit these systems, both the transactions and the greenliness. Who will develop the interfaces that make playing in this area safe for the non-technical?

As an intelligent building guy, I feel that all of this is helped along by abstract discoverable interfaces to the home and office embedded systems. By policy, I must say that oBIX is the way. Whether that is true or not, I know that it will be a protocol that is able to talk to the building systems, but is itself higher up, where human interactions can occur.

It should be fun.

More than One Control System per Building

A few years back, we passed around a list, and quickly came up with more than 40 different types of building control systems. It was a nice list, a comprehensive list – except it was not.

When I returned home, I shared the list with someone I worked with whose work I respected. The colleague worked in a part of the University that was called, at that time, Classroom Technologies. I described how we were going to come up with a way to interact with these systems. He glanced at the list for just a moment and said “But you left off what I do – AV and Event Management…”

A week later, another friend, who worked with systems at the hospital, and I were enjoying the late spring weather during an afternoon of malted beverages at the fine Chapel Hill old beer garden “He’s Not Here”. He asked if he could see the list, and right off said “Where’s Medical Gas Distribution?”

And so my education went.

Each of these control systems have a different mission. The primary service each can provide the enterprise is to defend its mission first, and to respond to requests second. Even when systems look alike, and use the same protocols, they may have different missions. Vents, fans, actuators, and ducts? It is either a HVAC or it is a Laboratory Fume Hood. Woe betide the person who flood the lab with poisonous gas because he thinks he is working on the former.

I think that control systems should be smaller. Too often they are as large as people can make them, based upon shared communication protocols. They need to be smaller, small enough to have a single mission. Then we need to make them perform that mission well.

Why Control Systems need Interfaces

Recently I was asked at my day job “Why do we have different protocols in the control center and in the buildings at UNC?”. I listend to a variant of this question when I was at the GridWeek symposium.

One of the big challenges of the internet-scale control systems is diversity. Even if we (or the Power Company, or the Utilities Commission) were to pound a stake in the ground today and say “this product only”, it would be (1) decades before we achieved the standard and (2) by the end of that time, we would be unable to acquire “this product” any more. Control systems are 20 year (or on the grid, 50 year) decisions. This means that aside from whatever the inadequacies of control protocols in the open, you simply cannot have a homogenous control system of any size.

Below is the answer I gave to my colleague on campus:

1. Control protocols, every one of them, have no concept of enterprise requirements such as scalability, heterogeneity, security, abstraction. Not a one of them. Anyone who says otherwise is not sure what the words mean.
2. Prior to adding an abstraction level for talking to buildings, diversity was unmanageable in the control center. This prevented developing the ability to respond nimbly to developing circumstances within or without the campus. We had to solve that.
3. We chose to restrict all control protocols from the campus back-bone. There is not control interaction between the Library and the English Building – so there is no need for their control systems to talk. Inappropriate interactions within over-large control systems made fixing the problems in buildings harder, slower, and more expensive. This was effectively a boat anchor on simplifying the problems in the buildings. This inflexibility inhibited our ability to respond to campus users who had special needs. Once we decouple each building’s control system from those in other buildings, we free ourselves up to upgrade existing systems or install new ones.
4. We chose a protocol suite for connecting across campus between buildings that would encapsulate (i.e., hide – protect – provide standard interfaces) building controls in the fastest way possible. We chose protocols based upon e-Commerce standards (and e-Business, and e-Government…), the tools of the internet. These scale to the size systems the size of the planet. These let us use the full suite of business analysis tools rather than proprietary tools developed by controls companies. We chose protocols that support security as understood by banks doing EFT over the web. This includes values such as composability, granularity, non-repudiation, play-back prevention and not merely encryption or isolation. These protocols also understand heterogeneity (or diversity) in ways control systems do not. The supply chains of WallMart and Dell are based upon this class of protocol. They do not require their suppliers to use particular systems, or applications or technologies. The generic term for this class of protocols is web services.
5. To achieve (4) as quickly as possible, we chose to hide many systems that we could not upgrade. Many of the most expensive systems to upgrade were implemented in the hopelessly proprietary protocols, implemented using 1990s-vintage controlers. We hid those behind standards-based JACEs that were purpose-built to do this. In the LON buildings, we “rolled our own interface” based upon GridLogix software to isolate those systems. If I am not mistaken, we have a couple other systems being read directly through their web services protocols. This is where we are now.

Note that this does not yet solve the problems of the HVAC shops, only gets us to the point where we can solve the problems of the HVAC shops without facing significant integration issues outside the buildings.

This is where we are now. We have begun to address the problems of the entire campus by creating an open standards-based architecture. Within that architecture, each individual building now has been freed up for innovation and standardization based upon the dual (and not always compatible) needs of the HVAC Maintenance shops and the (occasional) special needs of the customers.

The architecture will continue to develop. The Standards for communication with building systems using web services will continue to evolve. The requirements for access to and interaction with building control systems being promulgated by Homeland Security will place new demands on the external interface. (I saw a presentation suggesting that National Weather Service CAP alerts would be delivered directly to public buildings whose control systems would have in-place approved operating postures during weather emergencies. Clearly we cannot do this today. But such a mandate will apply to the external web services surface only, and have little to do with the underlying control systems.

As the architecture matures, it will have less and less to do with the details of the control systems. In many ways, it will mirror what we are doing in the buildings. There will be fewer proprietary applications, and more and more functions implemented as plug-ins to the architecture.