BMS Commissioning, Graphics and Operator Dashboards

I have walked into a lot of plant rooms where the BMS was signed off, the certificates were filed, and nothing worked the way the drawings said it did. Valves commanded open and stayed shut. Sensors reported twenty-two degrees because they were reporting a default, not a measurement. Graphics showed a chiller running that had been isolated for six months. None of that was sabotage or incompetence exactly. It was the predictable result of treating commissioning as a paperwork exercise and graphics as something the controls engineer draws in the last week before handover. Both are engineering deliverables in their own right, and both decide whether the building you have just paid for is operable.

The message up front: BMS commissioning is not the act of energising controllers, it is the act of proving every point and every sequence behaves as specified, with a witnessed record. And the graphics are not decoration, they are the operator's only interface to the system. Commission properly and you get a building that can be run. Draw the screens for the engineer who built the system rather than the operator who will live with it, and you have built a system only one person can use.

1. Installed, energised, working: three different states

The most useful distinction to hold in your head on a controls project is that installation, energisation and working are three separate milestones, and contractors routinely conflate them in progress reporting.

• Installed: controllers mounted, field devices fitted, cabling pulled and terminated. Nothing about this state tells you a single point reads correctly.
• Energised and online: controllers powered, network up, supervisory front end seeing them, points appearing on a list. This is where a lot of projects declare victory, because on a screen it looks like a working system. A point appearing in a list only proves a database entry exists.
• Working: every input reflects reality, every output moves the thing it is wired to, every sequence behaves as written under normal and abnormal conditions, and the operator interface tells the truth about all of it. That state is reached only by deliberate testing.

The gap between the second and third state is where BMS commissioning lives, and it is almost always underestimated in programme and in fee. The controls foundation is covered in the complete guide to building management systems, and the points and devices under test in the BMS points lists and field devices pillar. On scope: this article is about controls commissioning. The wider building commissioning process, the Cx authority's role and the full evidence pack at practical completion sit in the building commissioning and handover Cx pack pillar. Read that for the process framework; read this for what happens at the controller and at the screen.

2. The commissioning stages, in order

Controls commissioning is sequential and the order is not negotiable. You cannot tune a control loop whose sensor has not been verified, and you cannot functionally test a sequence whose outputs have not been proven point by point. The commonest cause of a chaotic commissioning period is stages running in parallel because the programme slipped, and skipping forward does not save time, it just moves the discovery of the problem to a more expensive moment.

What I would recommend to any client procuring a controls package is that these six stages appear as named, separately priced deliverables with their own hold points, not as a single line item called "commissioning" with a lump sum against it. The moment commissioning is one undifferentiated activity it becomes the compressible item at the end of the programme, and compression always takes the same victims: point-to-point coverage, abnormal-condition testing, and seasonal revisits.

3. Point-to-point testing, and what proving a point actually means

If I could enforce one thing on every controls project, it would be full point-to-point testing with a witness. Not a sample, not a statistical subset, every point on the list, because the whole value of a BMS rests on the assumption that what the screen says is what the building is doing, and a single mis-wired point quietly destroys that assumption for everyone who uses the system afterwards. The confusion is about what counts as proving a point. Watching a value change on a screen is not proof. A four-part test is:

A point that passes only steps one and four is the dangerous case, and it is commoner than people expect: the command lands in the database, the graphic animates obediently, and nothing in the building moved. Twelve months later an operator is troubleshooting a comfort complaint against a screen that has been lying since day one. For analogue inputs, apply a calibrated reference and confirm scaling at both ends of the range, not just near the middle where a wrong scaling factor still looks reasonable. A sensor scaled zero to one hundred degrees instead of zero to fifty reads correctly at nothing except zero, and looks entirely believable in a mild plant room.

4. Witnessing and sign-off: who signs, and for what

A test that nobody independent watched is a statement of intent. The pattern that works is a three-tier structure: the controls contractor performs and records the test, a commissioning specialist or the consultant witnesses a defined proportion, and the client or incoming FM representative countersigns the record they will later have to live with. A few specifics I would put in the specification rather than leave to custom:

