In The News

By Mike Donlon – Director of Research and Development

Introduction

Historically, building owners in the market for a new building automation system have always been forced to choose between one of several proprietary equipment manufacturers. The purchase of a new proprietary system was inevitably just the beginning of a long-term sole-source relationship. Throughout the duration of this type of relationship, a building owner has only two choices:

• No History
• Accept the vendor’s pricing for additions and maintenance, or
• Completely replace the vendor’s equipment at tremendous cost

Building owners and managers have been demanding interoperability from vendors of building automation equipment for well over a decade.

Standards and protocols are at the heart of the question of interoperability in any industry. Standards and protocols are more political in nature than they are technical. They require technical personnel from various organizations to work together to create an agreement by which the entire industry can follow. The parties involved must participate in standards development with the spirit and intent of true interoperability.

The building automation industry was dominated by proprietary systems prior to 1995. Starting around 1995, two standards did gain acceptance in the building automation industry—BACnet® and LonWorks®. Since that time most of the major players in the industry have aligned themselves with one of these two standards. But Computrols, Inc.—an innovator in the building automation industry—has instead chosen to use Internet protocols throughout their entire building automation product line.

Internet Protocols

Throughout the building automation “protocol wars” of the last decade, a revolution was taking place in the networking and computing industries. The Internet and its’ associated protocols became the dominate driving force for technology in the 90’s.
The proliferation of personal computers in the 80’s laid the groundwork for the Internet explosion of the 90’s. But the truly amazing thing about the Internet’s success is that everyone agreed to connect these computers using the same set of protocols. Computers of all different types, with different operating systems, from different manufacturers, came together in cyberspace under a unified set of protocols. That is the crowning achievement of the Internet. This type of technical cooperation is unprecedented in history.

Let’s quickly look at some of the advantages of using Internet protocols instead of BAS-specific protocols:

• Internet protocols are well defined.
• Internet protocols widely accepted. Widely … as in … hundreds of millions of people.
• Internet protocols are free. No single company controls them. Anyone can look up the standards and can choose from a long list of component manufacturers.
• Internet protocols are continually improved and benefit from research and development from thousands of companies across hundreds of industries. The amount of money in R&D for the Internet and Internet-related technologies dwarfs that in the building automation industry.
• Internet protocols allow building automation systems to cross industry boundaries and interface with a wide variety of other systems.
• Internet protocols allow separate systems and groups of components to share the same set of wires. This reduces the overall cost of installing and maintaining several systems.

And Internet technology is not limited to desktop computers. The term Internet Appliance is applied to embedded electronic devices that use standard Internet protocols. Internet appliances are small devices (like building automation system components) that have this type of Internet protocol capabilities built in them. There is a tremendous amount of research in this area. The vision is to have all of the electronic devices in the home and office communicating with each other and sharing information. Devices from different manufacturers will instantly connect and exchange meaningful data with each other.

But before we cover the specific Internet protocols (TCP/IP, HTTP, and XML), let’s first cover the two dominate building automation standards.

BACnet

BACnet is a standard that was developed by a consortium of people and organizations under the supervision of ASHRAE (American Society of Heating, Refrigerating, and Air-Conditioning Engineers). BACnet is an open standard that has been plagued by politics and lack of comprehensive compliance. Active development on BACnet began in June of 1987 and took over eight and a half years to complete. One of the committee members, Ira Goldscmidt [1], had the following to say about the development of BACnet:

“The committee came together optimistic that, with cooperation from all involved, the standard could be completed in a year. Unfortunately, Mike Newman’s prediction that if ‘...cooperation is less than complete, it could take forever.’ was closer to the truth.”

One of the advantages of BACnet was that BACnet was developed by what was supposed to be an unbiased committee. This is in direct contrast to standards like LonWorks® that are essentially dictated by a single corporation. In addition, BACnect covers the specific needs of the building automation industry.

One of the disadvantages of BACnet has been that cooperation among the players has been half-hearted. There have been many releases of BACnet products that were not 100% compliant. True interoperability between these products and compliant products could not be achieved. This left consumers somewhat disillusioned. To address this problem the BACnet Testing Laboratories® (BTL) was formed. But this was not launched until the year 2000—13 years after the conception of BACnet!

