How to prove a BMS does what its sequence says: point checks, witnessed functional tests, an acceptance decision and the handover pack, worked through on one air handling unit with answers.
Tan Kok XinBuilding Automation & BMS Fundamentals
Part 15 of 16 in Cobler's Building Automation and BMS Fundamentals course. New here?See the course page.
Parts 12 to 14 described what a well-set-up building management system (BMS) should do: run the plant, run the air side and hold down demand. That left a question: how does anyone know the BMS actually does all this before the building's owner accepts it from the contractor? A BMS is much harder to try out than a new phone. It controls equipment on every floor, and much of what it must do, such as reacting to a failed fan or a power cut, only happens when something goes wrong.
You prove it by testing the BMS against its written sequence of operation: first point by point, then function by function, with a witness watching and signing each result. This process is called commissioning. The signed results, together with backups of the system and a set of handover documents, are what the owner accepts at handover. This part is a paper exercise on AHU-12A, the air handling unit we have followed through the course, with worked answers.
Commissioning checks the installed system against the design
A BMS project starts with a design: a points list, a network, and a sequence of operation, the plain-English description of what the controls must do (Part 6). Contractors then 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, usually the consultant's engineer or a commissioning specialist appointed by the owner, watches each test and signs the result.
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.
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 cannot be tested on an AHU with no power or no chilled water.
The BMS is usually the last system to be finished on a building site, because it depends on everyone else's equipment. When earlier work runs late, commissioning time gets squeezed, and there is pressure to skip tests to meet the handover date. A BMS that was never properly tested will usually still switch on for a handover demonstration, then run poorly for years: equipment starting and stopping too often, false alarms and wasted energy that nobody traces back to the missing tests. Good project engineers protect the testing time, and if it is squeezed, they record the risk in writing rather than quietly skipping tests. Our article on the reality of BMS project delivery describes these pressures.
Commissioning happens in two stages:
Point checks (often called point-to-point checks): every sensor reads correctly and every output moves the right device.
Functional tests: the sequence behaves as written, including what happens when something fails.
AHU-12A's sequence, and the points it needs
Here is the short version of AHU-12A's sequence that we test in this part. It gathers what earlier parts described: the control loops from Part 4, the schedule from Part 7, the alarms and overrides from Part 8, what happens when the network fails from Part 11, and the static pressure reset from Part 13.
Occupied mode: on the schedule (8am to 6pm, Monday to Friday, with optimum start allowed to begin earlier), the BMS sends the supply fan a run command.
Fan proving: the fan status must show "running" within one minute of the command. If it does not, or if it drops out while the fan is commanded to run, the BMS raises a high-priority "AHU-12A supply fan failure" alarm, removes the run command and closes the chilled water valve.
Temperature control: while the fan is proven running, the chilled water valve holds the supply air temperature at its setpoint (14 °C, with reset as in Part 13). Whenever the fan is not proven, the valve stays closed.
Pressure control: the fan speed holds the duct static pressure setpoint, which the reset adjusts from the VAV damper positions.
Sensor failure: if the supply air temperature reading goes outside 0 to 50 °C, or stops updating, the BMS raises a high-priority alarm and holds the valve at a fixed 50%.
Fire alarm: a hard-wired signal from the fire alarm panel stops the fan directly, whatever the BMS commands. The BMS reads the fire alarm signal, shows it and does not try to restart the fan. Once the fire alarm is reset, the fan returns to its normal sequence.
Alarms: if the supply air is more than 2 °C above its setpoint for 15 minutes in occupied mode, the BMS raises a medium-priority alarm with the text "AHU-12A supply air too warm". If the filter differential pressure stays above 250 Pa for 10 minutes, it raises a low-priority "AHU-12A filter dirty" alarm.
Overrides: any point in manual or override is flagged on the AHU-12A graphic and listed in a daily override report.
Power-loss restart: after a power cut, the controller restarts with its setpoints and schedules unchanged and its clock correct. In occupied mode, the fan restarts after a 3-minute delay, so that the building's AHUs do not all restart at the same moment (Part 14 explained why staggered starts matter).
Network or head-end failure: AHU-12A's field controller keeps running on its own, with its stored schedule and setpoints (Part 11 explained what keeps working). Alarms raised while the link is down are held in the controller and reported, with their original time, when the link returns. The head-end then 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), and Part 13 added a ninth, duct static pressure (an analogue input). The tests below use all nine.
{{media:489}}
AHU-12A's nine points, and which of the seven functional tests uses each one.
Point checks: does each point tell the truth?
A point check compares what the BMS screen says with what is really happening at the equipment. One person stands at the AHU with a measuring instrument; another watches the BMS screen. The table below is AHU-12A's point check sheet, with the check for each point and the rule for a pass.
Point
Type
Check
Pass if
Supply air temperature
Analogue input
Compare with a calibrated handheld thermometer beside the sensor
Within the tolerance the specification sets, for example ±0.5 °C
Return air temperature
Analogue input
Same as above, in the return duct
Within the same tolerance
Duct static pressure
Analogue input
Compare with a handheld pressure gauge at the same tapping
Within the specified tolerance
Filter differential pressure
Analogue input
Compare with the local gauge on the filter section
Readings agree
Chilled water valve
Analogue output
Command 0%, 50% and 100% from the BMS; watch the valve actuator
Valve moves to each position, in the right direction
Supply fan speed
Analogue output
Command 40% and 100%; read the drive's display
Drive follows each command
Fan run command and fan status
Digital output and input
Command the fan on, then off; confirm the status is wired from the differential pressure switch or current switch
Fan starts and status shows "running" within one minute; both return to off
Fire alarm signal
Digital input
The fire alarm contractor simulates a fire signal
BMS shows the fire alarm and the fan stops
One check needs special attention: command versus status. When the BMS commands the fan on, the screen shows the command. 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. 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 that the drive or starter has switched on, so it would not notice a broken belt. A status point that is wired to copy the command is worse: it will always agree with the command and hide a tripped motor as well.
Witnessed functional tests: does the sequence do what it says?
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. Tests that switch off equipment or interrupt power are done by the right contractor, 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 while the BMS still commands it to run. Expected: the status drops; within one minute the BMS raises the high-priority fan failure alarm, 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; 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; 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's alarm list 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 and schedules unchanged and its clock correct; 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, hold a test pressure of 300 Pa on the filter pressure sensor for more than 10 minutes, using a hand pump, so the controller has an alarm to report. Expected: AHU-12A keeps holding its supply air temperature and follows its stored schedule; when the head-end returns, it reconnects to the controller, the filter alarm appears with the time it was actually raised, and the trend shows the outage as a marked gap.
{{media:490}}
Test A step by step: the command stays on while the fan stops, and the BMS must notice within one minute and make the AHU safe.
The exercise: AHU-12A's test day results
Here are the witnessed results from AHU-12A's test day in the office tower. The specification's acceptance rule is:
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 reading the answers, decide for each test: pass or fail, why, and what should happen next.
Test
What the witness recorded
A. Fan failure
Status dropped at 10:02:05. Fan failure alarm at 10:03:05, high priority. Run command removed. Chilled water valve stayed at 64%.
B. Sensor failure
Screen showed −50.0 °C. Valve closed to 0%. No alarm. Supply air warmed steadily.
C. Fire interlock
Fan stopped 2 seconds after the fire signal. Fire alarm shown on the graphic. Chilled water valve stayed at 58%. Fan stayed off until the fire alarm was reset, then restarted under its normal sequence.
D. Alarms
Alarm arrived after 15 minutes, as expected, but at low priority, with the text "AI-3 HI".
E. Override removal
Valve flagged in manual; released; loop in control within 1 minute. End-of-day override report still listed the supply fan speed in manual at 80%, left from air balancing the day before.
F. Power-loss restart
Controller back in 4 minutes. Setpoints unchanged. Fan restarted after 3 minutes. Controller clock showed 1 January 2000.
G. Network failure
Head-end disconnected 11:02 to 11:22. Supply air held at 14 °C throughout; schedule unaffected. Test pressure applied 11:06. On reconnection at 11:22, "AHU-12A filter dirty" alarm appeared, timed 11:16. Head-end reconnected to all controllers within 2 minutes. Trend showed "no data" from 11:02 to 11:22.
Worked answers:
Test A: fail. The alarm arrived on time and the run command was removed, but the valve stayed at 64% instead of closing. Chilled water kept flowing through a coil with no air moving across it. This is a control fault. The contractor must add the missing valve interlock (sequence item 3), then repeat test A.
Test B: fail. The disconnected sensor read −50.0 °C, which is outside the 0 to 50 °C valid range, but the BMS did not treat it as failed. It 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 have grown steadily warmer with nobody told why. This is a control fault. The contractor must add the range check, the alarm and the 50% fallback, then repeat test B.
Test C: fail, same cause as test A. The fan side worked: the hard-wired signal stopped the fan and it stayed off until the fire alarm was reset. But the valve stayed open once the fan had stopped, which is the same missing interlock found in 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.
Test D: fail, defects list. The alarm logic worked, but an operator reading "AI-3 HI" at low priority would not know which unit had a problem or how urgent it was. 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.
Test E: pass, with a finding. The test itself passed. But the override report found a different point, the fan speed, still in manual from the day before. A fan fixed at 80% ignores the static pressure reset and wastes energy, as Part 13 showed. Release it to automatic now and record it. Before handover, the override report for the whole building should be empty.
Test F: fail. The restart worked, but the controller's clock was wrong. With the wrong date and time, the schedule would run at the wrong hours, and every alarm and trend would carry the wrong timestamp (Part 10 explained why timestamps matter). The contractor must set up automatic time synchronisation from the network, then repeat test F.
Test G: pass. AHU-12A kept controlling on its own while the head-end was gone, which is what the distributed design in Part 3 promised. The filter alarm was raised at 11:16, 10 minutes after the test pressure went on, and it reached the operators when the link returned, carrying the time it actually happened rather than 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 is not 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, and those four tests repeated. Test D goes on the defects list. The fan speed override is released and recorded. Tests E and G passed and do not need repeating. When the repeat tests pass and are signed, AHU-12A can be accepted.
Handover: what the owner should receive
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. 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 is actually in the controllers.
Final sequence of operation, updated to match the program as tested.
Backups: copies of every controller's program and settings, the BMS database and the graphics, dated, stored away from the BMS server, with a restore that has been tried at least once (Part 11 covered backups and recovery).
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 set up and 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.
Worth knowing: Look again at the trends 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.
What comes next
Commissioning proves that the BMS does what its design says on the day it is tested. The last part, The Limits of a BMS: Where Control Ends and Analytics Begins, looks at the following months and years and recaps the whole course. It starts from this question: why can a BMS that passed every test still drift into wasting energy, and what would show that drift?
Check your understanding
The BMS screen shows AHU-12A's fan as "ON". Why is that not enough to prove the fan is running? The screen may be showing the run command, which only proves that the BMS sent the instruction. Proof must come from a status point wired to a device that sees the fan working, such as a differential pressure switch across the fan or a current switch on the motor cable, not a contact in the drive or starter. Test A checks this by stopping the fan while the command stays on.
In test B, the failed sensor read −50.0 °C. Why did the valve close, and why is that dangerous? The BMS treated the reading as real, so it "saw" very cold supply air and closed the valve to warm it up. The supply air then warmed with no alarm, so level 12 would get warmer while the screen gave no sign of a fault. A range check that treats an impossible reading as a failed sensor, raises an alarm and moves the valve to a safe fixed position prevents this.
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, including 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; wording faults can go on a defects list. The owner then receives signed test sheets, an as-built points list, the final sequence, tested backups, network records, individual accounts, working trends and a list of open items.
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
