AutomatedBuildings.com Article - Using Standard Internet Protocols in Building Automation

Abstract
In this article we will attempt to introduce the motivation for using open protocols in building automation. We also cover the two most popular open protocols in the building automation industry-BACnet® and LonWorks®. Next we introduce some well-accepted Internet protocols and how they can be applied to building automation today. Finally, we cover emerging Internet protocols and how they can be applied to building automation. Here, we focus mainly on XML and the future of interoperability in building automation.

[an error occurred while processing this directive]Introduction
Historically, building owners in the market for a new building automation system have been forced to choose between one of several proprietary equipment manufacturers. The purchase of a new proprietary system was just the beginning of a long-term sole-source relationship. For the duration of this type of relationship, a building owner has only two choices:

Many vendors take advantage of being the sole source for additions and maintenance by engaging in price gouging. Prices are competitive during the initial sale, but are far from competitive after the sale. Ending a relationship with a vendor like this can be compared to going through a long and ugly divorce. The transition to a new system is often hostile and expensive.

Because of this, building owners and managers have been demanding interoperability from vendors of building automation equipment for well over a decade. Interoperability in building automation would mean that BAS components from different manufacturers would seamlessly operate together-sharing information as needed in a standardized way.

With true interoperability, building owners would no longer purchase a building automation system as a whole. They would simply purchase the components of that system as needed. They could choose to install and maintain the system themselves, or they could out-source the maintenance to others. Interoperability would give owners the freedom to enjoy competitive pricing while choosing products from multiple vendors for adding to or replacing existing equipment.

This open-source situation would be analogous to the way that computer networks are purchased, installed, and maintained today in almost every business. You don't buy your office network as a whole. You purchase individual components like computers, software, and printers. You grow your office network over time through many different purchases. And although there are compatibility issues and stumbling blocks, in general, the various components of your network operate together.

Imagine that you had to purchase all of your office computers, printers, peripherals, and software from the same vendor. How would that affect the price? Imagine further that you want to purchase some new computer equipment from a different vendor, but none of your existing equipment would work with it. For the most part, this is still the case in the building automation industry. So what is it that would allow equipment from multiple manufacturers to work together? The answer is simple … a set of widely accepted standards and protocols.

Standards and Protocols
Standards and protocols are at the heart of interoperability in any industry and 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. Standards and protocols do not directly affect the advancement of technology. However, the lack of good standards and protocols can inhibit cooperation between organizations, which ultimately inhibits technical advancement.

Typically, the companies with the fastest time to market in a new industry or a new technological area introduce proprietary products to that market. Proprietary technology produces higher profit margins because of the lack of competition. These early companies reap large profits on the new technology and generally become the largest players in the area. But over time, standards that circumvent proprietary technology are developed for the benefit of the consumer. Companies late in the game embrace the open standards in an attempt to gain market share from dissatisfied consumers. Under pressure from the consumers and the newer non-proprietary companies, the older companies have to make a choice:

Two well-known examples of this struggle between proprietary and open technology include:

The building automation industry was dominated by proprietary systems prior to 1995. Before that time, some attempts were made by manufacturers to publish their own standards and protocols for use by other companies. But in general, these standards were not widely accepted by the building automation industry. Also, some open standards like ModBus were borrowed from the industrial automation industry. But these also failed to gain widespread acceptance.

Starting around 1995, two standards did gain acceptance and began to dominate 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. Each of these standards has its' advantages and disadvantages.

BACnet®
BACnet® is a standard that was developed by a consortium 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 Goldschmidt [1], had the following to say about the development of BACnet®:

One of the advantages of BACnet® is that BACnet® is a truly open standard. It was developed by a supposedly unbiased committee. This is in direct contrast to standards like LonWorks® that are essentially dictated by a single corporation. In addition, BACnet® thoroughly covers the specific needs of the building automation industry. Other standards, such as ModBus, do not directly address these needs.

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. To address this problem the BACnet® Testing Laboratories® (BTL) was formed. This is an independent testing and compliance organization that attempts to enforce compliance among manufacturers. Manufacturers have their products tested in a laboratory, and if deemed to be compliant, they are BTL listed and can bear the BTL logo. 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 on a par with to the advanced networking technology found in other industries and standards. Part of this is due to the sluggish pace of the standards committee. From the time of conception to release a revolution occurred in the computer networking industry. For example, ARCNET was chosen to serve as the backbone of BACnet® networks. Even in 1987, ARCNET was considered to be an outdated standard. Although ARCNET is inexpensive and deterministic, it does not conform to the TCP/IP (Internet) networking model-a must for any network today. 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.

