Daikin Integration to BACnet, Modbus, KNX, WIFI, Mobile Apps
INTERVIEW Michael Newman and George Thomas
During the recent Light+Building show in Frankfurt, the BIG-EU was celebrating their 10th year anniversary with a party in their stand. One of the industry leaders being recognized that evening was H. Michael Newman of Cornell University. Mike is considered the father of BACnet and was visiting the show. George Thomas, President of Contemporary Controls had the opportunity of interviewing Mike after the party.
As published in Contemporary Controls newsletter Volume 9.Issue 3 May-June 2008
Meet the "Father of BACnet®"
In an interview with Contemporary Controls, H. Michael Newman tells his story of leading the charge for adopting the BACnet® protocol, and the battles and victories that ensued. He describes the development of BACnet, its greatest strengths and much more.
Thomas: Mike, how does it feel to have your concept of an open-building automation system protocol grow into a worldwide standard and for you to be recognized at this huge trade fair?
Newman: It feels great, naturally. But to really understand how great it feels, you would have to understand the trials and tribulations that were involved in getting the standard developed, published and commercially accepted. There isn't enough time here to describe the entire minefield that had to be traversed to get things to where they are today! Suffice it to say that BACnet is the result of an incredible group of dedicated professionals who simply didn't know when to quit.
Thomas: I noticed that you made your comments in German. When did you learn German?
Newman: I studied engineering physics at Cornell in the '60s. It was the Sputnik era and the college instituted a language requirement because they felt we needed more people who could read the scientific and technical works of the day, many of which were written in foreign languages. I studied both German and Russian for awhile. I had the chance to work in Berlin for a couple of summers at AEG and lived with a family, all of which had been arranged by a German professor who wanted his American students to see what the Berlin wall and Cold War were really all about.
Thomas: After you received your education, where did you first begin to work?
Newman: I got involved with aviation and spent several years as a charter pilot and flight instructor. In the mid-70s the Arab oil embargo came along and many of our main charter customers decided it was "patriotic" to stay home and use the telephone to conduct their business so the charter operation fell on highly unprofitable times. I decided to return to Cornell and began working on energy conservation projects. One of the most sophisticated was the installation of an "Energy Management and Control System." Since I was one of the few people in the facilities group that had had even the slightest computer training, I got the job of trying to implement a true computer-based EMCS.
Thomas: What were some of the first building automation systems you worked on?
Newman: We had a Honeywell Selectrographic 6 electromechanical central monitoring and control system that we initially interfaced to an IBM System/7 computer. Then came a parallel-to-serial interface unit that let us talk with Fischbach & Moore Remote Terminal Units. These RTUs had been designed for remote monitoring of pipelines in the west Texas oil fields. They were essentially "dumb multiplexers." They had A/D and D/A converters but no computer. All the logic was in the "head end." The first true DDC system, in 1981, was a Johnson Controls DSC-8500.
Thomas: What prompted you to conceive of an open systems protocol for building automation?
Newman: It took awhile to shake loose the DSC-8500 protocol from Johnson and the better part of a year to write and debug our own version of a device driver for the DSCs. We also had the driver for the F&M RTUs to support. Then Honeywell, Powers and other vendors started coming along, also offering their versions of DDC equipment—all of which used the same asynchronous byte-oriented serial communication technology but with different message structures. It was madness. A standard was desperately needed, at least as far as I was concerned.
Thomas: Was ASHRAE initially receptive to your ideas and willing to initiate a committee?
Newman: At the recommendation of my boss, an avid ASHRAE supporter, I attended my first society-level meeting in January of 1981. I went immediately to sit in on the meeting of TC 1.4, Control Theory and Application, the technical committee that focuses on building automation and controls. Not a word was mentioned about the data communication issue. At the end of the meeting I spoke with the chairman, a gentleman from Johnson Controls, and asked him if there were plans to develop a standard for this emerging DDC technology. He said, in effect, "No, the vendors aren't interested in it." So I joined TC 1.4 and began advocating for a standard. It took six years, but in January 1987 the ASHRAE Standards Committee approved the formation of a Standard Project Committee to develop what we now call BACnet.
Thomas: Who were some of the initial committee members?
Newman: The initial group of voting members was quite a cast of characters. We had folks from Cornell, Yale and Iowa State University; NIST and Public Works Canada; Johnson, Honeywell, Powers, American Auto Matrix and Novar; Energy Applications, Inc,. Universal Software Corp., and Ralston Purina. It was a mixed but, as ASHRAE rules require, a balanced "bag." We also had another ten non-voting members representing a cross-section of the building controls industry.
Thomas: How did you meet Steve Bushby and what role did he play?
Newman: When the call for members went out in January, 1987, I received many suggestions and applications for membership. Steve was recommended to me by the late Warren Hurley, a colleague of his from the National Bureau of Standards, now NIST. We met for the first time at the Carnegie Deli in New York City, in the context of the ASHRAE meeting. Steve was not only eager to sign on, but expressed a willingness to serve as committee secretary, thus instantly endearing himself to the chairman! During the spring, we worked out a strategy for the first meeting which was to take place in June, 1987, at Nashville. We wanted to "hit the ground running." I drafted a set of three issue areas that were to form the basis for three "working groups" (the use of the term "working group" was intentionally picked so that the concept of doing "work," as opposed to sitting around in a "sub-committee," was clear from the outset). They were the "Data Type and Attribute WG," the "Primitive Data Format WG" and the "Application Services WG." At the appropriate point in the initial meeting, Steve was to move the formation of these WGs and, we believed, we would be off to the races.
Thomas: Were controls manufacturers at all interested in your committee that they decided to send representatives?
Newman: Absolutely, but the initial group of representatives consisted predominantly of sales and marketing guys who had the task of trying to figure out if the ASHRAE effort was really going to be going anywhere. There was shock and awe when the motion was made by Steve, on our pre-arranged signal, to hand out work assignments to be completed by our next committee meeting. The vendor reps were largely unprepared for any real action and didn't know whether to vote Yea or Nay. As it turned out, they ended up deciding it would look bad to vote against moving forward and the vote to form our initial set of working groups passed unanimously.
Thomas: What did you consider the most difficult aspect of defining the BACnet protocol?
Newman: I would say learning and adhering to ANSI/ASHRAE procedures. The public review process, for example, protects the integrity of the standards development process but is arduous to comply with and is also susceptible to mischief if a commenter wishes to impede the process. This occurred, in fact, and was brutal for those of us at the center of the storm. But we prevailed, simply because it was more important to us to succeed than it was to our antagonists to cause us to fail.
Thomas: Do you feel that the development of the protocol took far too long to develop through the committee process?
Newman: It was, of course, frustrating that it took 8 and a half years to get a standard put together. But the process had its advantages. By the time we were ready to publish, no one could claim that they were "taken by surprise" or that they "had no chance to participate." The development procedure was completely open and well-publicized in the industry press. Because the basis of the process was reaching consensus, everyone had already bought in to the standard at the time of its finalization and knew exactly what implementation would mean for them. Thus companies (that wanted to) were able to bring products to market fairly rapidly.
Thomas: Why was ARCNET® included as one of the approved data links?
Newman: Fairly early on we surveyed all the committee members and asked them what network technologies they used in their existing non-BACnet (obviously) product lines and which technologies they were familiar and comfortable with. The results of this ruled out IBM's Token Ring, for example, but ruled ARCNET in. At the same time, we found out that there was no standard approach to using EIA-485—so we ended up rolling our own, based on Profibus, which became MS/TP. The same situation occurred with respect to the Point-to-Point protocol.
Thomas: I noticed that BACnet has evolved from conformance classes to BIBBs, device profiles and PICS statements. What do these things mean and how did they come about?
Newman: We realized soon after initial publication that the attempt we had made to provide some help to specifiers, namely specifying "Conformance Classes" (CCs) and "Functional Groups" (FGs), was fatally flawed. The problem was that the CCs and FGs did not properly deal with the difference between initiating a service request and executing it, did not cover all the services, and did not provide sufficient granularity of function. The "building block" concept, coupled with the idea of device profiles for common device configurations, solved this problem. There was another huge benefit: each BIBB provides a shorthand way of representing its purpose so that the BACnet communication capability of a device can be described accurately and succinctly. With BIBBs you can see at a glance exactly which services a device can initiate and respond to.
Thomas: Was it always a major goal of the BACnet committee to ensure interoperability among different vendors' equipment?
Newman: Yes. This was our main goal.
Thomas: Is the BTL Mark the answer?
Newman: The BTL Mark is simply the symbolic representation that a device has successfully passed a set of rigorous third-party tests that prove to the end-user that the device does what it claims in a conformant way. It is intended to boost user confidence and therefore the use and meaning of the mark needs to be actively protected.
Thomas: Through the ANSI approval process, the committee needed to respond to criticisms of the standard. Did you meet much resistance before BACnet became an ANSI standard?
Newman: Most people submitted constructive suggestions during the several public review cycles. There was one exception, a company that was determined to try to stop the process. Ironically, after the inevitability of BACnet was perceived, the company lost substantial market share, was forced to shutdown a major facility and certain individuals moved on, this same company is now a major supporter of BACnet worldwide!.
Thomas: I noticed that BACnet is now a European Norm (EN) as well as an ISO standard. How well has BACnet been accepted in Europe and other parts of the world?
Newman: Incredibly well! One of the rules of the European Union is that EN standards must be adopted as national standards in each country if there is no directly competing local standard. Thus BACnet is now the "law of the land" in the 28 member states of Europe. BACnet is also a national standard in many Asian countries and its adoption as an ISO standard has also contributed to its global acceptance. I leave it to our marketing colleagues to provide the actual numbers.
Thomas: What is the next step for BACnet? Is it a mature technology?
Newman: One of BACnet's greatest strengths is that it is relatively easy to enhance as user needs and market conditions evolve. At the moment, for example, there are 11 working groups that are crafting a wide variety of enhancements. These enhancements cover the waterfront: improving network security, such as for systems involving the interfacing of access control and HVAC; improved operation in Network Address Translation environments; the use of BACnet Web Services for enterprise system integration; communication with utility companies for demand response and real-time pricing applications; wireless networking; lighting control; CCTV integration; etc. The list of enhancements is long and growing. The real beauty of BACnet's original design is that most most of these enhancements can be added on to the protocol in a backward compatible way so that newer and older products can still work together.
Thomas: What role is Ethernet and IP networks going to play in future building automation systems?
Newman: BACnet®/IP over Ethernet is already the most common networking technology for "building level" controllers. Most of these devices can also act as BACnet routers to Master-Slave/Token-Passing (EIA-485) or ARCNET LANs that interconnect application-specific controllers.
Thomas: Do you envision Ethernet being used at the device level?
Newman: It is only a matter of cost—and probably time. I can well remember when an Ethernet card for a PC cost $1000—now it's hard to find a motherboard without Ethernet built in. Now that Ethernet can run happily on unshielded twisted pairs, and the cost for Ethernet chips continues to drop, it is likely that not only Ethernet but IP itself will be supported on the tiniest of field devices. People once roared with laughter at the mere thought of an IP smoke sensor—but it is getting ever closer to reality.
Thomas: Several years ago I read your book Direct Digital Control of Building Systems. Any plans on publishing a second edition?
Newman: I have been discussing this with my editor. It could happen, although I have also been toying with the idea of writing a book dealing solely with BACnet. At the moment, the only such book is that of Hans Kranz, written in German. It has sold quite well in the German-speaking world but, obviously, we need a book in English for the English-speaking audience.
Thomas: If you had to do it all over again, what would you do differently?
Newman: Very little, really. Fortunately, we can't know the future. If we had known how arduous the journey was going to be, we might have pulled back from starting out. As it turned out, BACnet has become a global success and those who have been involved in its development and who have persevered through thick and thin have become life-long friends and true "BACneteers."So for me, and for us, it has all been well worth it!.
The BIG-EU Celebrates its 10th Birthday
It wasn't exactly a large group of individuals, but their hard work and persistence paid off. The BACnet Interest Group Europe (BIG-EU) made its formal entry into the register of associations on May 14, 1998—founded by 18 manufacturers and end-users promoting the BACnet standard. Since then manufacturer neutral integration with BACnet has developed successfully in building automation. BIG-EU consequently used this year's Light + Building show in Germany to celebrate its 10th birthday.
The BIG-EU was exhibiting under the banner "BACnet—the World of Integration—10 Years of Success in Europe," and had its biggest exhibition stand ever. About 30 exhibitors representing seven countries built the common booth. A spectacular booth party was held and celebration cakes were served to members and partners. Many thanks go out to the sponsors who made the party and the press conference possible.
Today the BIG-EU has 80 members representing Canada, Europe and the USA and its membership is increasing month by month. This association promotes the application of the worldwide communication protocol ISO 16484-5 in European building automation and safety engineering. For more information, visit www.big-eu.org.
[Click Banner To Learn More]
[Home Page] [The Automator] [About] [Subscribe ] [Contact Us]