• Named witness and date on every sheet, not a company stamp. Anonymous sign-off is unauditable.
• Defined witness percentages per stage: full witnessing of safety interlocks and fire interfaces, a stated minimum for routine points, plus the random re-prove right described above.
• Hold points. Stage four cannot start until stage two records are accepted. Without them the stages collapse into each other under programme pressure.
• The FM team present for functional testing. They learn the system, and they ask the questions the design team stopped asking months ago.
• A defects register that survives handover, with an owner and a date per item, transferring to the operational team rather than evaporating at practical completion.

That last point matters more than it sounds. Once the project team demobilises, an open item with no owner is just an undocumented feature of the building.

5. The handover documentation set, and the cost of each missing item

Controls handover documentation is the one area where I would advise being genuinely difficult, because every gap converts into either a recurring cost or a vendor dependency you cannot escape. The wider Cx evidence pack sits in the Cx pack pillar; below is the controls-specific subset and what its absence costs.

• As-built points list, machine-readable: address, type, units, scaling, alarm limits, parent plant item. Missing it, the next contractor rediscovers the building point by point and charges you for the privilege.
• Approved sequences of operation, as built. Missing them, nobody can distinguish a fault from intended behaviour, which is the root cause of most long-running unexplained comfort complaints.
• Graphics source files, editable, not just the deployed screens. Missing them, you cannot add a plant item or correct a label without going back to the original integrator.
• Controller programs and configuration backups. Missing them, a failed controller is not a replacement job, it is a re-engineering job.
• Licences in the owner's name, including point-count and integration driver licences. Missing this is how owners discover at year three that their own system is licensed to a company that has left the market.
• Engineering-level credentials and the tooling to use them. With only operator-level access you do not own your building's controls, you rent them.
• Alarm configuration listing: every alarm, its limits, delays, priority and routing. Missing it, the alarm set stays noisy forever because nobody can rationalise it.
• O&M manuals and training records, asset-specific rather than generic vendor PDFs, with training evidenced by name and date.

6. Seasonal commissioning, and the building signed off in spring

Here is a scenario that plays out constantly. A building reaches practical completion in March. Commissioning was thorough: cooling tested, air handling units proven, chilled water balanced and signed off. Then November arrives, someone calls for heat for the first time, and it turns out the heating valves were mapped in reverse, the boiler enable interlock was never proven, and the changeover sequence has never once executed in anger. Every test that was performed, passed. The problem is that half the plant's operating envelope was never entered.

Seasonal commissioning exists precisely for this, and it is the stage most reliably skipped. The reasons are structural rather than technical: by the time the opposite season arrives the project is closed, the budget is spent, the contractor has demobilised, retention has usually been released, and the only party with an interest in the revisit is the operational team, who have no contractual lever. What I would recommend, in order of how much difference it makes:

• Hold retention specifically against the seasonal revisit, as a separately identified sum with a named deliverable, not folded into general retention released on a date.
• Schedule the revisit at handover with actual dates, in the operational calendar and the maintenance plan, not as an obligation in a clause nobody re-reads.
• Simulate what you cannot wait for. Where the plant safely permits it, override outside-air temperature, drive the changeover, prove the heating side in April. Simulation is weaker evidence than real load but far stronger than nothing.
• Use trend logs as the deferred test. If a revisit genuinely will not happen, agree the trend points and a review date, so the first heating season produces reviewable data rather than complaints.

Naming the untested envelope is the useful discipline here. At handover, write down which sequences and which plant have never operated under real load, and hand that list over as a known open risk. It converts an invisible gap into a managed one. For how this feeds into the ongoing regime, see the BMS maintenance and lifecycle pillar and the preventive maintenance for HVAC systems pillar.

7. Graphics: the hierarchy from portfolio to component

Now to the half of the delivery that decides whether the commissioned system is usable at all. BMS graphics are the operator's entire experience of the building, and they should be designed as a navigable hierarchy with a defined purpose at each level. The failure mode is a flat pile of schematics reachable only through a tree menu that mirrors the controller topology rather than the way a human thinks about a building.

