A Look Inside Two Open System Control Technologies

A Look Inside Two Open System Control Technologies

To improve performance of equipment, reduce operating costs, and comply with state and federal energy regulations, facility owners and managers want to achieve building automation in the most economical way. Thus, an open system technology one that breaks the sole source lock, enables competitive bidding, and allows for selection of the best products is today's vision. To achieve the goal of vendor

To improve performance of equipment, reduce operating costs, and comply with state and federal energy regulations, facility owners and managers want to achieve building automation in the most economical way. Thus, an open system technology — one that breaks the sole source lock, enables competitive bidding, and allows for selection of the best products — is today's vision.

To achieve the goal of vendor independence, a user must be able to purchase products from many vendors and easily install them in new or existing networks. To achieve the goal of interoperability, a user must be able to create a control network that consists of dissimilar systems, like HVAC, lighting, security, elevator service, and fire/life safety, and have them all work together in a seamless manner.

Many control technologies claim to be “open,” but only the BACnet standard and the LonWorks technology have gained wide use in building automation systems. Let's look at the two control concepts and do some comparisons.

The BACnet platform. Developed by ASHRAE in the mid '90s, BACnet (an acronym for building automation and control network) is a communications-only standard developed for a building's mechanical and electrical systems, particularly heating, ventilation, and HVAC. The standard describes rules for data communications and for programming and installing the hardware (the devices that are controlled along with other items, such as network controllers and gateways) that respond to the supported protocols. A communications protocol is a set of rules that defines the method for sending and receiving messages on a network.

BACnet is based on a 600-page document and defines six broad categories of conformance classes that describe general features that a device in that class must provide. Generally speaking, a class with a higher number has more features implemented at a device. Every device has an “object,” and the standard lists 23 virtual objects for representing most of the functions in a building. The virtual objects, such as binary input, analog output, schedule, and calendar, can be grouped together to represent specific functions. The objects have a set of properties that represent information about system operation or that provide operating parameters and commands.

The BACnet standard leaves many implementation decisions to the discretion of the product manufacturers. Thus, building control system makers add optional properties to standard object types to gain specific features. In the case of a temperature sensor, a firm might add a property to the “schedule” virtual object, which sends temperature information to a central database every 24 hours.

BACnet supports five different network protocols. The first is Ethernet, which can run at speeds up to 100 Mbs and is the most popular communications protocol. Next comes ARCNET at 2.5 Mbps. Both Ethernet and ARCNET use a variety of physical media, including twisted-pair, coaxial, and fiber optic cable. For devices with lower transmission speed requirements, BACnet defines the MS/TP (master slave/token passing) protocol that runs at speeds of 1 Mbps or less over twisted-pair conductors. Finally, the LonTalk protocol, which also runs on various media, is supported. All four of these protocols are examples of LANs that can be designed in various topologies, such as a tree or star. BACnet also defines a dial-up, point-to-point protocol, called PTP, for use over phone lines or hardwired EIA-232 connections. It runs at speeds of up to 56 kbps.

BACnet uses a four-layer collapsed architecture structure, corresponding to the physical (1), data link (2), network (3), and application (7) layers of OSI seven-layer reference model. For that reason, the BACnet application layer is more complicated than a protocol that uses all seven layers of the reference model. Data carried on the network must be encoded using ANS.(1), which isn't widely used.

To enable the communication of data among different devices in a building control system in a timely manner, BACnet defines a set of message types. Thus, if a smoke detector goes into alarm, a user can set up to 16 levels of priority for command messages that go to lighting or damper controllers, for example. This feature also applies to other building functions, such as energy management.

All major control and equipment manufacturers have a BACnet gateway product, and some have developed a complete BACnet building solution, called Native BACnet, that applies the standard from the controllers to the supervisory computer in a tiered architecture.

A device that conforms to the BACnet protocol must have a Protocol Implementation Conformance statement that identifies what portions of the protocol are implemented. However, certification is voluntary. Since BACnet is under constant development and review, the list of classes and objects can be extended.

