A comparison of the CEBus's CAL and the BACnet protocols for home and building control.

Introduction *

Overview of the protocols *

BACnet *

CAL *

Comparison of the protocols *

Link and Media standards *

Addressing *

Object models *

Protocol Encoding *

Flexibility *

Scaling *

Typical hardware requirements *

Industry adoption *

Summary *

References *

Introduction

There are two popular application level standards for home and building automation, BACNet and CEBus. BACNet, Building Automation and Control Network, is targeted at larger scale industrial applications like office buildings or campus settings. CEBus’s CAL, Consumer Electronics Bus, Common Application Language, is seen as a protocol exclusively for home automation. Within the home/building automation industry, these two protocols seem to have completely different applications.

However, from first glance, these protocols seem to have more similarities than differences. They both allow for integration of currently disparate home and office subsystems. They both view devices on the network as collections of objects. They are both connectionless. Finally, they both sit on top of a protocol stack that allow for various lower layer protocols and media types.

This paper will compare and contrast the two application level protocols. I will try to see if they are truly the same thing or if they have major differences making them unsuitable for each other’s job.

Overview of the protocols

BACnet

BACnet is the Building Automation and Control Network. It is a standard developed by ASHARE (American Society of Heating, Refrigerating, and Air-Conditioning Engineers) and adopted by ANSI in 1996. Its main goal was to be able to integrate the many proprietary control systems that had been independently developed by various HVAC companies. The standard defines the format of the data used to communicate between the different systems. It doesn’t define an API or any device-internal requirements.

Below is how BACnet relates to the OSI Reference Model.

CAL

CAL is the application layer of the CEBus protocol suite. CEBus was designed to enable new interoperability between devices in the home. Development of the standard began in 1984. In 1992 it was adopted as an EIA standard. It is about to, or may already have, become an ANSI standard.

CAL specifies how the different devices on the network, like stereos, light switches, and burglar alarms, share status and control information.

Below is how the CAL layer fits into the OSI model. Note that even though CAL is part of the CEBus standard, it is being enabled to run on different protocol stacks. Also, some of the functionality that would appear in the transport layer is actually handled in the application layer by CAL. This includes message acknowledgement and re-sending.

Comparison of the protocols

Link and Media standards

Both CAL and BACnet support a number of different link standards. They are summarized in the table below.

The original intent for CEBus’s CAL was that it would only use the CEBus link layer. With the standardization of CAL on other links, this no longer the case. However, the typical setup for HPnP/CAL will most likely be on the CEBus lower layers. This is because the popular media choices for the CEBus, PLC and twisted pair, involve limited or no additional wiring to the facility.

Regardless of media, the CEBus protocols use CSMA/CDCR (Carrier Sense Multiple Access/ Collision Detection Collision Resolution) and an encoding scheme of transitioning the line between "Superior" and "Inferior" states. A "1" is a state lasting 100us, a "0" is a state lasting 200us. There are also special "end of field" and "end of packet" markers which are states lasting 300us and 400us respectively. The encoding of the inferior and superior states on the media varies depending on the media type. The actual data rate of the CEBus links varies depending on the data being sent. It averages about 8,500 bits/sec. To make up for the low bit rate, the twisted pair and coaxial media also contain channels for streaming data such as video or sound in analog format. The slow data rate and the superior/inferior states make possible a simple and effective collision detection and resolution scheme. (see [Evans])

IEEE 1394 is a high-speed link between computer peripherals. The standard for running CAL on top of 1394 is still being finalized.

MS/TP (Master-Slave/Token-Passing) was mostly designed to lower the costs for setting up BACnet as an automation solution. It is based on RS-485 so that means it uses twisted pair and can use a normal UART instead of a custom IC. An MS/TP based device is either a slave or master. Slaves can only respond to requests while masters can initiate requests. As a result slaves can be much simpler since only the masters will need to contain the token management logic.

LonTalk was originally a proprietary protocol from Echelon Corp. It lets LonWorks devices communicate with each other. The protocol has recently been made open, however, the spec is not yet widely available. The main reason BACnet was made to work with this protocol is that many sites already have a LonTalk infrastructure.

Arcnet, like LonTalk, is mainly an option for BACnet because there is already an installed base of Arcnet systems.

Addressing

CAL uses CEBus addresses to identify other nodes on the network. A CEBus address is split in to two parts, a two-byte "system address" and a two-byte "node address". The system address typically corresponds to the building that is being automated. It is particularly needed when using PLC since signals can easily get propagated to other houses that are on the same side of the power company’s transformer. The address space for the CEBus address is summarized in the tables below.

When CAL runs on a CEBus network, the addresses used map directly to the link layer. When it is used on other networks like Ethernet, some additional address resolution needs to happen.

BACNet addresses are a combination of a network number and a data link layer address. The network number is two bytes. The data link layer address can be from one to six bytes depending on the technology.

It is obvious that neither CEBus nor BACnet addresses were intended to be used in a large-scale network like the Internet. With less than 65,536 system/network addresses, a single internet could not cover the office buildings and houses in a good sized city. However, this number of address is more than sufficient for buildings on a corporate or college campus.

Object models

HPnP/CAL breaks up its view of the world into nodes, contexts, objects, and instance variables. A node is a device on the network like an air conditioner or TV. A context is a function of the node like the amplifier on a television or the thermostat on an air conditioner. An object represents a well-defined control or sensing task within the context. Examples of objects are the bass control in the amplifier or the overheating alarm in the thermostat. Finally, instance variables are the attributes of objects that are changed or monitored. Examples of instance variables are the units of measurement of the bass control or the current value of the alarm.