Another flaw is that the BACnet® committee attempted to design the ultimate building automation protocol. The specification journeyed into the domain of the application, leaving little room for innovation or advancement. If new companies want to provide innovative solutions for building automation, they must either add proprietary messages or submit these innovations to the BACnet® committee for review. Neither of these is desirable. Proprietary messages defeat the whole purpose of the protocol. And placing an idea under BACnet® review could entangle it in debate where it could remain indefinitely.

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 a truly open protocol. To have the entire standard placed at the mercy of a single company is not an ideal situation for many manufacturers. But even with this situation, many manufacturers have embraced the technology.

The LonWorks® phenomenon is somewhat of a wolf in sheep's clothing. Most consumers speak of LonWorks® as being open in the same way that BACnet® is open. Many consumers who purchase products from different LonWorks® product vendors don't even realize that they're indirectly buying products from the same company.

The Neuron® chips sold by the Echelon Corporation not only implement the LonTalk® protocol, but are also general-purpose microprocessors. But these chips are not considered to be competitive when compared to other general-purpose microprocessors in terms of cost and performance. Much of the value in these chips is in the protocol itself, not the computing horsepower. Many BAS product manufacturers choose to use larger microprocessor chips for the application and add the necessary Neuron chip only for communication services. Although the larger processors have enough horsepower to perform both the application and communication functions, the LonTalk® protocol could not be separated from the Neuron chip until recently.

To address this problem, in October of 1999, Echelon released a reference implementation of the LonTalk® protocol for use on any processor. However, this was no free lunch. The required license for third-party manufacturers to use this protocol was not free and somewhat restrictive. So even after eliminating the Neuron chips from the picture, LonWorks® product manufacturers are still bound by the terms of the license agreement and are still required to pay a single company.

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.

One of the Echelon's achievements has been its' ability to have LonWorks® incorporated into so many other standards. Even though a single company controls the LonTalk protocol, it still appears as part of many different open standards. As a matter of fact, LonWorks® is an accepted part of the BACnet® standard. But in practice, these two standards are rarely used together. Ira Goldschmidt [1] had the following to say about the inclusion of the LonTalk protocol into the BACnet® standard:

So although LonWorks® provides a good level of interoperability, it's future rests in the hands of the Echelon Corporation. This is a corporation that has gained considerable market share, but has had significant trouble turning a profit since it went public several years ago. Although it is now marginally profitable, some manufacturers are nervous to align themselves with LonWorks®.

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 underlying technology of the Internet is quite good from an academic and scientific viewpoint. But that's not what really contributed to the Internet's success. Internet technology is not that revolutionary. For decades people have had the ability to communicate with each other from anywhere in the world using common telephones. So what is it about the Internet that is so amazing? The answer again is standards and protocols!

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:

So why don't building automation equipment manufacturers build products that use Internet standards and protocols instead of BAS-specific protocols? Actually, many building automation systems do incorporate Internet protocols into different parts of the system. However, BACnet®, LonWorks®, and proprietary protocols still dominate the core infrastructure of the BAS networks. Internet protocols are usually tagged onto the product line as an option, and only in places where it is convenient for the manufacturer.

One reason that BAS equipment manufacturers have not adopted Internet protocols as the core networking standard is cost. Internet protocols, in general, are more sophisticated and require more computing power than is typically available on smaller, inexpensive BAS control products. Historically, networking protocols were the domain of mainframes and business computers while embedded electronics used serial communications. But in the past year or two, the price of 32-bit controllers, networking chips, and software has allowed true TCP/IP networking to become a realistic and cost-effective solution at the controller level. It is now possible to have 32-bit Internet-capable processors inside of every single BAS controller in a building.

Another reason for the lack of Internet protocol support is that the well-established Internet protocols do not directly address all the needs of a building automation system. They provide great inter-connectivity, addressing, and graphical display. But they do not specifically dictate how to exchange BAS data (like temperatures or alarms) between BAS components. But new emerging standards address the general need for meaningful component-based interoperability. But before we cover these, let's take a look at the Internet standards that are firmly in place today.

Ethernet and other Link Layer Protocols
The list of Internet protocol standards can be mind boggling to those not familiar with the technology. The good part is that most Internet users don't even know that they exist. It is not necessary to understand the underlying technology in order to use it. This is analogous to the fact that most drivers don't understand how their car's transmission works. We will not attempt to cover the details of all of these standards and protocols. They could literally fill hundreds of books. Instead we will try to focus on the important protocols and concepts and how they can be applied to building automation.

