FIGURE 1: For the most part, this is today's vertically integrated bas. In reality, they are islands of automation. Open devices may actually exist on each island, but communicating with or configuring devices on other islands is far from seamless.

Engineers, however, are a little more skeptical. Being rather conservative to begin with, they aren't necessarily ready to jump on every bandwagon that passes their way.

Interoperability is no different. Some engineers don't believe it can work at all. Some engineers believe it can sometimes work, but not with legacy systems. And still others believe it may be able to work, but are unsure how to approach the whole situation.

They've heard the stories about trying to get systems to talk to one another (the expense, trouble, and confusion); many, it appears, are not willing to put their reputations on the line in order to be pioneers in this area.

The big questions, of course, remain: Is true interoperability possible? Can you tie together all building systems, such as lighting, fire, security, hvac, elevators, etc.? After interviewing scores of industry experts on the subject, the answer is (drum roll)... maybe.

What It Is And What It Isn't

Not to burst any bubbles, but the industry is nowhere near this point - at least, not yet. However the industry, either intentionally or unintentionally, has led many endusers to believe that interoperability really does mean plug and play. This can lead to high expectations, which the industry, including engineers, can't deliver on.

Even though the industry is not there yet, Mike DeNamur, manager of interoperable systems, The Trane Company (Minneapolis), questions whether plug and play is even a good idea. In his estimation, it would, by nature, require a commodity definition of all systems and equipment, including their sequences of operation, data content, and methods of programming.

"This would limit products to the least common denominator supported by all devices, stagnating development and implementation of new ideas and technologies," said DeNamur.

A more realistic definition of interoperability may be the ability of equipment or systems from different manufacturers to share information for the purpose of daily operation. This could include monitoring and controlling point status, viewing and editing schedules, receiving and acknowledging alarms, viewing and editing trend logs, etc.

But even that definition doesn't work for everybody. DeNamur notes that true interoperability is a significant achievement. He likens it to two people agreeing to learn a language they didn't previously know. Each buys a textbook and goes away for a year. When they meet again, the first conversations in the new language will be pretty basic. As they gain confidence and proficiency, they'll advance to more eloquent discussions.

"It's relatively easy today to provide data exchange [point status and control] in an interoperable manner. Unfortunately, while that's a nice accomplishment, it doesn't match up with people's expectations. They expect that they should immediately be communicating with the ease and flair of Walt Whitman or Samuel Clemens," states DeNamur.

Adding to the definition of interoperability is John Huston, P.E., systems integration project manager, Teng and Associates (Chicago). He says it's important to note that when products or systems from one manufacturer communicate with products or systems from another, they must use the same protocol, or language, in order to be considered interoperable. Having the same language allows the sharing of information for the purpose of creating unique control solutions without the need for developing custom hardware, software, or tools. "Interoperable systems do not require the use of gateways," Huston says.

Not An Easy Road To Travel

In an effort to obtain the top spot, proponents of both protocols may be at fault for leading customers to believe that interoperability is easy to achieve. (One person interviewed for this story even referred to them as "BACnet bigots" and "LonMark zealots.")

Clair Jenkins, president of Alerton Technologies (Redmond, WA), says that interoperability is not as easy as some would have you believe.

"There are many in the industry who are misleading people as to how easy it is to hook various systems together and make them work. One must be very careful to understand exactly what he/she is trying to accomplish and test that against the track record of specific vendors and manufacturers of both LonWorks and BACnet," says Jenkins.

Huston also states that interoperability can be a problem if the engineer does not have in-depth knowledge of the technology. He notes that the options must be thoroughly understood before true interoperability can be achieved and the maximum benefits realized. "Anything you don't understand will be a nightmare to accomplish."

"True interoperability depends on a number of issues including the definition and expectations of the system," continues Huston, "the technology utilized [LonMark or BACnet], the products and subsystems integrated in the design, the interaction required between the products and subsystems, the communications media, the network design, phased implementation, future upgrade capability, competitive bids, etc. The primary complication is understanding the options and how all of the pieces fit together."

The biggest problem most engineers run into is trying to tie into a legacy system; that is, the building automation system (bas) that is already in place. Many building owners want to squeeze as much life out of a system as possible, and completely tearing it out for the sake of interoperability is usually not an option. Therefore, engineers must first figure out what is in place and how it will interface with a new system, which is usually the most difficult and expensive part of the job.

