Bacnet/IP with .NET

Question

I have a task where I need to understand the technical feasibility to setup a remote monitoring scenario for a HVAC solution which uses Bacnet/IP. I need to setup a .NET client that gets the telemetry and sends it to Azure IoT Hub. My current concern is to understand how can I connect to a Bacnet/IP network.

I don't have that much information about the hardware installed besides the fact that it has sensors for pressure and humidity on the network and a DDC controller (EBCON - Delta Controls). As I was told, I don't need to care about the actually sensors since they are sending the telemetry to the controller, so I only to care about the controller and connect to it.

Yet based on what I have read so far, I have some doubts about this information, but I don't have the technical knowledge to support it. It seems that based on the information that I have read Bacnet communication is done by UDP listening on a port (which seems to go against the above information that I need to connect to a controller), if this is true and I listen on a UDP port, will all devices broadcast the telemetry on the network and I only need to be listening? What is the controller role then? Can I ignore it?

Any explanation or pointers can could help me understand this from a programmer PoV would be appreciated.

Answer 1

For the benefit of others, if not also for yourself; there is the more BACnet-ty aspect of your question that I don't think has been addressed.

You have to be a bit more proactive with BACnet - you might have the presence of new devices (or at least devices that have just come online again) broadcast to you, but otherwise you have to actively read all the properties (/telemetry) values - at least the ones of interest.

There is the facility for subscribing for CoV (Change of Value) changes/values but at least in the past (if still not now) the concern was that this could flood the network, as well as possibly burden the device in having to keep sending updates to possibly many clients or just too-too often (above & beyond its primary job of monitoring & controlling the building for comfort and health & safety).

The standard does provide an 'object list' (upon 'device'-type objects), and a 'property list' upon every object, but you'll probably find that the 'property-list' is never supported/implemented despite it been a mandatory property (!?!).

So this is where you have to take an interest in every physical device - at least it's IP address & possibly MAC address too, along with all it's (relevant) objects & object-properties, for which you'll most likely have to sit with one/two/more engineers first to agree & understand as to what information that will actively be exposed (for you to monitor) & how (- e.g. the measurement units that a value is conveyed in).

In some cases (- e.g. maybe for small buildings), you might have to talk to all the devices individually, but in other cases you'll have points (/point 'object's) upon a gateway device that will represent all the devices that sit behind it.

So all in all, whether you direct to up to say 300 devices, or you interrogate 300 objects upon a gateway device - each one representing a physical device, you still might have a few properties of interest that you're interested in - under the guise of your telemetry, so 300 x 3 (for example), it adds up quite quickly, and then there's the error handling and complexity of the standard as a whole (- an uphill learning curve / you have to buy-in to understanding the foundations at least).

I'd recommend you also take a look at the (advanced & free) VTS (Visual Test Shell) tool.

You would require a VPN to allow secure access to the building's 'Internetwork' (/building-controls networks) remotely.

You can avoid the 'Foreign Device' registration piece/usage by using bog-standard network routing instead, in order to access the various VLANs/subnets within your building's 'Internetwork'.

The BACnet/IP (communication stack) is the BACnet protocol running over IP (Internet Protocol) transport, aka UDP/IP.

Not sure if this helps but it was worth pointing out; underestimate BACnet at your own peril (- at least the commitment/knowledge involved!!). ;)

Answer 2

And just by the way, there is a FOSS C# BACnet Client you can use for reference: https://sourceforge.net/projects/yetanotherbacnetexplorer/

Answer 3

BACnet does indeed communicate via UDP. The scenario you describe, while possible, is quite a dangerous approach. Very few BACnet products offer any sort of BACnet protocol security, so to make a secure connection you will need to VPN into your site. Once on the VPN, then the VPN itself will most likely block broadcasts, so you will need to use BACnet "Foreign Device Registration" to connect. However most VPNs do a NAT translation too, so the BACnet server on site will have to supply "BACnet BBMD with FD with NAT" support. Quite rare. An alternative is to get a box on your site supplying connectivity from the site to the Azure IoT site. There are a few companies that offer this type of product, but it seems you want to program your own. This will not be trivial, and then you will have to do the "BACnet Object" to "whatever-data-format-you-need-on-Azure" mapping, which will need a rather deep understanding of the BACnet specification, which, on paper, is about 2.5 inches thick. You could ignore the VPN approach, port forward port 47808 (BACnet default, but it can be different per site config) to the controller. This is how some rather large companies have had their HVAC systems hacked. If you do pursue this approach, you will still need a BACNet Client-to-Azure mapping/transfer agent. You have not chosen a trivial project here. ;) Or you could purchase an off-the-shelf product (box) that does this all already.