Open Communication Protocols for Elevators, Part 2

In the first article of this series (ELEVATOR WORLD, July 2014), the science and concept of open and interoperable protocols were discussed, with an introduction to the seven layers of the International Organization for Standardization (ISO) standard Open Systems Interconnection (OSI) network model and several popular networks, including ModBus and CANBus, with applications in elevator systems and others. Then, one key player in this industry, LonWorks, and an associated protocol, LonTalk, were discussed in further detail. In this discussion, functional profiles particularly designed for elevators were presented.

In this concluding article of the series, another key industry player, Building Automation and Control Networks (BACnet), will be the main theme. The history of BACnet’s development started in 1995, when the first BACnet specification was published. The latest version, Standard 135-2012, was published in 2012, and is continuously being updated. The recent development of BACnet related to elevator systems is the main focus of this article.

What Is BACnet?

BACnet is a standard, open and interoperable communication protocol developed by the American Society of Heating, Refrigerating and Air-Conditioning Engineers (ASHRAE). It provides the communication infrastructure needed to integrate products made by different vendors and to integrate building services used independently of each another.

History of Development

Up to the mid 1980s, protocols used in building management systems (BMSes) were proprietary; therefore, islands of systems by different vendors were connected to each other by gateways as translators of proprietary protocols. The solution was to combine all of them together, while data would be consistently and repeatedly used by different systems when intercommunication was carried out. In January 1987, ASHRAE began developing an industry-standard communication protocol for building automation and control systems. The Standard Project Committee (SPC) 135P was formed to accomplish the task. Its members came from manufacturers, engineering consultancies, universities and governmental agencies from the U.S. and Canada. In 1988, another solution was proposed, which became LonWorks in the 1990s (EW, July 2014). In 1990, a solution from Europe resulted in the formation of the European Installation Bus Association (EIBA). These three open protocols laid the building-controls platform for BMSes around the world. In the late 1990s, EIBA, Batibus and the European Home System, merged to form the Konnex Association (EW, July 2014).

According to Bushby,[1] the first meeting of the SPC was conducted in June 1987. In August 1991, the first public review of the proposed BACnet standard was published for comment, which generated 507 comments from six different countries. A revised version of the draft standard was published in March 1994 for a second review, which generated 228 comments from 12 countries. A third and final public review was done in March 1995, generating six comments. This 1995 version was called ASHRAE – 135, which became an American National Standards Institute standard in the same year.

In 1998, two BACnet Interest Groups (BIGs) were formed in North America and Europe. In 1999, the BACnet Manufacturers Association was established. In 2000, BACnet Testing Laboratories (BTL) was formed, which later came under the umbrella of BACnet International (a global organization to promote BACnet) to support compliance testing and interoperability testing activities, consisting of the BTL Manager and Working Group (WG). The WG was formed by BACnet International to oversee the establishment of the BACnet conformance certification and listing program. The WG is comprised of members of BACnet International and BIG-Europe, the goals of which are to promote and maintain the BACnet and BTL trademark.

In 2001, BACnet version 2001 was released. In 2002, the first BTL-listed device became available. The same year, the Extensible Markup Language (XML) WG was established to look at the possible utilization of this commonly used markup language to support BACnet. This was so BACnet would no longer be a simple protocol between control devices – enterprise solution systems and computerized facility-management systems could also talk in it. In 2003, BACnet became an international standard, designated ISO 16484-5. In the same year, BACnet Methods of Testing and Conformance, ASHRAE – 135.1, was published. Then, BACnet version 2004 was released. In 2005, the 100th BTL-listed device was available to the industry. In 2008, BACnet version 2008 was released. Now, there are more than 726 unique vendor identification designations (IDs) in the world. Each vendor manufacturing BTL-listed devices is listed, and we are using the latest BACnet version, 2012.

Modern BACnet

Now, despite its ASHRAE designation, BACnet is not only used in the heating, ventilation and air-conditioning industry. It is also applied in closed-circuit TV, laboratories, lighting, security, access control, and fire and life safety. Its application in the vertical-transportation industry is considered brand new.

