BACnet® at Cornell

[ILLUSTRATION OMITTED]

The story of BACnet at Cornell University really begins with the story of BACnet itself. As you may know, the initiative to develop a communication standard for building automation within ASHRAE began here. This is how it happened.

It was the early 1980s and building controls manufacturers had discovered the power of microprocessors and computer networking. At Cornell, we had invested in a central, electromechanical control system that dated back to the mid-60s. The system was installed along with a district chilled water system that initially served a single new high-tech science building. In the mid-70s, as a direct result of the Arab oil embargo and the resulting cry for energy conservation, a small, diskless IBM System/7 minicomputer was interfaced to the electromechanical system. The minicomputer could measure electrical load and perform load shedding and time-of-day start/stop of a limited set of building equipment. This system was called our energy management and control system or EMCS. Not long after, a newer, more powerful minicomputer replaced the diskless machine. To place the new machine into perspective, it had a whopping 128 kilobytes of RAM and 5 megabytes of disk storage. In comparison, my current desktop PC has about 30,000 times more of both. The advantage of the new machine was that it could digitally communicate using "high-speed" 1,200 bits-per-second modems over dedicated copper wiring. This allowed us to read field sensor values with previously unattainable accuracy.

Meanwhile, our primary controls vendor wanted us to buy into the concept of direct digital control (DDC). When we asked them if we could use our existing minicomputer as a head-end to oversee the DDC computers in the field, they insisted we purchase a new computer from them to provide such supervisory control. This made no sense to us. We already had a perfectly good computer that communicated with the original electromechanical system, as well as a growing number of field equipment multiplexers through the modem links, which was something their computer could not do. We told them that if we were going to buy their fancy new DDC controllers, we wanted to use our existing computer and write our own software to accomplish the interface; all we needed from them was the communication protocol--the set of rules that described how their DDC equipment communicated. After considerable back and forth, under cover of darkness, in a brown paper bag, the protocol specification arrived at the door. The controls vendor had never imagined that an owner actually would want to write his own communication driver to talk with their controllers and they were concerned about the dire consequences to our buildings if we messed up. However, we pushed on and soon the System/7 was happily talking with the new DDC computers.

At that point, the die had effectively been cast. Cornell had a multiprotocol computer that made use, simultaneously, of three separate communication languages.

The cost, however, was great. If you were fortunate enough to have the programming resources, you could "roll your own" as we had done. If not, you could buy a head-end computer from the manufacturer. Either way, you ended up with an ongoing maintenance situation because any change to the protocol necessitated programming work or the purchase of software updates for the vendor's computer. Expansion was highly constrained since equipment from a different vendor either required more programming or the purchase of a new computer. It was as if every TV channel required you to buy a TV just to watch that channel. An absurd situation!

[ILLUSTRATION OMITTED]

With the realization that all the controls vendors were implementing basically the same type of networking, but all were doing it slightly differently, the frustration in the trenches became intolerable. Interoperability was all but impossible. A standard was desperately needed!

One day I was discussing this unfortunate situation with my director. He suggested that if anyone were working on the problem, it would be ASHRAE. At the time, I must confess, I had never heard of the society, having studied physics and astronomy in college. In January 1981, I dutifully headed off to my first ASHRAE meeting, in sunny Chicago, to see what ASHRAE was doing about this problem. To me, the lack of any network standardization had to be the biggest problem facing the building controls industry and surely was holding back the acceptance of this new and exciting DDC technology. I sought out the meeting of ASHRAE Technical Committee (TC) 1.4, Control Theory and Application. The topic was never mentioned. After the meeting I introduced myself to the chairman who, it turned out, worked for the company that had sold us our first DDC equipment. He explained that a communication standard was "impossible, because the controls vendors will never go along with it."

I joined TC 1.4 and began to work to persuade my new colleagues that a communication standard was not only possible, it was essential. It took six years, but in 1986 it was suggested that I write a title, purpose and scope that could be used by the standards committee as the basis for the formation of a new project committee to develop a protocol. With the sentiments of the previous TC 1.4 chairman still in the back of our minds, we decided to propose the creation of a guideline (a type of document that had been formalized within ASHRAE around this time), thinking this would allow us to approach full-fledged standardization more gradually, and possibly not incur as much opposition from the controls companies, at least in the early stages. Fortunately, the standards committee at the time would have none of it. They believed the ASHRAE protocol should be a bona fide standard right from the start, so the Standard Project Committee 135P was born, and I was asked to chair it.