AutomatedBuildings.com Article - Web Services

One of the few lessons I remember from my Machine Design course is the concept of “degrees of freedom.” Build a machine with too many degrees of freedom and it flops around uselessly, like a limp piece of rope, with no way to predict the output. Build a machine with too few degrees of freedom and it’s a rigid structure, incapable of any movement whatsoever. Build a machine with just the right degree of freedom and it moves smoothly, with precise, predictable results.

In some ways, Web services today have too many degrees of freedom. Potentially they can be a very powerful tool to integrate all the automated systems within a building into a smooth running machine. They can also be used to communicate and coordinate with other high-level computer systems such as accounting systems, utility systems, and weather forecasting systems. Currently there are no rules on how to apply Web services to building automation however. This gives programmers virtually unlimited freedom to use Web services any way they want, but it also makes them a very expensive tool to use. Each individual integration requires hours of custom programming. Fortunately, ASHRAE is adding a little structure to Web services by preparing an addendum to the BACnet specification that will add Web services to the BACnet toolkit. The standard is flexible enough to make full use of the power of Web services, but with enough structure to greatly simplify the task of using Web services to integrate building systems. In short, it has just the right degree of freedom.

Just what are Web services? Web services are a standard way for two computers to exchange data over a network. Web services can be used to read data from or to write data to another computer application. Web services can also be used to direct another computer to run a program or subroutine to generate the data needed by the requesting computer. A simple example is the customized weather forecasts many people run on their PCs. Chances are, this forecast is being provided through a Web service hosted by the weather computer. Your computer sends a request to the weather computer, asking it to generate a three-day forecast for Zip Code 12345, with emphasis on outdoor sports and airport conditions. (Or whatever options you’ve selected.) The Web service itself is based upon Information Technology (IT) standards such as XML and SOAP, but you don’t need to understand them to use Web services. The important thing is that the IT world understands them, and Web services are well supported throughout the computer industry.

How widespread are Web services? To begin with, Web services have been adopted as a standard by Microsoft, Apple, Sun, Linux, IBM, and many others. It’s unusual for this group of competitors to agree on the time of day, so when they agree on something as technical as Web services it immediately becomes an industry standard. They all put their own little “spin” on it – Microsoft calls their implementation .NET while IBM calls it WebSphere – but at heart they’re all based on Web services. Web services have been used in Business to Business (B2B) communications for several years and are quickly becoming the accepted norm. Some of the more prominent adopters include Amazon.com, Google, and Microsoft Passport. The State of New Mexico is using Web services to create a “portal,” a single web site where users can access data and services from multiple government agencies.

Figure 1 King Street Wharf in Sydney, Australia

Within the BAS industry, Web services are already being used world-wide to import HVAC after-hours use and utility meter readings into accounting systems and automatically generate tenant bills. (See figure 1) They are also being used to automate commissioning tests, calculate and compare energy use by similar facilities, and to create “virtual thermostats” that give users control over their office environments. Test programs are integrating building automation systems with utility systems, implementing control options based upon real-time utility pricing and implementing energy curtailment during emergencies. Universities and other large complexes are experimenting with using Web services to create interactive web pages, integrating utility consumption, maintenance management, cost accounting, record drawings, and other facility systems into a “facilities portal,” a single user interface that can be used to access all of these systems. (See Figure 2.) Projects under consideration include using weather forecasts to optimize ice storage systems, boiler start-ups, and morning pre-cooling. Universities are exploring the possibility of using their central classroom scheduling computer to automatically schedule HVAC, lighting, and other classroom services.

If BAS vendors are already providing Web services, where does ASHRAE fit in? ASHRAE is establishing a standard means of using Web services to integrate facility data from multiple sources. The IT world established standards for the mechanism of Web services, but these standards say nothing about the actual data being exchanged. (This is analogous to the way the telecommunications industry establishes standards for telephone systems but does not specify what languages or conversations the system can carry.) Vendors can claim support for Web services while making as little or as much data available as they wish. They can also use whatever data structure they please and can make it very easy or very difficult to locate data in their system. Even if every vendor tried to create useful Web services interfaces to their system, chances are no two interfaces would be alike and connecting two dissimilar systems would require hours and hours of custom programming. Some of the more farsighted members of our industry foresaw these problems, and three years ago they used this web site to call for a standard information model. ASHRAE answered the call, and began gathering input from facility engineers, equipment manufacturers, government agencies, and universities. They used this information to develop a standard for using Web services in building automation systems. This standard covers the types of data to be exchanged, the path used to locate the data, and attributes of commonly used data objects such as analog inputs or binary outputs. The services required to read or write values are defined, as well as services needed to obtain information about the available data or to return error messages if a service fails. The standard covers arrays as well as scalar data, making it particularly useful for handling trend logs.