The 2012 BACnet standard defines seven network types (Figure 1): BACnet Internet Protocol (IP) (most popular), BACnet master-slave/token passing (MS/TP) (second-most popular), BACnet over Ethernet, BACnet over ARCNET, BACnet Point-to-Point via RS-232 or telephone, BACnet over LonTalk, and BACnet over ZigBee (a wireless network).[3] BACnet is only implemented on four of seven layers of the ISO OSI, called the “collapsed OSI.” “BACnet IP” means the BACnet protocol is written in terms of IP but not channeled through IP. BACnet achieves device interoperability in three ways: objects (information), services (action requests) and transport systems (internetworking, electronic messages).

BACnet presently defines 54 different standard object types, functions of which are similar to those of network variables in LonWorks. Objects may be physical or virtual, single or multiple. The existence of standard object types is important, as their meaning and application are well defined and consistently implemented in devices of different vendors. Every object has properties (currently, there are more than 190 standard properties), which give the exact information of the BACnet objects. For example, a temperature sensor is an analog input object, while the present value, in degrees Fahrenheit, is one of its properties.

Devices communicate with one another by sending and receiving services. Each service request and the returned service acknowledgement (reply) become a pair of message packets transferred over the network between the sending and receiving devices. The program running on each device issues the service requests and processes them upon receipt. All services are grouped into five categories: object access (read, write, create and delete), device management (discover, time synchronization, etc.), alarm and event (changes of state, etc.), file transfer (trend data and program transfer) and virtual terminal (human/machine interface).

The transport systems of BACnet are the different network types used (i.e., ISO OSI levels 1 and 2). It should be noted that the exact content remains the same, no matter which network is used to transport a message. Only in this way is a gateway not required in a BACnet network.

BACnet defines five interoperability areas to reach its main goal: data sharing, trending, scheduling, alarm and event management, and device and network management. All are represented by different BACnet Interoperability Building Blocks (BIBBs). To show users how a BACnet device performs, a standard “manual” for each device is enforced: the “Protocol Implementation and Conformance Statement (PICS),” which is basically a standard datasheet for disclosing BACnet features implemented on that device. Again, like LonWorks, the PICS concerns the input/output interfaces of a device, while the internal control programs are not governed. The PICS normally consists of the following information of a device:

1. Product name, version and description
2. Device profile, workstation, building controller, smart sensor, etc.
3. BIBBs support
4. Segmentation support and window size
5. Standard object types support
6. Media-access-control layers support
7. Device address static building support
8. Networking options support
9. Character sets support.

BACnet Usage Issues

According to Hoffmann,[2 & 4] BACnet has to be specified correctly to be fully interoperable. Here, interoperability means that devices, even manufactured by different vendors, can be connected and work together to accomplish a big task. It should be noted that interoperability is much more than communication between two devices. It is only useful when two devices from different vendors can communicate with each other, then cooperate to work together for the same goal. A specification should include all information facility executives want to be able to access via BACnet. Common questions may be related to the goals for the BMS, specific information that needs to be visible, format of display or user friendliness. Knowing the answers to these questions up front will help specifying engineers take these needs into consideration during the design process.

BACnet is only a set of protocols for communication between electronic devices and computers. Therefore, BACnet by itself does not determine how a building-automation system is programmed or scheduled to work as a whole. Hence, information in the specification should also include the sequence of operations, a points list and input/output points that should be accessible via BACnet.

BACnet for Elevators

According to Chapter 14 of the Chartered Institution of Building Services Engineers Guide D: Transportation Systems in Buildings,^[5] there are many advantages for the remote monitoring of elevators, including fault monitoring, condition-based monitoring, video monitoring, data logging, site personnel safety, alarms and vandalism control. Remote monitoring can improve reliability and availability of an elevator system as building management can closely keep track of the operation of the system in real time. In this way, the response time to attend to faults and release trapped passengers can be shortened.

