Interfacing UPS Systems to a BACnet Network Monitoring the UPS alarms from BACnet presents challenges that are not compatible with traditional gateways.

Jim Hogenson Founder & President Control Solutions, Inc.

The most wide spread use of UPS systems and related power equipment is in data centers. Data centers monitor all of their equipment using SNMP, which stands for Simple Network Management Protocol. This protocol is intended for managing networks and network equipment. Therefore, data centers will monitor everything from servers, routers, and switches to UPS systems and transfer switches using SNMP.

The old way of doing things had the IT people monitoring the IT related equipment with their own network while the building management people had their own network to monitor HVAC and building related things (if they had any network at all). The line in the sand between these two monitoring networks is rapidly washing away. Building management wants more information from the IT side, especially when it comes to backup power systems. Network management wants to know more from the building side, especially when it relates to HVAC and keeping network equipment running cool.

One piece of equipment that users have often wanted to monitor via BACnet is the UPS (Uninterruptable Power Supply) system. There is a standard for how a UPS will present its status information known as RFC 1628. This is sort of the SNMP version of a BACnet BIBB if you are familiar with that BACnet term. The RFC defines something known as a MIB, or Management Information Base. The MIB is, in general, a list of SNMP data variables that are provided, along with a definition of SNMP Traps that the UPS will send when there is an alarm or status change. A “Trap” is a spontaneous notification that an SNMP device will send out typically upon alarm conditions.

UPS vendors often include both RFC 1628 and their own proprietary MIB. The proprietary MIBs are often expanded versions of the standard RFC 1628 MIB, and typically function in the same manner. It is possible to simply query SNMP variables that are always present, but RFC 1628 presents a couple of challenges: (1) The alarm table is only populated when there is one or more alarms; (2) Traps are spontaneous messages that cannot be queried.

Attempting to directly query the alarm table when there are no alarms will result in an SNMP error message. Furthermore, the alarm table is simply a circular buffer of observed alarm indications. Therefore, the same alarm will not appear in the same table entry twice in a row. The only way to successfully scan a UPS for alarms is to do what is known as a “table walk”, walking the entire alarm table using a series of Get-Next requests. The table walk may return nothing, or may return multiple alarm entries. If there is an alarm, the table entry will contain an OID, or object identifier, identifying the alarm. As an example, if the UPS is running on battery, an entry somewhere in the alarm table will contain the unique OID “1.3.6.1.2.1.33.1.6.2.1.2.2”. To an SNMP monitoring system, this makes sense. But those of us in the BACnet world would argue that this thing that looks like an IP address on steroids is not very intuitive, and certainly does not translate easily into a simple BACnet Binary Input state. Some extra intelligence is required to decide that the respective Binary Input state should be “inactive” when we do not find this anywhere in the alarm table, and “active” when it does appear somewhere (and it can be anywhere in the entire table).

Monitoring a UPS or any other SNMP enabled equipment on a BACnet network requires the use of a gateway. A traditional gateway will provide for setting up a table that maps SNMP variables to BACnet objects. This works well for monitoring data values that are always present, such as voltage and current. But monitoring the UPS alarms from BACnet presents challenges that are not compatible with traditional gateways.

Control Solutions, Inc., of Minnesota has recently introduced a BACnet-SNMP gateway that addresses all of the RFC 1628 challenges. The Babel Buster Pro V230 includes an intelligent table walker that understands the complexities of RFC 1628. This gateway also includes a trap receiver that can translate SNMP alarm notifications called Traps into BACnet COV notifications when the traps are received into a BACnet object. A pre-built configuration for translating the entire RFC 1628 UPS collection of data into BACnet objects is available. All alarms defined as “well known” alarms in RFC 1628 are translated into a series of Binary Input objects. Each Binary Input has a defined specific meaning, such as “UPS running on battery”. Regardless of where the respective alarm shows up in the alarm table, it will result in that same Binary Input being set to the active state when present, and inactive when not present.

The method of handling information in a UPS system with RFC 1628 will seem overly complex and difficult to someone more accustomed to BACnet or Modbus protocols. Within the context of SNMP, RFC 1628 is considered to be “best practice”. But best practice for SNMP does not necessarily translate well into best practice for other protocols. A good deal of extra work is required to make all of the RFC 1628 information readily available as BACnet objects. The Babel Buster Pro V230 performs all of this extra work in the background, thus making the UPS system look like just another BACnet device.

About the Author

Jim Hogenson is founder and President of Control Solutions, Inc., of suburban St. Paul, Minnesota. Jim has been in the embedded control product development business for 37 years, starting first at a small startup controls company, then moving on to contract engineering and consulting. During his contract development activities, Jim’s engineering company worked for a number of large companies including HVAC companies. The first product line for Control Solutions in 1995, a spin-off from the engineering company, was originally intended to be a demo product promoting engineering services. Jim continues to be the lead product developer at Control Solutions, and stays connected with customer needs by often personally responding to technical support requests.