AutomatedBuildings.com Article - Implementing Open, Interoperable Building Control Systems

Michael R. Tennefoss is the Director of Product Marketing at Echelon.

In the early days of building automation systems, before the advent of control networks, control systems consisted of pneumatic controls or wire bundles connected to relays, switches, potentiometers, and actuators. Cabling was installed in a point-to-point fashion between electrical panels, the sensor inputs and actuator outputs. The functionality of these control systems was relatively rudimentary and inflexible, and adds, moves, and changes required extensive rerouting of wiring and connections.

The advent of solid state technology offered a means of using logic circuits to replace wire and relays. Pneumatic controls and electrical panels gave way to direct digital controllers (DDCs), which were programmed or configured not with a screw driver but a data terminal. As increasingly powerful algorithms were developed, tighter control over processes could be achieved. However, the issues associated with adds, 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 (figure 1). 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 (figure 2).

The incompatibilities between products from different manufacturers were highlighted when customers attempted to interconnect DDC systems or devices 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.

Figure 2
Using Gateways In Workstations To Link 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. They allowed only limited status and control information to be passed between the different systems. Fault status information couldn't be shared, information from different sensors wasn't accessible for combinatorial logic programs, and systems couldn't adapt their responses in real-time based on receiving the overall system status. In addition, the gateways needed to be changed whenever one of the subsystems was modified, creating an open-ended development and support problem for integrators and facility owners alike.

Creating a seamlessly integrated control system requires interoperability among the components of that system, as well as other related systems that must exchange information (figure 3). Interoperability is the process by which products from different manufacturers, including those in different industries, exchange information without the use of gateways, protocol converters, or other ancillary devices. Achieving interoperability requires a standardized means of communicating between the different devices and managing device commissioning and maintenance; it depends on a system level approach that includes a common communication protocol, communication transceivers of different types, media routing, object models, and management and troubleshooting tools.

The benefits made possible by interoperability are many. Since one sensor or control device can be shared among many different systems, fewer sensors/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 systems. For example, in response to access control reader data and daylight illumination sensors, the HVAC and lighting systems can automatically adjust the comfort and illumination levels in pertinent work areas based on individual preferences and energy costs. Lighting can be adjusted on a cubicle-by-cubicle basis for computer operators and occupants near windows - either automatically or through commands entered from a user's PC via the corporate LAN. Heating and air conditioning can be similarly tailored. Or, based on signals from smoke detectors, the HVAC system can create positive or negative air pressure of select areas to cause a fire to move away from occupied areas while the lighting system leads the way to the closest exit. The possibilities are limited only by the creativity of the designers.

For a facility owner, interoperable products offer the advantage that devices can be selected from among different manufacturers; the owner is no longer tied to any one manufacturer's closed technology. Aside from the cost savings achieved by open competition, the facility owner is safe in the knowledge that replacement products will be available if any one manufacturer goes out of business or discontinues products. Service contracts can be openly bid since no proprietary devices will be used, thereby avoiding single source service contracts.

Interoperability also benefits equipment manufacturers because their products will be assessed based on their quality and functionality - not on their ability to meet a closed, proprietary specification. Interoperability levels the playing field and increases competition, insuring that the best devices for the job will win.

[an error occurred while processing this directive] In an effort to create a standardized method of interconnecting heating, ventilation, and air conditioning (HVAC) subsystems from different manufacturers, 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 originally 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® (an open control standard also known as ANSI/EIA 709.1).

BACnet defines a messaging format that uses objects (a logical representation of an input, output, or functional grouping of inputs and/or outputs), properties (the characteristics of an object through which it is monitored and controlled), and services (the means by which BACnet devices obtain information from one another). 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 of 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 - products which appear to perform identically may vary considerably in terms of their functionality and the accessibility of data.

While the BACnet standard had the potential to be open and non-proprietary, the means by which it has been implemented varies considerably 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. Proponents of BACnet envisioned, and facility owners have the right to expect, that BACnet workstations, sensors and actuators from different manufacturers may be used seamlessly in a common control network, and that devices from one manufacturer can be replaced by devices from another manufacturer without assistance from the manufacturer or the redesign of the control system. Due to variations in the implementation of BACnet PICS by different manufacturers, however, neither scenario has been realized. In short, BACnet devices from different manufacturers are neither interoperable nor interchangeable.

In an effort to bridge the gap between existing control networks and BACnet networks, and to appease engineers who are specifying BACnet because of its promise, 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. This allows the manufacturer to state that a product supports BACnet because BACnet packets can be received by the gateway and forwarded to the non-BACnet system, and vice versa.

The problem is that the use of a gateway violates the spirit of BACnet and fails to deliver interoperability to control systems. Why? As discussed earlier, 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. While gateway manufacturers may have had the best of intentions in mind, gateways do little to realize the promise offered by BACnet and instead merely extend the life of closed, proprietary systems.

The vision of a unified BACnet network has been lost, transformed into the reality of islands of proprietary networks linked by workstations and gateways running the BACnet protocol over IP-based LANs. Like silicon curtains, BACnet workstations and gateways impede the free flow of network information, making impossible peer-to-peer communication between sensors and actuators situated within different proprietary islands.

