Proving the BMS Works: Commissioning and Handover

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

When you buy a new phone, you can try everything in an evening. A building management system (BMS) is much harder to try out. It controls equipment on every floor, and much of what it must do only happens when something goes wrong. Think of reacting to a failed fan, or to a power cut.

So far we've described everything a well-set-up BMS should do. In Parts 12 to 14, that went right up to running the plant, running the air side and holding down demand. So how does anyone know it really does all this, before the owner accepts the building from the contractor? We test the BMS against its written sequence of operation. First we go point by point, then function by function, with a witness watching and signing each result. We call this commissioning, and we'll work through it as a paper exercise on AHU-12A, with worked answers.

Commissioning

A BMS project starts with a design. That's a points list, a network, and a sequence of operation, the plain-English description of what the controls must do, from Part 6. Then contractors install sensors, controllers and wiring on site. Commissioning is the work of proving that what was installed does what the design says, before the owner takes it over.

Several parties are involved:

• The BMS contractor carries out the tests and fixes what fails.
• A witness watches each test and signs the result. That's usually the consultant's engineer, or a commissioning specialist the owner appoints.
• The owner's facility team will run the system afterwards, so they should attend and learn how it behaves.
• The mechanical and electrical contractors must have finished their own work. The BMS can't be tested on an AHU with no power or no chilled water.

That last point causes a familiar problem. The BMS is usually the last system finished on a building site, because it depends on everyone else's equipment. So when earlier work runs late, commissioning time gets squeezed, and there's pressure to skip tests to meet the handover date.

What happens if they're skipped? A BMS that was never properly tested will usually still switch on for a handover demo. Then it runs poorly for years. Equipment starts and stops too often, false alarms pile up, and nobody traces the wasted energy back to the missing tests.

So good project engineers protect the testing time. If it gets squeezed, they record the risk in writing instead of quietly skipping tests. Our article on the reality of BMS project delivery describes these pressures.

Commissioning happens in two stages:

1. Point checks, often called point-to-point checks: every sensor reads correctly and every output moves the right device.
2. Functional tests: the sequence behaves as written, including what happens when something fails.

AHU-12A's sequence

So what exactly are we testing? Here's the short version of AHU-12A's sequence. It gathers what earlier parts described. That's the control loops from Part 4, the schedule from Part 7, and the alarms and overrides from Part 8. It also covers what happens when the network fails, from Part 11, and the static pressure reset from Part 13.

1. Occupied mode: on the schedule, the BMS sends the supply fan a run command. That's 8am to 6pm, Monday to Friday, and optimum start may begin earlier.
2. Fan proving: the fan status must show "running" within one minute of the command. If not, the BMS raises a high-priority "AHU-12A supply fan failure" alarm.
3. Temperature control: while the fan is proven running, the chilled water valve holds the supply air at its setpoint. That's 14 °C, with reset as in Part 13. Whenever the fan isn't proven, the valve stays closed.
4. Pressure control: the fan speed holds the duct static pressure setpoint, which the reset adjusts from the VAV damper positions.
5. Sensor failure: if the supply air reading leaves 0 to 50 °C or stops updating, raise a high-priority alarm. It then holds the valve at a fixed 50%.
6. Fire alarm: a hard-wired signal from the fire alarm panel stops the fan directly, whatever the BMS commands.
7. Alarms: if the supply air is over 2 °C above setpoint for 15 occupied minutes, raise a medium-priority alarm.
8. Overrides: any point in manual or override is flagged on the AHU-12A graphic, and listed in a daily override report.
9. Power-loss restart: after a power cut, the controller restarts with its setpoints and schedules unchanged, and its clock correct.
10. Network or head-end failure: AHU-12A's field controller keeps running on its own, with its stored schedule and setpoints.

A few of those items need more detail, because the tests depend on it.

• Fan proving. The same alarm fires if the status drops out while the fan is commanded to run. In both cases the BMS also removes the run command and closes the chilled water valve.
• Fire alarm. The BMS reads the fire alarm signal, shows it, and doesn't try to restart the fan. Once the fire alarm is reset, the fan returns to its normal sequence.
• Alarm text. The too-warm alarm reads "AHU-12A supply air too warm". If the filter differential pressure stays above 250 Pa for 10 minutes, a low-priority "AHU-12A filter dirty" alarm is raised.
• Power-loss restart. In occupied mode, the fan restarts after a 3-minute delay, so the building's AHUs don't all restart at the same moment. Part 14 explained why staggered starts matter.
• Network failure. Part 11 explained what keeps working. Alarms raised while the link is down are held in the controller, then reported with their original time when the link returns.
• After a network failure. The head-end reconnects to every controller, and the trend records show the outage as a marked gap.

