EBMS the Next Time – Agents and Enterprise Interactions

The University of North Carolina’s Enterprise Building Management System (EBMS) is an innovative open system for managing energy use and operating building systems. It hides the diverse brands and control protocols of the buildings, keeping each safely contained in its own building sandbox. All communication with these systems is by web services, the basis for modern internet e-Commerce. All systems communicate primarily with a central system that programs each building.

In many ways, rather than doing things a new way, we have perfected the old. Instead of many consoles, one for each bran, we have one. Rather than specifying a single brand of building system for compatibility, we can select the one that performance requirements and competitive bidding indicate. Because all data is now normalized and kept in an standard database (it happens to be MSSQL), we can use standard tools for reporting and OLAP.

But we didn’t change that much. They say you go to war with the army you have, and not the army you want. And you go to bid with the technology you have, and the specs you have, not the technology you want. Push the technology and business processes too hard, and no one bids. Someone told one of our executives that XML was a fad, so we were forbidden to even mention it in our bidding documents. The entire building controls industry still has a poor concept of security, so allowing open access to systems is still a problem.

All things considered, EBMS is a remarkable project, one that pushed the state of the art. But it could have been better.

We should have pushed the performance abstractions down to the Local Gateways (EBLG). Rather than shedding load centrally, we could have been able to send a command to each building “LoadShedLevel3”. We could have submitted a web services request to the building, “StayInOccupiedMode” “8:30pm”. We could require the facility system integrator to define these contracts t comply with performance expectations. This would have prepared each building to have enterprise interactions beyond central monitoring and operation.

This would have defined a realm wherein enterprise programmers with enterprise skills (and not building skills) could operate the buildings. Building gateways would become building agents, and maintain responsibility for performance.

Today the EBMS is REST, meaning simple URLs define all interactions. SOAP would have let us better prepare. Transactions may need various levels of security. Today we encryption and firewalls. I want signatures, and roles-based security, and delegation. I want guaranteed delivery and non-repudiation. I want to be able to store decisions and authorization to run contracts, with signatures, in a business process (BPEL). When the business process arrives, I want the pre-authorized contract to be issued.

In short, I want enterprise interactions.