Dennis Tuft, senior marketing manager for system integration solutions with Honeywell Home and Building Control (Golden Valley, MN), says that before even attempting to specify a system, engineers need to find out very specifically what's already in place.

"Sometimes that isn't very easy," he adds. "Usually the recordkeeping isn't very good, so engineers need to do an on-site inspection, which is expensive and time consuming. That's one reason why many engineers opt to say, 'We're not going to try interoperability here.'"

He adds that some engineers, who would like to tie a building's systems together but who don't want to spend the time researching the existing system, will just write it into a specification stating that, for example, there is a need for the bas to communicate to a Trane chiller. "That's a recipe for disaster, when you just command it to communicate to a device or interoperate with a device, and you really don't know what's meant by that," notes Tuft.

Trane's DeNamur agrees, stating that by simply saying a system must be BACnet- or LonMark-compliant can be a problem. He says the following three points must be specified:
1. Which protocol and media option is acceptable; for example, "Data communications between global controllers and operator workstations shall be provided using ASHRAE Standard 135-1995, BACnet, over Ethernet local area network."
2. Which data points should be communicated between the systems or controllers; it's easy to provide an interoperability table or point list that defines exactly which points each manufacturer must provide in an interoperable manner (e.g., "The unit controller shall provide the point data defined in table x as LonTalk standard network variable types according to the _____ LonMark functional profile, for control and monitoring by other devices).
3. What each device should be expected to do with this information; for example, "The operator workstation shall access the global system data defined in table x and display it on graphics. The operator workstation shall provide operator override and scheduling of all controllable points defined in table x. The operator workstation shall include points defined in table x in trend logs and reports."

Frankly, all this emphasis on protocols makes Brian Kammers a little nervous.

"There is an overemphasis on communication protocols," says Kammers, program manager for facility management systems, Johnson Controls (Milwaukee). "These are just tools to accomplish building control. The first thing to do is define what the goals are for the control systems, not the communication protocol. The second step is to apply these tools to meet the goals," says Kammers.

Not All Players Have Same Protocol

Jack Harmon, P.E., an independent consulting engineer (Richmond, VA), says that if an engineer wants to feed information such as power management, emergency generator, domestic water booster pump, elevator, fire alarm, security, and adjustable-frequency drives into the bas, he would have to specify that each piece of equipment be of a certain protocol.

Unfortunately, Harmon notes, this would severely limit the bidding, which would adversely impact the cost.

Kammers adds that all the attention has been focused on hvac control, and looking at it from a larger viewpoint in which all other building systems are considered, "We're still far behind as an industry."

He notes that there is some interest, for example, from the fire protection industry in BACnet and LonMark.

"But there's a problem if one fire protection manufacturer creates an object set and another manufacturer creates another set. Then the interoperability part goes to hell. On the fire side, most of the information is going to come through a gateway, so there isn't a UL issue. It will be a secondary reporting situation."

As Usual, It's The Cost That Counts

As an example, Harmon relates a project on which he was involved not too long ago. The building owner wanted to interface his bas with three boilers. The cost for the interface, however, was $18,000, which was far too great. Harmon believes that while owners need to start thinking about interoperability, he doesn't think that it will ever be cost effective to integrate older systems.

"Wait a few years and when the equipment needs to be replaced, then we will probably be at the point where new equipment will be available," says Harmon. John Gnadinger, director of engineering, Electronic Systems USA (Louisville, KY), states that the more systems you try to integrate into a single homogenous system, the more complicated and costly the process will be. However, he doesn't think it's impossible. "It takes more coordination up front from the engineer's standpoint for making sure that each system will integrate at the appropriate level," he says.

Kammers agrees that interoperability is possible today, but it does all come down to cost.

"Any integration is going to be a cost-benefit issue. If you have thousands of controllers with a manufacturer, it's going to be a lot cheaper to create integration than it will be to swap out those controllers. But it's a balancing act," he says.

Kammers notes that Johnson Controls has been working on interoperability issues for years and has a number of solutions already "in the box" and ready to go. That means a lower cost to endusers, because the research and development have already been done.

What To Do First

