Trends, Alarms and Dashboards: The Operator's Window Into the Building

The building has a face, and this is it

Imagine you manage a twelve-storey office tower. You cannot walk every riser, feel every duct, or stand next to every pump at 3am. So how do you actually see the building? You see it the way an air-traffic controller sees the sky: through screens. The Building Management System (BMS) — the network of controllers we have been describing throughout this course — is not only the brain that runs the plant. It is also the window the operator looks through to know whether the building is healthy.

That window has three panes. The BMS logs trends, raises alarms, and centralises control on a workstation or app. Those are its three operator-facing functions, and they map neatly onto three human questions: What happened? What is wrong right now? What is going on this second? Get these three right and a facility manager runs a calm, efficient building. Get them wrong — especially the alarms — and the same tools quietly train the operator to ignore the building altogether.

Let's walk through each pane, then look at the two failure modes that undo them: alarm floods, and the silent killer of savings, the forgotten manual override.

Trends: the building's memory

A trend log (or historian) is simply the BMS recording the value of a point at regular intervals — say every minute or every fifteen minutes — and keeping that history so someone can look back later. A "point," recall from earlier parts, is any single measured or commanded value: a chilled-water supply temperature, a fan's on/off status, a valve position, a floor's power draw.

Think of a trend as the building's memory. Without it, every question about the past is a shrug. Why was level 8 warm yesterday afternoon? With trends, the operator pulls up the zone temperature and the cooling valve position side by side and reads the story like a heart-rate chart: the temperature climbed, the valve was already wide open, so the problem was not the control loop — the plant simply could not deliver enough cooling. That is a diagnosis you can act on, and it came entirely from history.

Trends are how you catch slow problems that no single snapshot reveals. A chiller that takes a little longer to hit setpoint each week. A pump drawing slightly more current month over month. A zone that reaches its unoccupied setback — where the cooling setpoint is deliberately allowed to drift up when the floor empties out to save energy — but never quite recovers on time during optimum start, the pre-cooling that should have the space comfortable before people arrive. None of these announce themselves. You only see them by laying weeks of history on one graph.

Good trending is deliberate. You cannot log everything forever — storage and network traffic are finite — so a well-commissioned BMS trends the points that matter (temperatures, key statuses, energy) at sensible intervals, and lets the rest be sampled on demand. Which points, how often, how long to keep them: these are commissioning decisions, and skipping them is why so many buildings discover, the day they need history, that nobody was recording it.

Alarms: the building's doorbell

If trends are memory, alarms are the doorbell. An alarm is a rule that fires the instant a value goes out of range or a device reports a fault — and pushes a warning to the operator immediately.

The rules are usually simple to state:

- Out-of-range: a zone that should sit near 24 °C reads 29 °C.
- Failure to achieve: a chilled-water loop that never reaches setpoint for an hour.
- Command-versus-status mismatch: the BMS commanded a pump to start, but the run-status feedback says it never did — a classic sign the motor tripped, the belt broke, or the starter failed.
- Equipment fault: a variable-speed drive reporting its own fault code, or a filter differential-pressure switch saying the filter is choked.

A good alarm turns an invisible problem into a phone call. A pump that fails to start at midnight is, without alarms, discovered at 8am when the lobby is warm and tenants are cross. With a well-set alarm, it is a message on the duty engineer's phone at 12:01am, dealt with before anyone notices. That is the whole promise of alarming: time. It buys you the gap between something going wrong and someone feeling it.

Alarms also carry priority. A safety or comfort-critical fault (a chiller down, a smoke-related trip) should shout; a filter approaching its change-out date should merely note itself for the next maintenance round. Priority is what lets an operator triage — and, as we are about to see, it is exactly what badly configured systems throw away.

Dashboards and graphics: the live view

The third pane is the one people picture when they imagine a BMS: the dashboard, or graphics. This is the live, colour-coded picture of the building — floor plans with each zone tinted by temperature, and plant schematics that draw the chillers, pumps, cooling towers and valves as a flowing diagram, with live numbers sitting right on the equipment.

A good schematic is readable at a glance. Running equipment shows green; stopped shows grey; a fault glows red or amber. The chilled-water supply and return temperatures print next to the pipes. A valve drawn as 70% open looks 70% open. The operator's eye sweeps the screen the way a pilot scans an instrument panel — not reading every number, but hunting for the one thing that is the wrong colour.

Dashboards are where the three panes meet. From a live graphic the operator clicks a point to open its trend and see how it got here, and the same graphic shows any alarm attached to that equipment. Live status, history, and warning in one place: that is the operator's window, whole.

When the doorbell never stops: alarm floods

Here is where good tools turn toxic. Alarm flooding is what happens when a BMS raises so many alarms — most of them low-value or nuisance — that operators simply stop reading them. It is a recognised cause of operators missing the critical alarm, and it is one of the most common real-world failures in building automation.

