The network infrastructure for most enterprise BACnet/IP systems can have extremely high throughput. Most of the sites I visit have no problem with network traffic in terms of capacity. The same cannot be said for network endpoints.

While your infrastructure might include fiber to your data closets, and gigabit speeds to your workstation and server endpoints; your field equipment and devices tend to be quite a bit more limited. For example, the Siemens PXCMs and DXRs, Jace 8000s, Schneider Automation Servers, and JCI’s Metasys controllers are 10/100, and the Delta DAC is only 10BaseT. This means that your infrastructure can provide an order of magnitude more throughput than your endpoints can accept.

These speeds are perfectly acceptable for normal operation of the controllers (and the systems they control). At high levels of throughput, however, the processors can become strained. Since most of these controllers do not have coprocessors for handling IP communication, the increased network traffic can cause problems with the execution of control programs. In extreme cases, the controller might even cold start, turning off its associated equipment.

In my experience, most traffic-related issues in building automation systems are user-created. It tends to be a badly configured report, a thoughtless alarm configuration, or a networked sensor that has a COV setting that is way too low. Because the controllers are both the bottleneck for network traffic, the source of the excessive traffic, and the component that malfunctions during a failure, it makes sense to treat control system network problems as automation problems first, and IT problems second.

Having a process for rationalizing which points get passed across your IP network is important to preventing outages. For most sites, this process doesn’t have to be extensive or formal. Two knowledgeable people need to make a guess about the amount of traffic that could occur in the worst case, and agree that the approach is fine. For regulated or mission-critical sites, this process should generally be more rigorous and well-documented. We like to keep this information in a Network Dependency Report along with a list of all the systems impacted by each controller.