The LonMark Association hosts a website at www.lonmark.org, which contains a large amount of information regarding its protocol. In late May of this year, the association held its LonMark General Meeting and System Integrator Conference in Orlando. At the systems integrator conference (which was targeted at system integrators, consulting engineers, and equipment specifiers), attendees heard from system integrators about successful installations of open interoperable LonMark systems around the world. The program was divided into four tutorials that covered how to specify, design, install, configure, monitor, and control open systems based on LonWorks networks.

Meanwhile, BACnet also has its own website at www.bacnet.org. In addition, it has a user's group called the "BACnet Interest Group - North America" (BIG-NA), which also has a website at www.BIG-NA.org. Via BIG-NA, you can find out how others are implementing BACnet-based systems and share experiences with those using BACnet.

Of course, many of these sources will be biased toward one protocol or another or one product over another, but, as with all other information on the Internet (or indeed, any other product in this industry), you need to sort through and determine what's pertinent. As Tuft notes, it's a "bit confusing because every vendor puts a different spin on it."

Huston states that a number of manufacturer advertisements oversimplify the technology, which leads to high expectations and misconceptions. He recommends thoroughly researching the companies behind the ads. For example, when a claim is made that thousands of open systems are installed worldwide, you need to ask the following questions:

• How many of the installations involve integration with other manufacturers, or are they single vendor?
• How was the integration performed; was the manufacturer's assistance required?
• What was integrated?
• Who performed the integration?
• Does it work as expected?
• Are competitive bids possible in the future?
• Does phased implementation require a sole source (Phase I manufacturer)?
• Were gateways required?
• What level did the integration occur on (headend computer, gateway, master panel, field device)?
• What media was used?
• What communication speed was required?
• How is maintenance performed?

Another good idea is to take a look at existing buildings in which interoperable systems are functioning. (Again, you'll have to probably rely on a manufacturer's recommendation.) Tuft says it can sometimes be a problem finding such a building locally, because they aren't necessarily widespread yet. But he says this should become easier within the next year or so, when more products become available and the number of sites increases.

Once you feel comfortable with the technology, it's time to take the plunge. Alerton's Jenkins agrees, saying that engineers first need to define the objective of integrating two or more systems.

"Interoperability can work well when it is well thought out within the capabilities of each system," he says. "For instance, if the data points are clearly listed and the attributes that are associated with them are as well, and how they will be networked together, etc., interoperability can work very well."

Tuft says the key point is to make sure that the engineer gets as much information as possible about the systems in place. Then, be very specific about which interoperable functions are required, so everything is spelled out up front - what is going to happen between two or more systems, and what can be communicated between the systems.

"This helps reduce finger-pointing and problems that can arise from not understanding what was required. These are critical issues," says Tuft.

Gnadinger says it's important to make sure the core of the system you are designing has the abilities to give as many options as possible. "The monitoring and control software must be able to integrate many systems into a single package and have the ability to communicate to the open protocols on the market today," he says. "With this package in place, the job of integrating the individual pieces is up to the engineers to decide which manufacturer's equipment is best suited for each application needed."

Then, just keep your fingers crossed and hope it flies.

There's no question that interoperability will continue to be an issue for quite some time. And who knows? In a few years, we may look back and wonder why we spent so much time agonizing over it. But in the here and now, interoperability continues to be a concern. It's confusing. It can be costly. And it ain't easy. But that's life, isn't it? Like everything else, you have to tackle it head-on. ES

FIGURE 1: Integration focus of standard protocols and OPC.

You've heard of BACnet and LonMark. But is the best answer...OPC?

Now, many believe an independent consortium called the OPC Foundation (Boca Raton, FL) is on the faster track to reaching factory and office interoperability.

What Is OPC?

Today the foundation is leading a charge for plug-and-play connectivity through its own OPC acronym, which stands for "Object Linking and Embedding (OLE) for Process Control." OPC now has nearly 140 member companies, including ABB, GE Fanuc, Fisher-Rosemount, Foxboro, Honeywell, Intellution, Johnson Controls, Yokogawa, National Instruments, Rockwell Software, Schneider Automation, Siemens, USDATA, and Wonderware.

