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