Networking VFDs in high-performance buildings


By John Gross, PE, ATD, Page, Houston March 15, 2017

Learning objectives

  • Learn how VFDs can enhance high-performance buildings.


Historical operational issues




Technical issues




Enter VFD networking




The value of networking VFDs

Networking allows the collection, storage, and later review of a broader spectrum of data by multiple individuals for the purposes of troubleshooting problems, identifying potential issues before they occur, and enhancing delivery of service to the occupants of the building (see Figure 1). For example, power- and energy-consumption data points are available through most VFDs today. A key tenet for high-performance buildings is knowing where power is consumed. By monitoring these VFD parameters, users know what these systems consume. However, more important is the ability to trend this data. If users trend the power consumption of an air handler serving an open-office plan, they may see that the consumption is greater this month than last. This could be due to several factors including occupant count and outdoor ambient temperature. However, it could be due to the air handling unit filters beginning to load, increasing the pressure on the fan. By monitoring and trending this power-consumption data, operators are able to identify when equipment and systems are operating at other than peak efficiency. By reacting to this information, operators can better maintain the systems for optimum energy efficiency and reduce energy costs.

While able to be monitored via a hard-wired input, the status of the VFDs hand/off/auto switch can aid tremendously in troubleshooting drive issues. On multiple occasion, hot or cold calls have been logged on a given system, indicating the system was not delivering sufficient airflow. Upon looking at the VFD, it was noted that someone placed the VFD into hand operation, locking the VFD at a given speed. In many cases, this is done because of issues with the control loop, or someone simply forgot to place it back in auto mode after performing maintenance on the system. However, monitoring this point allows visibility to the mismatched operation and allows the team to determine the reason. Whether left in hand mode accidentally, or due to a faulty control loop, degraded service to the occupants and an impact on energy use are the results.

Another data point available in most VFDs today is motor-speed feedback. A common issue observed when reviewing the operation of a poorly controlled or excessively slow hydronic pumping system is a mismatch between the VFD setup and control programming that causes the systems to fight each other. VFDs have settings that affect the maximum acceleration and deceleration rates of the motor. No matter what the BMS is commanding the VFD to do, the VFD will not accelerate or decelerate the motor faster than these ramp settings. The BMS pump speed control loop assumes that the pump speed is changing effectively in sync with the change in commanded speed. If the VFD ramp rates are set slower than the BMS control loop is configured, the VFD will lag behind the BMS command, causing a hunting issue. This is most commonly observed when starting and stopping pumps and is exacerbated on critical chiller plants, which typically require very fast response to disturbances in the system. This issue can be easily diagnosed by monitoring the motor speed feedback relative to the commanded speed. Correcting the issue also can be easily addressed by ensuring the VFD ramp rates are set faster than the BMS control loop rate. A nice benefit to motor speed monitoring is a second means for determining if a VFD is placed in hand mode versus auto mode.

Using trend data

When it comes to system monitoring, one of the most critical uses of trended data is forensic analysis (see Figure 2). When a system has failed, time is spent looking at the data available to determine a root cause. Sometimes there is sufficient data; but all too often, the data is lacking. This usually is due to a combination of insufficient channels monitored and insufficient trend rates. Historically, the list of channels to be trended is left to the BMS contractor and the owner’s operators. Depending on the contractor on the project team and the experience of the operators, the project might end up with no trends other than temperatures and flows—or it may end up with a trend on every point regardless of its benefit to the operators.

Traditionally, unless otherwise specified, HVAC trends of analog values are stored once every 15 minutes or so. While the actual intervals in use may vary, the order of magnitude is similar. However, in the event that a pump fails on a chiller plant on an overcurrent trip, trend intervals in the 15-minute range are insufficient to identify the sequence of events (see Figure 3). This leaves the user to ask the following questions:

  • What was the current draw at the time of the trip?
  • What was the ac input voltage at the time of the trip?
  • When the pump failed and the lag started, how long did it take for the flow in the plant to recover?
  • How quickly did the VFD accelerate from “off” to the commanded speed?
  • What was the lowest flow recorded?
  • What was the impact on the loop temperature?

If the temperatures, flows, and pump speeds are trended at only 15-minute intervals, there is no data for review. Trend rates can be addressed easily in a new BMS due to the increased throughput of their data infrastructures and larger hard drives. A modern-technology BMS is capable of running multiple trends on a trend. One trend can be used for long-term monitoring using 15-minute (or similar) intervals, while the other is passed through a first-in/first-out buffer at 1- to 5-second intervals and saved to the historian only when an alarm condition occurs. Though this functionality is not native in today’s BMS—custom programming usually is required—it is available. Channel monitoring and trending comes down to specification and networking.

Equipment tripping offline due to fault conditions is a fact of life in this business. Most equipment, such as VFDs with solid-state controllers, have the ability to individually identify different fault conditions. However, if the VFD monitoring is performed via a hard-wired input, all that is logged and trended in the BMS is typically a general fault condition. While most VFDs have the ability to individually program relay contacts to actuate on specific alarms, monitoring more than one requires additional pairs of signal wires. If the VFD is networked, however, literally dozens of discrete alarms can be monitored, logged, and trended, providing end users with a clear, consolidated history of alarm events with the VFD. Additionally, this functionality allows multiple alarms occurring simultaneously to be seen and prioritized, which a general alarm does not provide. Again, to ensure a high quality of service to the occupants, this type of data arms the building operations team with the information necessary to quickly restore the system to proper operation (see Figure 4).

