Steve Thom, Chief Technical Information Officer, Automated Logic Corporation,
has been working with HVAC systems for over 30 years. At ALC, Steve served as the program coordinator for training, documentation, and technical support, and worked with R&D engineers on product requirements and usability. Steve currently leads the development of CtrlSpecBuilder, a free web-based HVAC specification tool.One of the lessons I learned from my mechanical design course was the concept of «degrees of freedom.» If you build a mechanism with too many degrees of freedom, it will lock into incapacity, like a piece of string from a tangled knot with no end in sight. If you build a mechanism with too few degrees of freedom, it will become a rigid structure incapable of movement. If you build a mechanism with the right number of degrees of freedom, it will operate smoothly with precise, predictable results.
Web services today have too many degrees of freedom in their own way. In general, they can be a very powerful tool for integrating all the systems automated in a building into a single, well-functioning mechanism. They can also be used to communicate and coordinate with other higher-level computer systems, such as metering systems, energy supply systems, and weather forecasting systems.
There are currently no uniform rules on how to use Web services for building automation systems. This gives programmers virtually unlimited freedom to use Web services as they please, but at the same time this condition makes Web services a very expensive tool to use. Each new integration process requires many hours of special programming.
Fortunately, ASHRAE has created Web services as an extension to the BACnet standard framework, adding them to the building automation toolbox. This standard (BACnet) is flexible enough to take full advantage of the strengths of Web services, but at the same time, it is structured in a way that makes it much easier to use Web services to integrate systems in a building. Simply put, BACnet has the right amount of freedom.
What are Web services?
Web services are a standardized way for two computers on a network to exchange data. They can be used to read and write data from applications between computers. Web services can also be used to cause another computer to run a program or routine that produces data needed by the requesting computer.
Here's a simple example: Many people use weather forecasts on their computers. With the help of these capabilities, the weather forecast is provided by Web services installed on the computer that collects the weather data. Your computer sends a request to the weather computer, for example, asking it to generate a three-day weather forecast for zip code 12345, detailing outdoor sports conditions and airport conditions (or some other query term). Web services are based on information technology standards such as XML and SOAP, but you don't have to understand them to use Web services. The main thing is that the IT community understands them, and that Web services are widely supported by the computer industry.
How widespread are they?
First, it should be noted that Web services have been adopted as a standard by companies such as Microsoft, Apple, Sun, Linux, IBM and many others. It is not always easy for this group of companies, who are competitors to each other, to come to an agreement. So, if they do agree on some technical points, such as Web services, they immediately become an industry standard. Each of the companies has added a little of their own to the solutions: Microsoft calls its developments .NET, while IBM calls theirs WebSphere, but internally they are all based on Web services.
Web services have been used for several years in business-to-business (B2B) communications and have quickly become a widely accepted standard. Notable applications include Amazon, Google, and Microsoft Passport. The state of New Mexico in the United States uses Web services to create a single portal (website) where users from different government agencies can access information and services.
In the building automation industry, Web services are already being used to import HVAC usage and building energy data into a system for automatically preparing bills for tenants.
They have also found applications in quantification testing, where the energy consumption of similar systems can be compared and “virtual thermostats” can be created that give users control over their office space. These benchmark programs integrate building automation systems with energy systems, using control options based on real-time pricing and calculations for reducing energy consumption during emergency situations.
Universities and other large building complexes are experimenting with using Web services to create interactive web pages that integrate energy consumption data, building maintenance management, billing, accounting, and other operations-related systems. All systems are linked into a single “operations portal,” with a common user interface that provides access to all systems.
Some projects under consideration use weather forecasts to optimize ice-making systems, boilers, and night-time cooling systems. Universities are exploring the possibility of using a central computer with class schedules to automatically apply schedules to HVAC, lighting, and other systems.
If major building automation vendors already support Web services, what is ASHRAE's position?
ASHRAE is preparing a standard way to use Web services to integrate building operation data from different sources. In the information technology world, standards have been developed to implement the Web services mechanism, but these standards do not say anything about the information that needs to be exchanged. An analogy can be drawn with the telecommunications field, where there are standards for telephone systems, but these standards do not prescribe what language can be used to communicate on the phone, or what specific topics can be discussed.
Equipment manufacturers can provide as much and as little Web services support in their systems as they deem necessary. They can also use any data structure they want: they can make the data placement in their systems very simple or very complex. Even if we assume that all building automation equipment manufacturers have tried to create Web services interfaces for their systems, there is virtually no chance that any two interfaces will be similar, and connecting two different systems together will require a huge number of hours of special programming.
Some forward-thinking players saw these problems ahead of time and proposed a standard information model three years ago. ASHRAE accepted the proposal and began work involving facility engineers, equipment manufacturers, government agencies, and universities. They developed a standard for using Web services in building automation systems. The standard covers the types of data that need to be exchanged, the paths for data, and attributes for data from common objects such as analog inputs or binary outputs. Services should perform functions such as reading or writing values found, as well as getting information about the data or delivering error messages if the service is unavailable. The standard covers large volumes of data, particularly by allowing for trending.
Since this standard was intended for use in building automation systems, it was developed by the BACnet Technical Committee. Once it receives public approval, it will become an add-on to the BACnet standard and will automatically become an ANSI (American National Standards Institute) and ISO (International Organization for Standardization) standard. Naturally, this standard is compatible with the BACnet protocol, but is not limited to it.
Indeed, one of the most likely applications of Web services is as a standard for exchanging data between automation systems using different protocols. Web services could be an ideal way to connect at the top level of automation between systems running BACnet, LonWorks, MODBUS, or other proprietary protocols. Engineers would not have to learn the details of each specific protocol to create connections. They would just need to understand Web services.
Connecting systems using Web services helps avoid problems with incompatible data rates, network connection types, proprietary communication chips, and other problems that can arise when using gateways to connect different protocols. Since Web services have quickly become the standard for B-B communications, it is natural to assume that they could replace BACnet, LonWorks, and other building automation protocols, but this is not the case for several reasons. For starters, no one has yet developed a set of Web services that provides all the functions needed for a building management system. Messaging, alarms, time synchronization, backup and restore are all building automation functions that are not provided by the proposed Web services standard.
Of course, such a standard could be developed in the future, but it would essentially be another building automation protocol that would have to prove its worth in the marketplace. And it wouldn't be a perfect solution, since Web services require more resources than most existing automation controllers can provide. By definition, Web services use XML to communicate over IP networks, which are great for connecting computers and servers, but creating an IP network for every device (e.g., a boiler, a VAV unit, an exhaust fan) would be extremely expensive.
XML is a multi-layered data transfer language. It is designed to be easy for users to understand while remaining flexible. These characteristics mean that it must be used by a powerful computer and transmitted over high-speed networks. This is beyond the capabilities of controllers used in small HVAC systems (such as VAV units), where they are especially sensitive to price increases. This limitation may be temporary, as inexpensive controllers increase their power and data transfer speeds every year, but once a protocol such as BACnet has been developed that is more efficient for integrating controllers and is open to all equipment manufacturers, there is little incentive to connect equipment via Web services.
When you need to integrate with systems outside the building, such as the local power system, the situation changes dramatically. First of all, the systems you are trying to integrate with do not use BACnet, LonWorks, or any other building automation protocol. The people who manage these systems are not interested in providing special capabilities for communicating with building management systems. Their goal is to provide a basic interface that any external computer system can use. Their system is already running on a high-end computer connected to a high-speed IP network. This is precisely the situation that lends itself best to using Web services.
Computers and networks have the horsepower to handle Web services. Creating connections using Web services may require significant programming, but the characteristics of XML make the task much easier for programmers. The programmer will likely already be familiar with Web services from previous B-B integrations, which can also make the job easier. For example, one Texas customer who contracted to develop a custom interface between their building automation system and billing system found that the contractor cut the price in half when he discovered that the existing automation system supported Web services. The addition of Web services to the ASHRAE standard holds the promise of further simplifying system integration by leveraging advanced IT technologies and taking building automation to a whole new level.
1. Appendix «c» of ANSI/ASHRAE Standard 135-2004
BACnet, (ASHRAE – American Society of Heating, Refrigerating,
and Air Conditioning Engineers), ASHRAE.org
2. «The Information Model: Key to Integration.» Eric
Creighton and Dave Robin, ALC, AutomatedBuildings, Jan 02
Information from AutomatedLogic Corporation was used in preparing this material.
|
