Part 1: Technology
Specify building automation interoperability and it will happen? Unfortunately, current evidence indicates that this is not a given. Some believe that BACnet® and/or LonWorks® were not properly designed to make interoperability easy. Others believe that design (MEP) engineers are not properly specifying BAS for
|
| FIGURE 1. The OSI model. |
Fortunately (or unfortunately), there is sufficient evidence to lend credence to all of these beliefs and then some. Putting blame to the side, the fact is that a number of technological and business practice shortcomings remain that make interoperability a challenge. Engineers are presently caught somewhere between specifying what is available, what they are told is available (but may be untried at best), and what they are hoping will become available. What challenges must we overcome to more readily achieve interoperability in BAS? The first article in this two-part series will focus mainly on the technological challenges that remain, while the second article will focus on how changes to industry design and construction practices are not only equally important to improving interoperability, but may actually be the real key to meeting the challenge.
THE CURRENT STATE OF INTEROPERABILITY TECHNOLOGY
There is no question that the interoperabililty technology has achieved a critical mass of building automation manufacturer and market acceptance. There is a steadily growing body of projects demonstrating that some degree of interoperability is readily achievable on most commercial HVAC and/or building construction projects. The reason for this success is that essentially all general-purpose DDC systems (e.g., the HVAC controls manufactured by building automation companies) now use either BACnet or LonWorks (or both) in some or all of the components. So, regardless of the fact that many design specifications are now calling for the use of these protocols, they have essentially become a given.
The irony in this is that the mere use of open/standard protocols does not mean that a project is interoperable (or that interoperability is an intended design feature). More importantly, many projects where interoperability is a goal have usually yielded a mix of successes, near-successes, and disappointments. The problem begins with the fact that there is no universal understanding of “interoperability” and, worse still, there are great misconceptions about what it is and what it can do.
WHAT IS INTEROPERABILITY?
The first step in achieving interoperability lies in a realistic definition of the results expected. Without this definition, success or failure will be judged solely in the “eye of the beholder.”
A general-purpose definition. There is no one definition of interoperability that fits all projects and clients. However, the following is a good starting point for developing a project-specific definition:
-
The use of digital communications to provide:
- Shared data between controllers/systems of more than one manufacturer. These “controllers” can be DDC controllers by building automation manufacturers or those by provided with equipment (chillers, air-handling equipment, etc.). The “systems” can be other BAS (fire alarm and lighting control systems), or even enterprise software (maintenance management), and/or
- Operator interface capabilities from a single hardware and software platform to controllers and/or systems of more than one manufacturer.
-
Digital communications technologies that:
- Need not rely on an open and/or standard protocol(s), though use of such protocols will enhance the results, both present and future.
- Shall not require manufacturer customization (e.g., to a controller product’s firmware).
THE DEVIL IS IN THE DETAILS
What makes this definition a starting place should be clear from the fact that there is considerable leeway in the phrases “shared data” and “operator interface capabilities.” Given that there is no single set of shared data and operator interface capabilities that applies to all projects, the following guidelines should be considered when refining a project’s interoperability goals.
The overriding message should be that the technology of interoperability can only be successful if the expectations of that technology are well defined and within reason.
What makes this definition a starting place should be clear from the fact that there is considerable leeway in the phrases “shared data” and “operator interface capabilities.” Given that there is no single set of shared data and operator interface capabilities that applies to all projects, the following guidelines should be considered when refining a project’s interoperability goals.
- Shared data. There is simply no way of avoiding the fact that the shared data required depends completely on the project requirements. Fortunately, this list of shared data can be readily determined from a well-developed set of sequences of operations and point lists, along with research into the data communication technologies used and the capabilities of each of the systems/products involved (e.g., between a DDC system and HVAC equipment-provided controls).
- Operator interface capabilities. While these capabilities are less challenging to define than the above, one must avoid overreaching. In particular, it is fairly safe to assume that an operator interface provided by one manufacturer will not be able to configure or program controllers made by another manufacturer. On the other hand, viewing (and modifying where applicable) most point/setpoint data is easily achievable as long a reasonable data list is developed (don’t just use the word “all”). Between these two extremes are several capabilities — like scheduling, alarming, and trending — that require research into the various products involved in order to determine how and if they can be achieved for a given project.
The overriding message should be that the technology of interoperability can only be successful if the expectations of that technology are well defined and within reason.
OVERVIEW OF BAS PROTOCOL TECHNOLOGY
The following overview provides a discussion of some of the broader data communications issues that are important to understand the current state of building automation protocols.
There are many protocols involved in building automation interoperability. BAS communications involve the use of multiple protocols. While we typically refer to BACnet or LonWorks each as a single protocol, they are actually a collection of various protocol requirements, choices, and options that can be combined in a variety of ways to suite different applications. The importance of dividing data communications technology into multiple protocols was formalized by the ISO in a 1984 standard referred to as the Open System Interconnection (OSI) model.
The OSI model defines seven categories (called “layers,” Figure 1) which are to be used as a guide in dividing the multiple protocols involved into the various standards and products used. The collection of protocols that are uniquely combined into a given product is called the “protocol stack.” Fortunately, many of today’s protocol components have become so ubiquitous that they should be readily familiar:
- The main protocols used in Internet communications are TCP and IP (or “IP” as it is commonly known). These two protocols are part of two layers of an OSI protocol stack used by a device that communicates over the Internet.
- The bottom two layers of the OSI model — the physical and data link— together form the functions of a local area network (LAN). Ethernet is probably the best known example of a LAN technology. BACnet’s MS/TP is a local area network option that combines the physical layer standard known as EIA-485 along with data link protocols that are unique to BACnet.
It is important to note that both BACnet and LonWorks are still in the process of refining and/or adding more protocols to their technologies to address the changing needs of the industry.
Transport vs. application protocols. It is sometimes more convenient to divide the functions in the OSI model into two major categories — transport and applications (Figure 1). Simply put, the bottom transport half of the OSI model deals with the reliable transport of data within the system without regard to the contents or structure of that data. The top applications half is concerned with the structure of the data and the services that are used in accessing that data.
A few examples of this concept will further help to clarify the state of building automation protocols:
- In LonWorks technology LonTalk® is essentially the set of transport protocols, while LonMark® is a collection of applications protocol choices.
- The BACnet standard is primarily a set of applications protocols with a limited set of transport protocol choices that are generally standards developed by others (e.g., Ethernet, and IP).
When two different applications protocols interoperate, the additional applications functionality of the OSI “presentation” layer is needed; and is typically provided by a product called a gateway (which sometimes is referred to as a driver, translator, integrator, etc).
An important point is that comparing LonTalk (essentially a transport protocol) to BACnet (mostly an applications protocol) is like comparing apples and oranges.
The major DDC system protocol choices. Without predicting the future or reflecting on the past, BACnet and LonWorks have clearly become the DDC market’s communications protocols of choice. The apparent competition between these two protocols somewhat masks the fact that they are very different in some key aspects.
In particular:
- BACnet is, in its entirety, a single ASHRAE standard and began life as such. LonWorks was initially developed as a communications product by the Echelon Corporation but now includes a combination of several industry standards, open technologies (typically involving a licensing fee), and some proprietary products.
- Echelon manufactures and sells dozens of products in support of the LonWorks technology, while there is no similar entity or products behind BACnet.
- While more subjective, the differences between LonMark and the BACnet applications protocols can be seen in the earlier success that LonMark achieved with “smaller” controllers (e.g., for VAV boxes) and the likewise earlier success that BACnet had with more general-purpose controllers.
Modbus is a protocol that can provide a supporting role for certain BAS designs. This is particularly true for products that are extensively used in the industrial market like VFDs and boilers. However, the industrial market where customization is the norm, created Modbus. Consequently, it does not include the applications protocol features needed to make interoperability readily achievable. For this and other reasons, it is never expected to play more than this supporting role, a role that may diminish over time.
The market acceptance of BACnet and LonWorks might indicate that BAS with proprietary protocols will soon be a thing of the past. However, existing systems with proprietary protocols will undoubtedly remain in commercial buildings for some time to come. While this should not affect the continuing growth in the use of open/standard protocols, it does mean that gateways will be an important component of many interoperating automation systems for the foreseeable future.
Constraining a protocol to provide interoperability. Availability of open/standard protocol technology alone does not provide interoperability. Two additional steps are necessary:
- Interoperability rules. A subset of any suite of communication protocols’ capabilities needs to be selected and a set of rules about how these capabilities should be designed into various product types needs to be defined. Without such constraints, predictable interoperability without customization on a project-by-project basis is not possible. This need resulted in the definition of “BACnet Standardized Device Profiles,” which was added to the standard in 2001, and LonMark “Profiles,” which have been in development for a number of years.
- Testing. Protocol definitions and interoperability rules, no matter how well written, are subject to interpretation. Therefore some form of testing program is a further assurance that a product can provide interoperability. This has led to the BTL (BACnet Testing Laboratories) Listing program and the LonMark self-certification program.
THE REMAINING TECHNOLOGY CHALLENGES
Use of the Internet. The originators of BACnet and LonWorks could not have anticipated the Internet’s dominant use in the world’s communications systems. Nevertheless, BACnet and LonWorks did take early steps to ensure that the Internet could serve as a transport protocol option. However, it has become apparent that use of the Internet purely as a transport protocol generally only makes sense between IP-addressable building automation controllers/systems. Instead, it is now known that the use of Web services and XML (an applications protocol widely used by the Internet for device-to-device data transmission) would greatly widen the opportunity for interoperability between building controllers and other devices/systems such as operator interfaces (which are now Web-based), and building management and enterprise software. Simply put, Web services are an Internet standard for facilitating the sharing of data, while XML is an Internet standard for encoding that data as opposed to HTML and HTTP which are used for defining and transmitting webpages).
Web services and XML were not designed to provide the level of interoperability expected by the building industry. Therefore, the BACnet/WS addendum was recently added to define how Web services are to be used for communicating BACnet data encoded in XML.There is also another initiative called oBIX that has just voted to release their first version of a set of rules (not based on BACnet) for providing building automation interoperability via Web services and XML.
Unfortunately, these additional applications protocols will probably need some time before they are widely available in building automation products and provide the additional interoperability solutions needed.
The status of certification and listing programs. The BTL listing and LonMark certification programs are confronting challenges that have yet to be overcome. In particular, there is currently no BTL listing program for operator interfaces; and, a significant number of products currently marketed as using BACnet are not yet BTL listed.
LonMark is confronted with a different challenge; namely, that profiles are fine for fairly simple devices (e.g., VAV box controllers), but may not be possible (and have not yet been developed) for more general-purpose controllers (e.g., those used for custom central plant control). Therefore it is currently not possible to install an all BTL-listed or LonMark-certified DDC system in most building project types. A corollary to this conclusion is that it currently makes no sense to specify that a system be (in its entirety) BTL-listed or LonMark-certified.
Equipment manufacturer controls and other low-voltage systems. While the dominant use of open/standard protocols by DDC system manufacturers appears to be a given, the same cannot be said of equipment manufacturer-provided controls or other low-voltage systems. It is difficult to find open/standard protocols in wide use on many classes of HVAC equipment and other building automation products. Even if the trend within a class of products (e.g., chillers) seems to be toward providing open/standard protocol solutions, it is more often via a gateway rather than the complete use of BACnet or LonWorks. Further, the commitment to BTL listing or LonMark conformance is clearly lagging.
Gateways. Gateways are the Dr. Jekyll and Mr. Hyde of interoperability. On the one hand, they are a necessary solution for interoperability to existing systems with proprietary protocols. They may also be the only solution available for a class of equipment manufacturer controls or low-voltage systems (e.g., fire alarm systems will undoubtedly use proprietary protocols for some time to come). On the other hand, a very good guiding principle in any BAS design is to avoid the use of gateways wherever possible. Why is this?
Gateways perform applications protocol conversion. This might sound like a relatively straightforward matter of designing a product that converts one data structure format into another. However, there are numerous complex challenges associated with data structure conversion that a gateway may have to resolve. Examples include:
A failure to analyze the details of a gateway’s operational requirements can lead to disappointing results (which is the main reason why gateways developed a bad reputation in the first place). While more widespread use of gateways will undoubtedly lead to a better understanding of these issues, the need for gateways will probably remain a challenge to interoperability for as long as they are a necessary evil.
Use of the Internet. The originators of BACnet and LonWorks could not have anticipated the Internet’s dominant use in the world’s communications systems. Nevertheless, BACnet and LonWorks did take early steps to ensure that the Internet could serve as a transport protocol option. However, it has become apparent that use of the Internet purely as a transport protocol generally only makes sense between IP-addressable building automation controllers/systems. Instead, it is now known that the use of Web services and XML (an applications protocol widely used by the Internet for device-to-device data transmission) would greatly widen the opportunity for interoperability between building controllers and other devices/systems such as operator interfaces (which are now Web-based), and building management and enterprise software. Simply put, Web services are an Internet standard for facilitating the sharing of data, while XML is an Internet standard for encoding that data as opposed to HTML and HTTP which are used for defining and transmitting webpages).
Web services and XML were not designed to provide the level of interoperability expected by the building industry. Therefore, the BACnet/WS addendum was recently added to define how Web services are to be used for communicating BACnet data encoded in XML.There is also another initiative called oBIX that has just voted to release their first version of a set of rules (not based on BACnet) for providing building automation interoperability via Web services and XML.
Unfortunately, these additional applications protocols will probably need some time before they are widely available in building automation products and provide the additional interoperability solutions needed.
The status of certification and listing programs. The BTL listing and LonMark certification programs are confronting challenges that have yet to be overcome. In particular, there is currently no BTL listing program for operator interfaces; and, a significant number of products currently marketed as using BACnet are not yet BTL listed.
LonMark is confronted with a different challenge; namely, that profiles are fine for fairly simple devices (e.g., VAV box controllers), but may not be possible (and have not yet been developed) for more general-purpose controllers (e.g., those used for custom central plant control). Therefore it is currently not possible to install an all BTL-listed or LonMark-certified DDC system in most building project types. A corollary to this conclusion is that it currently makes no sense to specify that a system be (in its entirety) BTL-listed or LonMark-certified.
Equipment manufacturer controls and other low-voltage systems. While the dominant use of open/standard protocols by DDC system manufacturers appears to be a given, the same cannot be said of equipment manufacturer-provided controls or other low-voltage systems. It is difficult to find open/standard protocols in wide use on many classes of HVAC equipment and other building automation products. Even if the trend within a class of products (e.g., chillers) seems to be toward providing open/standard protocol solutions, it is more often via a gateway rather than the complete use of BACnet or LonWorks. Further, the commitment to BTL listing or LonMark conformance is clearly lagging.
Gateways. Gateways are the Dr. Jekyll and Mr. Hyde of interoperability. On the one hand, they are a necessary solution for interoperability to existing systems with proprietary protocols. They may also be the only solution available for a class of equipment manufacturer controls or low-voltage systems (e.g., fire alarm systems will undoubtedly use proprietary protocols for some time to come). On the other hand, a very good guiding principle in any BAS design is to avoid the use of gateways wherever possible. Why is this?
Gateways perform applications protocol conversion. This might sound like a relatively straightforward matter of designing a product that converts one data structure format into another. However, there are numerous complex challenges associated with data structure conversion that a gateway may have to resolve. Examples include:
- What if the gateway is designed only to communicate simple data structures (point, setpoints, etc.)? Schedule, trend data, and alarm summaries are complex data structures that a gateway may not have the capability to convert (even if the conversion were within reason). For example, if a gateway cannot pass start/stop schedule information, then this information must either reside on both sides of the gateway (with separate operator interfaces for manipulating them) or all schedule information must be contained within the system which will be used for both systems’ operator interface capabilities (Figures 2 and 3). The first choice is clearly not desired, while the latter choice means that the gateway is a single point of failure for an important system feature.
- What if the gateway is needed to connect two very large systems? Gateway operations are complex and therefore cannot handle large amounts of data (or even lesser amounts of data if frequent update rates are needed). Multiple gateways will typically be needed if the data conversion volume is great. A detailed analysis based on the specific systems and gateways involved, along with the data and update times expected, is necessary to determine the number of gateways needed.
A failure to analyze the details of a gateway’s operational requirements can lead to disappointing results (which is the main reason why gateways developed a bad reputation in the first place). While more widespread use of gateways will undoubtedly lead to a better understanding of these issues, the need for gateways will probably remain a challenge to interoperability for as long as they are a necessary evil.
CONCLUSION
Use of open/standard protocols in the building automation industry has essentially become a de facto feature of DDC systems. This trend is also steadily spreading to equipment-provided DDC and other BAS. However, this does not mean that interoperability is easily achieved on all projects and/or with all product combinations. On the other hand, the technological barriers to interoperability are actively being addressed and are clearly lessening on a daily basis.
The second article in this two-part series will present design and specification guidelines that can mitigate these barriers so that the technology of interoperability can be optimized today. It will also discuss how our industry’s current business practices make it difficult to provide the design care required and, more importantly, do not encourage the construction practices necessary for maximizing interoperability. Which then, are the real barriers to interoperability?
Use of open/standard protocols in the building automation industry has essentially become a de facto feature of DDC systems. This trend is also steadily spreading to equipment-provided DDC and other BAS. However, this does not mean that interoperability is easily achieved on all projects and/or with all product combinations. On the other hand, the technological barriers to interoperability are actively being addressed and are clearly lessening on a daily basis.
The second article in this two-part series will present design and specification guidelines that can mitigate these barriers so that the technology of interoperability can be optimized today. It will also discuss how our industry’s current business practices make it difficult to provide the design care required and, more importantly, do not encourage the construction practices necessary for maximizing interoperability. Which then, are the real barriers to interoperability?