Furthermore, the market demand has moved beyond just integrated HVAC systems to integrated systems encompassing HVAC, lighting, security, life/safety, power management, submetering, and other control systems. These other applications were not contemplated for BACnet, and the protocol was not optimized for their operation.

This begs the question of what a specifying engineer or facility owner has the right to expect from an open, interoperable control system. If one accepts the original intentions of BACnet then one has the right to expect lower installed costs (due to open competition among vendors for like, interchangeable products), lower life cycle costs (from service contracts and/or replacement parts that can be purchased from multiple suppliers under an open bidding process), and enhanced functionality and expandability (from the many building control systems that can be interconnected with HVAC systems). To date BACnet has not delivered on its promise, and while beyond reproach in concept, BACnet has been sullied by hype that hasn't been matched in the execution of BACnet compliant products or systems.

One of the control networks specified within BACnet for communications between sensors and actuators is LONWORKS. Developed by Echelon Corporation, Palo Alto, California, 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, Internet Protocol (IP) servers, network interface cards, and development tools are all available off-the-shelf to speed development and reduce time to market. In short, LONWORKS offers a system level approach to interoperability, and comprises a complete set of tools and products.

The heart of a LONWORKS hardware device is the Neuron® Chip, an integrated circuit that combines a sophisticated communications protocol, three microprocessors, a multitasking operating system, and a flexible input/output scheme. Manufactured under license by Cypress, Motorola, and Toshiba, the Neuron Chip is sold and supported worldwide. Almost 10,000,000 have been shipped since 1992. Devices that complement and/or use Neuron Chips are available from Echelon and roughly 4,000 manufacturers worldwide.

Ensuring the interoperability of these network communications is the responsibility of an organization called the LONMARK® Interoperability Association. Funded through member dues, the LONMARK Association defines the interoperability guidelines for LONWORKS devices, including communication transceivers and object models. Products that bear the LONMARK logo are certified to adhere to the LONMARK interoperability guidelines and can be used with confidence in integrated control systems.

LONWORKS has been successfully used in a wide range of industries - building and industrial automation, transportation, and home/utility automation are the four largest markets for LONWORKS products. Besides its inclusion in BACnet, LONWORKS has been included in many international standards including IEEE 1473 (train control), ANSI/EIA 709.1 (control networks), TC247 (building automation), AAR (electro-pneumatic train braking), and the SEMI standard (semiconductor manufacturing equipment). Its inclusion in so many international standards has validated LONWORKS as an open standard. Likewise, its use by thousands of manufacturers, across many industries, has proven the utility of LONWORKS for a wide range of applications.

One of the reasons behind the success of LONWORKS is the availability of a powerful network management architecture that can accommodate real-world installation scenarios. After all, even a well designed control system needs to be changed from time to time. The LONWORKS Network Services operating system, LNS, provides a powerful client-server architecture that permits multiple installers to simultaneously configure a control system. In order to speed commissioning of devices from different manufacturers, LNS defines a "plug-in" standard. This standard allows sensor, actuator, and device manufacturers to provide customized applications for their products. When those products need to be configured, an LNS-based tool will automatically present a configuration screen that the manufacturer has tailored to the device being configured. Regardless of the LNS-based tool being used, the configuration screen for that product will remain consistent. This capability simplifies the task of training installers, allows device manufacturers to give the programming interface a unique look and feel, and permits tool vendors to offer products that are both unique looking and interoperable.

Figure 4 shows the LonMaker™ for Windows® Integration Tool from Echelon, an LNS-based tool that implements a Visio® user interface. Visio provides users with a familiar, CAD environment in which to design a control system, and Visio's smart shape drawing environment offers an intuitive, simple means for creating devices. The tool includes a number of smart shapes for LONWORKS networks, and users can create new shapes for unique device configurations or complete subsystems. Stencils can be constructed with predefined devices, function blocks, and connections between them. Master shapes corresponding to complete subsystems can be created and saved. Additional subsystems can then be created by simply dragging the shape to a new page of the drawing, a time-saving feature when designing complex systems.

To ensure interoperability, LNS supports the LONMARK interoperability guidelines. LONMARK features such as standard functional profiles, configuration properties, resource files, and network variable aliases make it possible to achieve interoperability between tools, devices, and tools and devices.

The Internet: Connecting Devices, Workstations and Browsers, Locally and Across the Globe

One of the underlying tenets of LONWORKS is that every device in a network should have the ability to send packets to, and receive packets from, any other device in the network without an intermediate gateway that filters and modifies information. This capability is one of the cornerstones of any open, interoperable, peer-to-peer network. Importantly for the BACnet world, LONWORKS allows customers to use an IP-based network (including LANs, WANS, and the Internet) as a seamless pathway to communicate with workstations, sensors, actuators, and displays. Where BACnet workstations and gateways act like silicon curtains and filter out information, LONWORKS Internet Servers intelligently route LonTalk packets through the IP network by tunneling, making these packets available to any sensor, actuator, or workstation that needs them.

