The problems with BACnet IP in IoT building management devices

BACnet IP is a industry specific network transport stack, competing with the likes of TCP/IP - is it lunacy to develop a non-TCP/IP solution specifically for prop-tech IoT building management devices? And more specifically Building Automation and Control Networks (BAC net)?

Introduction

On the face of it, saying "TCP/IP isn't good enough for the HVAC industry" seems preposterous. Is that the case, or does it make sense - right time/right place?

The Good

• BACnet is a standard developed by the US based industry professional association ASHRAE (the Australian equivalent is AIRAH). Therefore the standard has had considerable time in consultation with industry to meet industry requirements.
• BACnet makes it easy for installers to scan a network to discover available devices, and to understand what those device capabilities are.
• BACnet, as an industry led initiative, displaced a vendor developed solution (later ratified as an open standard) - LonWorks. BACnet simplified the approach of LonWorks, and ultimately has largely displaced LonWorks protocol.
• BACnet devices are tested at the BACnet Testing Laboratories (BTL) for compliance - ensuring consistency in interoperability with vendor solutions.

The Bad

• ASHRAE decided that TCP/IP wasn't good enough for building automation and controls networks.
• BACnet was initially developed as a 2-wire RS485 serial data protocol. The IP extension was added on after the fact.
• BACnet IP devices have their own address space, separate to a standard IPv4 or IPv6 network address.
• No protocol security layer exists - packets can be sniffed, intercepted or re-routed using wireshark, for example.
• Limited number of devices on a network segment - no flexibility as with TCP/IP.
• Managed network switches and routers will not route traffic.
• BACnet IP devices use edge multicast broadcast to declare their presence on the network.
• Each reading or control data sent across the network carries a large metadata payload with every transmission.
• The above issues with the network design cause significant delays in sending messages from one device to the other - seconds rather than milliseconds on TCP/IP.
• The above limitations large IT networks require a Virtual LAN (VLAN) segment to be created to isolate BACnet devices from other devices, therefore requiring additional configuration including adding routing rules.
• Remote data collection or control of a field office is not possible directly using BACnet, necessitating having a local computer or BMS on site.

Changes we'd like to see

Our perspective is that HVAC/prop-tech/operational IoT building management devices should play by the rules of the IT game when connecting to IT equipment. Having a standard that effectively condones edge multicast broadcast as part of the way the protocol 'just works' runs counter to the interests of the IT department and network administrator. Saying this is the only way it can be done reflexively sounds wrong on so many levels.

We can see a place for a protocol like BACnet IP - on small and private networks, unconnected to corporate or user traffic. Elsewhere, we need to find a better solution, such as Message Queuing Telemetry Transport (MQTT). Modbus TCP is still the default position where routing messages via the network infrastructure is required. This is not ideal as Modbus is a protocol that requires constant polling for data, where protocols such as MQTT are a publish/subscribe messaging platform, where data is only sent where required.

Conclusion

BACnet is a bit of nightmare from the perspective of the IT network administrator, requiring special treatment from other typical network connected devices. Equally, BACnet makes the job of an installer easier than using, say, Modbus IP. That is, until connection to a large IT network with a remote read/write capability becomes the requirement. In which case, it is deficient in the extreme. Building a stand-alone network is insane when we as an industry are trying to create convergence and integration between systems and processes to allow for optimisation to occur.

In our project with the NSW Education Department, we encountered this over and over. We have a professionally run network that is focused on security and reliability, and there are vendors required to connect to such infrastructure that, due to standards such as BACnet IP, find it incredibly difficult to be a 'good citizen' on the network.

We have to consider that sharing the network is the path forward for building-to-grid and other optimisation applications - so we (as in industry) must accordingly consider other users on the network.