BACnet Device Discovery: Running and Reading a Site Scan

Every integration, analytics project, head end replacement and estate acquisition starts with the same unanswered question: what is actually on this network. The documentation answers a version of it that was true at handover, filtered through whatever happened since. A discovery scan answers it as of this morning, and the gap between the two is usually the single most useful finding of the whole project.

The message up front: a discovery scan is read-only, takes under an hour on most sites, and produces an inventory you can compare against the asset register and the handover documents. Run it before specifying any integration rather than after. Plan it for a quiet period and agree it with whoever runs the controls first, because discovery uses broadcast traffic and a careless scan on a loaded trunk can disturb a system that is already near its limits. Then read the results for the four things that matter: duplicates, orphans, defaults and absences.

1. What a scan actually does

Discovery works by broadcast. A client asks, in effect, who is out there, and devices answer with their identity. From each answer the client can then ask that device for its object list and for the properties of those objects, building up an inventory without needing any prior knowledge of the site.

Two consequences follow. First, the scan is fundamentally a read operation and does not change anything, which is what makes it safe to run on a live building. Second, it depends on broadcasts reaching you, which on a routed network means the broadcast forwarding described in BACnet objects, device instances and addressing has to be working. A scan that finds devices on your own subnet and nothing beyond it has usually found a configuration problem rather than an empty estate.

2. Running it without upsetting the building

• Agree it in advance with whoever maintains the controls, and record that you did. A scan is harmless and an unannounced one on a system somebody else is responsible for is a poor way to begin a relationship.
• Pick a quiet period. Discovery and the object-list reads that follow add traffic, and a trunk already running near capacity may show read failures during the scan. That is a finding in itself, but you want it to be a controlled one.
• Throttle the enumeration. Reading every property of every object on every device as fast as possible is the one part of this that can genuinely disturb a loaded serial trunk. Pace it, and scan one trunk at a time rather than everything at once.
• Use a read-only tool and confirm it is one. Many engineering tools can discover and also command, and the same precautions apply as in securing read-only BACnet data access.
• Record the scan's own parameters: when, from where, what range, which tool and version. A scan without those details cannot be compared against the next one.

3. What to capture

4. Reading the results: the four things to look for

Duplicates. Two devices sharing a device instance number is the classic site fault, and it produces intermittent, confusing behaviour because both answer to the same identity. Sort by instance number and look for repeats. This check alone justifies the exercise, and it is essential before joining two previously separate networks.

Orphans. Devices that answer and appear nowhere in the documentation, the asset register or anyone's memory. Common causes are equipment from a project that was never documented, a contractor's test device left connected, or plant that was decommissioned physically but not electrically. Each needs a disposition.

Defaults. Devices still carrying a factory instance number, a factory name, or an obviously sequential block that suggests nobody chose them. These are the duplicates of the future, and they indicate that the numbering plan described in BMS point-to-asset mapping either does not exist or was not followed.

Absences. Equipment in the documentation that does not answer. Either it was removed, it is switched off, it is behind a routing problem, or it has failed. The last two are the ones worth chasing, and a device that has silently been offline for months is a reasonably common finding.

5. Comparing the scan against your other records

The inventory on its own is interesting. Set against three other lists it becomes actionable.

• Against the handover documentation. Establishes how much has changed since the system was delivered, which is the context for every claim in that pack.
• Against the asset register. Controllers are assets and are frequently missing from the register entirely. This is also where the point-to-asset mapping begins, and the scan is the natural starting point for building one.
• Against the points list. Object counts per device against points scheduled per plant item. Large discrepancies mean either the points list is stale or the scope was reduced at some stage without the documentation following.
• Against the previous scan. Once you have two, the difference is the most valuable output. New devices nobody told you about, devices that have stopped answering, and instance numbers that have changed all show up immediately.

6. When to run one

• Before specifying any integration or analytics project. The scope and the price both depend on what is actually there.
• Before joining two networks, to find the duplicate instance numbers before they become a live fault.
• At the start of a head end replacement, where it is the baseline you will verify against afterwards.
• On taking over an estate, as part of due diligence. It is cheaper than any survey and more honest than any document pack.
• At acceptance of any controls work, as part of the set in the BACnet integration acceptance test checklist.
• Annually thereafter, as a short routine. The value is almost entirely in the comparison against last year.

7. What a scan does not tell you

Worth being clear, because a scan can give a false sense of completeness.

• It does not tell you what anything physically is. A device named AHU3 may serve a different unit than it did five years ago. Establishing that needs a survey, which is the limitation described in point-to-asset mapping.
• It does not find devices it cannot reach, so an absence is ambiguous between removed, off and unreachable until you investigate.
• It does not cover non-BACnet equipment, and most buildings have some, sitting behind gateways or on other protocols entirely.
• It does not tell you whether a point is reporting truthfully. A device can answer perfectly while its sensors are failed, which is the dead-point problem in BMS points lists and field devices.
• It is a moment, not a monitor. Continuous visibility is a different mechanism, covered in BMS ingestion monitoring.

The idea to walk away with

A discovery scan replaces an assumption with an inventory, for an hour of effort and no risk to the building when run sensibly. It is the natural first step of any project that touches a building system, and it is skipped almost universally because the documentation appears to answer the question already.

Read it for duplicates, orphans, defaults and absences, compare it against the asset register and the handover pack, and keep it so the next scan can be a difference rather than a snapshot.

Final thoughts

The most consistently surprising number in a first scan is simply the device count against what anyone expected. It is rarely the same, and the direction of the error is informative: more devices than documented usually means undocumented projects, and fewer usually means equipment that stopped answering some time ago and nobody noticed.

Either way it reframes the conversation about what the estate actually is, which is generally worth more than whatever the scan was commissioned to establish.

Related reading: BACnet objects and addressing, BMS point-to-asset mapping, BACnet acceptance test checklist, Securing read-only BACnet access, BMS points lists and field devices, Timestamps and clock synchronisation.