Browse through any HVAC magazine, wander the aisles of an HVAC trade show, or visit with your favorite HVAC Controls salesman and you're bound to hear a lot of talk about web-based control systems. Ask some of these manufacturers to show you a working system and you're liable to suspect that all this talk about web-based control is just that. All talk, and no substance. Actually there are operational web-based control systems in use today, and judging by the details some manufacturers are putting in their ads and interviews, a few more systems are about to make the transition from "vaporware" to products. Judging by these same sources, there are significant differences in the designs of these products. A detailed description of these differences would fill many pages, but there are three major areas where different design philosophies have shaped the products: (1) how much control is provided via the browser interface; (2) how the web pages are generated; and (3) how well the product supports open protocols.

1. The first area is key to everything that follows. Many manufacturers view web access as an "accessory" to their workstation software. Their system will display key sensor readings on a web page, and maybe let the operator adjust a setpoint or two, but for anything more complex the operator needs to use the proprietary workstation software. System configuration, schedules, trending, alarms, reports, and other "normal" features are not available through their web interface. When a manufacturer takes this approach, each new feature that is added to the web interface represents a significant additional workload on the developers. It soon becomes natural for them to ask "why do users need to do this through the web?" Since their proprietary workstation software already provides this tool it's easy for them to decide it isn't necessary to provide this feature over the web. As a result, their web system's feature set tends to remain very limited.

Alternatively, a few manufacturers have developed web systems that replace their proprietary workstation software. Like the Spanish explorer, Cortez, who burned his ships off South America to show his troops there was no turning back, these manufacturers have forced themselves to develop a complete toolkit for their web-based system. For them, the question "does the user have to do this through a browser?" becomes an edict "the user will be able to do this though a browser!" Not surprisingly, the web-based control systems offered by these manufacturers provide a much richer environment than those that are merely intended as an adjunct to a traditional workstation-based system. Trending, scheduling, alarming, reports, program changes, memory downloads - all can be accomplished through a browser. It also follows that these systems provide a better platform to support the new generation of "gadgets," such as WAP cell phones, because these devices are also based upon a browser interface.

2.  The second major area where the different manufacturers' philosophies become apparent is in the methods used to generate the web pages. There are many web authoring tools on the market today that can be used to generate web pages for a building automation system. The problem is that hand crafting individual web pages for even a moderately sized control system is a very time consuming process. The customer is ultimately the one who pays for the labor required to create these pages, whether the control system manufacturer creates these pages as part of the control system design or merely gives the tools to the user so he can create his own pages. Maintenance can also become a costly proposition when hand crafted pages are used. If every change to a sequence of control requires manual editing of the associated web pages, costs can skyrocket. Also, there is always the danger of having the web pages get out of sync with the actual control system. A better approach is to develop a system where the web pages are automatically generated by the same tools that are used to engineer the control system. Write a control program for, say, a VAV Air Handling Unit and the web page that provides the user interface to this unit is created automatically. Make a change to this control program and the web page is automatically updated to reflect this change. Here again, systems in which the browser serves as the primary user interface may have an advantage because these systems are designed from the ground up to be web-based. For these systems, the web pages are not an afterthought - they are an integral part of the system design. Since the manufacturers of these systems must provide a way to access every single element of their system through a browser, it is in their own best interest to automate the creation of web pages.

3. The third major area in which the manufacturer's philosophy shows itself is in the support for standard protocols. Web-based control systems aren't any different than other systems in this regard. The degree to which a control system supports standard protocols has a dramatic effect upon its ability to interact with a control system made by a different manufacturer, and it also affects the freedom the customer has to compare manufacturers when the system needs to be modified or expanded. Today the concept of interoperability has become a "motherhood" issue in the marketing of control systems. You'd be hard pressed to find a single manufacturer who says they're against interoperability. However, the definition of "interoperability" varies greatly from one manufacturer to another. BACnet, LonWorks, MODBUS, and other protocols are often touted as the "one true path" to interoperability. At the controller level, there is not a clear winner today. The most interoperable system may be the one that supports all of the popular protocols. At the workstation to controller level, however, there is a clear winner. That winner is BACnet. This is because BACnet is the only open protocol that defines a standard way to handle all of the higher workstation level functions, such as trending, alarming, scheduling, and file transfers. A workstation that uses BACnet to implement these functions will be able to interoperate with other systems that support these BACnet services. This is true whether the workstation is web-based or not. A web-based system may have a slight advantage in this regard because it will of necessity support Internet standards such as TCP/IP, HTML, and XML, but it is important to realize that these standards do not in themselves guarantee interoperability. TCP/IP, for example, is the standard used by the Internet for packaging, addressing, and delivering information "packets." TCP/IP imposes no standard upon the information contained in these packets. It could be a BACnet object or Japanese Haiku poetry. The content makes no difference to TCP/IP, but it definitely makes a difference to the control system that receives this packet! Similarly, HTML simply defines the way information will be presented on your computer screen. While this may provide a degree of interoperability if you are simply viewing a graphic page from another system, it doesn't help much if your system is receiving an alarm from another system and needs to decide what actions to take in response. XML is a system for creating and documenting data structures. It provides an excellent platform upon which to create an interoperable system, and ASHRAE's BACnet committee is in the process of defining an XML-based structure called "BML." By itself, however, XML does not define a standard way of communicating alarms, schedules, setpoints, or any of the other data required for a true interoperable system. These Internet standards facilitate the transfer of data between control systems, but if the data being communicated needs to be interpreted by the other system it has to be packaged in a standard building automation protocol like BACnet.

The three major areas just described - the functionality available through the browser interface, the way web pages are generated, and the interoperability of the systems - represent major differences between various manufacturers' web-based control systems, but they are by no means the only differences. Ease of use, security, control of operator privileges, and many other features can vary greatly from one product to another. Clearly all web-based control systems are not created equal! To help engineers distinguish "vaporware" from products, and to compare the functionality of different systems, we have created a "checklist" of questions you should consider when looking at web-based systems. We suggest that you weight the answers according to the importance each feature holds for you. You may wish to add your own questions to this list, as well. With this as a starting point, you can go beyond the "talk" and get to the real substance of web-based control systems.

[Click Banner To Learn More]

[Home Page]  [The Automator]  [About]  [Subscribe ]  [Contact Us]