Buiilding Controls: Open Systems and LonMark

In the early days of building automation systems, before the advent of control networks, control systems consisted of masses of wires connected to relays, switches, potentiometers, and actuators. The advent of solid state technology offered a means of using logic circuits to replace wire and relays. Electrical panels gave way to direct digital controllers (DDCs), which were programmed not with a screwdriver but a data terminal. As increasingly powerful algorithms were developed, tighter control over processes could be achieved. However, issues associated with add-ons, moves, and changes remained and grew increasingly complex as systems grew in size. The software required to handle large systems was very complex: each controller represented a single point of failure, and each controller was still tethered to all of the sensors and actuators by cable bundles that were not easily modified. Moreover, the manufacturers of DDCs developed them using proprietary internal architectures: if you wanted to expand a DDC system then you had to use components from the original manufacturer.

The incompatibilities between products from different manufacturers were highlighted when customers attempted to interconnect DDCs from different manufacturers. The use of incompatible communication protocols, data formats, and electrical interconnections made it very difficult to exchange information. Seeking the communication equivalent of the “least common denominator,” systems integrators and manufacturers turned to the use of gateways at the workstation level to tie together subsystems from different manufacturers.

The problem was that these gateways didn’t provide a detailed, seamless view into the different systems to which they were connected. Creating a seamlessly integrated control system requires interoperability among the components of that system, as well as other related systems that must exchange information. The benefits made possible by interoperability are many. Since one sensor or control device can be shared among many different systems, fewer sensors and controls are needed and the overall cost of the control system drops appreciably. For example, in a building automation system one interoperable motion sensor can share its status with the zone heating system for occupancy sensing, the access control system for request-to-exit purposes, the security system for intrusion detection, and the fire alarm system for occupancy sensing. The motion sensor still performs the same task — detecting motion — but it can share the information with the many subsystems that can make use of its status.

The ability to share more information between systems makes possible many long sought-after applications, including integrated energy control.

The dawn of BACnet

In an effort to create a standardized method of interconnecting subsystems from different manufacturers, the American National Standards Institute (ANSI) and the American Society of Heating Refrigeration and Air Conditioning Engineers (ASHRAE) set about to create an open standard called Building Automation and Control NETwork (BACnet). BACnet was intended to eliminate the need for proprietary gateways between workstations by defining a standardized means of communicating over a local area network (LAN) to which the workstations were connected. Several different LANs were defined including point-to-point, master slave/token passing, ANSI/ATA 878.1, ethernet, and LonTalk.

Since under BACnet devices can have varying levels of functionality, even if they perform the same task from an end user’s perspective, BACnet defines conformance classes that categorize the capabilities and functionality of devices.

Devices within a conformance class must have a minimum set of features, but optional features are permissible. All the features of a device are presented in a device’s Protocol Implementation Conformance Statement (PICS). A specifying engineer needs to know which objects and services are supported by which devices, since this varies from device to device, and the PICS provides most of this information. The PICS represents a point at which manufacturers can diverge in their implementation of BACnet.

BACnet offers no standardized installation or maintenance structure, depending instead on each device manufacturer to provide any necessary network management tools. These tools are invariably proprietary and their capabilities and features vary from manufacturer to manufacturer. This variability has undermined the fundamental precepts of what BACnet was intended to be and do, and has resulted in the creation of closed, proprietary BACnet devices.

In an effort to bridge the gap between existing control networks and BACnet networks, some manufacturers have turned to BACnet gateways. The function of a BACnet gateway is to convert data from the format used by one control network into the BACnet format. The problem is that the use of a gateway violates the spirit of BACnet. In the process of converting information between two networks a gateway discards information, thereby limiting the scope of the tasks that can be performed across the gateway. Diagnostic information from nodes, network traffic statistics, network management messages — all are affected by the insertion of a gateway.

Lonworks technology

One of the control networks specified within BACnet for communications between sensors and actuators is Lonworks, developed by Echelon Corporation. Lonworks technology allows all manner of control devices to communicate with one another through a common communication protocol that is shared among all devices. Communication transceivers and transport mechanisms are standardized, as are object models and programming/troubleshooting tools to enable the rapid design and implementation of interoperable, Lonworks-based devices. Network management software, protocol analyzers, IP routers, PC and PCMCIA interfaces, and development tools are all available off the shelf to speed development and reduce time to market.

The heart of Lonworks is the LonTalk protocol, an open control standard also known as EIA 709.1. This protocol can operate on any processor; however, most applications have used a hardware implementation known as the Neuron Chip manufactured under licence by Toshiba.

Ensuring the interoperability of these network communications is the responsibility of an independent organization called the Lonmark Interoperability Association. Funded through member dues, the Lonmark association drafts interoperability guidelines for Lonworks devices, including communication transceivers and object models.

Michael R. Tennefoss, director of product marketing, Echelon Corporation, Palo Alto, California.