Using Internet Protocols for BAS

The following is exerpted from an article called ‘Using Standard Internet Protocols in Building Automation,’ written by Mike Donlon of Computrols, Inc. (a developer of BAS controls). For more information about this piece and the information it presents, you can contact Rehan Kamal at rehank@computrols.com .

Standards and Protocols

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. 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:

1. Stay the course and continue to sell proprietary products. Doing this, companies retain their profit margins but risk losing market share to non-proprietary companies.

2. Join the open standard community. Doing this, they generally can’ t hold on to the same profit margins, but retain their market share and satisfy their customers.

3. Tread a fine line between proprietary and open products. Using this philosophy, companies will try to be as proprietary as they can get away with. Using a bend-before-you-break methodology, companies will sluggishly and incompletely embrace new standards.

Two well-known examples of this struggle between proprietary and open technology include: Sony Beta Max video recorders vs. the open VHS standard and Apple Computers vs. the industry standard architecture of IBM PCs.

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, and the two protocols have undertaken a battle to gain the upper hand in the industry.

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 90s. 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. We put a man on the moon back in 1969. 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 80s laid the groundwork for the Internet explosion of the 90s. 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.

So why don’t building automation equipment manufacturers build products that use Internet standards and protocols instead of BAS-specific protocols? Well 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.

One reason that Internet protocols have not been adopted by BAS equipment manufacturers as the core networking standard is cost. Internet protocols generally 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 of 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, actually 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 their network is Ethernet or TCP/IP? The answer could very well be both.

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 a single connection message travels through several networks using different link layer protocols. The TCP/IP protocol ties all of this together and safely guides messages through these networks.

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.

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 direct digital control (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.

And 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 is 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:

• It must use the existing Internet protocols to take advantage of all of the existing Internet technology.

• It must be used to communicate high level data between computers and other embedded devices, not between computers and humans.

• It must be simple for everyone to setup, view, edit, and develop products for.

• It must incorporate the description of generic data for flexible use.

• It must allow for dynamically accepting different and new data formats without committee approval or product updates.

XML meets these fundamental requirements, and more.

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 a very widely accepted and widely used in the very near future.

Let’s take a look at how XML could 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 in 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.

At home you 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.

To sketch out the above examples is 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:

• Current

• Voltage

• Real Power

• Power Factor

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:

• Current

• Voltage

• Real Power

• Power Factor

• Peak Demand

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.

Do you have experience and expertise with the topics mentioned in this content? You should consider contributing to our CFE Media editorial team and getting the recognition you and your company deserve. Click here to start this process.