EBMS – Design Decisions for the UNC Enterprise Building Management System
Wednesday, October 3, 2007 at 07:22PM
Toby Considine in Background, EBMS

This post continues a series about a particular large system at UNC

As described in the last post, Building System protocols suffer from a number of problems. They are unstable. The protocols are not standards compliant. They have poor security characteristics. So we decided to put them in a sandbox.

Each buildings system was to be isolated within that building. No protocols not easily recognized by Network Support Technicians would be allowed on the backbone; BACnet, LON, et al., were all gone, even their IP versions. All network traffic for control systems would come from protocol stacks that were written for mainstream use. Systems would be secured using our standard network security

All connections to building systems be sessionless. This one needs some explanation. When a program on your computer connects to a database, you log in, and establish a session. That connection is maintained by regular hand shaking. The remote server remembers things about you, so you can continue the conversation. This is efficient, but it does not scale well.

When you contact a web server, you connect, get your page, and then the web server forgets all about you. This allows one web server to service thousands of clients. The standard for sessionless program to program communications is web services. You use web services whenever Gmail types ahead to finish an address for you. We opted to use web services for all routine communication.

We defined two ways to connect to the sand box. It was necessary that we choose names that were not tied to any particular brand, so we made up our own. All communications between the EBMS and the control system are through the Enterprise Building Local Gateway (EBLG). All maintenance of the building system is through the Local Control Station (LCS). Both access points are secured by network security.

We defined a Local Control Station (LCS) to support the needs of each individual system. The LCS runs all the proprietary software that is used to configure the control system. All of them run Windows XP and are members of a windows domain. Users do not have administrative rights on an LCS. All access to LCS’s would be defined by security policy.

The Enterprise Building Local Gateway (EBLG) was created as the gateway and translator. All operational access to the building system is through the EBLG and is exclusively by web services. Maintenance or reconfiguration is performed on the LCS instead.

The Enterprise Building Management System (EBMS) was conceived of as a central harvester of all information from all the web services on all the EBLGs. No software or hardware to work with traditional control protocols would be installed on the EBMS. No traditional controls enter or leave the EBMS.

Using web servers to access the information on the EBMS, operators can see everything in all systems, no matter what the brand or the protocol. This provides a web based point for operating all the buildings. We carefully defined a distinction between Operations and Maintenance/Configuration. You can think of it as the difference between driving a car and performing service on a car.

Article originally appeared on New Daedalus (http://www.newdaedalus.com/).
See website for complete article licensing information.