For example, Echelon's i.LON™ 1000 Internet Server (figure 5) incorporates Cisco's Network Foundation Technologies to offer Layer 3 packet routing through an IP network. Certified by Cisco under their NetWorks™ program, the i.LON 1000 seamlessly links the data and control networks, allowing the IP network to be treated as an extension of the LONWORKS network, and vice versa. All of the features of LONWORKS networks - peer-to-peer networking, network management, device diagnostics, software downloading, secure access, and so on - are supported over IP networks. From the IS perspective, the i.LON 1000 includes SNMP MIB II, TCP/IP, UDP, DHCP, ICMP, SNTP, TOS, HTTP, FTP, and MD5 support. The i.LON 1000 also includes a programmable packet aggregation feature which throttles the rate at which control packets are broadcast on the IP network, ensuring that the IP network is not overwhelmed with control-related packets.

The ability of the i.LON 1000 to tunnel LonTalk packets through an IP network allows devices to communicate on a peer-to-peer basis across a LAN that connects floors of a building, a WAN that connects buildings within a city, or over the Internet to facilities spread around the world (figure 6). The i.LON 1000 eliminates the need to install a separate and dedicated data network for the control system, and instead permits the existing data infrastructure to be used for control networking, saving both installation and on-going maintenance costs. The i.LON 1000's integrated Web server and access security also permits authorized support and service personnel to observe and control the LONWORKS network, using Internet Explorer or Netscape Navigator, from any PC or laptop running locally or over the Internet.

As another example of LONWORKS IP connectivity, the standard LONWORKS network operating system - LNS - includes remote Internet Protocol (IP) client support. This feature allows software applications on IP-connected workstations to interact with an LNS Server connected to the same network. These applications can monitor, control, diagnose, or reconfigure the LONWORKS network (figure 7) via the Internet or any other IP-based network.

Used together, the i.LON 1000 and LNS provide LONWORKS networks with all of the functionality originally envisioned for BACnet devices and workstations, but without the drawbacks and limitations of the BACnet systems actually being fielded:

While LONWORKS is specified within BACnet at the sensor bus level, the many proven capabilities of LONWORKS networks - including those which BACnet was originally intended to offer but were never realized - begs the following question: Has LONWORKS supplanted BACnet as the solution for open, interoperable HVAC control? The answer to this question should reference the original intentions of BACnet, namely satisfying what a specifying engineer or facility owner has the right to expect from an open, interoperable control system. Let's review these points individually:

In consideration of these goals, LONWORKS does indeed satisfy the needs of specifying engineers and facility owners with regard to what they should expect from an open system, while BACnet does not. Moreover, the market appears to have spoken with regard to the overwhelming commercial acceptance of LONWORKS within the building automation industry, by manufacturers, integrators, and facility owners alike. According to the BCS Partners report BCS/99 - The Building Controls Systems Market (1998-2003), manufacturers representing approximately 70% of the worldwide building control system market are building and shipping LONWORKS-based products. Market leaders in the wiring device, lighting, emergency lighting, ballast, elevator, variable frequency drive, sunblind, security, fire/life-safety, closed-circuit television, standby power, power measurement, and submetering markets are likewise building and shipping LONWORKS-based products. Based on both unit shipments and actual market penetration, one can only conclude that LONWORKS is the solution for open, interoperable building control, including HVAC applications.

If the BACnet community is to avoid the painful downward spiral of CAB and other previous control standards efforts, perhaps the best future direction is to join ranks with the LONWORKS community. By joining in the efforts of the LONMARK Interoperability Association, BACnet community members can have a say in the future direction of LONWORKS and the integration of different subsystems.

The world of control systems has come a long way technologically since the advent of DDCs. The availability of LONWORKS control network technology has opened the door to a new generation of open, interoperable control systems. LONWORKS delivers on the benefits promised by BACnet - higher reliability, greater vendor choices, and lower life-cycle costs - while BACnet itself has fallen short in these areas.

Michael R. Tennefoss is the Director of Product Marketing at Echelon. Mr. Tennefoss joined Echelon from Stellar Systems, a manufacturer of intrusion detection sensors and alarm monitoring systems, where he served as Director of Monitor & Display Products. Before joining Stellar Systems, he was the Director of Marketing at ETP and Vice President of Marketing at Vindicator Corporation. Echelon's LONWORKS technology was introduced in 1990 and is today being built into next generation products by thousands of companies in a wide variety of industries -- from factory automation to energy control systems to consumer electronics. Echelon Corporation provides a full range of hardware and software products to support the development of control networks. Echelon is headquartered in Palo Alto, California, and has subsidiaries throughout Europe and in Japan and China. Echelon is located at 4015 Miranda Avenue, Palo Alto, California, 94304, USA, Phone +1-650-855-7400, FAX +1-650-856-6154.

[an error occurred while processing this directive]
[Click Banner To Learn More]

Events	Want Ads
Our Sponsors	Resources