Another problem is that, in general, the technology behind BACnet is not comparable to the state-of-the-art networking technology found in other industries and standards. Part of this is due to the sluggish pace of the standards committee. To address this major shortcoming, BACnet/IP was quickly introduced after the initial release. The idea of BACnet/IP is to place BACnet packets over the Internet. But this was more of an afterthought than a primary design goal. And it only further muddied the already murky waters of BAS interoperability.

LonWorks

LonWorks® is a standard that was developed by the Echelon Corporation. From its’ conception, LonWorks® has revolved around the LonTalk® protocol and the company’s Neuron® chips. Unlike BACnet, LonWorks® was developed by and is primarily controlled by a single company. Until recently, any product that was LonWorks® compatible contained one of Echelon’s Neuron chips. This of course raises the question of whether or not LonWorks® is truly open. To have the entire standard placed at the mercy of a single company is not an ideal situation for many manufacturers.

One benefit of the single-company philosophy is controlled interoperability. By having Echelon enforce strict implementation of the LonTalk protocol, LonWorks® products achieve a higher degree of interoperability between multiple manufacturers than does BACnet. But this is at the cost of soul-source components and licenses.

Even though Echelon is the sole source for LonWorks, it has managed to get the LonWorks standard accepted as part of several other open standards. For example, LonWorks is an accepted part of the BACnet standard. But in practice, these two standards are rarely used together. Ira Goldscmidt [1] had the following to say about the inclusion of the LonTalk protocol into the BACnet standard:

“The issue of including LonTalk as a LAN technology within BACnet was passed prior to the third public review of the standard in 1995. The alternative appeared to be a deadlock and potential appeal of BACnet by Echelon, which led to an observer’s remark that some committee members held their noses while voting ‘yes.’”

TCP/IP

The TCP/IP protocol is the glue that binds the entire Internet and almost every network in the world. TCP stands for the Transmission Control Protocol and IP stands for the Internet Protocol. Embedding the TCP/IP protocol into small electronics is not only possible; it is now inexpensive and commonplace. Almost every general-purpose widely accepted networking protocol of the future will ride on top of the TCP/IP architecture.

Building automation systems can use TCP/IP today as the underlying connection protocol for building automation. By building a TCP/IP infrastructure into buildings today, owners will be ensured that they will be ready for the technologies of tomorrow. With the introduction of its’ new product line, Computrols provides true TCP/IP connectivity to every single controller in a building.

HTTP

HTTP is the protocol that is used today by every web browser on earth. A simple web browser connects to a web server using this protocol. Web service and HTTP protocol support can easily be added to electronic devices that are TCP/IP-capable.

Some manufacturers of embedded electronics might ask the question “Why do I want to include a Web Server on my new product?” With such massive acceptance and potential connectivity and interoperability at a their fingertips, the only valid question is “Why would I NOT want to include a Web Server on my new product?” Three or four years ago this may have been considered too expensive. But now, with the advent of inexpensive 32-bit microprocessors, networking chips, and software, there is no viable reason not to offer web capability. Computrols provides web server capability on every single controller in a building—providing a completely open system.

With web service provided at the controller level, building engineers armed with a common web browser can browse into any BAS component in their building. They can do this from anywhere in the facility where there is access or from anywhere on the Internet if the options and security are in place.

XML

XML is an emerging protocol that allows devices to efficiently exchange data. Like HTTP, XML uses TCP/IP to provide reliable connections. But unlike HTTP, XML is designed for data exchange between devices only, not between devices and humans. This simpler more lightweight protocol is needed so equipment from different manufacturers can quickly and easily exchange information without graphics.

One of the main selling points of XML is that it not only provides data exchange, but also defines the data to be exchanged. This eliminates the need for fixed data types in the protocol. As new products are introduced, or old products revised, new data descriptions are deployed with new product releases. This is allows seamless integration into older systems and allows for much greater maintainability.

Computrols also provides XML services in their latest product line, allowing third party manufacturers to integrate directly to these controllers.

References

[1] Ira Goldschmidt, “Development of BACnet”, Association of Energy Engineers “Strategic Planning for Energy and the Environment”, November 1998.