"OPC is based on Microsoft's Distributed interNet Application [DNA] Architecture and Component Object Model [COM]," explains Dave Rehbein, OPC president and senior principle engineer, Fisher-Rosemount Systems. "The OPC specification defines an industry-standard interface to make COM useful for process control and manufacturing automation."

Microsoft's COM is a software architecture that allows applications to be built from binary software components. COM forms the foundation for higher-level software services, like those provided by OLE. OLE services span various aspects of commonly needed system functionality. OLE and COM allow applications to share "objects" such as spreadsheets' embedded word-processing documents. When updates to the spreadsheet occur, OLE and COM ensure that those changes are automatically reflected in the document.

Rehbein says that OPC, for example, can allow an engineer in an office remote from the control room to populate a daily report on the performance of a heat exchanger with real-time data from the process-control system. "In the past, if I wanted to get data from a company's proprietary control system, I had to buy their proprietary application programming interface. But OPC exposes the data from any control system in the same way. So any OPC client application can be connected to any vendor's OPC-compliant server in the same way and expect the same behavior from the server."

One Example

The mill was particularly interested in integrating the Delta V with OSI Software's PI history software package. In addition to using PI to maintain process history, the mill used the system as part of a bridge to company business systems, based on IBM AS/400 computers.

"This project involved our developing COM objects to enable the communication between PI and the Delta V," says Jerry Clark, an engineering manager with Quaker Computer Systems (Savannah, GA), the mill's system integrator on the project. "We wrote an OPC-compliant interface to pull the information out of the Delta V and put into PI. So now that we have the interface, it will work with a Honeywell system, a Siemens system, or anyone else's that conforms to the OPC standard."

Clark notes that having an OPC standard will make future implementations easier. "We don't have to write custom interfaces for every project."

There Are Believers

"A couple of years ago, I was having dinner with one of the world's foremost building automation systems consultants," says Moult. "We were lamenting the state of our industry and the slow rate of standardization of protocols. The consultant commented, 'What this industry needs is for Bill Gates to step in. Microsoft could establish a standard in no time!' We laughed, but didn't know that this was exactly what was happening in the U.S."

Figure 1 illustrates the difference between using a standard protocol and using OPC to integrate devices. "The focus of protocols such as BACnet and LonMark is the placing of controllers from multiple vendors on a common wire to exchange information without a protocol translator [or gateway]," says Moult. "The focus of OPC is to integrate systems [islands of automation], each with its own information server into a common client."

According to Moult, there is a keen desire in Southeast Asia to integrate the building's enterprise management system (room reservation, web-based tenant interface, etc.) into the building systems. "Standard protocols such as BACnet and LonMark are not designed to address this type of application," says Moult. "Because it is client-server-based and complies with Microsoft's de facto standards in the office automation industry, OPC is well-suited for this type of integration.

"It is my personal opinion that OPC will be far more relevant in addressing the needs of the Southeast Asia market than standard protocols. OPC is based on the Microsoft platform of OLE/Active X, and therefore is an excellent tool to integrate the building's enterprise management system with the building systems."

In Hoffmann's estimation, seamless integration is "no longer a pipe dream," because "OPC permits true plug-and-play compatibility among hardware and software products across the full spectrum of automation vendors, devices, and systems."

Hoffmann referred to Gesytec, a company based in Aachen, Germany. It provides its Easylon Server(r), which allows OPC clients to gather data from any LonTalk(r) automation and control network. This includes Microsoft's Excel(tm) spreadsheet and Access(r) database programs. Because the interface for these programs build on TCP/IP, source data can reside anywhere on the owner's intranet or, with security precautions, on the Internet.

"The new M-Web(r) web server from Johnson Controls now uses OPC to gather information from a Metasys(r) building automation system," Hoffmann explains.

Is OPC right for everyone? "Perhaps," says Hoffmann; "but like any technical solution, OPC is one of several tools designed to accomplish a task within a defined environment. Manufacturers, developers, specifiers, and endusers should carefully investigate all alternatives within the context of their application."

For more information on OPC, check out the OPC Foundation's website at www.opcfoundation.org. The foundation's address is 20423 State Road 7, Suite 292, Boca Raton, FL 33498; 561-477-1375; 561-477-0520 (fax).

FIGURE 2: Consider this example a true open system. Here, the building is controlled by a single control infrastructure.