In 2006, your author was engaged by the Architectural Services Department of the Hong Kong Special Administrative Region government to work on the development of common protocols for elevators owned by the government in Hong Kong. The developed protocols should be both machine and platform independent, making time-consuming collaboration between an elevator company and the BMS supplier unnecessary wherever an integration project is run. It took almost one year for your author’s team to finish the project with the recommendation of three proposals, using XML, LonTalk and BACnet, respectively. The three systems, involving the development of a universal lift and escalator gateway for converting the proprietary protocol of the elevator supervisory controller to our open protocol, were installed and tested at two real sites in Hong Kong.

After the project was completed, your author met the late Bill Swan, who had been chairman of ASHRAE’s SPC 135 for several years. He was very interested in elevator systems and supportive, and we worked together to produce the first draft of elevator-related BACnet objects in early 2010. Unfortunately, he passed away in mid 2011, and it took more than a year before the drafted objects were ready for the first public review. Prior to this, a joint paper between Swan and your author was published to introduce the draft.[6] The second public review was completed in early 2014. We are looking forward to the final approval before the end of 2014.

The hierarchy of a standard elevator (including both lifts and escalators; here, the name “elevator” is used in a more general sense) object was designed jointly. It involves buildings, machine rooms (for lifts) or machine compartments (for escalators), elevator groups, and individual lifts or escalators (Figure 2). Such objects consist of properties that represent the current status of the installation. Though such a design easily makes sense to elevator engineers, it is not compatible with the standard format of BACnet. Some modification is necessary, which is the version included in the second review document (Figure 3).

The elevator group object consists of the properties listed in the left column of Figure 4. Here, new properties were introduced, such as “Landing_Calls” and “Landing_Call_Control.” The latter is a limited control command that can be issued by the BMS remotely as if a passenger were to push the landing-call buttons on site.

The lift object or escalator object is much more complicated, with new identifiers (Figure 4). Here, “Making_Car_Call” and “Car_Door_Command” are two remaining remote commands allowed, as if a passenger made a car call inside a lift car or opened/closed the car doors manually. Besides the standard safety signals, properties like “Car_Load,” “Car_Position” and “Energy_Meter” are new for evaluating the energy-performance benchmarking parameter, J/kg-m, discussed in Part 1 of this article series.

Some systems utilizing the objects and services are quite large or remotely spaced and thus connected by IP networks. For this reason, data is not considered to be conveyed in a timely manner, yet a BMS needs to be able to know which data it has are the latest. Moreover, the Internet itself is not synchronous, while the elevator system is very dynamic, changing second by second. This led to the introduction of time-stamped data. Also, because of the potential for large numbers of change-of-value (COV) subscriptions (and runtime changes in those subscriptions), the ability to subscribe and unsubscribe for COV notifications in a single request (on a number of properties of a number of objects) is provided. The ability to convey multiple object COVs in a single notification is also available.

Conclusion

In this article, the BACnet structure has been briefly looked into, while the data structure of the newly developed elevator group object, lift object and escalator object has been introduced. With these objects, the communication between a BMS and an elevator supervisory controller becomes straightforward, and there is no need to interconnect them on a project-by-project basis. With these objects hopefully approved in the near future, BACnet could officially be implemented in the greater elevator industry.

Acknowledgement

Your author would like to dedicate this article in memory of his late friend, Bill “BACnet Bill” Swan, for all his contributions to and efforts on the preparation of BACnet’s new objects and properties.

References
[1] Bushby, S.T. “BACnet – a standard communication infrastructure for intelligent buildings,” Automation in Construction, Vol. 6, No. 5-6, 1997, p. 529-540.
[2] Hoffmann, T. “BACnet: Setting the New Standard,” Johnson Controls Building Efficiency White Paper, August 2010.
[3] Martocci, J.P. “Bacnet Unplugged – Zigbee and BACnet Connect,” ASHRAE Journal, June 2008, p. 42-46.
[4] Tom, S., “A Simple Way to Specify BACnet,” BACnet Today – A Supplement to ASHRAE Journal, November 2005, p. B27-B32.
[5] Chartered Institution of Building Services Engineers Guide D: Transportation Systems in Buildings, 2010.
[6] So, A. and Swan, B., “BACnet for Elevators,” Elevatori, Vol. 1, Jan/Feb, 2011.