In promoting the use of this standard, the BACnet Manufacturers Association created the BACnet Testing Lab (BTL) to certify devices. The testing process is somewhat complicated, and at present only the simpler functions receive evaluation.

The LonWorks platform. LonWorks technology, which was developed by San Jose-based Echelon, combines a communications standard, called LonTalk, with a specialized microprocessor called the Neuron chip, along with other products and services. The LonTalk communications protocol allows a peer-to-peer data exchange at the field level (the sense and control devices), thus creating a flat network architecture, which can be called a distributed control system or a local operating network.

Unlike other protocols like TCP/IP, the open standards-based LonTalk protocol is optimized for efficient transmission of small packets, making it ideal for a control system in a building or a campus.

Nevertheless, the LonTalk protocol can be encapsulated in the TCP/IP protocol. By encapsulating LonTalk, any network hardware that uses TCP/IP, including Ethernet, Arcnet, ATM, Frame Relay, PPP, and Sonet, can be used. Additionally, Ethernet/Internet routers can encapsulate LonTalk in IP packets for delivery over a WAN.

The LonTalk protocol embraces all seven layers of the OSI model and handles tasks such as media access and transaction acknowledgment, along with more advanced services such as sender authentication, priority transmission, duplicate message detection, and recovery. The features of the seven-layer protocol in LonTalk are summarized in the Table above.

At the Data Link level of the OSI model (media access and framing), the LonTalk protocol uses a proprietary collision prediction algorithm called predictive p-persistent CSMA (collision sensing multiple access), which permits a channel to carry its maximum capacity, rather than having its throughput degrade due to excess collisions. Collisions that reduce throughput can occur with some versions of the Ethernet protocol, which also uses the CSMA procedure. At the fastest data rate of 1.25 Mbps, using twisted-pair, the LonTalk protocol supports more than 500 transactions per second, in the case of a 12-byte message length.

