An earlier article on this site looked at Clause 19.9 of ASHRAE 135-2024, Device Address Proxying, and at where it earns its keep. It closed on a limit worth returning to. Discovery on a BACnet network is really two questions, not one, and the new clause takes up the first of them and leaves the second untouched. This article is about the second question, what it costs, and why the standard was right to find it the harder one.
Two Questions, Not One
Every act of discovery on a BACnet network is one of two requests, and they are not the same question asked two ways. The first is Who-Is, which asks where a device is. A client that knows it needs to reach device instance 200145 but does not know its address sends a Who-Is, and the device answers with an I-Am that carries its address. This is discovery at the level of the device, keyed by the device’s instance number, and it is the request Clause 19.9 was written around.
The second is Who-Has, and it asks a different thing. It does not ask where a device is. It asks which device holds a particular object. A client that needs the point named “AHU-3.SupplyAirTemp,” and does not know which controller it lives on, sends a Who-Has carrying that name. The device that holds an object by that name answers with an I-Have that reports the object, the device that contains it, and where that device can be reached. Who-Has can carry an object’s name, as in that example, or an object identifier when the type and instance are known but the host is not. Either way the question is about an object, and it is answered at the level of the object.
The distinction is not academic. The two questions are keyed differently, one by a device instance and one by an object, and that difference is the whole reason one of them is far harder to contain than the other.
Why Anyone Sends a Who-Has
It is tempting to think of discovery as something that happens once, when a system is first stood up, and then falls quiet. Device discovery comes close to that. Object discovery does not, because resolving a point by name is woven into ordinary operation.
Consider what it takes to bring a graphic online. An operator’s front end holds a floor plan with a supply air temperature on it, and that value is bound to a point by name. Before the graphic can show a live reading, the name has to be resolved to an actual object, on an actual device, at an actual address. Multiply that across every point on every graphic across a campus and the resolution work is considerable, and it recurs. It recurs when a front end is rebuilt or replaced, when an integration tool is pointed at the system to pull a point list, when a commissioning technician searches for a tag they know by name but not by location, when middleware tying the BACnet system to an analytics platform or a tenant billing system refreshes its mapping. In each of these the tool holds a name and needs an object, and the way BACnet turns a name into an object is Who-Has.
None of this is exotic. It is the daily texture of operating and integrating a building, and every instance of it is, at bottom, a request to find an object by name.
The Same Broadcast, a Harder Shape
Who-Has is a broadcast, and it travels the way Who-Is travels. Sent globally, it is routed to every network in the system, reaching devices on subnets far from the one that asked. The I-Have that answers it is conventionally a broadcast as well, issued so that any device with an interest in the binding can hear it, which means the answer propagates much as the question did. In the terms the standard itself uses for Who-Is, a single such request is no concern, but repeated requests for something offline or slow to answer can weigh on the whole system, and Who-Has is subject to exactly the same behaviour. Anyone who has watched broadcast traffic on a large campus during a commissioning push has seen what it looks like.
So far this is a problem the series has described before, appearing now in a second form. What makes the object form the harder one is what it would take to contain it.
Why the Clause Stops at Who-Is
Device address proxying works because device discovery has a shape a proxy can get hold of. Every device announces itself. When a device comes online it issues an I-Am without being asked, and a proxy sitting on that network can build its picture largely by listening, filling in the rest with an occasional local Who-Is for anything it has not heard from. What it is cataloguing is bounded: one entry per device, a population a router can reasonably hold, and the standard sets a floor of a hundred and twenty-eight entries per proxied network to make the expectation concrete. A device address is also stable. Once learned it rarely changes, so an entry stays good for a long time. All of this is what lets the clause answer a Who-Is at the router and keep it off the network behind it.
Object discovery offers a proxy none of those handholds. A device does not announce its objects. There is no unsolicited I-Have when a controller powers up, nothing a proxy could passively collect the way it collects I-Am, so the only way to know what objects a device holds is to ask, object by object, or to read the device’s object list outright. The population is far larger, since a single controller can carry hundreds or thousands of objects, each with a name, and a proxy that meant to answer for them would have to enumerate and hold all of them, for every device behind it, and keep that current as names are edited during commissioning. A name is a more fragile thing to hold than an address, besides, because names are precisely what changes as a system is tuned and re-tuned. To answer Who-Has on another device’s behalf is therefore a materially larger undertaking than to answer Who-Is, and the standard did not take it on in this clause.
The arithmetic is worth making concrete. A campus of four hundred controllers presents four hundred device instances for proxies to hold, and the standard sizes its expectations accordingly, with a minimum of one hundred and twenty-eight table entries per proxied network. The same four hundred controllers, at even two hundred objects apiece, hold eighty thousand named objects. None of them announces itself, every one of them can be learned only by asking, and each name is subject to change as the system is tuned. A table of devices is something a router can reasonably carry. A live catalogue of every object name on a campus is a different order of undertaking.
That is a reasonable place to have drawn the line. Clause 19.9 was written to relieve a specific and well understood pain, the repeated Who-Is for a device that is offline or unreachable, and against that pain it is effective. Object discovery is a harder problem of a different shape, and it is no criticism of the clause to observe that it did not set out to solve it. It is only worth being clear about where the relief ends, so that the half of discovery still carried entirely by broadcast is not mistaken for a half that has been addressed.
What That Leaves on the Network
After Device Address Proxying is deployed, and doing exactly what it was designed to do, the object half of discovery sits where it was. A Who-Has still crosses every boundary a global broadcast crosses. It still reaches the devices on a proxied network, because the proxy is only a router for it and passes it through. It is still answered by the device that holds the object, with an I-Have that is itself broadcast. Nothing in the clause holds any of that back, because none of it is device address proxying.
The timing is the uncomfortable part. Name-based resolution is heaviest exactly when a system is busiest and least settled: during commissioning, when a new front end comes online and binds thousands of points at once, when an integrator sweeps the system for a point list, when a tool that has lost its cache rebuilds it. These are the moments a campus network already carries the most discovery load, and they are the moments the object-discovery broadcast reaches its peak. The relief the new clause offers, real as it is for the offline-device case, does not reach them.
A Name Is a Lookup, Not a Broadcast
The earlier article made the larger argument in full, so it need only be pointed to here: a broadcast is necessary only when the asker has nowhere else to turn, and a network that keeps an authoritative directory of what sits where can answer a Who-Is from that directory instead of carrying it across the boundary. What matters for the object half of discovery is that the same directory answers the same way. A record that knows where a device is can also be the record that knows which device holds the object named “AHU-3.SupplyAirTemp,” and at what address that device can be reached. Once the network holds that, a Who-Has has somewhere to turn other than the wire.
This is the capability BACsync brings to the second question. What each subnet knows first-hand about the objects it hosts is shared, so that resolving a name becomes a lookup against a directory the subnets hold in common, rather than a broadcast sent out to search. The device address was the subject of the earlier article; the object, found by name, is the subject here, and it is the harder of the two precisely because nothing announces it. A directory is how a name gets answered without a broadcast going to find it.
Discovery was always two questions. The 2024 standard took up the first, for the case it fits best, and by its own reasonable scope left the second alone. Object resolution is what remains carried by broadcast across the whole system, and carried most heavily when a large network can least absorb it. The relief the new clause brings is real. This is the edge of it, and the object half of discovery waits on a different answer.
If this resonates with what you are seeing on your network, we would welcome the opportunity to discuss it further. More information about BACsync is available at bacsync.com.
About the Author — Mark Van Weert is the founder and director of Humber Horizons Limited, a building automation and cybersecurity consulting firm based in Ontario, Canada. With thirteen years of experience in BACnet systems integration, CCNA/CCNP certifications, and a background in large campus deployments, Mark specializes in IT/OT convergence and network infrastructure for universities, hospitals, and commercial facilities.
More in this series