Computers and devices that communicate over the Internet do so using several different protocols at the same time. This is why we refer to them in plural as the Internet protocols. You might ask someone if his or her network is Ethernet or TCP/IP. The answer could very well be both. Figure 1 shows an example of how two devices on the Internet might actually connect to each other.

You can see that several different protocols are used to make the complete connection. Ethernet, DSL, and FDDI are all examples of Link Layer protocols. The connection is not possible unless all of them are present. The reason for this is that the Internet, as the name implies, actually inter-connects several completely different networks to form one large inter-network. You can actually setup an internet (small "i") between two networks in an office. But there is only one Internet (capital "I"). This is the one and only large interconnection of millions of networks and devices around the world. So Figure 1 shows how a single connection message travels through several networks using different link layer protocols. It also shows how the TCP/IP protocol ties all of this together and safely guides messages through these networks.

For building automation networks, Computrols uses a 1Mbps Ethernet variant at the link layer to connect building automation devices together. This Ethernet-like implementation uses inexpensive and easily installed twisted pair multi-drop wiring-similar to RS-485 wiring found in most BAS systems. All of the 1Mbps sub-networks throughout the facility are connected to a 10Mbps or 100Mbps Ethernet networks using various routers. These can, in turn, be connected to the Internet. The 1Mbps sub-networks allow true TCP/IP connectivity at each device but assist building owners in reducing the cost of installation and wiring.

TCP/IP
TCP stands for the Transmission Control Protocol and IP stands for the Internet Protocol. TCP and IP are actually separate protocols that, when used in conjunction (TCP/IP), provide reliable point-to-point connections. TCP/IP handles all of the error detection, transmissions, addressing and routing needed to seamlessly carry messages from network to network. But the Internet itself is not a necessary part of the TCP/IP protocol. Local area networks can also employ the TCP/IP protocol for short local connections. In this example, TCP/IP is still used even though connections don't leave the local network. Two neighboring devices can "speak" TCP/IP on a single LAN. Global connectivity is just a bonus. In true multi-layered fashion, TCP/IP itself does not specify the format of the connection. This is left up to the application-as it should be.

Building automation systems can use TCP/IP today as the underlying connection protocol for building automation. With the introduction of its' new product line, Computrols provides true TCP/IP connectivity to every single controller in a building. This TCP/IP infrastructure is an absolute must for buildings that want to lay the groundwork for the interoperable devices of the future.

HTTP
HTTP is the basic protocol used to display web pages. A client's browser uses TCP/IP to form a solid connection to a web server somewhere on the Internet using the HTTP protocol. The browser requests an HTML (Hypertext Markup Language) file from the web server. The web server, in turn, delivers this file back to the browser. The browser then parses the HTML file and generates the corresponding graphical display on the screen for the user. Figure 2 illustrates this process.

Other well-established application layer protocols that use TCP/IP are SMTP for e-mail, FTP for file transfer, DNS to resolve domain names, and SNMP for network management. But we will not discuss any of these other protocols as they might apply to building automation. However, some clarification is needed at this point. When people think of the Internet, they generally think of two things-the World Wide Web (web browsing) and e-mail. But these two things are actually just high level protocols that use TCP/IP and the underlying Internet for connection. In fact, the World Wide Web is just the use of the HTTP protocol over the Internet. WWW is a subset of the entire Internet.

So the HTTP protocol defines a way that graphical data is transmitted over TCP/IP for display to people using a web browser. It is a complete, well-defined and widely accepted protocol. All building automation systems can and should offer this type of universally accepted protocol in their systems. It would be remiss in this day and age not to offer some sort of web connectivity to a building automation system.

In addition, web page service should not be limited to just the main BAS computer. Every BAS component should have TCP/IP connectivity and offer, at minimum, one default web page. This is true for the exact same reason that building automation systems use DDC. Although you want your components to communicate with other components in the building, you also want them to have the ability to operate independently. If you are using a browser that is physically close to a controller, it just makes sense to browse directly into it instead of having to go back to the main computer. And what if the main computer is down? Do you lose all web connectivity? And what if several systems like lights, HVAC, and fire are all on the same network? Wouldn't you prefer to have a technician browse directly into the local air handler for simple operations without going through the main HVAC computer? What if you don't even want a main HVAC computer? No … TCP/IP and web browsing capability must be provided at the controller level for a truly interoperable BAS system.

Web server technology is not something from the future. This is technology that is readily available today. By using this widely accepted Internet protocol and a common web browser, building engineers 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.