Two design rules keep this hierarchy honest. First, every level must be reachable in one click from the level above and below, with a persistent breadcrumb, because an operator responding to an alarm navigates by drilling, not by remembering a menu path. Second, a state shown at any level must be derived from the level beneath it. If a site tile shows green while a chiller three levels down is in alarm, the operator stops trusting the top-level view entirely, which removes the whole point of having one.

8. Information design: state at a glance

The measure of a good BMS screen is how quickly someone with no context can tell whether things are normal. That is a testable property, and most graphics fail it because they are built to display data rather than communicate state.

• Normal should look boring and uniform. When everything is fine the screen should be visually quiet: muted, low contrast, nothing competing for attention. Abnormal conditions then stand out by contrast alone, without the operator reading a single number.
• Show deviation, not just value. A supply air temperature of fourteen degrees means nothing on its own. Fourteen against a setpoint of thirteen, with the deviation indicated, is information.
• Plain-language labels and units on every value. "AHU-03 Supply Air Temp 14.2 degC" not "AH3_SAT 14.2". Controller tag names belong in the engineering view.
• Distinguish command from feedback visually. The most valuable thing a graphic can show is where these two disagree. A commanded-open valve with closed feedback should be unmistakably wrong on the screen, because that mismatch is the most common real fault in a building.
• Make stale data visibly stale. A point that has not updated, or whose controller is offline, must not display its last known value as though it were current. A confidently displayed old number is worse than a blank.
• Show overrides prominently. Forgotten overrides are a great silent cause of energy waste and comfort complaints. Every override should be visible at plant level and counted at site level, with who set it and when.
• Keep the schematic geometrically honest. Sensors in their actual position in the airflow, dampers in the duct they serve, flow direction consistent across every screen.

9. Colour discipline, and why red for everything trains blindness

Colour is the most abused resource in BMS graphics. The typical screen uses red for alarms, red for stopped plant, red for hot water, red for closed valves and red for emphasis, at which point red has stopped meaning anything at all. The operator's eye adapts within days and the colour carries no information. The discipline I would apply is simple and strict:

• Reserve one colour exclusively for abnormal conditions requiring attention, and never use it for anything else. Not for hot water pipes, not for headings, not for a pump that is stopped because it is correctly off-duty.
• Use grey scale for normal operation. Running plant, normal values, correct states: all in muted neutrals. This feels underwhelming on a demonstration screen and works far better at three in the morning.
• Do not colour-code status and medium with the same palette. If red means hot water and also means alarm, the reader must decode which meaning applies every time. Use line style or labelled legends for medium, and keep colour for state.
• Never rely on colour alone. Some operators have colour vision deficiency, and screens get viewed on badly calibrated monitors in bright plant rooms. Pair every colour signal with a shape, icon, border or text.
• Hold the palette across every screen and every site. Per-screen invention is how a portfolio becomes unreadable as it grows.

10. Dashboards versus schematics: two different jobs

A recurring confusion is treating dashboard and schematic as interchangeable words for "a BMS screen". They serve opposite purposes, and mixing them produces something that does neither job.

A schematic is a diagnostic tool. Its job is to let someone understand the physical arrangement of a plant item and locate a fault within it. It is geometrically faithful, dense, and it rewards study. It is where an engineer goes once they already know something is wrong. A dashboard is a monitoring tool. Its job is to tell someone, without study, whether they need to do anything and what deserves attention first. It is sparse, comparative and ranked. It is where an operator starts their shift and where they land when an alarm wakes them.

What belongs on an operator dashboard, in priority order: active alarms ranked by consequence rather than timestamp; systems failing to meet setpoint, with how long they have been failing; comms and controller health; active overrides; plant in a non-standard mode; and a short list of trends that matter today. What does not belong: every point in the building, gauges that look impressive and inform nothing, and metrics nobody has a defined response to.

The filter I would apply to every dashboard element is one question: what would the operator do differently because of this? If there is no answer it is decoration, and decoration on a monitoring screen is not neutral, because it costs attention the important elements needed. Where the dashboard carries operational metrics, the definitions should tie back to a single agreed set rather than being invented per screen, which is the argument of the FM KPI framework pillar. Where it carries energy and fault-detection content, the analytics layer is covered in the BMS energy optimisation, FDD and analytics pillar.

