This post continues a series about a particular large system at UNC
The first hurdle we had to solve in our EBMS project was containing all building controls protocol traffic and keeping it off the enterprise backbone. We used a variety of approaches for this, as we had considerable diversity in our installed base. Some systems ad compatible purpose-based hardware that we could plug right in. For others, embedded Linux systems translating older protocols to Web Services were available. For still others, we had to craft custom integrations running on top of a Windows PCs. 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.
Under EBMS, we operate and monitor all buildings using exclusively Web Services. This transition enabled us to get our first buy-in from the enterprise IT group. The network demands and fragility of traditional control protocols caused them many problems. We simplified their life by using only well understood and well behaved web services.
We called the gateway between intra-building control interactions and extra-building monitoring and operations the Enterprise Building Local Gateway (EBLG). We had to accept some diversity of EBLG to encapsulate the much greater range of underlying systems, protocols, and even product cycles.
The most obsolete systems were fronted by oBIX surfaced JACES from Tridium
Standard vendor web services were used for many systems, including iLONs and TAC Soap Services.
Custom mappings of many systems were created using GridLogix software atop Windows XP.
Configuration and maintenance remains un-standardized. We installed Local Control Stations (LCS) for many of the buildings. Each LCS is a locked-down domain-secured PC running Windows XP. The proprietary applications for configuration and control for each building were installed on the local LCS. Some effort was required to make these applications work because of the outdated programming and security models that are rife in the building controls industry. These efforts paid off in that we were able to fully secure these systems for the campus network and to use managed patch application to keep them secure. Control system technicians are authorized to access these systems by remote desktop based upon their organizational position and status.
These are the key components of EBMS. We allow only standard well-known, well-behaved protocols on the campus backbone. We reduced the number of building interfaces to as few variants of web services as we could. All PC-based systems in EBMS are centrally managed, with policy-based patch management and security control. All systems allow remote access using directory enabled security. Technicians can get to the systems they support remotely using the account and password they use to perform the rest of their work.