The special microprocessor, or Neuron chip, which is actually three 8-bit inline processors (two to execute the LonTalk protocol and one for the node's application) in a single package, is a key to interoperability and to the flat network architecture. Echelon's partners, Cypress Semiconductor and Toshiba, make the chip, which is available in different versions, although they all share the same basic features of the processors, the memory, and the communications functions in various combinations. Additional control or data processing applications can be gained by interfacing the Neuron chip to more powerful processors through a microprocessor interface program (MIP).

Referenced in a number of standards, such as ANSI/CEA 709.1 and IEEE 1473-L, the LonTalk software instructions are written in Neuron C, which is basically the ANSI C programming language, plus three extensions.

At the application level on a LonWorks network, standard network variable types (SNVTs) are used to ensure interoperability of devices. An SNVT definition can consist of units, a range, and an increment. Two examples would be a variable type of “temperature” consisting of Fahrenheit units, a range of ± 3,200, and an increment of 0.1° — thus referring to a thermometer. A second example would be a sensor that records relative humidity, with units of percent, a range of 0-100 and an increment of 1/256%. Most applications can be specified using SNVTs, but users are able to define anything they need.

LonMark International — previously known as the LonMark Interoperability Association — is a group of manufacturers and others in the industry formed to set up standard ways of implementing LonWorks technology. Using LonWorks devices makes it possible to achieve interoperability; however, using LonMark-certified devices makes it even easier to accomplish that goal.

For example, a LonMark-certified temperature sensor follows a set of rules, known as a LonMark functional profile, which has mandatory and optional elements. A manufacturer can't alter the mandatory elements but can add specific functions for greater usefulness. With some recent changes in the published guidelines regarding profiles, installing devices is easier than it was in the past; version 3.3 is considered the best. The LonMark logo indicates which revision of the guidelines the device follows, and a vendor shouldn't sell a device based on guidelines prior to 3.0. Backward compatibility isn't followed.

The LonWorks technology platform also includes transceivers, network management tools, and databases needed to integrate devices in a control network.

Comparing the two platforms. Generally, defining one or the other as being better is difficult. The best system is one that meets a client's requirement for performance, function, and overall life-cycle cost. In fact, some installations are a hybrid of both BACnet and LON protocols, integrated into a single design to satisfy a building's requirements. Gateways are available from many firms that allow the two systems to share data. And third party products are making integration significantly easier.

Nevertheless, many consultants and engineers, in considering their client's definition of an open system with device-level integration, select the LonWorks product line. They consider it to be the best solution based on cost, flexibility, and vendor independence. LonWorks has good field-level integration capabilities among many manufacturers, and the owner can select from various network management tools and third party options for graphic displays.

Generally, a free topology, twisted-pair network is less expensive to install than an RS-485 network. In addition, with LonWorks, an integrator can select products from the device level on up from various manufacturers and rest assured that they'll work smoothly together. And the ability to communicate through the AC power circuits makes LonWorks an economical choice for lighting control, daylighting window control, electric power sub-metering, security, and other functions.

On the other hand, BACnet is developing device-level profiles, so the advantage held by LonWorks will disappear some time in the future. Furthermore, a number of DDC system makers are boosting their support of BACnet. Consider also that the BACnet protocol runs well on a supervisory controller, or head-end workstation, where alarming, scheduling, and trending are carried out.

Two other factors will work to reduce the cost of building system monitoring and automation in the future. Wireless devices and mesh networking will lower the installed cost for BACnet, LonWorks and all facility control systems. Secondly, XML and Web services will push the integration of building systems and simplify the sharing of operational data with a user anywhere on the globe.

At present, some facilities managers are reluctant to fully automate their environmental controls — but are very much interested in monitoring the major functions in the building — as a way of fostering energy savings.

Author's note: Based on material provided by Echelon, Douglas Lighting Controls, and the BACnet Manufacturers Association.

Sidebar: Using Training to Boost Application

At the IBEW Local 164 Training Academy in Paramus, N.J., Richard Paredes, LonWorks instructor and systems integrator, is familiar with control networks that use lighting system devices such as wall switches, multi-circuit switching panels, and dimming electronic ballasts that have LonWorks capabilities. In teaching his classes, he demonstrates how easy it is to set up a LonWorks control network using a step-by-step procedure.

As an electrician, Paredes is able to think in terms of ladder-based programming, which means he's familiar with starting a logical rung of a ladder and going through each device. However, using object-based programming, he creates a virtual device first and inserts this object, or functional block, into a drawing that represents the control circuit. A functional block is a graphical representation of a device with its network variables, such as SNVTs and UNVTs.

To provide automatic control of a lighting load by a wall-mounted light switch, Paredes connects the switch to the digital input of a DIO-10 digital input/output module; this device is also connected to the network using an FTT-10 free topology twisted-pair transceiver. A relay is then wired in series with the branch circuit that serves the lighting load (lighting fixture) and also connected to the communications network.

Using the graphic display on the computer screen, Paredes establishes the control circuit for the lighting load. The switch receives network variables (NVs) that correspond to “on” and “off.” He then “binds” the lighting fixture and the switch together by dragging a virtual wire between the two items with a graphical tool. Binding can also connect other devices to the same wall switch. Thus, the binding procedure tells the wall switch device which other devices on the network it should talk to and what information it should share.

The network supports one-to-many and many-to-one binding of NVs regardless of a device's function; this binding of NVs is similar to the grouping of standard object types used to make a BACnet device. LonTalk uses the term “node” to define a device. Thus, a switch node has its output network variable (NV_Switch) connected, or bound, to the input variable (NV_Switch) on the lighting fixture node. When the switch is activated, the network variable is propagated over the network and received in the fixture node, which turns on the lamps. Thus, as Paredes notes, the light switch's NV can directly initiate actions in any number of other devices, or nodes, anywhere in the control network, without intervention from a centralized controller. It's also possible to convert one NV into another NV type, such as temperature to voltage.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.