11. Alarm presentation, and designing for three in the morning

Alarm design is where commissioning and graphics meet, because an alarm is a commissioned configuration item presented as an interface element. Almost every system I have looked at has too many alarms, flat priorities, and no defined response, which produces the worst outcome in operations: a team that has learned to ignore the alarm list. The principles that hold up:

• Every alarm needs a defined response. If nobody can say what a person should do when it activates, it is not an alarm, it is an event. Send it to the log, not to the operator.
• Priorities must be few and meaningful. Three levels, tightly defined by consequence and required response time. When everything is high priority, priority has been abolished.
• Suppress the cascade. One chiller trip should not produce forty alarms from the pumps, valves and loops downstream of it. Root-cause suppression takes real configuration effort and is the difference between a usable and an unusable alarm list.
• Deadbands and delays on everything analogue. A value oscillating around a limit will otherwise generate hundreds of alarms a day and bury everything real.
• Show the alarm in context. Plant item in plain language, the value that breached, the limit, how long it has been active, and a direct link to the plant screen.
• Review the alarm set after the first operational quarter. The set configured at commissioning is a first draft written by people who have never operated the building.

And the framing that decides all of it: design for the operator who opens this at three in the morning, not the engineer who built it. That person is tired, possibly on a phone, does not know the controller topology, and needs one answer fast: what is wrong and what do I do? The engineer can navigate anything because they hold the model in their head. They are the worst possible test user, and usually the only one consulted. Involving the incoming operations team in graphics review before the screens are built is the cheapest quality improvement available on a controls project.

12. The honest section: what usually happens instead

Everything above describes good practice. I should be straight about how rarely it actually occurs, because pretending otherwise makes the advice useless.

The practical response is not a stricter specification, though a clear one helps. It is to move the leverage earlier and put the operational team in the room. Concretely: name commissioning stages as separate deliverables with hold points; make graphics a reviewed design deliverable with an operator sign-off gate rather than a build activity; hold retention against named documentation items and against the seasonal revisit; and write the untested conditions into the handover as a known risk with an owner. Each is a procurement and governance decision made long before anyone opens a controls tool, which is precisely why they work. The specification language that supports this sits in the BMS specification clauses pillar, and the platform capabilities that make good graphics possible in the first place in the BMS software and platforms evaluation pillar.

On the wider standards framework, ASHRAE publishes the commissioning guideline and standard most consultants work from, and BSRIA the soft landings and commissioning guidance widely used in the UK and the Gulf. Both are worth reading properly rather than citing in a clause, because the value is in the sequencing logic rather than the compliance tick.

13. A commissioning and graphics acceptance checklist

What I would work through before signing acceptance on a controls package.

The idea to walk away with

A BMS delivers value in exactly two places: at the point, where the system must tell the truth about the building, and at the screen, where a human must be able to read that truth and act on it. Commissioning earns the first. Graphics design earns the second. Everything in between is plumbing that only matters because it connects the two. Which means the two most consequential decisions on a controls project are not technical: whether commissioning stages get named, programmed and priced as separate deliverables with hold points, and whether the people who will operate the building get to review the screens before they are built. Both are governance decisions, both are made early, and both are routinely skipped while the building lives with the result for twenty years.

Final thoughts

The difference between a BMS that runs a building well and one that becomes an expensive, distrusted screen in the corner of the plant room is almost never the product. It is whether someone insisted on proving every point, whether abnormal conditions were tested as well as normal ones, whether the documentation was actually opened before retention was released, and whether the graphics were designed for the tired operator rather than the engineer who already knew the answer.

If you are approaching handover on a controls package, the highest-value thing you can do costs nothing and takes an afternoon: pick ten points at random and prove them end to end yourself, then show three screens to an operator for three seconds each and ask what is wrong. Those two tests will tell you more about the state of your commissioning than the entire certificate folder.

Related reading: Building commissioning and the handover Cx pack, Building management systems: a complete guide, BMS controls, points lists and field devices, BMS in HVAC: controls, points and sequences, BMS specification clauses, BMS software and platforms: how to evaluate, BMS energy optimisation, FDD and analytics, BMS maintenance, servicing and lifecycle.