More networking options

In addition to manual data review and analysis, numerous products are coming to market aimed at the high-performance building market. In many cases, these products are black box add-ins to the BMS that work to collect, analyze, and optimize HVAC system operations based on building-specific needs and equipment. For these systems to operate to their fullest potential, substantial data on motor loads and consumption typically is required. Every major BMS vendor has some form of data analytics that can be added or enabled in the system to leverage the data collected. It is important to coordinate with the owner and permitted bidders during the design phase to understand what the owner wants and what the vendors can provide. Because every vendor has a different catch-phrase to describe a given solution, it is typically best in a competitive bidding environment to specify analytics packages with performance-based language that align with owner needs. Due to the rapidly evolving offerings, it also is recommended to require a live demonstration during the bid-evaluation phase, if not prior.

Many more useful pieces of data are available over the network interface to most HVAC VFDs today. These range from simple monitoring points, such as voltage and current draw, to complex analytical points, such as total harmonic distortion and power factor, when specified as options on the VFD, which become very 

important for large motors. Relative to the traditional monitoring and control used for VFDs, the available information is almost limitless, but at what cost? When discussing this topic with multiple control vendors in various regions of the country, the answer tends to be fairly consistent: Networked points cost approximately 10% of hard-wired points. Of course, this can vary greatly depending on what is done with the point and whether integration to the device already exists. 

But in general, points in addition to the first for a given networked device are available at a fraction of the cost of the hard-wired point. This is due to both the cabling requirements for hard-wired points as well as possible need for a field device to generate the data to the BMS. For example, a current switch. Another advantage to networking VFDs—or other equipment, for that matter—is that points can be added to a device easily and relatively inexpensively when the initial network connection is established. During the life cycle of a building, different information becomes important depending on the staff and the goals of the operations team. Instead of bringing contractors into the space and possibly disturbing occupants to add conduit and wire, some programming at the BMS allows the new points to be integrated into the system.

Justifying VFD networking

If networking a VFD is so cost-effective (relatively speaking), and so much data is available, why do we use hard-wired points at all? In most cases, it comes down to one thing: the criticality of the system served by the VFD. It is important to note that many VFDs still use BACnet MS/TP (serial) communications. As a result, powering down a device on the network, which may be completely unrelated to the system, can affect the speed of communication with the remaining devices. Because VFDs are operating one part of a control loop, with the commanded speed typically coming from the DDC controller, this can lead to a lag in the command reaching the VFD. This results in a reduction in the quality of control for the system, which may or may not be noticed by the building occupants. In some processes, such as data centers, semiconductors, medical surgical facilities, and others, this potential risk is not acceptable. In these cases, a typical VFD configuration may include hard-wired signaling for the basic and critical control functions, such as start command, speed command, status, and general alarm (does this data set sound familiar?), and networking for the monitoring points, such as energy consumption, discrete alarming, harmonics, and so on. This type of hybrid approach maintains the direct connection between the DDC controller and VFD, independent of outside influences, for all critical operations, but still provides a cost-effective means for monitoring the data that allows the team to maintain optimized operation of the system.

Another available option is to have separate subnetworks for devices on a common system. Depending on the project, the geographical layout of the hardware, and the number of potential subnetworks, it may be acceptable to install a handful of subnetworks that ensure only related equipment is on a given communication network. 

This could be useful for many reasons including limiting the data traffic on given networks; compartmentalizing systems for facilities that may see frequent renovations, such as lease spaces; and fault tolerance for critical systems. If choosing this approach, however, it is critical to follow up during submittal review and installation to ensure that this networking approach is maintained by the contractor.

As mentioned earlier, data throughput is much less of a problem today than in years past. But much like any technology, users will find a way to use all the capacity something provides them. During the design of any BMS that will use networking of equipment, it is important to have either the engineer or contractors include a network traffic analysis to confirm sufficient infrastructure exists to support the desired data throughput. To properly conduct this analysis, detailed specifications should be provided indicating the points intended for monitoring as well as the trending rates of the various points. Likewise, a minimum duration of data storage, rather than a particular storage size, should be specified to confirm sufficient data will be readily available to the building operations team for future use. If the data is not readily available, it will not get used regularly. Thus, the end goal of the networking and data collection will be lost.

From an HVAC perspective, the end goal for high-performance buildings is to provide a high-quality indoor environment with high reliability and minimal energy consumption. Recent changes in the market approach have complicated this goal by reducing head count or outsourcing building operations teams, thereby forcing this service to be delivered with less site experience and manpower. One of the most efficient ways to empower the remaining staff is through the efficient collection and use of operational data, whether directly or through building automation. Depending on the building use, either complete networking or a hybrid approach can bring substantial data to the hands of the building operations team to detect downward trends in building performance, quickly identify root causes of failures, and educate new staff on historical building operation.

John Gross is associate principal/senior project manager and senior mechanical engineer at Page in Houston. With 13 years of experience in data center, green building, and large chiller plant design and commissioning, Gross is Page’s lead DDC controls and forensic analysis engineer.