Who Owns the BMS Network? Access, Backups and Recovery

Part 11 of 16 in Cobler's Building Automation and BMS Fundamentals course. New here? See the course page.

When office email stops working, most people know to call the IT team. But what if the BMS (building management system) stops talking? The chiller contractor, the BMS contractor, the IT team and the facility manager may each assume it's someone else's job.

So who actually owns it? The building owner is accountable for the BMS network, even when contractors run parts of it day to day. And BMS network security comes down to five things the owner should settle in writing. Who is responsible for each part, and how does each person log in? How does remote access work, where are the backups kept, and what keeps running when the network fails?

In Part 10 we joined the office tower's chillers, air handling units (AHUs) and meters into one BMS over a network. Now let's take those five things one at a time.

OT and IT

The network from Part 10 looks like an office network, with 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 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 IT (information technology).

OT networks also hold equipment that office IT rarely sees:

• Long-lived controllers. A field controller may stay in service for fifteen or twenty years. Many can't 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 don't check who is sending a command.
• Fragile network connections. Picture the IT team running a routine security scan across every network it can reach. An old chiller controller gets more traffic than it can handle and locks up.

In that last case the chiller stops, and nobody links the two events for hours, because the scan is normal practice on an office network. None of this means IT and OT people can't 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.

Who looks after what

So the first thing to settle is who's responsible. A BMS fault often takes days longer to fix when nobody is sure whose job it is. The fix is a short responsibility table, agreed at handover and updated when contracts change. Here's one for the office tower:

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 carry the work forward.

Logins

The second thing is how people log in. Many BMS head-ends still run on one shared account, often with the username and password it had on the day it was installed. It's convenient, but 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 only shows that "admin" did it, which doesn't help anyone learn 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.

So change every default password at handover, and 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.

Remote access

The third thing is remote access. It lets a contractor diagnose a fault or adjust a sequence without driving to site. That's 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:

1. 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.
2. Bring remote users in through one secured entry point, such as a VPN or remote access gateway.
3. Switch remote access on only when it's needed, for example for a contractor's scheduled support visit, and log each session.
4. Agree how scans and updates are done. Plan IT security scans with the BMS contractor, and update controllers and the head-end in planned maintenance windows.

A VPN is a virtual private network, an encrypted connection, and each remote user still gets their own login. Where the system supports it, the entry point should add a second check, such as a code sent to the user's phone. And devices that can't be updated are protected by keeping them on the separated network.

Remote users reach the BMS through one controlled entry point. The office network and the internet never connect straight to a controller.

You might wonder why all this is needed if the protocols are so standard. Well, newer versions of BACnet add a secure option called BACnet/SC, which lets devices check who is sending a command. But many installed systems don't use it. So keeping the BMS network separate and controlling remote access still matter.

Backups

The fourth thing is backups. A BMS holds years of work that exists nowhere else. That's the programs in each controller, the head-end database, graphics, schedules, setpoints, alarm limits and the gateway mappings from Part 10. Say a controller fails and there's no backup of its program. Then the contractor has to rebuild it from the sequence of operation, if that document exists, which can take days instead of hours.

A good backup routine answers four questions:

1. What is backed up? Controller programs and settings, the head-end database and graphics, gateway files, user accounts and the points list.
2. When? At handover, after every change to programs or settings, and on a regular schedule in the maintenance contract.
3. Where? In at least two places. The owner controls one, and it isn't permanently connected to the BMS network.
4. Does it work? A backup is only proven once it has been restored. Ask the contractor to show a restore at handover, and now and then afterwards.

A copy that exists only on a contractor's laptop isn't the owner's backup. And the restore test can be done onto a spare PC, so it doesn't touch the live system.

When the network fails

The fifth thing is 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. 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 we 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, alarms reaching the operators, and schedules held only at the head-end. Trend recording stops too, unless the controller or gateway stores readings and sends them later.
• Needs a fallback: anything that uses information from other controllers. A chilled water reset that uses AHU valve positions (Part 12) can't see them, 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 that split, see edge vs cloud for building and energy systems.

So the practical question for any building is this. 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's one of the tests in Part 15.

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

So let's see how those five things work together. Say that at 7:40 one Tuesday morning, a technician at the office tower finds the head-end screen frozen. The server won't restart, because its disk has failed. In this scenario, the AHU schedules are stored in the field controllers.

So 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:

1. Check the building is running. Walk the plant room, read the chillers' displays and AHU-12A's local display, and ask level 12 if it's comfortable.
2. Cover the gap in alarms. Without a head-end, alarms reach nobody. Do manual rounds of critical equipment until it's back.
3. Call the right people. The responsibility table says the BMS contractor looks after the head-end.
4. Restore the head-end. The contractor installs the software on a new server and restores the database from the backup.
5. Check before trusting it. Confirm every controller and gateway shows good communication, then compare settings with the backup record.
6. Record what happened. Note the gap in the trend history, how long the recovery took and what slowed it down.

A few details on those steps. The manual rounds cover things like the chiller plant and the server room cooling. The facility manager provides the owner's copy of the latest backup and the licence details. The check before trusting the head-end compares setpoints, schedules and alarm limits with the backup. It also looks for points left in manual during the outage (Part 8), and checks that the clocks agree. And once it's all done, take a fresh backup of the restored system.

With a recent backup held by the owner, all of this can be done in a day. Now suppose the only backup was two years old, 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 run, but the building would be harder to operate for weeks.

The chiller plant

So now the BMS is connected, mapped and looked after, with an owner who holds the keys and the backups. That's the foundation. The rest of the course puts it to work on the equipment that uses the most energy.

Down in the basement, the office tower's chiller plant runs all day. How does the BMS decide how many chillers to run, and how cold to make the water? That's Part 12: How a BMS Optimises the Chiller Plant.

Check your understanding

1. Why is a separate login for each person better than one shared "admin" account?

2. The network switch serving level 12 fails. What keeps working on AHU-12A, and what's lost?

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, should agree a written responsibility table, and should 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. The BMS network is separate from the office network, and nothing is exposed directly to the internet.
• Backups cover programs, databases, mappings and accounts, sit 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.

This is Part 11 of 16 in Cobler's Building Automation and BMS Fundamentals course. Previous: Integrating Mixed-Vendor and Legacy Systems Into One BMS. Next: How a BMS Optimises the Chiller Plant: Staging and Temperature Reset.

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.