At Dartmouth College, eight devices were quietly responsible for more than half of all the BACnet traffic on the network. “We quickly realized that something like eight devices were responsible for over 50% of all the BACnet traffic on our network,” said Douglas Plumley, Software Architect on Dartmouth’s Technology Services team. Those devices were sending unscoped Who-Is requests that forced more than 1,000 other devices to respond at once — a self-inflicted denial-of-service condition that had been running undetected until the college’s team used OptigoVN to trace it.
That kind of problem is easy to miss in a single building. Across a multi-site building automation (BAS) portfolio, it’s nearly impossible to catch without the right visibility — which is exactly why OT network monitoring has moved from a nice-to-have to a foundational requirement for facilities and service teams managing more than one site. This guide covers what OT monitoring means operationally, the specific challenges multi-site portfolios create, and the strategy, tooling, and ROI framework needed to manage it at scale.
Key Takeaways
- OT network monitoring gives real-time visibility into BACnet traffic, device health, and network performance across every building in a portfolio, from a single platform.
- Multi-site portfolios face compounding challenges: inconsistent configurations, multi-vendor equipment, legacy protocols, and no shared baseline for what “normal” looks like.
- Small, unresolved network issues — a misconfigured BBMD, a chatty device — cascade into comfort complaints, equipment failures, and bad analytics data.
- Objective network data settles multi-vendor disputes that would otherwise take weeks of finger-pointing to resolve.
- A phased approach — baseline, prioritize by risk, deploy capture infrastructure, then build alerting workflows — scales monitoring across a portfolio without incomplete, inconsistent rollouts.
A healthy OT network is a prerequisite for everything layered on top of it — energy analytics, fault detection and diagnostics (FDD), and any AI-driven optimization. If the network feeding those systems has duplicate device instances, excessive broadcasts, or intermittent communication failures, the data those systems depend on is unreliable, and their outputs are too.
Vendors selling AI-driven HVAC optimization advertise the upside of clean data at scale — but an optimization layer is only as good as the network data it’s reading. Garbage in, garbage out.
Optigo’s How to Handshake podcast, Episode 1 makes the same case from the energy-efficiency side: the network is the foundation energy insights get built on, and a cracked foundation shows up in the numbers eventually.
The Dartmouth example above shows how far a small issue can travel before anyone notices. Eight misbehaving devices degraded token-passing and communication reliability for the whole segment. Left undiagnosed, problems like this tend to get blamed on aging equipment rather than identified as a network issue, because no one has deep enough visibility into what’s actually happening.
Why Multi-Site Portfolios Need a Different Approach
Managing OT network health for one building is manageable with occasional attention. Scaling that across 10, 50, or 200 sites introduces problems that don’t show up at a single-building scale:
- No shared baseline for comparison.
- No way to see whether an issue at one site is isolated or part of a pattern.
- Far more surface area for things to go quietly wrong.
The following seven challenges are the ones that show up most consistently once a BAS portfolio crosses from “a few buildings” into “a portfolio that needs to be managed as a system.”
7 OT Monitoring Challenges in Multi-Site BAS Portfolios
1. Lack of Centralized Visibility Across Sites
Each site in a portfolio often runs its own monitoring setup, if it runs any at all, which creates data silos that prevent comparison across locations. An anomaly at one site can go unnoticed while the same pattern quietly develops elsewhere, because nothing connects the two views. Real-time, continuous monitoring across every location is what closes that gap.
2. Multi-Vendor Protocol Complexity
Portfolios rarely run uniform equipment. Siemens controllers at one site, Johnson Controls at another, Honeywell at a third — and each vendor’s implementation of BACnet introduces subtle differences in how devices communicate and how that traffic appears in a packet capture. A monitoring approach tuned to one site’s equipment can miss critical events at another simply because the protocol implementation isn’t identical.
3. Network Configuration Inconsistencies
Duplicate device addresses, overlapping network numbers, and inconsistent BBMD configurations are common across portfolios where sites were commissioned by different integrators or renovated at different times. What counts as “standard configuration” at headquarters may directly conflict with a regional site’s setup, and the same symptom — a device failing to respond — can have a completely different root cause from one site to the next. Root cause analysis is what separates a real fix from a guess in these cases; Optigo’s Your BACnet Questions Answered: Episode 4 walks through diagnosing exactly this kind of cross-vendor BBMD and broadcast-forwarding conflict.
4. Remote Troubleshooting Limitations
Sending a technician to every site that shows symptoms is slow and expensive, but most legacy BAS installations don’t offer the visibility needed to troubleshoot remotely. Teams without that visibility tend to operate in break/fix mode — which means minor issues go unaddressed until they become major ones.
5. Legacy Equipment Blind Spots
Older buildings in a portfolio often carry controllers from the 1990s or early 2000s running protocols that predate modern monitoring. MS/TP is a serial trunk, so reaching it always requires a physical connection point — that’s a property of RS-485, not a tooling gap. *an RS-485 to USB dongle and a laptop running Optigo’s traffic capture software configured for MS/TP is all you need to solve this issue!
The newest, most visible sites tend to get more monitoring attention than legacy ones, simply because someone has to make that first physical connection before remote analysis can take over. Optigo’s Your BACnet Questions Answered: Episode 3 covers MS/TP troubleshooting directly — device capacity limits, checksum errors, lost tokens, and connecting legacy MS/TP segments to modern IP networks via a BACnet router.
6. Inconsistent Data Collection and Baselines
Comparing network health across sites requires a consistent measurement approach. If each location is using different methods, intervals, or diagnostic criteria, portfolio-wide analysis becomes unreliable — you can’t tell which sites are actually performing well versus which just haven’t been measured carefully.
7. Responsibility Attribution in Multi-Vendor Disputes
When something fails on a network with equipment from multiple vendors, everyone has an incentive to point elsewhere. Pranjal De, Director of Technical Services at EllisDon Facilities Services, described what changed once EllisDon had objective network data on hand: “Without that tool, I’d be splitting networks and pointing fingers forever. It just shut down that conversation.”
In one specific case, a lighting contractor claimed BACnet traffic from EllisDon’s system was flooding the network and causing flickering lights. Network analysis showed the excessive reads were coming from the lighting system itself — the contractor’s own driver issue, which it then fixed. What could have been a weeks-long dispute was resolved in a single meeting because both sides were looking at the same data.
What to Look for in an OT Monitoring Solution
General IT monitoring tools weren’t built to understand BACnet — they can capture packets, but they can’t tell you whether a site has duplicate BBMDs, misconfigured COV subscriptions, or MS/TP token-passing failures.
The right OT monitoring tools for a multi-site portfolio need four things.
- Protocol-specific BACnet diagnostics. Purpose-built OT monitoring tools decode BACnet traffic natively and run diagnostics specific to building automation: identifying duplicate device instances by MAC address, tracing the specific source of a broadcast storm, and flagging configuration drift before it destabilizes a network.
- Remote access and cloud-based analysis. Traveling to every building for a packet capture doesn’t scale past a handful of sites. Remote equipment monitoring — scheduled automated captures and cloud-based analysis — lets a central team diagnose problems and set health alerts without a truck roll.
- A unified dashboard across sites, built on consistent scoping. Comparing network health across a portfolio requires that every site be measured the same way. Optigo’s advanced diagnostics feature uses the same weights and measures in the individual diagnostics and network health score, so that a score at one location actually means the same thing as a score at another — the foundation for any real end-to-end visibility across a portfolio.
- Shareable, non-technical reports. Facilities leaders and property managers need to understand network health without being BACnet experts. Reports that translate diagnostics into a handful of clear metrics keep stakeholders engaged without requiring them to interpret raw capture data.
Want to see this against your own portfolio’s traffic instead of a hypothetical? Start a free trial of OptigoVN — no credit card required — and run the diagnostics above against a live capture.
Building an OT Monitoring Strategy: A 4-Step Framework
Rolling out monitoring across every site at once tends to produce incomplete, inconsistent results. A phased approach works better.
- Establish network baselines at each site. Capture traffic under typical operating conditions (including known spikes!) and record device counts, traffic volumes, and communication patterns. A site that normally sees 100 broadcasts per minute jumping to 5,000 is a signal only if you know what normal looks like first.
- Prioritize sites by risk and criticality. A hospital or data center carries different consequences for a network failure than a general office building. Rank sites by operational criticality, BAS complexity, and history of problems, and start monitoring deployment with the highest-risk group.
- Deploy capture infrastructure. BACnet/IP networks can typically be captured in software from any device on the segment. MS/TP networks need a physical tap on the trunk line — plan for capture devices where legacy serial networks are involved.
- Implement alerting and review workflows. Define thresholds that trigger action and assign who responds to each. Pair automated alerts with a regular (weekly or monthly) review of every site, including ones without active alerts, since gradual degradation often doesn’t cross a point-in-time threshold until it’s already a problem.
Incident Response Workflows for Multi-Site Environments
Establish a single source of truth. As EllisDon’s experience above shows, objective network data ends multi-vendor disputes faster than any amount of negotiation. When a problem occurs, the diagnostic data — not who argues loudest — should determine the next step.
Document and communicate findings. Reports that summarize network health, the specific issue found, and the recommended fix give stakeholders a record for future reference and a basis for billing or accountability conversations with contractors, without requiring them to read raw capture data.
Coordinate remediation across vendors. Once a problem is traced to its source, fixing it often requires the internal team, the controls contractor, the equipment manufacturer, and possibly the property manager to act together. Shared diagnostic data gives everyone a common reference point instead of a debate about whose equipment is at fault.
Measuring the ROI of OT Monitoring
Troubleshooting time. Track how long it currently takes your team to diagnose a network-related issue, then track the same metric after deployment. Even a handful of resolved tickets should show a clear drop once root causes are identified from diagnostic data instead of manual packet inspection.
Emergency service calls. Proactive monitoring catches problems before they become emergencies. Track after-hours dispatches and repeat visits for issues that were never fully resolved — these should decline as network health improves.
Reporting structure. EllisDon’s leadership now reviews four metrics each quarter: network health score, maintenance score, energy score, and comfort score. That structure lets executives engage with infrastructure performance without needing to understand BACnet — a useful model for any portfolio building its own reporting cadence.
Common OT Network Issues at a Glance
| Issue | Symptom | Typical | Fix |
|---|---|---|---|
| Duplicate device addresses/instances | Commands or data reaching the wrong equipment | Default addresses left unchanged at commissioning, or equipment replaced without updating config | Reassign unique instance numbers; audit during commissioning and equipment swaps |
| Broadcast storms | Devices unresponsive, degraded performance network-wide | Unscoped Who-Is/COV requests from one or a few misconfigured devices | Identify the source device(s) via traffic analysis; scope or reconfigure their requests |
| BBMD configuration errors | Cross-segment communication fails | Duplicate BBMD entries, missing registrations, incorrect broadcast distribution tables | Audit and correct BBMD tables across all segments |
| MS/TP token-passing failures | Intermittent device dropouts on serial trunks | Wiring faults, max_master settings that don’t match actual device addresses | Physical trunk inspection; correct max_master configuration |
Integrating OT Monitoring with Other Building Systems
FDD and energy management platforms. FDD and energy analytics depend on reliable BACnet data. When OT monitoring flags an issue affecting data quality, that finding should reach the FDD team directly — some facilities teams treat network health as a prerequisite and won’t trust FDD output from a site scoring below their health threshold.
Work order and CMMS systems. Findings that require remediation should flow into the existing work order or CMMS workflow so they get tracked and closed the same way any other maintenance item does.
Owner and property manager reporting. For teams managing buildings on behalf of an owner, regular network health reporting demonstrates proactive management and gives early warning of issues that could affect building operations before they become visible complaints.
A Foundation for Intelligent Buildings
Before any analytics or AI layer can be trusted, the network underneath it has to be stable and well-understood. That’s the case for OT network monitoring in a multi-site BAS portfolio: start with discovery, know what’s on the network and how it behaves, establish baselines, and resolve issues before they cascade into building-wide failures. Everything built on top of that foundation — energy optimization, FDD, predictive maintenance — is only as reliable as the network data feeding it.
Ready to see your own portfolio’s network health?
OptigoVN gives facilities teams and system integrators the same portfolio-wide visibility EllisDon and Dartmouth College used to catch these issues before they escalated. Start your free OptigoVN trial — no credit card required — and run your first cross-site diagnostic today.
FAQs
What is OT network monitoring in building automation? OT network monitoring is the ongoing collection and analysis of traffic on the operational technology networks that control building systems — primarily BACnet — to catch communication problems, configuration errors, and performance issues before they affect building operations.
How does OT monitoring differ from IT network monitoring? IT monitoring focuses on data throughput and application availability. OT monitoring has to account for physical consequences — a network problem can cause HVAC failures and comfort complaints — and requires protocol-specific analysis that general IT tools don’t provide for BACnet and similar industrial protocols.
Why do multi-site portfolios need centralized OT monitoring? Without centralized visibility, every site operates in isolation: there’s no way to compare network health across locations, spot patterns repeating across sites, or decide where limited troubleshooting resources should go first.
What are the most common OT network issues in BAS portfolios? Duplicate device addresses, broadcast storms from misconfigured devices, BBMD configuration errors that block cross-segment communication, and MS/TP wiring or token-passing faults are the most frequent issues, and they often persist for months without network-level visibility to catch them.
How does network health affect FDD and energy analytics? FDD and energy platforms depend on accurate BACnet data. A network with duplicate devices, broadcast storms, or communication failures corrupts that data, which leads to false alarms, missed faults, and unreliable optimization results regardless of how good the analytics layer itself is.
Who’s responsible when a network issue happens in a multi-vendor environment? Without objective data, responsibility is usually contested — each vendor has an incentive to point elsewhere. Network diagnostics that show exactly where a problem originated remove the guesswork, as in EllisDon’s case with a lighting contractor’s driver issue.
How often should multi-site BAS networks be monitored? At minimum, establish a baseline capture at each site and configure alerts for deviations from it. Sites with a history of problems or higher operational criticality (hospitals, data centers) warrant more frequent, closer review than lower-risk sites.
Can one monitoring platform handle equipment from multiple BAS vendors? Vendor-agnostic platforms that analyze BACnet traffic directly can diagnose issues regardless of which manufacturer’s equipment generated them, which is what makes consistent, portfolio-wide diagnostics possible in a multi-vendor environment.
