Is your BMS network ready for the future?
Pre-2000 BMS networks were mostly made up of proprietary RS485 communication networks, long daisy chained screened cable networks running through plant rooms, up risers and through floor ceilings picking up hundreds of BMS field controllers.
As obsolete mechanical equipment was upgraded over the years, the new equipment was often provided with a BMS high level interface. At the same time, the proprietary BMS system was being upgraded and replaced with a BACnet open protocol system.
It was great, we could simply extend the closest sub network to the newly replaced MSSB Electric meters, distribution board electric meters, chillers, Variable Speed Drives, thermal meters, fire panel, lighting control system, generators etc. Over a 10-20 year period our BACnet MSTP RS485 sub networks grew and grew.
Around 10 years ago we started to realise that although these new devices could quite easily communicate with each other on the same sub network, we started having communication issues, and there were a variety of reasons why this was happening.
What was causing our networks to deteriorate
BACnet MSTP (Master Slave Token Passing)
BACnet manages communications with a token passing system. If a device has the token, then it can communicate with the master controller or other devices; if the device needs to say something and it doesn’t have the token, then it needs to wait until the token is passed to it. The more devices we added to the sub network, the longer the token took to get around the sub network. Initially, this wasn't too much of an problem, since we weren't doing much with the new data, mostly viewed on graphics for occasional monitoring or troubleshooting.
New software applications
It didn’t take long for BMS software developers to start taking advantage of all this newly available data, more advanced graphics, trends and alarms. But certainly, cracks in our sub network design started to creep in with the advancement of Energy Management Systems (EMS). Now we had an application that was polling data at least every 15 mins, 24/7.
Now, keep in mind that the electric meter can only pass back the kWh consumption when the meter has the token.
Not all devices are equal
The BACnet protocol defines how devices communicate and the rules around objects and their associated properties, but vendors do not have to provide all the available BACnet options. For example, Change of Variable (COV) is a BACnet device property, which means that if you map a point on your graphic and set up the profile for COV, then the device will only transmit the data when the variable changes; it does not continually need to poll the device. If you have a VSD run status mapped as COV, then when the pump starts in the morning, the status is changed from Off to On. When the pump stops in the afternoon, the status is changed from On to Off. The token was only required twice. Most VSD’s when communicating with their on-board default BACnet communications interface, do not support COV. Some can be purchased with an advanced BACnet communication card which does support COV.
The issue is that, if you map the VSD run status as a control interlock in your BMS controller’s software program, the controller is going to poll to check if the pump is running every few seconds, and the VSD can only report the mapped status when it has the token.
Overloaded sub networks
By the time we realised this it was too late, we had hundreds of devices on hundreds of meters of cable running through electrical risers, plant rooms and through ceilings in occupied areas. Network speed dramatically decreased as the token slowed down as every device needed to communicate and likely had a back log of information to provide
Many devices can only pass back one piece of information when it has the token, therefore, if you open a VSD HLI graphic displaying five points, then the token needs to go round the entire sub network five time to update the graphic.
Technology
The issue gets exponentially worse once you add building analytics, which is polling data (hardware and software points) all day, every day. Integrated platforms are starting to get specified in premium grade new construction projects, and it is a matter of time until tenant side technology (space utilisation, wayfinding etc) starts finding its way into existing buildings as competition increases to attract or retain high profile tenants.
The need to poll for data is going to be doubling and our current subnetwork design is not going to cope.
BMS Network upgrades
Most BMS network upgrades focus on the Ethernet layer, connecting servers and main network controllers together, providing more network switches to reduce bottle necks, upgrading internet connections, connecting to client networks etc. However, people rarely consider that their communication issues are likely at the sub network layer and not the Ethernet layer.
How do we improve our sub-network design?
The issue is difficult to fix as it usually requires new communications cables to be installed to separate the sub networks, it is therefore important to understand the problem specific to your building and put in place a plan to improve the sub networks over time.
Ideally, we need to separate all different vendor devices onto their own sub networks, within reason and budget.
I would suggest two options; the first is likely how your subnetworks are currently being separated if you have already worked out that you have a sub network issue; the second option is one that will better protect you in the future.
Option one:
In a plant room, for example, at your main network controller, separate out one subnetwork for all the BMS controllers. This will stabilise HVAC critical control as the token is not passed to non-control devices (electric meters). This is usually quite simple, as all the controllers are likely in the same control panel. A second sub network round the plant room to all VSD’s. Most of this cable already exists and as meters and BMS controllers are generally not dotted around the pumps and fans, this may just require a few interconnecting cables.
All electric meters should be separated onto their own sub network, I think this is the most important sub network as communication issues with electric meters can cause zeros to creep into kWh databases and this can be dramatic when displaying consumption on dashboards and in reports.
If a floor nearby has VAV’s that are cabled back to the plant room panel, then separate that sub network.
Option two:
When we first started connecting new devices to the network, it made sense to connect them into the BMS. We did not have any other technology contractors or control networks in the building, so the BMS supplier cabled out to these network ready devices. At that time and still generally now, the BMS network architecture concept is to connect high volume devices (VSD’s and electric meters) to sub networks connected directly into BMS network controllers. It’s how their system works best.
The intent of option two is to take a sub network, for example, 20 electric meters, disconnect it from the BMS network controller and connect it directly to the Ethernet network via a BACnet/IP to BACnet/MSTP gateway. Rather than the BMS poll the data directly from its local RS485 truck, it will now poll the data via the Ethernet network.
Let’s assume that we have now connected the electric meter subnetwork and the VSD sub network separately into the Ethernet network. The BMS controllers should remain directly connected into the BMS network controller. This significantly opens up our subnetwork devices to current and future increased traffic.
The BMS server is now accessing HVAC control data via the Ethernet network directly to its network controllers. The Energy Management System is directly accessing data via the Ethernet network to the electric meter sub network gateways.
If you open a graphic of the high level interface to a VSD, the data is accessed directly from the VSD sub network gateways. The analytics server is accessing data from all sub networks. All these various servers, software programs and operators are accessing different sub networks, and they are, firstly, not all competing for the same token availability, and secondly, not all bottle necking data through the BMS network controllers.
Another advantage of this network design is that when you need to upgrade your BMS controllers/system, which can be quite disruptive, it won’t affect your Energy Management System, as the Energy Management System is not collecting data via your BMS network controllers. Even if currently your Energy Management System is your BMS system, the network separation will improve reliability and ready your network for when you upgrade to a cloud-based system.
Featured - Latest published online course
BMS for mechanical consultants course
This course was developed by a BMS consultant for mechanical consultants involved in Building Management System projects. Learn how to reduce risk to your company, your client, and the BMS contractor.
Self-paced online course.
12 hours of video lessons.
Training manual (+90 pages).
BMS design examples.
A sample of Lifecycle Controls BMS specification clauses are provided to assist with learning. You can use these in your own specification.
Online shop
Free control strategy mini courses
Create a free account in our Learning Management System and complete the free chilled water control system mini-course. A certificate is provided at the end of the course. A copy of the control strategy is provided as a Microsoft Word document for you to modify in your own BMS designs.
Please join our newsletter
To be notified when new courses, design templates, and digital products are published.
For updates to coaching availability.
For updates to business-to-business consulting services.
New Youtube video releases and occasional updates on what I am up to.
I will not fill up your inbox with crap.
Bryce Anderson
I am an independent Building Management System consultant based in Australia. I started in the BMS industry in 1998 and initially worked for BMS companies for the first 15 years of my career (2 years in South Africa, 9 years in London, and 4 years in Melbourne). In 2014 I transitioned into BMS consulting, saw a massive gap in the lack of specialist BMS consulting, and started Lifecycle Controls in 2017.
My focus is currently on BMS technical training, coaching, and B2B consulting for BMS companies and mechanical consultancies. Because, fixing one project at a time was making no difference. Training thousands of engineers will :-)