Because this standard is designed for use with Building Automation Systems, it was developed by the technical committee that is in charge of standards for Building Automation Control networks, i.e. the BACnet committee. Once approved, it will become an addendum to the BACnet standard, which means it will also become an ANSI, CE, and ISO standard. Naturally the standard is compatible with the BACnet protocol, but it is not limited to BACnet. Indeed, one of its most useful applications may be to serve as a standard for exchanging data between building automation systems using different protocols. Web services could be an ideal way to make a “top end” connection between systems running BACnet, LonWorks, MODBUS, or any proprietary protocol. Engineers would not have to learn the details of each individual protocol to program the connections, they would only have to understand the Web services standard. A Web services connection would also avoid the problems with incompatible baud rates, wire types, proprietary communication chips, and all the other issues that can come into play when a gateway is used to connect dissimilar protocols. (See Figure 3)

Figure 3: Web services used to integrate BAS running dissimilar protocols,
and to connect to a mainframe computer over the Internet.

Since Web services have quickly become the standard for B2B communications, it’s only natural to wonder if they will they replace BACnet, LonWorks, and other protocols within the BAS. That’s not likely, for several reasons. To begin with, no one has developed a set of Web services that covers all the functions needed by a BAS. Broadcasts, alarms, time synchronization, backup and restore – there are a host of BAS functions that simply are not covered in the proposed Web service standard. Certainly such a standard could be developed, but it would in essence become one more BAS protocol fighting for acceptance in the marketplace. It would not be a protocol that was well suited for a BAS because Web services require more “overhead” than most BAS controllers can provide. By definition, Web services use XML to communicate over an IP network. IP networks are great for connecting PCs, web servers, and other high-end computers, but it would be very expensive to run an IP network to every unit heater, VAV box, and exhaust fan in a building. Similarly, XML is a very “verbose” way to package data. It’s designed to be human understandable, flexible, and self-documented. These characteristics also mean it needs to be processed by a powerful computer and transmitted over a high-speed network. This is beyond the capabilities of the price-sensitive controllers typically used for small HVAC equipment like VAV boxes. This may be a temporary limitation, as inexpensive microprocessors gain power and speed with each passing year, but since existing protocols like BACnet are already developed, are a more efficient way of integrating controllers, and are open for use by any equipment manufacturer there is very little incentive to switch these controllers to Web services.

When you try to integrate with systems outside the BAS, such as the local utility system, the situation changes dramatically. To begin with, the systems you are trying to integrate with are not using BACnet, LonWorks, or any other building protocol, and the people who manage these systems have no interest in providing a special connection for a BAS. They would much rather provide a general-purpose interface that can be used by any external computer system. Their system is already running on a high-end computer connected to a high-speed IP network, which is exactly the situation Web services were created for. The computers and the networks have the “horsepower” to handle Web services. There will probably be certain amount of custom linking, if not custom programming, required to make the connections, but the self-documenting characteristics of XML simplify the programmer’s task. Chances are the programmer is already familiar with Web services from previous B2B integrations, which further simplifies the job. (A customer in Texas who was contracting for a custom interface between their BAS and a billing system found the contractor cut their price in half when they learned the BAS supported Web services.) The addition of a new ASHRAE standard to the Web services world promises even greater simplification, using IT technology and the foundation of BACnet to take building automation to the next level.

1. BSR/ASHRAE Addendum c to ANSI/ASHRAE Standard 135-2004 Public Review Draft, American Society of Heating, Refrigerating, and Air Conditioning Engineers (ASHRAE), www.ASHRAE.org

Steve Tom, PE, PhD, is the Director of Technical Information at Automated Logic Corporation, Kennesaw Georgia and has more than 30 years experience working with HVAC systems. At ALC Steve has coordinated the training, documentation, and technical support programs, and frequently works with the R&D engineers on product requirements and usability. Currently Steve is directing the development of www.CtrlSpecBuilder.com, a free web-based tool for preparing HVAC control system specifications.

Prior to joining Automated Logic, Steve was an officer in the U.S. Air Force where he worked on the design, construction, and operation of facilities (including HVAC systems) around the world. He also taught graduate level courses in HVAC Design and HVAC Controls at the Air Force Institute of Technology.

Events	Want Ads
Our Sponsors	Resources