Unfortunately, the HTTP protocol only handles half of the interoperability problem. It basically uses TCP/IP to carry graphical information from a BAS component to a human. But what about the scenario where one BAS component from a given manufacturer needs to communicate with another BAS component from another manufacturer? HTTP does not handle this situation. TCP/IP will definitely be the protocol of choice to universally address these devices and provide solid connections. But another high-level protocol is needed to specify the actual format of the data exchange between two BAS devices.

Emerging Internet Protocols
The TCP/IP protocol provides excellent addressing and connectivity between two devices in a network or inter-network, but does not specify the format of the information that is exchanged. The HTTP protocol provides a very specific and universally accepted format for displaying information to people, but does not dictate how computers or devices should communicate with each other. Any single company could layout a specific protocol format to exchange specific data between BAS components over TCP/IP. But what data and what format would that be? Any attempt by one company to include only the data that it requires would inevitably exclude some data that is used by other companies.

BACnet® tries to fill the void here by including all of the data that the original committee could think of at the time of writing. As an added on option, BACnet® packets can now be transmitted over IP. But this excludes data from those companies not involved in the BACnet® specification design. Much of the data exchanged over BACnet® networks is not BACnet® data. It is in the form of BACnet® proprietary messages. And this is not because the manufacturer wants to "hide" the data from others. It's because there is nothing in the BACnet® specification that handles sending their unique set of data. And what about new data from new building automation products that haven't even been invented yet?

What the building automation industry and other industries really need is a protocol standard that not only defines how specific data is exchanged between devices, but also defines the specifics of the data itself. The problem of simple meaningful data exchange between products of different manufacturers plagues all industries. Protocols using specific data formats are usually quickly outgrown or worse-bogged down with huge amounts of options. Several new protocols address this problem. These are XML, Jini®, and Universal Plug and Play™. Each of these new standards has its' advantages and disadvantages. But for the purposes of building automation, we've chosen to concentrate on XML because of its' simplicity and unquestionable universal acceptance.

Extensible Markup Language (XML)
The idea of XML is just what the building automation industry is looking for. But XML is not made for building automation. Every industry is looking for the same type of protocol. Here are the basic requirements for this protocol:

The amount of research and development being applied to XML in the past two years is tremendous. It, and its' related protocols and standards are one of the most significant advancements in Internet technology in the new milenium. Companies like Sun Microsystems® (the developer of the Java programming language), Microsoft™, IBM, and Oracle are developing new products around this emerging technology. At this time, there is no doubt that XML will be very widely accepted and widely used in the very near future. Let's take a look at Figure 3 to see a general example of how XML might be used.

A web server at the weather center provides XML data on current weather conditions and future weather predictions. It, like most servers in the coming years, provides both HTML web pages and XML data for clients. If someone simply wants to check the weather, they use HTTP to connect to the web server and display one of many HTML files in their web browser.

Another server resides at a mail order clothing manufacturer's main office. It, like most servers, provides both HTML and XML data. Fashion conscious individuals regularly check the web site and display the fashion HTML files in their browser. But in addition to this, the fashion server regularly gets weather prediction information from the weather center's server. It does this using XML data transfers over TCP/IP. It uses this information to dynamically build a web page entitled "Suggestions for Dressing Today". When the weather center predicts rain, the fashion server automatically shows one of their raincoats as part of the suggested ensemble in the web page. Not only does this page showcase its products in real life situations, but it is providing a service as well.

This simple example is shown mainly to get the point across. A more realistic example would show large numbers of application-specific business servers all connecting to each other and sharing huge amounts of data. The possibilities are virtually endless … all servers communicating with all servers! This is the vision of XML.

And this technology is not limited to desktop computers. The general term applied to embedded electronic devices that use these types of protocols is Internet Appliances. Internet appliances are small devices (like building automation system components) that have this type of Internet protocol capabilities built into them. Once again, a huge amount of development is being done 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. And like the Internet itself, this will all be done using the same set of protocols. Devices from different manufacturers will instantly connect and exchange meaningful data. Figure 4 shows a typical scenario of several Internet appliances working together in the home.

At home you might carry a wireless PDA (Personal Digital Assistant) that uses BlueTooth™ to communicate to your PC. The PC is in turn connected to devices throughout the house either using wireless technology, power line carrier, or network wire. Your alarm clock in your bedroom, your TV, the coffee machine, the answering machine, and the dishwasher are all interconnected. You use your PDA to set your alarm while you are not in the bedroom. The doorbell mutes the sound on the TV. Your alarm clock triggers the coffee machine to brew in the morning.