Picture a poorly configured system. Every time a fan cycles off overnight, it throws a "low airflow" alarm — correctly, but pointlessly, because it is supposed to be off. A temperature that hovers right at its alarm limit "chatters," firing and clearing every few minutes all night. A sensor with a too-tight range cries wolf on every normal swing. By morning the alarm list has four hundred entries. Somewhere in that wall of grey noise is one real alarm: a chilled-water pump that genuinely failed. Nobody sees it. It looks exactly like the other three hundred and ninety-nine.

This is not the operator being lazy. It is the predictable result of a system that never taught them which alarms deserve attention. Once people learn that the alarm list is noise, they stop looking — and then the alarm system, which exists entirely to catch the one event that matters, catches nothing.

What good looks like is the opposite discipline:

- Prune nuisance alarms. An alarm that fires when nothing is wrong is not a safety feature; it is damage. Suppress alarms on equipment that is intentionally off. Add small delays and deadbands (that tolerance band we defined earlier in the course) so values sitting near a limit don't chatter.
- Prioritise ruthlessly. A handful of critical alarms should stand out from the routine ones. If everything is urgent, nothing is.
- Make trends meaningful. Log the points that answer real questions, at intervals that show the story, kept long enough to compare across weeks.
- Actually review them. The best-tuned alarm and trend setup is worthless if no human ever reads it. Someone owning a weekly look at trends and alarm counts is what turns the data into decisions.

Configuring meaningful alarms and clear graphics is genuine commissioning work, not an afterthought you rush on handover day. It is a core part of getting a BMS — or a modernised, mixed-vendor one — actually usable by the people who live with it, which is exactly the kind of work Cobler's automation services exist to do.

The silent killer: manual overrides and points in hand

Now the failure mode that costs the most money and makes the least noise. Every BMS lets an operator take a point out of automatic control and force it by hand. The physical version is the hand-off-auto (HOA) switch at the equipment: Hand runs it flat out, Off stops it, Auto hands control back to the BMS. The software version is a point put into override — pinned to a value the operator chooses, ignoring the control sequence entirely.

These exist for good reasons. During a fault, a commissioning test, or an emergency, an operator needs to force a valve open or keep a fan running regardless of what the logic wants. The problem is not the override. The problem is the override that never gets undone.

Here is the pattern, and it is astonishingly common. A zone is too warm one afternoon. The operator forces its cooling valve wide open to satisfy the complaint — sensible, in the moment. The complaint stops. The override stays. Now that valve is always wide open. The clever sequence you paid for — the one that modulates the valve, lets the setpoint drift up when the floor is empty, trims the plant to match real load — is switched off for that zone, forever, and nothing on the dashboard screams about it. The building still runs. It just quietly burns cooling around the clock. Multiply that by every "temporary" fix left in place over a few years and you have a plant running near full tilt while the BMS reports business as usual.

This is the number-one reason BMS savings quietly evaporate. Not a failed sensor, not a bad control loop — just a drawer full of forgotten manual overrides and disabled sequences, each one individually reasonable, collectively expensive. The automation is still installed. It simply isn't being allowed to run.

The defence is visibility. A well-built graphic flags every overridden point — a distinct colour, an icon, a hand symbol on the schematic — so an operator scanning the plant can immediately see, these six points are in manual, someone forced them, are they still meant to be? A regular "points in hand" review — literally walking the graphics and the HOA switches looking for anything not in Auto — is one of the highest-return habits a facility team can build. It costs an hour. It can recover the entire savings case the automation was bought for.

The limitation that sets up the finale

Trends, alarms and dashboards make a BMS a superb real-time instrument. Right now, this second, is the building healthy? No system answers that better. But push on those same three panes and their edges show.

Trend storage is usually short-lived and local — weeks or months on a workstation, not years in a durable archive. Comparing this July's chilled-water efficiency against three past Julys, spotting a slow multi-year drift, benchmarking one building against a portfolio, running proper root-cause analysis across seasons — a BMS is not built for that. It is a live cockpit, not a long-memory analyst. It tells you the plant tripped; it is far weaker at telling you why the plant has been getting 8% less efficient every year, because it wasn't designed to hold and interrogate that much history.

That gap — real-time strength, long-term weakness — is exactly the seam between controlling a building and understanding one over time. It is the distinction the final part of this course is built around.

The takeaway

A BMS is the operator's window into the building: trends are its memory, alarms are its doorbell, and dashboards are its live view — three panes that together answer what happened, what is wrong now, and what is going on this second. But the window only works if the alarms are pruned and prioritised so real ones aren't lost in a flood, if the trends are meaningful and actually reviewed, and — above all — if someone hunts down the forgotten manual overrides that quietly switch the automation off while the screen still looks green. And precisely because a BMS lives in the present, it is weak at long-term storage, benchmarking and root-cause analysis.

Next, in the final part, we draw the line this whole course has been circling: the difference between a system that controls a building and an independent layer that measures, benchmarks and understands it over time — and why you want both.