EBMS – Bringing the EBMS Project to life
Monday, October 8, 2007 at 11:29AM
Toby Considine in EBMS, System Architecture

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

It is said, you go to war with the Army you have, not the Army you want. And you go to bid with the contractors you have, not the contractors you want. And you specify the technologies the market has, not the technologies you want. And we had to buy the Enterprise Building Management System (EBMS) we could rather than the one we wanted.

When we were finalizing the specification for the EBMS, Web Services was all the buzz among control vendors. Many vendors demonstrated SOAP-based building gateways to us – but the product never quite had a part number. Standards were non-existent. oBIX was not yet even a committee draft. The BACnet-WS committee had not begun to meet.

Administrative IT at Universities is always behind the times. The culture that cherishes and maintains Old East, the first State University building, preserves and protects old business processes as well. Our CIO had pronounced a year before that he was pretty sure that XML was a fad, and he knew Web Services were a fad, and we were to let none of that stuff in here. We needed innovation; we needed to push the building controls industry. Such efforts require very clear communication. We went to bid with a document that never once mentioned Service Oriented Architecture, or Web Services.

Building system contracts are traditionally managed as construction projects. UNC is a state agency. State construction projects rely on a very structured business process producing very predictable results. Because we were breaking new ground, we needed to contract for performance, not design. Performance contracting is not part of the normal process in the North Carolina State Construction Office.

State construction did not know what to do with this project. Our creative and resourceful energy manager, Jay Evans, continued to fight for EBMS. At one point, we actually received a suggestion to bid a small portion of the project and do most of the work on change orders; Jay rejected that approach and kept pushing. Finally, State Construction agreed that we could run a controls project through the State IT business process; SIPS supported an RFP / performance based project cycle.

So it began. All communications outside the building were going to be XML based, but no standard was specified. All Monitoring and Operation was going to be from a single web-based system. All graphics were going to be vector based, so every page could display on any device, and scale as needed from large screen to small. (And this worked – I’ve already seen our system operated from an iPhone).

Fortunately, every group associated with the final team approached the project as partners. An example of this occurred about six months in. To preserve legacy systems until the next building renovation, we were placing special purpose gateways in front of the existing building systems. The subcontractor installing these gateways, Yamas, was using the only solution available at bid time: a proof of concept web services engine available from Tridium. oBIX had become a committee draft, and was sliding into the slow process of OASIS Committee Standard approval. Based on a Phone call, Tridium agreed to re-write their gateways around oBIX and deliver us the newer product based on the standard. Yamas agreed to accept later delivery and still meet their delivery schedule to provide us a standards-based solution. Cyrus Technologies promptly agreed to revamp their development work our standards-based vision. All willingly cooperated as a team to deliver the innovative standards based solution we wanted.

One last system hurdle rose up in our path – standards-based XML graphics. When we launched the project, SVG (Scalable Vector Graphics) – a vector-based W3 standard - seemed the clear choice. During the project, the market leader in SVG tools and rendering bought a market leader in a competing technology; Adobe abandoned SVG after it acquired Flash. We had to scramble and switch to XAML. I am not entirely happy with that change, but that was the way the market developed. On the bright side, there are some DWG/XAML converters, so it looks like we will be able to bring our AutoCAD floor plans into EBMS.

Open Standards-based development is new to building systems. There will be hurdles that you do not expect. You need a team that is willing to commit to a vision. You will probably need to define a performance based project, as the road is not entirely clear. For us, the results are well worth it.

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