The ABCs of XML for BAS

Just a few years ago, integrating a building automation system (BAS) with any other computer system was so difficult that successful integration projects were heralded in all the major trade publications. Today, integration is commonplace. A college in Pennsylvania gathers data from multiple systems at a remote field station, compares utility consumption to a modeling program, and posts the results on a web site. Water consumption, electrical usage from multiple circuits, propane usage, temperature, and levels of CO2, CO, and O3 are all being monitored. An aeronautics research organization in Texas is pulling data from multiple chillers and AHUs into Excel for analysis and fault detection. They’re also implementing a scheme to give over 2000 users a simple desktop application that will allow them to turn the air conditioning on when they’re working late or on weekends. (Not surprisingly, this scheme will also keep a tally of the additional hours requested by each using organization.) An office complex in Melbourne, Australia is taking this one step further, using similar data to generate a bill for the after-hours utilities used by each tenant. Should any tenant question the bill, they can instantly produce a detailed report showing the exact start and stop time and date of every air conditioning request.

In Sydney, Australia a building engineer is using data from his BAS to maintain his SEDA rating. (Sustainable Energy Development Authority.) Comparable to our LEED certification, Sydney requires all new buildings to track their energy usage and compare it to indexed values on a daily, weekly, and monthly basis. And finally, in the United States, a controls contractor is collecting performance data from every VAV box and reheat coil in a new building and compiling it into a commissioning report to submit to the contract manager.

So, if system integration is so commonplace, why did I bother to list all these examples? Because these examples were implemented using a new standard for data exchange called XML. XML, or eXtensible Markup Language is an IT standard that is rapidly being adopted throughout many different industries. Think of it as a logical successor to DDE, OLE, and OPC, but a successor that is much more powerful, much more widely accepted, and much more at home on the Internet than these previous standards. You think it’s hard to find a common protocol to connect to HVAC vendors? XML has actually succeeded in getting Microsoft, Apple, and Linux to play nicely together!

Does this mean that BACnet, LonWorks, and all those proprietary protocols are on their way out? Not at all. XML was designed as a tool to be used by computers to exchange data at a high level. The data files are actually composed of human readable text, and the data structure includes verbose (for a computer) descriptions of what data is contained within the files. This makes it relatively easy for a human programmer to find the data they want and to quickly build links between computer databases, but it also means the resulting communication requires much greater bandwidth than any of the dedicated BAS protocols. Figure 1 shows a typical BAS architecture. XML is well suited to communications on the Ethernet IP network, but could strain the resources of the Field Controller network. Bandwidth issues mean it will be a long time, if ever, before you see XML used in a VAV controller.

By itself, XML does not provide any provisions that would standardize communications within a BAS, so in that regard it’s a step backward to the days before BACnet and LonWorks, when every vendor made up their own communication rules. Point data, trend logs, alarms – all can be presented in whatever format a vendor chooses and still fall within the XML umbrella. ASHRAE and other groups are working to correct this problem by developing a standard for presenting BAS data in XML.

Given that BACnet, or any other dedicated BAS protocol, is better defined and more efficient than XML, why is everyone so excited about XML? XML provides a standard method for a BAS to communicate with another computer, whether that computer is in another BAS or a completely different application. The initial version of BACnet did not support Internet Protocol (IP) addressing because when BACnet was created the Internet wasn’t a big deal. That changed in a hurry! BACnet and other BAS protocols now support IP communications because it is the standard for high-end communications. Today BAS manufacturers are similarly adding XML support into their web servers and operator workstations because it is the standard for communicating with other systems at that level. XML is a logical extension to a BAS protocol.

