Protocol audit: BACnet, KNX, Modbus, M-Bus

A network that responds is not necessarily a healthy network

Values arrive, the supervision displays them, nothing raises an alarm. Yet an overloaded bus responds late, a gateway polls points nobody looks at in an endless loop, a controller rewrites an unchanged setpoint every second. None of these faults triggers an alarm; they are paid for in frozen values, gaps in trend logs and equipment that wears out for no apparent reason. A protocol audit makes them visible, frame by frame.

The protocols we audit

• BACnet/IP and BACnet MS/TP: devices present, objects and properties actually exposed, checked against the points list, the EDE file and the PICS; COV subscriptions, broadcasts, BBMDs.
• KNX: topology (areas, lines, couplers), individual and group addresses, load on each line, repeated or unanswered telegrams.
• Modbus RTU and Modbus TCP: slaves present, response times, exceptions and timeouts, consistency of the register map (format, scaling factor, word order).
• M-Bus, wired or wireless: meters present, primary and secondary addresses, collisions, actual reading intervals.
• And the gateways between them, MQTT and OPC UA included: this is often where data gets lost and where absurd polling rates are born.

Network load, measured rather than estimated

We record traffic over a representative period (working days, nights, weekends) and measure the utilisation of each bus and segment, its peaks, broadcasts and retries. An RS-485 serial bus (BACnet MS/TP, Modbus RTU, M-Bus) has a fixed data rate: at 9,600 baud, reading one Modbus meter takes in the order of a hundred milliseconds. A gateway set to poll 40 meters every second therefore cannot hold its cycle: it actually takes several seconds, and the displayed values lag behind without anyone suspecting it. On KNX, it is often over-frequent cyclic sending and the visualisation’s read requests that saturate a line (see the example below); a permanently loaded line delays telegrams, and unacknowledged telegrams are repeated, which loads it even further. On IP, poorly contained BACnet broadcasts (misconfigured BBMDs, repeated device discovery) clog the whole segment.

Read and write frequencies: who polls what, and how often

For each client on the network (supervision, monitoring, gateway, neighbouring controller), we record the points read and written, their rate and how much they actually change.

• Reads: a room temperature polled every second when it changes over ten minutes occupies the bus for nothing; a meter read once an hour shows no power peak. We compare the observed rate with the actual need of each point. In BACnet, COV subscriptions are often a better choice than cyclic polling, provided the increment and subscription lifetime are set correctly.
• Writes: the costliest and least visible fault. A setpoint or command rewritten in a loop, even with an identical value, loads the network; and when the device stores it in non-volatile memory, it uses up its guaranteed write cycles. The drive or controller eventually fails for no apparent reason. We identify who writes what, how often, and whether the value really changes.
• BACnet priorities: a command forced at a high priority and never relinquished overrides the control loop with nothing to show for it. We record the priority array of every commanded point.

With our tools, without disturbing operation

The audit relies on our analysis tools: traffic capture, device discovery and inventory, statistics per device, per point and per network client. Listening is passive: we change neither the programming, nor the configuration, nor the addresses. Active queries (discovery, property reads) are limited, announced and carried out outside sensitive periods. We need access to the technical network (mirror port on the switch or connection to the bus), the available documentation (points list, EDE file, KNX project) and a contact on the operations side.

What you get

• The inventory of devices and points actually reachable, checked against the documentation: what is missing, what is surplus, what does not match.
• The measured load of each bus and segment, with its peaks and their origin.
• The read and write table: per client and per point, the observed rate and the recommended rate.
• Anomalies ranked by severity: duplicate addresses, silent devices, communication errors, write loops, unreleased priorities, uncontrolled broadcasts.
• The raw captures, in open formats, readable by another provider with free tools.

Exposure, along the way

Unsecured BACnet/IP, Modbus TCP and KNXnet/IP authenticate no one: anyone who reaches the network can read and write. The audit shows which devices are reachable, and from where. For the standards framework: the IEC 62443 standard and the Cyber Resilience Act.

When to have your protocols audited

• Before connecting monitoring or a new supervision system to an existing network, so as not to add load to an already saturated bus.
• When the supervision is slow, loses values or shows frozen points.
• When a drive or controller fails repeatedly for no apparent reason.
• Before extending an installation or adding many points.
• When taking over an installation whose documentation is incomplete or missing.

Further reading: BACnet: why “compatible” does not mean it will work.