The Dream

A man arrives in the dead of night to his place of work; he swipes his access card on the front door and is let in. Sensing that someone is in the building, the system turns the HVAC system to standby, calls the elevator to the ground floor, lights all (and only) the corridors to his office, sets his office temperature to his preferred level, and enables the PA to play his preferred type of music...This dream has been told in the building control circles for almost two decades.

To almost any user of buildings, the benefit of such a system is obvious when depicted in such a simplistic manner. Why is it that years later, these "dream systems" are only found in a handful of buildings? The dream buildings that do exist are typically demo systems or follies of building owners who spent such a fortune on these systems that many might regard them as having more money than sense.

What is the impact of such a vision to HVAC-centric designers, engineers, operators, and facility managers? The responsibility of these professionals is the maintenance of comfort and energy - not lights, access, elevators, and music!

The term "building automation" suggests the process of automating a building's systems; automation should be able to facilitate the coordinated interplay between all of the systems in the building if it is going to provide the maximum benefit to the owner or occupier. After all, a lighting circuit is logically no different from a fan (each is a digital output), and an occupancy signal is an occupancy signal, whether it comes from the access system or some other occupancy detector.

The dream described above has been shared over the past decades by many of the early adopters in the HVAC industry: manufacturers eager to provide their customers with more value from their systems, and contractors who are rapidly becoming integrators. They see that if they can provide additional benefits to their customers, they would be able to retain those customers. For those who have delivered such solutions, it has been an incredibly effective way to increase business and retain loyal customers.

For years, technology was a clear barrier. In the 1980s, it was simply too hard to connect these systems with each other; the only method available was volt-free relay contacts which are very inflexible and expensive. The early '90s saw serial data communications as the way to make systems talk to each other; with the promise of RS232 as the savior. Though elegant in theory, such system-to-system connectivity proved cumbersome as integrators fought with different proprietary protocols, incompatible versions, and expensive project-specific solutions.

Seeing an opportunity for a standard method to connect systems, numerous technology groups embarked on the development of standards. There was a time in the mid-'90s when dozens of standards were being developed and promoted, but for the most part they were not compatible with each other - that would have made life way too easy!

The Technology

At the turn of the century, there were basically four contenders remaining for the role of connecting devices and systems together in buildings: Modbus(tm), Konnex (EIB), LonWorks(tm), and BACnet(r).

ModBus was originally designed by the industrial controls industry and is typically used for device-to-device connectivity, primarily for devices such as diesel generators, UPSs, and PLCs (programmable logic controllers). While it is likely to remain in use for some time to come, it has no likelihood of system level interconnectivity. ModBus was not designed to do so.

Konnex, an association created by the merger of EIB, BatiBus, and ProfiBus, is primarily a European initiative supported most significantly by the Siemens conglomerate in Germany. Again Konnex has little to offer the system-level solution, and it does not seem to have much energy or support anywhere other than Europe.

That leaves LonWorks and BACnet, both with a great deal of support globally and both approaching the problem at a system level (to a differing degree) as well as at the device level (also to differing degrees). This article is not intended to be a comparison of LonWorks and BACnet, but it makes the presumption that in the North American market at least, both of these initiatives will remain alive for some years to come. There is simply too much momentum for either to be dismissed overnight.

The wild card is the technology the building industry is gaining from the IT and network industries. Propelled by the same need for standards, the Internet was born to be the ideal integration network protocol that today is able to connect millions of devices across the globe. So, why is it not used more in buildings? Why is the Internet (or TCP/IP to be more accurate) not the answer to all of our connectivity problems?

The main reason is that TCP/IP is purely a network protocol; it has no knowledge about the meaning of the data and information that travels on it. Its responsibility is simply to carry a packet of information (a series of ones and zeroes) from one device to some other device 6 ft away or on the other side of the world. It does this very reliably.

TCP/IP can be compared to a piece of copper wire connecting two devices. The copper wire knows nothing about the meaning of the signal it is carrying; it only knows about electrons going from one end to the other. To continue the analogy, TCP/IP's routers, hubs, and switches can be compared with connectors that connect pieces of wire to each other, and neither has any knowledge of the meaning of the information that travels through them.

When a webpage is displayed on a browser, TCP/IP carries the packaged information from the server to the browser, but it is HTML (hypertext markup language) that actually describes how the information is to be displayed on the screen for the viewer's consumption. HTML is designed to display information for humans. It deals with text size, background colors, hyperlink hotspots, and many other visual attributes so that the human eye can absorb the information and make use of the information, similar to how the eye absorbs paper such as this magazine. HTML is very well suited for user interfaces for building systems, but it is not at all useful for device-to-device or system-to-system communication in the HVAC world.

Enter XML

In a similar way that HTML describes information for human visual consumption, XML (eXtensible markup language) is a new protocol whose job is to describe information not necessarily destined for human visual consumption. XML describes the meaning of data in a manner that two devices on a TCP/IP network can understand. Thus, it is XML that holds the key to the use of the Internet and other TCP/IP networks for building controls. As an aside, XML is also the de facto technology being used by many other industries to carry its data across TCP/IP networks such as the Internet.

Because XML is so ideally suited for intersystem and interdevice communication, it should be the ideal technology for communication between HVAC controllers as well as integrating building systems, right? Not so fast! There is one small problem still to be solved. XML is a method and technology to describe data, but for it to be useful carrying HVAC and other building relevant data, all the players in the building systems industry must first agree on the description and meaning of the data that is being carried using XML. Without such agreement, XML will be used in many different 'proprietary' manners with little or no possibility for multivendor systems to work together.

