For a more recent article on building automation protocols, go to |
At the dawn of the age of personal computers, it was certainly not a given that one personal computer would be able to communicate with another. Then came DOS. Adopted first by IBM, it quickly became a de facto standard for much of the personal computer industry. Users didn’t have to worry about whether one system could communicate with another.
Things weren’t so simple for building automation systems. Each manufacturer developed systems on its own. There was no industry standard to follow. The result: Systems from different vendors were incompatible.
As the systems became increasingly sophisticated and flexible, facility executives frequently found that these incompatibilities were serious roadblocks to improving facility performance. It was difficult or impossible to integrate the independent automation and control systems into a single, integrated system.
The problem was that systems from different manufacturers weren’t interoperable.
The first attempts at interoperability were little more than individual manufacturers promoting their proprietary systems to accomplish all automation and control functions within a facility. While this approach allowed integration of previously separate and independent systems into a single system, it has its drawbacks. With proprietary systems, facility executives are locked into a single manufacturer’s system. If there is a function that they want to perform but is not offered by the manufacturer, they are simply out of luck. Even worse, with no competition for system expansions, modifications or upgrades, facility executives are at the mercy of the system manufacturer with respect to pricing.
Another approach to interoperability has been through the use of published interoperability protocols. A protocol is a set of rules that governs communications within a computer network, defining everything from how connections are made between devices to how the message itself is formatted. They can be implemented through software, hardware, or both. It is the widespread acceptance and use of standard protocols that have enabled the development of many of today’s communications systems, including local area networks and the Internet.
Within the building automation arena, two approaches have been taken with respect to protocols and interoperability. Some protocol developers have chosen to keep portions of the protocol proprietary while allowing manufacturers to develop products that adhere to the standards set by the protocol. Other developers have chosen to place the standard in the public domain for use by any vendor in developing equipment that will function in the system.
Three of the most widely used interoperability protocols today are BACnet, LonMark and Modbus. While all three have been used successfully in implementing interoperable building automation systems, their approach to interoperability is vastly different. These differences do not necessarily mean that one approach to interoperability is superior to the others, only different.
BACnet stands for Building Automation and Control Network. BACnet is the standard that was developed by ASHRAE — in conjunction with building management organizations, system users and building system manufacturers — specifically for building automation and control equipment. In 1995, after years of development and revision, the ASHRAE Board of Directors ratified and published the standard as ASHRAE 135-1995. The standard was submitted to ANSI and, in 1995, it also became an American National Standard, ANSI/ASHRAE 135-1995.
Over the next six years, the standard underwent a number revisions and upgrades. In 2001, ASHRAE released an updated standard, ASHRAE/ANSI 135-2001. In 2003, BACnet became an international standard, ISO-16484-5.
BACnet is a nonproprietary, open protocol communications standard. It can be applied to practically any type of system found in buildings today, including HVAC, lighting, life safety, access control, transportation and maintenance. By design, it can use a wide range of network technologies for communications. It is a written specification that includes everything from what type of cable must be used to how to initiate a particular information request or command. Its rules are specifically designed for building automation and control equipment, covering such tasks as how to request a temperature reading, send a status alarm or establish a fan schedule.
The approach that BACnet developers took when developing the standard was that for a system to be truly interoperable, there must be some standardized agreement covering two major areas: overall system operation and individual system components. They accomplished this by using an object-oriented approach in examining, controlling, modifying and interoperating with information in different devices. The BACnet object-oriented model has two major components: objects and services.
In BACnet, objects are collections of properties, each representing some bit of information. In addition to standard defined properties, objects may include vendor-defined properties as long as they function in accordance with the standard. BACnet also defines the expected behavior from each property for that object. What makes the object-oriented approach work is that every object and every property as defined by the system is accessible in exactly the same manner.
The process of reading or writing to a property is what BACnet calls a service. Services are the methods used by any BACnet device when it communicates with another BACnet device, including retrieving information, transmitting information or communicating an action. The standard defines a wide range of services for accessing objects and their properties.
To help ensure that products developed by different manufacturers conform to the BACnet standard, a testing laboratory was established. The laboratory tests and certifies any device for conformance with the standard. The laboratory has also developed a complete set of testing procedures that are to be used by manufacturers.
A second standard, LonMark offers a different type of solution to the interoperability issue. Unlike BACnet, LonMark is a proprietary protocol developed by the Echelon Corporation in conjunction with Motorola in the early 1990s. The LonMark standard is based on the proprietary communications protocol called LonTalk. The LonTalk protocol establishes a set of rules to manage communications within a network of cooperating devices. To simplify implementation of the protocol, Echelon chose to work with Motorola to develop a specialized communications microprocessor called the Neuron. Through the use of this chip and its supporting software, the protocol establishes how information is exchanged between devices. Because much of the communications protocol is contained on the chip, system designers and installers can focus on other aspects of the system.
While LonTalk addresses the issue of how devices communicate, it does not consider the content of the communication. A second protocol, known as LonWorks, defines the content and structure of the information that is exchanged. LonWorks is a distributed control system that operates on a peer-to-peer basis, meaning any device can communicate with any other device on the network or use a master-slave configuration to communicate between intelligent devices. The LonWorks platform supports a wide range of communications media.
LonWorks-compatible devices communicate with each other through what is known as a Standard Network Variable Type or SNVT. While a SNVT defines a device just as an object does for BACnet, its approach is somewhat different. For a SNVT to function, both the sending and the receiving devices must have detailed knowledge of what the SNVT structure is. Therefore each SNVT is identified by a code number that allows the receiving device to properly interpret the transmitting data.
Initially, LonWorks did not define what a particular SNVT code meant. This resulted in confusion between vendors who used the same code to mean different things. To eliminate the confusion and to standardize SNVT codes, the LonMark Interoperability Association was formed in 1994. Made up of hundreds of manufacturers and integrators, one of its primary goals was to lay out standard methods for implementing the LonWorks technology.
To ensure that any device installed in a LonMark system will work properly with other devices, LonMark requires that in order to carry the LonMark logo, products must have been verified to conform to the LonMark protocol. LonMark uses a Web-based tool to reduce the time and cost for certifying devices.
One of the more recent innovations made by LonMark is the network profile. The idea behind the network profile is that no matter who makes a particular device used in a building system, such as a variable speed drive, all like devices will perform a similar function. To ease and speed system installation, LonMark then defines how a particular device should function on the network, from the points included to how they are named. This predefined network profile is the minimum profile for any connected devices. Manufacturers can add additional items to the predefined profile based on their particular product, giving them flexibility while maintaining simplicity and interoperability.
Like BACnet, LonWorks has been accepted and adopted by the international standards organizations (ANSI/CEA 709.1 and IEEE 1473-L).
A third protocol that has been used to achieve interoperability in building automation systems is Modbus. The Modbus protocol was developed during the 1970s by Modicon, Inc. for use in industrial automation systems with programmable controllers. Today it is one of the most widely used means for connecting electronic equipment in industrial applications. Its simplicity is also making it a useful tool for achieving interoperability in building automation applications.
Modbus consists of a messaging structure designed to establish master-slave, client-server communications between a wide range of intelligent devices. It supports traditional serial and Ethernet protocols. It is a truly open standard and is one of the most widely used protocols in the industrial manufacturing environment. There is no charge for using the protocol nor are there licensing fees. Tools and resources that can be used to expedite installation and support operations are available on-line.
The original version of Modbus included two transmission modes: ASCII and RTU. More recently, Modbus/TCP was developed, allowing the Modbus protocol to be transmitted over TCP/IP based networks.
In 2004, the standard was transferred to Modbus-IDA. Modbus-IDA is a nonprofit organization made up of users and suppliers of automation devices primarily in manufacturing.
While Modbus was initially designed for use in industrial applications, its use has rapidly spread to building automation, transportation, and energy applications. Its strengths include openness, simplicity, and minimum hardware requirements. Another significant benefit is the protocol’s use of the TCP/IP transport protocol, the same protocol used by the Internet. This means that Modbus can readily be used over the Internet.
Modbus does have a certification process to ensure conformance to their standard. However, in spite of the widespread use of the Modbus protocol, only a fraction of the installations have gone through the certification process.
Each of the competing protocols claims to be the best. So how do facility executives select the one that is best suited for the facility?
Protocols must be selected based on the needs of the facility and its ability to support a particular protocol. Each has been used many times to implement an interoperable system. Each has its advantages and disadvantages. Involve your information technology department. They generally are the controlling agency for the facility’s network infrastructure. If your organization lacks the in-house expertise to evaluate competing protocols, enlist the assistance from a qualified, independent outside firm.
James Piper, PhD, PE, is a writer and consultant who has more than 25 years of experience in facilities management. He is a contributing editor for Building Operating Management.