Like the Internet, the technology to do this type of automation has been around for years. This would not be that difficult for a single company today to produce all of these products and have them work together. But to get different products from different manufacturers in different industries working together is another story. For the coffee machine manufacturer to agree with the TV manufacturer on a protocol would be almost impossible. Each has different ideas and motivations for open protocols in their products and in their industry. This is the real strength of these new protocols like XML. They don't describe the exact data that is transferred. Instead, they describe a method for describing the data that is transferred.

The drawings in the above examples look easy enough, but the underlying technology is not that simple. How do these completely different computers and devices find out what data each of the others has? Is there a weather protocol for the weather industry that has data fields like "wind speed"? Is there a clothing protocol for the clothing industry that has data fields like "shirt color"? No. Each server uses a process known, in general terms, as discovery. XML and its' related protocols handle the discovery of new foreign data structures.

XML handles different data types and structures by providing two types of documents-XML Schema and XML Data. Computers or devices that are unfamiliar with the types of data available from a new device on a network will get the schema document from them. The device parses and analyzes the schema for data and services that it may want to use. From there, it can use the schema to get the actual data-ignoring anything that it doesn't understand or want to use.

This allows upward compatibility with future revisions. Take the example where the initial release of a controller that monitors power consumption has the following data items in its' schema:

Other devices could get that schema and search for known or recognized data. One device may want all of the data items while another device may only be interested in the Real Power. Later, a new firmware release is loaded onto the power-monitoring device. By request, the manufacturer has added a Peak Demand data item into the schema. It now contains these data items:

Because of the way that XML schema and data documents are parsed, this should never cause a problem. Parsers ignore those items that they do not understand and never assume an order or limit to data items.

One of the design goals of XML was that it be simple. XML is very similar to HTML. That is part of its' appeal. First, it doesn't require a special network port and can therefore pass through any firewall. Also, programmers familiar with HTML will have little trouble moving into XML programming. And because the files are just simple ASCII text, you can search new and unknown files for familiar words and data descriptions. An HVAC controller might get all of the XML schema documents from neighboring BAS components looking for anything that resembles "Outside Air Temperature".

The current state of XML development is actually quite mature. Much of the development, like the XML document schema and formats, has been complete for some time. The main area of research and development is taking place in the area of development tools and discovery. First development tools will allow manufacturers to quickly and easily produce XML-based products.

In the area of discovery, researchers want to improve the discovery methodologies to the point where seamless interoperability between totally unrelated devices is a reality. Currently, devices can use XML over TCP/IP to exchange data. The developers from different companies don't even need to speak to each other. The simply get the schema from the other device and code their device to read and write that data. This is a nice first step. The only step left is for devices to plug into networks full of unknown devices and begin to communicate with them.

Summary
TCP/IP is the glue that binds the entire Internet and almost every network in the world. It is no longer strictly for large computers. Embedding the TCP/IP protocol into small electronics is not only possible, it is inexpensive and commonplace. Almost every general-purpose widely accepted networking protocol of the future will ride on top of the TCP/IP architecture. Building a TCP/IP infrastructure into buildings today ensures that they will be ready for the technologies of tomorrow.

At the time that this article was written, 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, this question is not even valid. The only valid question is "Why would I not want to include a Web Server on my new product?" Three or four years ago the only answer to that question might have been "Because it's 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. Even if HTTP is not the primary protocol used to exchange data, not including a web page service is inexcusable.

Finally, using TCP/IP connections, protocols like XML will dominate the future of interoperability among embedded devices-even in building automation. This is because XML and other Internet protocols benefit from research and development across industry boundaries. No single building automation protocol will be able to surpass them in terms of complexity, maturity, and acceptance. By using them today, you can begin enjoying a competitive environment in building automation-integrating all of your building automation systems as one seamless local area network.

Computrols
It its' new Internet Ready product line, Computrols offers TCP/IP connectivity as well as HTTP and XML services on every single controller. Customers can get data from or command outputs on a controller by using a web page. Computers can be connected to controllers directly, over a LAN or over the Internet. From there, users simply type the IP address of the controller into a browser and voila-a web page is displayed with a picture of the controller and all associated inputs and outputs.

For interfacing to other devices, Computrols offers the XML service. Third-party computer software or devices can simply download the schema, and begin using the data. All the schema is available from Computrols for developers. In addition, the schema can simply be read from the installed device itself. This is what makes XML so powerful. This is true for any product and any revision.

References:
[1] Ira Goldschmitdt, "Development of BACnet®", Association of Energy Engineers "Strategic Planning for Energy and the Environment", November 1998.

[an error occurred while processing this directive]
[Click Banner To Learn More]

Events	Want Ads
Our Sponsors	Resources