Who Owns the BMS Network? Access, Backups and Recovery | Cobler
Blog
Who Owns the BMS Network? Access, Backups and Recovery
Who is responsible for a building's BMS network, how people should log in and connect remotely, what to back up, and what keeps running when the network fails, with a head-end recovery scenario.
Tan Kok XinBuilding Automation & BMS Fundamentals
Part 11 of 16 in Cobler's Building Automation and BMS Fundamentals course. New here?See the course page.
Part 10 joined the office tower's chillers, air handling units (AHUs) and meters into one BMS (building management system) over a network, and left a question: who is responsible for that network, who may log in and connect remotely, and what keeps running when it fails? When office email stops working, most people know to call the IT team. For the BMS, the chiller contractor, the BMS contractor, the IT team and the facility manager may each assume someone else is responsible.
The building owner is accountable for the BMS network, even when contractors run parts of it day to day. BMS network security comes down to five things the owner should settle in writing: who is responsible for each part, how each person logs in, how remote access works, where the backups are kept, and what keeps running when the network fails. This part takes them one at a time, using the office tower, and ends with a recovery scenario.
The BMS network runs equipment, so it has different priorities from office IT
The network from Part 10 looks like an office network: switches, cables and IP addresses. But it does a different job. An office network carries data. A BMS network carries commands to real equipment, such as a valve on AHU-12A or the enable signal for a chiller.
That difference changes the priorities. For office IT, the first priority is usually keeping data confidential, and a short outage to install an update is an acceptable price. For a BMS, the first priority is keeping the equipment running, because an outage means a floor with no cooling. People who work with building and plant controls call this kind of network OT (operational technology), to separate it from .
FAQ
Frequently asked questions
Ask us about this topic
Something in this article you want to dig into — or a situation in your own building it doesn't quite cover? Send us your question. We don't run public comments; the team replies to you directly by email.
OT networks also contain equipment that office IT rarely sees:
Long-lived controllers. A field controller may stay in service for fifteen or twenty years. Many cannot run security software or accept frequent updates, and restarting one to install an update stops whatever it controls.
Protocols that trust whoever can reach them. BACnet and Modbus were designed for closed networks. In their common forms, they do not check who is sending a command.
Fragile network connections. Imagine the IT team runs a routine security scan across every network it can reach. An old chiller controller receives more traffic than it can handle and locks up. The chiller stops, and nobody connects the two events for hours, because the scan is normal practice on an office network.
None of this means IT and OT people cannot work together. It means each side needs to know the other's first rule before they share a cable. For a longer discussion, see OT vs IT networks: why the two teams clash.
Write down who is responsible for each part
A BMS fault often takes days longer to fix when nobody is sure whose job it is. The remedy is a short responsibility table, agreed at handover and updated when contracts change. Here is one for the office tower:
Part of the system
Usually looked after by
What the owner should hold
Field controllers and their programs (for example, AHU-12A)
BMS contractor, under the maintenance contract
Latest program backups; the sequence of operation (Part 6)
Head-end server, software and licences
BMS contractor, with the facility team as daily users
Licence details; head-end database backup; admin account under the owner's control
BMS network switches, cabling and the firewall between the BMS and the office network
Agreed between the IT team and the BMS contractor, and written down
Network drawing; who holds the firewall rules
Remote access
Approved by the facility manager; run by IT or the BMS contractor
List of who has remote access, and how it is switched on and off
User accounts
Approved by the facility manager
Current list of users and their access levels
The chillers' own controls and safeties
Chiller maintenance contractor
Chiller register maps; service reports
The owner can hand the work to others, but should keep copies of everything in the right-hand column. If a contractor leaves, those records are what let the next one take over.
Give every person their own login
Many BMS head-ends are still run on one shared account, often with the username and password it had on the day it was installed. It is convenient, and it causes two problems.
First, nobody can tell who did what. In Part 8 we saw how a point left in manual can stay that way for weeks without anyone noticing. With a shared account, the log shows that "admin" did it, which does not help anyone find out why. Second, when a person leaves, the only way to remove their access is to change the shared password and tell everyone else.
Individual logins fix both. Each person gets their own account, and each account gets only the access that person's job needs. A common arrangement has three levels:
View: see graphics, trends and alarms.
Operate: also acknowledge alarms and change setpoints and schedules within set limits.
Engineer: also change programs, point mapping and system settings.
Change every default password at handover. Remove accounts on the day someone leaves or a contract ends. The BMS then keeps an audit trail: a record of who changed what, and when.
Control remote access through one path
Remote access lets a contractor diagnose a fault or adjust a sequence without driving to site. It is useful, but an uncontrolled connection is also a way for outsiders to reach the building's controls. So no BMS device should be reachable directly from the internet, and all remote access goes through one controlled path.
In practice, that means:
Keep the BMS network separate from the office network, with a firewall between them. The firewall only allows the connections that are agreed and written down.
Bring remote users in through one secured entry point, such as a VPN (virtual private network, an encrypted connection) or a remote access gateway, with individual logins and, where the system supports it, a second check such as a code sent to the user's phone.
Switch remote access on only when it is needed, for example for a contractor's scheduled support visit, and keep a log of each session.
Agree how scans and updates are done. IT security scans of the BMS network should be planned with the BMS contractor. Updates to controllers and the head-end happen in planned maintenance windows, and devices that cannot be updated are protected by keeping them on the separated network.
{{media:482}}
Remote users reach the BMS through one controlled entry point; the office network and the internet never connect straight to a controller.
Keep configuration backups, and keep a copy yourself
A BMS holds years of work that exists nowhere else: the programs in each controller, the head-end database, graphics, schedules, setpoints, alarm limits and the gateway mappings from Part 10. If a controller fails and there is no backup of its program, the contractor has to rebuild it from the sequence of operation, if that document exists. That can take days instead of hours.
A good backup routine answers four questions:
What is backed up? Controller programs and settings, the head-end database and graphics, gateway configuration files, user accounts, and the points list.
When? At handover, after every change to programs or settings, and on a regular schedule agreed in the maintenance contract.
Where? In at least two places, one of which the owner controls and which is not permanently connected to the BMS network. A copy that exists only on a contractor's laptop is not the owner's backup.
Does it work? A backup is only proven once it has been restored. Ask the contractor to show a restore, for example onto a spare PC, at handover and occasionally afterwards.
Know what keeps running when the network fails
In Part 3 we saw that a BMS is built from many field controllers, each running its own program. That design is what keeps the building going when the network fails. If the network cable to level 12 is cut, AHU-12A's field controller keeps reading its sensors and moving its valve to hold its setpoint.
What you lose depends on where each job lives:
Keeps working: each field controller's own control loops, safeties wired to the equipment, and any schedules stored in the controller itself.
Stops or weakens: the head-end's view of the building, alarms reaching the operators, trend recording (unless the controller or gateway stores readings and sends them later), schedules held only at the head-end, and anything that needs information from other controllers. For example, a chilled water reset that uses AHU valve positions (Part 12) cannot see those positions, so a well-written sequence falls back to a safe fixed setpoint.
Cloud services: if the building sends data to a cloud platform for dashboards or analytics, those stop updating during an internet outage. Control should never depend on an internet connection. For more on this split, see edge vs cloud for building and energy systems.
The practical question for any building is: "If the head-end or the network goes down, which of our jobs stop?" The answer should be in the sequence of operation, and it is one of the tests in Part 15.
{{media:483}}
When the network is cut, the field controller keeps AHU-12A running; the operators lose their view, their alarms and the coordination between controllers.
A recovery scenario: the head-end server fails
Here is how the pieces above work together. Suppose that at 7:40 one Tuesday morning, a technician at the office tower finds the head-end screen frozen. The server will not restart; its disk has failed. In this scenario, the AHU schedules are stored in the field controllers.
What happened overnight: the field controllers carried on. AHU-12A started on its own schedule and is holding its supply air temperature. The chillers are running under their own controls and the plant sequence in the supervisory controller. What the team has lost is its view and its alarms. The recovery goes like this:
Check the building is running. Walk the plant room and read the chillers' own displays. Check AHU-12A's local controller display, and ask level 12 whether the space is comfortable.
Cover the gap in alarms. With no head-end, alarms will not reach anyone. Start regular manual rounds of critical equipment, such as the chiller plant and the server room cooling, until the head-end is back.
Call the right people. The responsibility table says the BMS contractor looks after the head-end. The facility manager provides the owner's copy of the latest backup and the licence details.
Restore the head-end. The contractor installs the software on a replacement server and restores the database from the backup.
Check before trusting it. Confirm every controller and gateway shows good communication. Compare setpoints, schedules and alarm limits with the backup record. Look for any points left in manual during the outage (Part 8). Check that the clocks agree.
Record what happened. Note the gap in the trend history, how long the recovery took and anything that slowed it down. Take a fresh backup of the restored system.
With a recent backup held by the owner, this can be done in a day. Now suppose the only backup was two years old and on a contractor's laptop that has since been replaced. The team would have to redraw graphics, re-enter schedules and alarm limits, and rediscover every change made since. The equipment would still be running, but the building would be harder to operate for weeks.
Worth knowing: Newer versions of BACnet add a secure option called BACnet/SC, which lets devices check who is sending a command. Many installed systems do not use it, which is why keeping the BMS network separate and controlling remote access still matter.
What comes next: running the chiller plant
You have now seen how the BMS is connected, mapped and looked after. The rest of the course applies it to the equipment that uses the most energy. The next part, How a BMS Optimises the Chiller Plant: Staging and Temperature Reset, starts with the office tower's chiller plant and this question: how does the BMS decide how many chillers to run and how cold to make the water?
Check your understanding
Why is a separate login for each person better than one shared "admin" account? Each change is then recorded against a named person in the audit trail, so a problem such as a point left in manual can be traced and explained. Access can also be limited to what each job needs and removed on the day someone leaves, without changing everyone else's password.
The network switch serving level 12 fails. What keeps working on AHU-12A, and what is lost? AHU-12A's field controller keeps reading its sensors and controlling its valve and fan from its own program, and any schedule stored in the controller still runs. The head-end loses its view of AHU-12A, alarms from it do not reach the operators, trends stop unless the controller stores them, and any sequence that needs AHU-12A's data, such as a chilled water reset, falls back to its safe default.
Recap: A BMS network runs equipment, so keeping it running comes first, and its controllers and protocols need different care from office IT. The owner is accountable and should agree a written responsibility table and hold copies of the key records. Every person gets an individual login with only the access they need. Remote access goes through one controlled, logged path, with the BMS network separated from the office network and nothing exposed directly to the internet. Backups cover programs, databases, mappings and accounts, are held in a place the owner controls, and are tested by restoring them. Field controllers keep their equipment running when the network fails; what stops is the view, the alarms, the trends and the coordination.
Cobler builds CobiNeural, a platform that shows a facility team its building's energy, water and indoor air data as live numbers across the whole site. To see how your building performs, talk to us.
Tan Kok XinBuilding Automation & BMS Fundamentals