AHU-12A started with seven points in Part 3. Part 6 added an eighth, the fire alarm signal, a digital input from the fire alarm panel. Part 13 added a ninth, duct static pressure, an analogue input. The tests below use all nine.

AHU-12A's nine points, and which of the seven functional tests uses each one.

Point checks

So where do we start? With the simplest question: does each point tell the truth? A point check compares what the BMS screen says with what's really happening at the equipment. One person stands at the AHU with a measuring instrument, and another watches the BMS screen. Here's AHU-12A's point check sheet, with the check for each point and the rule for a pass.

One check needs special attention, and that's command versus status. When the BMS commands the fan on, the screen shows the command. But that only proves the BMS sent the instruction. The status point must come from the equipment itself, so that it shows whether the fan is actually moving air. So during the point check, confirm where the status signal comes from, as Part 6 explained.

A differential pressure switch across the fan, or a current switch on the fan motor's cable, sees the fan working. A run contact in the fan's drive or starter only proves the drive or starter has switched on, so it wouldn't notice a broken belt. And a status point wired to copy the command is worse. It always agrees with the command, so it hides a tripped motor as well.

Functional tests

Once every point tells the truth, the functional tests check the sequence itself. Each test states a starting condition, the action and the expected result, and the witness signs pass or fail. The right contractor does any test that switches off equipment or interrupts power, following the site's safety procedures.

• Test A, fan failure (command versus status): with AHU-12A running, the contractor stops the fan at its drive. The BMS still commands it to run. Expected: the status drops, and within one minute the BMS raises the high-priority fan failure alarm. It removes the run command and closes the chilled water valve.
• Test B, sensor failure: disconnect the supply air temperature sensor at the controller. Expected: the reading shows as failed, and the BMS raises a high-priority alarm and holds the valve at 50%.
• Test C, fire interlock: the fire contractor simulates a fire signal. Expected: the fan stops within seconds, whatever the BMS commands, and the BMS shows the fire alarm. The valve closes because the fan is no longer proven. The fan stays off until the fire alarm is reset, then returns to its normal sequence.
• Test D, alarms: override the chilled water valve closed so the supply air warms up. Expected: after 15 minutes more than 2 °C above setpoint, the "AHU-12A supply air too warm" alarm reaches the operator at medium priority. Then release the override.
• Test E, override removal: put the chilled water valve in manual at 100%. Expected: the graphic flags it as manual, and it appears in the override report. Release it to automatic. Expected: the temperature loop takes control again, and the override report is empty.
• Test F, power-loss restart: during occupied hours, switch off the controller's power supply for a few minutes, then restore it. Expected: the controller restarts with setpoints, schedules and clock correct, and the fan restarts after its 3-minute delay. No points are left in manual, and the trend logs resume with a visible gap for the outage.
• Test G, network or head-end failure: with AHU-12A running, disconnect the head-end from the network for about 20 minutes. During the outage, use a hand pump to hold 300 Pa on the filter pressure sensor for more than 10 minutes. That gives the controller an alarm to report.

For test G, here's what we expect. AHU-12A keeps holding its supply air temperature and follows its stored schedule. When the head-end returns, it reconnects to the controller, and the filter alarm appears with the time it was actually raised. The trend shows the outage as a marked gap.

Test A step by step: the command stays on while the fan stops. The BMS must notice within one minute and make the AHU safe.

Test day

So let's run the exercise. Here are the witnessed results from AHU-12A's test day in the office tower. The specification's acceptance rule says:

• Every test must pass as written.
• A fault that affects only wording or display may go on a defects list, with a named person and a fix date.
• A fault that affects control or safety must be fixed and the test repeated before the owner accepts the AHU.

Before you read the answers, decide for each test: pass or fail, why, and what should happen next.

Worked answers:

1. Test A: fail. The alarm was on time and the run command was removed, but the valve stayed at 64%.
2. Test B: fail. The sensor read −50.0 °C, outside the 0 to 50 °C range, but the BMS didn't treat it as failed.
3. Test C: fail, same cause as test A. The hard-wired signal stopped the fan, and it stayed off until reset.
4. Test D: fail, defects list. The alarm logic worked, but the text and priority were wrong.
5. Test E: pass, with a finding. The test passed, but the override report found the fan speed still in manual.
6. Test F: fail. The restart worked, but the controller's clock was wrong.
7. Test G: pass. AHU-12A kept controlling on its own while the head-end was gone.

