Can building automation systems overcome interoperability problems to assert control over our offices, hotels, and airports?
If only you could work in a building where you could keep your office as you like it, icicle-cold, while your neighbor turns hers into a sauna. If only your office lights and computer could flicker on every morning when you swiped your security card in your building's lobby, so that you would be ready to work when you sat down with your first cup of coffee. And while we're on this flight of fancy, wouldn't it be reassuring to know that your building would shield you from harm in the event of an earthquake, or even a chemical or biological attack?
Buildings could do all these things and more, if only they had brains.
As it happens, a few buildings already do, and they're getting smarter. The brainiac of buildings, the U.S. Pentagon, opened for business on 12 September 2001, the day after terrorists crashed a plane into it. Thanks to a network of digital sensors and controllers that let operators close dampers and turn off fans, the fire from the crash was confined to one wedge of the building. [For more details, see "Saving the Pentagon"]
The Pentagon's costly, proprietary automation system isn't likely to find its way into ordinary office buildings any time soon. But that doesn't mean that we'll be stuck with "dumb" buildings for the foreseeable future. The good news is that two open communications standards for building automation are finally taking hold in the marketplace. One, known as BACnet (for Building Automation and Control Networks), has been endorsed by the American Society of Heating, Refrigerating, and Air-Conditioning Engineers, Atlanta, Ga. The other, called LonWorks, was developed by Echelon Corp., San Jose, Calif. ("Lon" stands for local operating network.) These two standards have the best chance yet to turn the tide of the long, disappointing history of smart building control and automation.
In the meantime, technologies like those deployed in the Pentagon, along with some even more advanced, are being tested in government and university research labs. Among other things, they'll let future buildings minimize damage when an earthquake hits by automatically changing the way weight is carried by internal structures. Or upon detecting a harmful chemical substance in the building's air ducts, the system would instantly seal them off and contact authorities [see "The Road Ahead"].
For now, though, efforts to make buildings smarter are focusing on cutting costs by streamlining building operations like air conditioning and lighting. Building automation is critical to these efforts, mainly because it could reduce the annual operating costs of buildings by a whopping 3.6 to 7 cents per square meter, according to a 1999 study conducted by the U.S. National Institute of Standards and Technology [see "Getting a Handle on Costs"].
Towers of Babel
If building automation is such a fabulous boon, why hasn't it caught on everywhere? Start by considering that the term building automation is a catchall for a sprawling category of control and communications technologies that link building systems that are typically controlled separately—like electrical distribution, fire, security, heating and air conditioning, and elevator and escalator systems. To be effective, any automation system must enable all these mechanical and electrical systems to work from a single building control point.
That's a tall order because those systems, and the digital controllers that run them, are made by scores of manufacturers, use proprietary hardware and communications protocols, and may even be administered through special workstations that are almost impossible to integrate into a single control setup.
BACnet and LonWorks take different approaches to integrating these diverse systems. BACnet, developed in the mid-1990s, is a communications-only standard developed for a building's mechanical and electrical systems, particularly heating, ventilation, and air conditioning (HVAC). Companies that manufacture such systems are now beginning to make devices that "speak" BACnet rather than, or in addition to, proprietary control languages.
LonWorks, on the other hand, combines a communications standard, LonTalk, with a piece of hardware, the Neuron Chip from Echelon Corp. Born in the early 1990s, LonWorks has already caught on in the transportation and utilities industries and has been adapted for buildings; it is installed in more buildings worldwide than the BACnet standard.
Fortunately, the two are not mutually exclusive. BACnet can let Echelon's Neuron Chips interact with building control devices made by other manufacturers.
While LonWorks may have a head start in some industries, BACnet is poised to challenge LonWorks as a preferred way to handle building control. Backed by a powerful trade association, it was specifically designed for building automation systems and was adopted as Standard 16484-5 by the International Organization for Standardization (ISO, Geneva, Switzerland) in January 2003.
The BACnet standard comprises rules for data communications for hardware and software used in building control. At its heart are 23 virtual object types that together represent much of the functionality a building needs to operate. These virtual objects, such as "analog input," "binary output," "schedule," and "calendar," can be grouped together to represent the functions of real building systems. The objects are characterized by a set of properties that are used either to represent information about the operation of the system or to provide operating parameters and commands to the system.
A room air-conditioning system, for example, might have an "analog input" virtual object with a property that tells the HVAC system what the temperature sensor in the room is reading at the moment. Another of the air conditioner's virtual objects might be a "schedule" with a property that would set the system's set point to 20 C at night.
Because the standard is compatible with the Internet protocol (IP), BACnet objects and devices can be viewed via standard Web browsers. Its workstation may be in a dusty basement, but a maintenance engineer sitting in front of an Internet-connected PC in London could conceivably set lighting, temperature, and escalator speeds in a mall in Montreal [see " Remote Control via the Web"].
But as valuable as BACnet is in letting a building communicate to maintenance engineers and to the outside world, it also makes it possible for devices inside a building to talk to one another. BACnet defines a set of message types that enable data to be shared among the different devices in a building automation system, resolving conflicts when two different messages are being received by a single device.
For example, when a smoke detector senses smoke, BACnet defines the way a signal from the smoke detector is relayed to a switch that would close off the dampers in a ventilation system, preventing smoke from spreading throughout a building. Furthermore, BACnet allows users to set up to 16 levels of priority for command messages coming to, say, damper controllers from building automation software, such as energy management, fire safety, and comfort-level programs.
Fire, for instance, might have the highest priority level of 1, comfort 10, and energy management 5 [see " Setting Priorities"]. So if it's cool outside, the energy management program will send a message to start a fan and draw in outside air to save money on air conditioning. If there's a fire, the fire safety program will send a message to stop the fan. If it's a cool day and a fire breaks out, the fire safety message will have priority, even if the energy management message arrives afterward.
A developer's dream
This setup of priorities is an important distinction between BACnet and LonWorks, according to H. Michael Newman, manager of the utilities computer section at Cornell University, Ithaca, N.Y., who chaired the committee that developed the BACnet standard. "In LonWorks, the last command wins, no matter when it arrives," says Newman. "With BACnet, you can assign priorities based on the job and situation, and they're enforced by the protocol."
BACnet is compatible with a variety of networking standards, including Ethernet, ARCnet, and LonTalk. Almost anything that runs behind the walls of a building—twisted-pair copper, coaxial cable, fiber optics—can accommodate BACnet systems, an advantage over proprietary control systems that typically work with only one kind of cabling.
Coupled to an ARCnet network, BACnet lets technicians set a limit on how long a device will have to wait before it can send a message on the network—important for time-critical applications, like fire safety. In contrast, LonTalk isn't compatible with ARCnet.
Often makers of BACnet-based building systems add optional properties to standard object types to make them run more efficiently or effectively. For instance, in the temperature sensor example, an HVAC company might add a property to the "schedule" BACnet virtual object type that would have the sensor send its temperature information to a central database periodically. The data can then be analyzed to advise owners on how to run their buildings to maximize energy efficiency and slash expenditures.
That capability is fundamental to BACnet because it means engineers can easily develop new applications and functions within the framework of the existing standard. Some developers say this feature gives BACnet an edge over LonWorks and vendor-specific standards.
Certification of BACnet-compliant devices has been under way since 2001, but so far only a handful of controllers, for things like thermostats and fans, have been certified. Nevertheless, the standard's backers estimate that thousands of buildings in 80 countries are using BACnet-compliant automation systems. It's being deployed in numerous clusters of buildings, including some on the Pennsylvania State University campus in University Park and in a group of new residence halls at Cornell University, as well as in Cornell's new nanotechnology research center.
LonWorks, developed by Echelon as a generic platform for networking embedded devices used in the transportation and utilities industries, is coming to be widely implemented in buildings as well.
Echelon's partners, Cypress Semiconductor, STMicroelectronics, and Toshiba, make the Neuron Chip, the system-on-chip microcontroller used with LonTalk, LonWorks' communications protocol. Different chip versions share the same basic features in various combinations: processor cores, memory, communications, and I/O, as well as sensors, actuators, and transceivers, all in the same package. Depending on the features and quantity, chips usually costs US $3 to $5 each.
In the LonWorks network, the Neuron Chip is the basic interface between each device being controlled and the central control system software. The chip sends and receives data over a wired connection (or any other medium, including RF, infrared, fiber optics, and coaxial), as well as to and from a Web server, the i.LON 100, which straddles the building's LonTalk network and the Internet. For example, a lighting fixture might have a twisted-pair wire connected to a lighting controller, which would contain a Neuron Chip and a twisted-pair transceiver and may control several fixtures.
With LonWorks software applications, building systems are controlled via networks of standard objects made up of so-called network variables (NVs). The NVs are lines of computer code that define inputs and outputs of devices, such as temperature, a switch value, or an actuator position setting—all analogous to BACnet standard object types.
To control a light, say, the switch would be assigned NVs that correspond to "on" and "off." Programming the network with a graphical tool, an engineer binds the light and the switch together by drawing a virtual wire between the two objects. LonWorks networks support one-to-many and many-to-one binding of NVs, regardless of the function of the actual devices (this binding of NVs is similar to the grouping of standard object types to make a BACnet device). In this way, the light switch's "on" NV could kick off actions in one or even hundreds of other devices—of any sort, in any part of the system—directly, without intervention from a centralized controller.
As to whether LonWorks networks allow users to assign priorities to certain commands—to turn that fan off in the event of a fire, say, as previously mentioned, or to close a damper—Steve Q. Nguyen, Echelon's director of corporate marketing, replies that the system does have some priority-scheduling capabilities.
"Instead of binding equal-priority outputs to a single input, a damper would include a fire emergency input that would be acted on by the device as a higher-priority action, overriding even the scheduling defined by an i.LON server," Nguyen says. Another option would be "requiring that an 'OK' value be sent periodically by the smoke control system, without which the damper would assume a default safety position," he adds.
Like BACnet data, data from a LonWorks system can be displayed on standard Web browsers.
Currently, LonWorks leads BACnet in the number of devices and products that have been certified, more than 350 at last count, according to Nguyen, who adds that other not-yet-certified LonWorks products number in the thousands. Worldwide, some 30 million Neuron Chips are deployed: in monitoring and controlling systems in 1100 7-Eleven convenience stores in Japan; the huge Le Coeur Défense office building complex in Paris, Europe's largest installation, with some 17 000 devices [see photo, below] the Sears Tower in Chicago; and the Bellagio Hotel and Casino in Las Vegas, Nev., among others.
BACnet and LonWorks have come far in the last 10 years, but neither is yet in a position to end the long, stubborn history of proprietary turf battles in building automation. Vendors of mechanical and electrical systems still make devices that communicate using their own idiosyncratic protocols. Even when systems are based on BACnet or LonWorks or both, manufacturers can still program devices to preclude free-flowing data exchange with other vendors' equipment. For instance, with BACnet-compliant systems, adding (or failing to fill in) optional fields when defining a BACnet object type can make data sharing among devices trickier.
For the LonWorks platform, some makers of controls choose not to design to the standard's guidelines, as defined by a group of companies that has been dubbed the LonMark Interoperability Association. Some even create intentionally closed types of LonWorks-based products, making integration of the products more difficult.
Hope for an ultimate resolution to interoperability problems might lie with that paragon of interoperability, the World Wide Web, which is transforming the interface of building control. As more building owners demand remote access to building systems, manufacturers will have to make their systems accessible through Web browsers instead of proprietary workstations—something that BACnet and LonWorks already allow.
For example, Johnson Controls Inc. (Milwaukee, Wis.) has teamed with Microsoft Corp. (Redmond, Wash.) to use the latter's .NET technology so that Johnson's HVAC, lighting, and other building systems can be monitored and operated online from any computer. Yet Johnson's controllers speak a proprietary language called Metasys, which would make it technologically tricky and expensive for a building owner to implement BACnet or LonWorks, or to replace Johnson's equipment with another manufacturer's.
It's precisely plug-and-play operation of systems made by different vendors that frustrated owners are beginning to demand—and that's the nut that both BACnet and LonWorks are helping to crack.