More than 300 BACnet devices appear to make the Ignition driver a risky replacement for a Kepware-to-OPC-UA path. Device count alone does not set capacity: transaction rate, response time, retries, object count, polling interval, and discovery behavior determine whether the direct connection remains usable.
Architecture comparison
The decision is between retaining a proven protocol gateway and making Ignition the BACnet client. A third requirement—access to MQTT—belongs to the publishing architecture and does not demonstrate that the BACnet acquisition layer can handle the required load.
| Approach | Strength | Engineering concern | Decision test |
|---|---|---|---|
Kepware BACnet to OPC-UA
|
Preserves the current middleware boundary and isolates Ignition from BACnet behavior | Adds another configuration and diagnostic layer | Measure OPC update latency, bad quality, and gateway resource use under peak demand |
| Direct Ignition BACnet | Consolidates acquisition and visualization in one platform | Integrated BACnet discovery is missing, increasing commissioning effort | Prove initialization, object reads, write behavior, recovery, and full-load timing |
| Ignition Edge substitution | May align acquisition with an edge and MQTT design |
The target edition, installed modules, licensing, and BACnet functionality must be checked before treating it as a drop-in replacement | Build the exact licensed runtime and execute the same benchmark used for the existing path |
The recommended path is a controlled direct-driver pilot while Kepware remains the production baseline. Replace the middleware only when the pilot meets defined quality and latency limits at the projected object load, not merely when 300 devices appear online.
Transaction load behind the device count
The number that matters is completed BACnet transactions per second at an acceptable response time. Three hundred devices with a few slowly changing objects can impose less work than dozens of controllers serving many rapidly polled objects.
For polling, the initial request rate is:
requested reads/s = total polled objects / polling interval in seconds
If each of 300 devices contributes P polled objects at interval T, the requested rate is 300 × P / T. Retries, timeouts, fragmented responses, writes, discovery traffic, and offline devices add work beyond that base rate. BACnet Change of Value subscriptions can reduce repetitive polling where both client and controller behavior support them, but subscription establishment, renewal, and reconnect handling still require testing.
| Quantity | Why it matters | Where to read it |
|---|---|---|
| Configured objects per device | Sets the base polling workload | Ignition tag configuration and BACnet object list |
| Polling interval | Converts object count into requested reads per second | Tag group or equivalent scan configuration |
| Response latency | Controls how quickly outstanding requests clear | Driver diagnostics and packet capture |
| Timeouts and retries | Multiply traffic when devices respond slowly or fail | Driver settings, logs, and packet capture |
| Bad-quality count | Separates connected devices from usable data | OPC Quick Client and tag quality diagnostics |
| Gateway CPU and memory | Shows whether load is local processing rather than network delay | Gateway system diagnostics |
Initialization and bad-quality mechanisms
A device reaching the network is not the same as a readable BACnet object. Initialization can fail during device discovery, address resolution, routing, object enumeration, or the first property exchange. A displayed object can still report bad quality when reads time out, the selected property is unavailable, the object reference is wrong, or the controller rejects the request.
A Carrier PIC6 installation with 40 controllers initialized only one, and attempts to read a value through the OPC Quick Client returned bad quality. That result calls for validation of the controllers’ native BACnet/IP settings before it can diagnose driver capacity. One working controller also provides a useful control: compare its network, device, and object behavior with a failing controller.
Integrated BACnet discovery is a known missing capability. Discovery improvements were described as work to be addressed after the driver-team work for version 2027.2 ships, so they offer no immediate commissioning remedy or committed delivery date.
Pilot diagnostic procedure
- Inventory every BACnet device, its device instance, network path, required objects, requested update interval, and required writes. Mark routed devices separately from devices on the client’s local BACnet network.
- Confirm the client and controller IP settings, subnet behavior, BACnet network configuration, device instances, and router path. Where broadcasts cross IP subnets, verify the installed BACnet broadcast-management or routing design rather than relying on local broadcast discovery.
- Start with one known controller. Initialize it, browse or configure a small set of required objects, and read them in the OPC Quick Client. Record quality, response latency, timeout events, and reconnect behavior.
- Add devices in measured batches. Keep object selection and scan timing representative of production so the test measures transaction load rather than an artificially light device count.
- Introduce the expected offline case by disconnecting a test controller. Observe whether retries delay healthy devices, then restore it and measure recovery without restarting the gateway.
- Repeat the same load through the Kepware
OPC-UApath. Compare quality, update age, resource use, failure isolation, and recovery using the same devices and requested objects.
Acceptance and verification
Define acceptance values from the BMS control and alarming requirements before testing. Read the actual update age at the consumer; a connected status is insufficient when values arrive too late for alarms, trends, or supervisory logic.
| Test | Pass condition | Failure direction |
|---|---|---|
| Steady-state acquisition | All required objects retain good quality and meet the project update-age limit | Reduce transaction demand or investigate device response timing |
| Offline-device test | Healthy devices remain within their update limit while one device times out | Review retry behavior, timeout settings, and request concurrency |
| Recovery test | The restored controller resumes good-quality updates without manual intervention | Inspect registration, routing, subscription, and reconnect diagnostics |
| Gateway load test | CPU and memory remain stable through peak polling and reconnect activity | Separate local processing limits from BACnet network limits |
| Write test | Authorized writes reach the intended property and read back correctly | Check object property, priority behavior, permissions, and controller configuration |
Recurring design pitfalls
Discovery convenience and runtime capacity are different properties. Missing integrated discovery raises engineering time and configuration risk, but it does not by itself prove a 300-device runtime ceiling. Conversely, successful discovery says little about sustained object quality.
Another common mistake is scaling by device count while leaving object count and scan rate undefined. Preserve the calculation sheet for total objects, requested reads per second, expected writes, and offline-device retries. Trend quality and update age during commissioning; a snapshot can miss periodic congestion and slow failure recovery.
Keep the existing middleware rollback path until the direct driver passes the complete benchmark. Introducing MQTT may solve distribution requirements, but acquisition quality must be verified before values are published downstream.
FAQ
What happens if Ignition connects to 300 BACnet devices?
Connection count alone predicts little. Calculate 300 × objects per device / polling interval, then measure response latency, retries, bad quality, CPU, and memory under the resulting load.
What happens if a BACnet device initializes but values show bad quality?
Check the object reference, requested property, controller BACnet/IP settings, routing, response packets, timeouts, and driver logs. Initialization proves only that part of the communication sequence completed.
What happens if one BACnet controller goes offline?
Timeouts and retries can consume request capacity and delay healthy devices. Test this condition deliberately and verify that the restored controller returns to good quality without a gateway restart.
When should I stop testing and contact official support?
Stop expanding the pilot when repeatable bad quality, failed initialization, or recovery faults remain after device addressing, native BACnet settings, routing, and packet flow have been verified. Capture gateway logs, driver diagnostics, a packet trace, the smallest failing device set, and the matching working case. Escalate that package through the manufacturer’s official support channel before changing production architecture.