So why does each one land where it does? In test A, chilled water kept flowing through a coil with no air moving across it. That's a control fault. The contractor must add the missing valve interlock (sequence item 3), then repeat test A.

In test B, the BMS believed the air was very cold, so it closed the valve, and the supply air warmed with no alarm. On a real day, level 12 would grow steadily warmer with nobody told why. That's a control fault too. The contractor must add the range check, the alarm and the 50% fallback, then repeat test B.

In test C, the fan side worked. But the valve stayed open once the fan had stopped, which is the same missing interlock as test A. One fix covers both, and both tests are repeated. When two tests fail in the same way, look for one shared cause before looking for two.

In test D, an operator reading "AI-3 HI" at low priority wouldn't know which unit had a problem or how urgent it was. But this affects wording and priority, not control. So under the acceptance rule it may go on the defects list. Correct the text to "AHU-12A supply air too warm" and the priority to medium, with a named person and date. A quick retest confirms it.

In test E, the fan speed had been left in manual from air balancing the day before. A fan fixed at 80% ignores the static pressure reset and wastes energy, as Part 13 showed. So release it to automatic now and record it. Before handover, the override report for the whole building should be empty.

In test F, the wrong date and time would make the schedule run at the wrong hours. Every alarm and trend would carry the wrong timestamp too, and Part 10 explained why timestamps matter. The contractor must configure automatic time synchronisation from the network, then repeat test F.

In test G, AHU-12A did what the distributed design in Part 3 promised. The filter alarm was raised at 11:16, 10 minutes after the test pressure went on. It reached the operators when the link returned, carrying the time it actually happened, not the time it arrived. The gap in the trend is marked, so nobody will mistake it for real readings. Release the test pressure and record the result.

The decision: AHU-12A isn't accepted on this test day. The valve interlock (tests A and C), the sensor range check (test B) and the clock (test F) must be fixed. Then those four tests are repeated. Test D goes on the defects list, and the fan speed override is released and recorded. Tests E and G passed and don't need repeating. When the repeat tests pass and are signed, AHU-12A can be accepted.

Handover

But passing tests is only part of handover. The owner's team will run and repair this system for many years, often without the original contractor. So they need the evidence, and the means to do that. A handover pack should include:

• Signed test sheets: every point check and functional test, with dates, results, retests and witnesses' names.
• As-built points list: every point's name, address, type, range, units and alarm limits, matching what's actually in the controllers.
• Final sequence of operation, updated to match the program as tested.
• Backups: dated copies of every controller's program and settings, the BMS database and the graphics, stored away from the BMS server.
• A tried restore: at least one restore from those backups, as Part 11 covered.
• Network records: a network drawing, device list and addresses.
• Accounts: individual logins for the owner's staff, with the contractor's default and shared passwords changed or removed (Part 11).
• Trends and alarms running: the trends and alarm list from Part 8, recording from handover day, so the first weeks of operation are on record.
• Manuals, as-built drawings and a training record for the operators.
• The defects list: each open item with a named person and a fix date.

And it's worth one more look later. Check the trends again a few months after handover, once the building has seen a full range of weather and occupancy. Problems that only show at light load or on the hottest days often appear then. Add anything new to the defects list, with a named person and a fix date.

Drift

So now AHU-12A has passed its tests, and the owner holds the evidence. On test day, the BMS did exactly what its sequence said. But that was one day. Buildings run for years, sensors drift, valves wear, and someone overrides something on a hot afternoon.

So why can a BMS that passed every test still drift into wasting energy, and what would show that drift? That brings us back to the quiet start on level 12 from Part 1, in Part 16: The Limits of a BMS.

Check your understanding

1. The BMS screen shows AHU-12A's fan as "ON". Why isn't that enough to prove the fan is running?

2. In test B, the failed sensor read −50.0 °C. Why did the valve close, and why is that dangerous?

Recap

• Commissioning proves that the installed BMS does what its sequence says.
• Point checks confirm that each point tells the truth, including that fan status comes from the equipment and not from the command.
• Functional tests, watched and signed by a witness, check the sequence. They cover fan failure, sensor failure, fire interlocks, alarms, override removal, power-loss restart and network failure.
• Control and safety failures are fixed and retested before acceptance, and wording faults can go on a defects list.
• The owner then receives signed test sheets, an as-built points list, the final sequence and tested backups.
• The owner also gets network records, individual accounts, working trends and a list of open items.

This is Part 15 of 16 in Cobler's Building Automation and BMS Fundamentals course. Previous: How a BMS Guards Your Electricity Bill: Load Shedding and Demand Limiting. Next: The Limits of a BMS: Where Control Ends and Analytics Begins.

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.