Efforts in this area are currently underway, and a group of industry leaders embarked on this effort in April 2003, as part of the BuilConn Forum in Dallas. Supported by the Continental Automated Buildings Assoiation (CABA) along with the participation of engineers from the LonWorks and BACnet communities, this group is driven by a need to define the use of XML in buildings.

Will this group succeed? The answer has to be yes. The prospect of not being able to use TCP/IP networks to exchange HVAC and building system information cannot be acceptable for our industry. The benefits are simply too significant for this initiative to fail.

So, what of LonWorks and BACnet? They will continue to have a very important role in buildings; TCP/IP networks simply cannot scale connectivity down to the smallest device level such as sensors, actuators, light fittings, intrusion, or fire and smoke detection devices. LonWorks and BACnet also have something that the XML initiatives need: the information definitions that both groups have worked on for many years including LonWorks' LonMark profiles and SNVT (standard network variable types) definitions and BACnet's BIBBs (BACnet interoperability building blocks) and objects.

So given some time, TCP/IP networks such as the Internet will carry XML data with useful building systems information based on some combination of LonMark and BACnet object definitions. Is this the end of the story? Not quite yet; there is one very significant challenge still to overcome, a challenge that if not addressed by the industry will negate all of the benefits of the technology we have available.

The Discipline of 'Integration'

There are many different definitions of integration, but one aspect of integration is agreed to by all: it is the process of connecting two or more systems that were not intended or designed to be connected. When you integrate two systems together to effectively become one system, you are at the same time integrating the suppliers of the systems, and more importantly, the users of the systems.

Take a simple case of integrating access control to HVAC for the purpose of exchanging simple occupancy information so that the two systems can use the same source to indicate if the building or room is occupied. The traditional approach is that the HVAC system is provided by one vendor and the access system by another, where each vendor's objective is to install its respective system at some reasonable profit level, complete the project, and get out. Unless the connectivity between the two was embedded in the specification provided to both vendors, a great deal of fingerpointing can occur if the two vendors are not working together. Before the systems are even up and running, a significant potential for failure and disappointing commercial results exist for one or both vendors, not to mention the building owner.

Now consider the challenge on the user side, this time in a scenario of integrating an access control system with the HR department. The benefits are easy to see: if an employee is laid off (an HR task), the HR department, making the adjustment to its database, should automatically cancel the employee's access control card. At the same time, it should be possible for the IT department to disable the employee's network access, disconnect his voice mail, disconnect temperature and lighting control to the employee's old (and unused) office, etc.

A problem exists in the organizational structure on the enduser's side. In the above example, actions taken by one department affect numerous other departments within the same company. If this scenario is to work, then all of these systems need to be connected together, and appropriate procedures and processes will need to be in place to handle any changes that will have a huge impact throughout the corporation.

And for an HVAC system provider to sell, design, and install such a system, does it mean that they have to deal with the HR and other departments? The HR department has just become an "input" to the HVAC system used to control the comfort control of an office!

Successful HVAC engineers who have been involved with integration know that HVAC and integration are two separate disciplines, as different as HVAC is to access control.

Savvy building owners and consultants also know that the function of integrating all the building's system elements needs to be handled by professionals who can focus on making all of the systems work together as one. These individuals also know they are to be the enduser's single point of contact for the multitude of disciplines involved in the different systems being installed in the building.

How Should the HVAC Industry Proceed?

Up until now, the HVAC industry has been able to keep itself in a silo focused on delivering comfort systems and energy management. The current economic climate together with the efficiencies brought about by technology and the expectation of endusers and occupiers (brought about mainly by the Internet) is putting significant pressure on the HVAC industries to deliver more.

The industry can behave in one of two significant ways:

Be reactive. In this scenario, the HVAC industry can simply carry on as normal. After all, buildings will still need comfort control and energy management. The industry can become even more efficient at providing these solutions; reduce costs of its products and services and maintain a strategy of proprietary development of technologies and standards as a way of securing customer loyalty.

Eventually some other group of people or industry - most likely the IT department or industry - will provide the whole building solution, technology, and systems into which the HVAC system can somehow plug into, much like a number of other services found in buildings such as plumbing and electrical.

Be proactive. In this scenario, the HVAC industry takes an active participation in the evolution of the integrated and intelligent buildings of tomorrow. Consider that almost all commercial buildings in the Western world (as well as many in the rest of the world) have comfort control, without which occupants of the building would be unwilling to tolerate it, or would at least be unproductive. Comfort is, after all, one of our most basic needs, and until recently, comfort was the most significant element of building systems. Recently, security concerns have made comfort and safety equals in terms of importance to occupants.

By taking a proactive approach, the HVAC industry can play a very significant role in defining how the buildings of tomorrow are designed and constructed. HVAC systems affect almost all areas of a building and can significantly impact other building systems such as life safety, lighting, IT, and communication equipment.

The difference between the two approaches above depends on the HVAC industry's acceptance of the fact that the future of integrated, intelligent, and advanced buildings is an unquestionable reality.

When Will the Dream Become Reality?

One day, the dream outlined at the beginning of this article will come true. There is absolutely no doubt about that. The only questions are when, how, and by whom will such systems be delivered?

The HVAC industry is further along in understanding the intelligent building than any other discipline in the building system field. The security industry is totally focused on security; the life safety industry is similarly (and understandably) focused on protecting lives; and the lighting industry is more concerned about the aesthetics of illumination, while other industries found in buildings are relatively small compared with HVAC. This leaves only the IT industry, which is always looking for ways to expand its empire!

So will the HVAC industry be subservient to the IT departments of the future? Only time will tell. ES