Standards bodies define CAL contexts, classes, and instance variables. Some of the existing CAL contexts are time, video display, security sensor, tuner, and light. Existing object classes include binary switch, binary sensor, analog control, analog sensor, motor, and multi position switch. Instance variables are usually referenced by a single letter and have attributes of type and read/write or read only. Ranges of context ID’s, object class ID’s, and instance variable names have been allocated for manufacturer use so that proprietary functionality can be added to new components while still staying within the bounds of CAL

Polling for state changes is possible by simply checking the value of instance variables repeatedly. It is also possible to register to receive notifications of changes. A node wanting to receive a notification of a change in, say, temperature would put it’s address, context ID of an internal context, object ID of an object in the context, and the instance variable name into instance variables of the temperature sensor. When the sensor changes value, it checks to see it should notify anyone by examining its instance variables. If so, it sends the change notification to the node, setting the appropriate instance variable. The address set in the instance variables can also be a broadcast address so that multiple listeners can get the information.

One can view the BACnet object model in terms of the CAL object model. If you remove contexts from the CAL model, you essentially have the basic BACnet object model. A BACnet device will contain a collection of object class instantiations. Defined object classes in BACnet include binary input, binary value, analog output, analog sensor, multistate input and multistate output. The objects have member values that are read and written in order to control the device. For example, a thermostat device on the network will have an object representing the current temperature. It will be of type "analog sensor" and have member values such as current value, units, and max value.

Devices on the BACnet can also either poll or register themselves for notifications. A device will contain event enrollment type objects that are contacted by clients who want to be notified.

Protocol Encoding

Both of these protocols are object oriented but the underlying network is not. There needs to be some form of encoding used. A complete comparison of the message encoding beyond the scope of this paper we will limit the comparison to how a "write property" request is encoded for CAL and BACnet.

CAL messages need to contain information about what context, object, and instance variable the value is destined for. The encoding of the information is defined fully by the CAL standard. The byte sequence below shows the command for setting the channel on a TV tuner.

BACnet allows for much more flexibility in its encoding. The format of BACnet PDU’s is defined in ASN.1. The encoding is based on the ASN.1 Basic Encoding Rules (ISO 8825). The byte sequence for a BACnet "write property" is as follows: [Butler]

Flexibility

Both protocols allow for additions. Additions happen either by standards being updated or by manufacturers using areas allocated for extensibility. BACnet probably has the upper hand in terms of flexibility due to its explicit encoding scheme.

However, adding functionality beyond the protocol specification is of limited value. On the automation networks, a client can only use features it knows about. It is unlikely that new features provided by manufacturer A will be used by manufacturer B unless it is standardized.

Scaling

Both of these networks are in the same situation in terms of size scaling. They each define a two-byte network address with no subnetting. The largest possible internet is less than 65,536 networks.

However, the application of home and building automation doesn’t benefit much from every network being connected. Some may argue that for safety and security reasons, it is probably best that these networks remain as disparate as possible.

CAL can be limited by CEBus slow speed. However both BACnet and CAL can go quite fast on a 1Gbps Ethernet.

Typical hardware requirements

CAL and CEBus in general has been designed from the ground up to be able to run on microcontroller based systems. CEBus applications have been implemented on various microcontrollers as well as on some sub-microcontrollers like the PIC processors

BACnet was also designed so that a microprocessor-based system could provide the needed support. BACnet compliant systems have been implemented on microcontrollers such as the 68HC05 and the 8051.

Industry adoption

Virtually every major HVAC systems company has produced or is in the process of delivering BACnet compliant systems. BACnet is currently in use at many installations. Companies that have proprietary systems are often providing BACnet gateways to their systems.

CEBus is still getting off the ground. A check of home automation suppliers shows very few CEBus products compared to other technologies like X-10. However, there are signs that things will pick up soon. IC’s that act as transceivers to the different CEBus media are becoming available from multiple sources for under $10. Microsoft, Honeywell, Intel and other companies are developing the "Home Plug and Play" standard which extends CAL to be more user friendly and transparent to users.

Summary

From a technical standpoint, these two protocols are very much alike. They accomplish very similar things in a similar manner. Their differences are further limited by the fact that they can run on many of the same types of network.

However, from the point of view of making purchasing decisions, you are still better off buying BACnet compliant technologies for commercial and industrial purposes and CAL/CEBus compliant equipment for home automation. It is unlikely that HVAC, elevator, and other industrial equipment producers will adopt CAL/CEBus. Just as unlikely is it that Sony will be building BACnet compliant televisions. Though technically possible, it is also unlikely that one side will abandon the other standard and have everybody on the same home/building automation standard.

References

"BACnet", http://www.emcs.cornell.edu/BACnet/BACnet.html

Butler, Jim, "BACnet: An Object-Oriented Network Protocol for Monitoring and Distributed Control," Circuit Cellar INK, February 1997, 26-33

Dunn, Adrian, "Building a CEBus-Compliant Product", Circuit Cellar INK, March 1997, 12-19

Evans, Grayson, "The CEBus Standard User’s Guide," The Training Dept. Publications, May 1996

Fisher, David, "BACnet and LonWorks: A White Paper," Polarsoft Inc., July 1996, http://www.alerton.com/whtpaper.htm

"Home PnP Task Force Report: Volume 1 HPnP Specification" Version 0.71, November 1996

"Questions and Answers about BACnet", http://www.alerton.com/bqa.htm

Swan, Bill, "Internetworking with BACnet", http://www.alerton.com/ES0197.htm

Swan, Bill, "LonWorks to BACnet – a Difficult Upgrade", http://www.alerton.com/lonwrk.htm

Swan, Bill, "The Language of BACnet-Objects, Properties, and Services", http://www.alerton.com/langbac.htm