One Recipe For Achieving Holistic Building Controls

A recipe can be defined as a known and repeatable way to do something that provides for success. In the realm of equipment controls and building automation systems (bas), a recipe for success seems to have been a long time coming.

There are various claims of control "openness" among system manufacturers; this article offers definitions and a "recipe" to maximize desired enduser benefits from among the control variables.

Openness And Market Realities

It is quite possible to use open devices in a control system that is closed and proprietary. This fact confuses many; it sometimes leads consultants, owners, and endusers to buy open devices that are installed in systems that are difficult to expand and impossible to integrate without the assistance of the original manufacturer.

What exactly is an open device? Some believe a device is open if it provides messages to other devices on a network that adhere to a standard range, resolution, and meaning. This is certainly a dramatic move forward from the proprietary products historically available from commercial control manufacturers.

To be truly open, however, a device should do more than provide standard messages to other devices. A truly open device should be able to provide an open configuration interface so that tools made by other companies can install and configure it. Documenting this interface, and making it available with appropriate supporting files to anyone who purchases the device, makes the device truly open.

Why is a documented configuration interface a requirement for an open device? The notion that standard messaging alone is enough to call a device open assumes that all devices begin life installed in a system and are already programmed or configured.

Resourceful integrators have proven they can usually find ways to use devices that do not have open configuration interfaces, but their efforts result in additional cost, which is eventually passed on to the enduser. And in the end, true integration of the components is seldom achieved. The major benefits of open systems are minimized.

All this leads to the construction of the following definition:

Open device: A device on a control network that uses standard messaging and provides a documented configuration interface that can be accessed by standard tools.

An open control network consists of more than just open devices. Standard network management is required to install and maintain the devices.

This network operating system (NOS) must contain published interfaces that are available to everyone, and a large number of control manufacturers must use it. The NOS should also provide published interfaces for applets or "plug-ins." These plug-ins allow device software developers to cost effectively insert their application knowledge into network tools.

To summarize:

Open control system - A collection of open products that is based on a standard network management scheme and is installed using standard tools and plug-ins.

The following can be considered generally accepted market realities:

• Intelligence at the point of control provides greater flexibility and reliability.
• Peer-to-peer control networks provide measurable advantages over master-slave architectures.
• Openness, as defined above, frees the integrator and endusers to select "best-in-class" products and services without fear of difficulty or "vendor lock-in."
• Total access to all system information from anywhere in the network can best be achieved via a standard protocol used throughout the system.

The traditional control structure in the commercial industry revolves around vertical subsystems, each with its own cabling, management system, and service contract.

Historically, the communication barrier between subsystems has been addressed through extra engineering effort and complex interfaces. This made even quasi-integration costly.

These islands of automation are often tied together with "string and band-ages," to allow users to view different subsystems without having to jump from one PC to another. But dividing the control system into collections of proprietary subsystems severely limits the power of the control network. It also prevents economic implementation of holistic building control.

Implementations like the one shown in Figure 1 are the tradition in the commercial control market. However, this implementation is not an open system under the definition given earlier. Open devices may actually exist on each island, but communicating with or configuring devices on other islands is far from seamless.

FIGURE 3: This is a network management framework that supports published interfaces for devices of all types; it can be seamlessly integrated into the overall system.

Leveraging The Power

Leveraging is achieved by eliminating the walls between building control systems. Figure 1 shows the construction of a vertically integrated bas. Now imagine eliminating the boundaries between the islands.

Visualize a singular control system that uses a common physical and logical infrastructure to provide holistic building control.

Figure 2 shows how the functional layers can be viewed from a construction or implementation standpoint. Here, the entire building is controlled by a single control infrastructure. A standard wiring scheme allows devices to easily access and share communication media. Network services help ease the enduser's use of these devices.

Since multiple manufacturers make the devices and software on the network, the network services must adhere to a standard. Different network control systems may have different needs, however, and different users may have training in different networking tools.

By creating standard network tools that adhere to the network management standard, different users can use the different tools on the same network. Finally, an application-level standard for the exchange of information between devices exists so they can easily communicate.

Figure 3 highlights the benefits of using this approach, with a focus on the power of the standard network management.