XML also makes it possible to present a higher-level abstraction of building automation data, and to present it in a format that simplifies communications with other systems. A programmer writing a computer application for, say, a utility company might be interested in retrieving information about scheduled equipment start-up from a BAS, or he might want to send a utility curtailment command to the BAS, but he wouldn’t want to learn an entire building automation protocol just for these few transactions. The same situation exists in computer programs used for accounting, classroom scheduling, hotel room management, hospital patient administration, maintenance management – there are many programs which a building owner may want to integrate with his BAS but which are not going to offer a BACnet interface, let alone a BACnet interface and a LonWorks interface and an interface to other proprietary protocols used in today’s BAS. Then of course there’s the poor enterprise integration programmer who’s trying to gather information from multiple computer systems throughout a college campus or a large corporation to prepare customized summaries for senior management. Is he going to want to learn the internal data structure of every application that contains information of interest? XML provides a way to present this data in a standard, self-documented interface that is independent of the data structure or the communication protocol used within the BAS. When combined with a standard service protocol like SOAP (Simple Object Access Protocol) it provides a universal interface that can be used to exchange data with thousands of individual computer applications.

Just how universal is this interface? Dan Traill of U.E.S. Controls, Houston Texas, gives two examples. A school district asked them to pull utility data from several individual schools, run a monthly energy audit, compare actual energy consumption to local weather data, and rank the schools based upon their energy efficiency. Since the BAS for these schools supported Web services, their in-house engineers had no trouble writing the report. “It was a very simple, straightforward process,” Dan said. “They used the built-in XML support in Microsoft’s Excel spreadsheet to gather the data and then wrote the report in Excel.” A more complex situation arose when they were asked to develop a custom tenant override system that would allow 2000 building occupants to extend their office’s hours of operation and would keep track of the resulting after-hours HVAC use. They hired a professional programming firm to develop this application, and the programmers presented U.E.S. with a rather hefty estimate of the cost to create the program using a custom data interface. When Dan told them the BAS system supported XML and SOAP, they cut their estimate in half.

The combination of XML and SOAP has already gained wide acceptance in the IT world. Microsoft calls it .NET. IBM calls it WebSphere. Sun calls it SunOne. Other vendors have other names, but they all fall under the generic term of “Web services.” Web services can be used to read or write data from one computer to another, but they can also be used to actually run applications on another computer. As a simple example, a weather system computer might provide access to hourly temperature and humidity data as well as routines to compute the average temperature, mean temperature, and heating degree days over any desired time period. If you ask for temperature readings over a given period the Web service will simply retrieve data for you. If you also ask for the mean temperature and heating degree days over the same period, the Web service could run a separate application on the weather computer to calculate this data. The weather computer might actually use Web services itself to gather data from other computers and combine it with its own data to respond to your request.

A universal standard for data exchange that can also generate new data. Could anyone ask for anything more? Yes, actually much more is needed. The IT world has developed a standard that supports data exchange, but this Web services standard does not cover the content of the data or services to be exchanged. It would be nice to be able to find the data you need, and better still, to be able to retrieve it without having to hire a programmer to write a custom application. This requires a standard that goes beyond the packaging and transportation of data, a standard that covers the data itself. Since the range and variety of data available from building automation systems is huge, the standard itself has to be very flexible and all encompassing – an information model of the entire building system.

This is not a problem that is unique to the building automation industry. Web services have been used in business-to-business (B2B) transactions for several years. As in the building automation industry, Web services were initially hailed as the ultimate solution to B2B needs for a universal tool for information exchange. It soon became apparent that Web services were an extremely valuable tool to expedite these transactions, but that the transactions still required much custom programming to locate and link the data to be shared. The problem could be greatly simplified if each industry adopted a standard information model, so programs could automatically find the data they needed without human intervention. Existing professional organizations became the logical choice to develop these standards, and today standards are in-place or under development in dozens of diverse categories such as biometrics, electronic procurement, legal court filings, and security services. And the building automation industry? ASHRAE has been working for several years on an XML information model for buildings. Not surprisingly, the BACnet committee has taken on this task, since the “BA” in BACnet stands for Building Automation. Designated “BACnet/WS” for BACnet Web Services, the new information model is not intended only to be used with BACnet. Instead, it is a model that can be used with BACnet, LonWorks, or any other control protocol, it could also be used as a common base for high-level communications between these protocols. The model was released for public review at the June 2004 ASHRAE meeting, and when accepted, it will become part of the ASHRAE/ANSI/ISO standard for building automation.