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.

Starting New Daedalus

Building Intelligence meets the Intelligent Building. The Intelligent Building negotiates with the Intelligent Grid. Emergency Management sends requests to the Intelligent Building to share its situation awareness with the first responder.

The concrete precision world of resource constrained embedded systems is recognizing the economical excess power provided by commodity computing. Readily available open source and free databases on these platforms are moving these systems from internal hash tables to OLAP. International consortia meet to find the ontology of meaning in engineered systems.

The internal processes of the control systems are being abstracted into services that can be offered up to the enterprise and to the home. System disciplines are now in place to build internet-scale control systems in which heterogeneity is the norm. The entire WS-* stack is coalescing into a suite wherein interoperability at last trumps standards conformance.

What can we build with these new tools? How will these trends transform how we interact with the physical world?

Two weeks ago, I participated in the GridWise Architectural Council’s Symposium on Business Interface Definitions. Last week I participated in the annual OASIS Open Standards Symposium  as chair of oBIX. At both events I was asked “Where do you blog on this stuff?” In answer, here is The New Daedalus.

Let me know what you think.