In this case, we see the network management framework that allows published interfaces - for devices of all types, from all industries, for any application - to be easily and seamlessly integrated into the overall system. These standard network services make it possible for any number of vendors to build tools that accomplish tasks using the network services.

Thus, all the installation, monitoring, control, and configuration tools from different manufacturers can access all the network devices in the entire building.

Having reviewed the concepts involved, it's time to develop our recipe for open-system implementation.

Recipe For One Open System

The most basic ingredient for a building-wide open control system is intelligent wiring. It grants the integrator and enduser the ability to more quickly and easily install the system, as well as to make additions and revisions in the future.

Almost as important, eliminating the physical barriers between systems encourages engineers and owners to create holistic building control. Gateways and islands of automation seem even more useless when a standard wiring infrastructure exists.

To achieve this on a project means getting approval up front and planning the wiring for all building functions. The owner and consultant must understand that the building can be better than the sum of its parts if proper thought is given to holistic control in the initial stages of design.

Ingredient 2: Standard network management.

Standard network management provides the necessary network services and published interfaces for the infrastructure. These services allow multiple tools from multiple vendors to coexist on the network. More importantly, they allow the various tools to share network data.

To achieve a network management foundation, use any control network operating system you can find that is in use by hundreds of companies around the world.

Providing a standard that many companies build to is the only way to leverage the real benefits of open control networks for whole building control. After all, a standard is of little use if it is only used by a handful of companies.

Ingredient 3: Standard network tools.

These include network management tools as well as HMIs, dataloggers, and other applications with a system-wide view. For this recipe, choose network tools based upon the NOS chosen in the previous step.

The benefit is the use of this tool for either the entire system installation or any portion thereof; in short, tools can be chosen based on functionality and usability rather than who made the physical devices.

Ingredient 4: Standard device messaging.

It is crucial that the devices installed on the common infrastructure share information without effort, so the fourth ingredient in the open system recipe is products adhering to a common communication guideline.

As previously determined, this means the devices must use standard communication variables.

Ingredient 5: Standard device configuration.

Recall that according to our definition of an open device, it must not only support standard communication, it must support a standard interface for configuration. Our selection should provide guidelines for the physical layer requirements of devices, as well as the common data types, configuration capabilities, and installation methodologies.

While it's adequate for product manufacturers to simply document the configuration interface for their device, it's obviously better if they encapsulate that knowledge into a small program that can be run inside one of the network management tools. This allows tools from other manufacturers to install and configure the device more quickly and easily.

Ingredient 6: TCP/IP support.

The Internet Protocol suite is the standard on which the Internet is built; an open control system must provide for encapsulation of the control system messages or packets into TCP/IP datagrams. Messages can then be passed around the world without translation into foreign protocols.

The cost of transmission is minimal, and the ability to use existing infrastructure is practically limitless.

Ingredient 7: Gateways (limited to legacy applications).

This seventh and final ingredient must be closely monitored. At any point in the system where the messages between devices are mapped from one communication protocol to another, the control network effectively ends. The mapping of messages from one protocol to another is accomplished via a gateway.

Gateways should only be used for interfacing to legacy systems or in situations where a whole-building system is unavailable. Every other ingredient in the open system recipe can be increased without concern. This is part of the beauty of open systems and the open system recipe.

Gateways have been a staple of the commercial control industry for the last 10 years. They are, however, bottlenecks in the flow of system data, and are inherently performance-limiting.

Performing the functions of a gateway requires processing power, which translates into higher cost. Gateways also require someone to indicate what should be mapped to what, which consumes engineering efforts.

Finally, gateways are difficult to maintain. Any change in system parameters has to be addressed at the gateway as well. Since a gateway is a transition from one communication protocol to another, it almost always is accompanied by a change in network management schemes. Different management schemes mean different tools are required for either side of the gateway. Therefore, a common network management tool for the entire system is difficult, if not impossible, to produce.

All In All

Whole-building control promises to adapt to the needs of users hour by hour, day by day, for the life of the structure.

Such control offers increased productivity of the occupants; better comfort; tighter integration of more sensors, actuators, and other sources of occupant data; better energy management; and lower facilities management costs.
Arnold is marketing director, Echelon Corp. (Palo Alto, CA). He can be reached at 650-855-7432; Rand Arnold. (e-mail). ES