Air handling units are usually the first equipment class an estate tries to analyse, because there are many of them, they are well instrumented compared with most plant, and they are responsible for a large share of both energy and complaints. They are also where the first analytics project usually discovers that the point list it was given describes an intention rather than a reality: points that were never connected, points whose names no longer match what they measure, and units whose supposedly identical siblings are instrumented quite differently.
The message up front: run a per-unit data audit before any analysis, covering inventory, identity, units and semantics, completeness, flags, range plausibility and change history. Do it as a table with one row per unit so the variation between nominally identical units is visible, because that variation is the usual surprise. This is a data audit and nothing in it diagnoses equipment; anything it flags goes to an engineer as a question, not as a finding.
1. What this checklist is and is not
The distinction matters enough to state plainly at the outset.
This is a check on whether the data stream from a unit can support analysis: whether the points exist, whether you know what they mean, whether they arrive reliably, and whether anything about them has changed. Every item is answerable from the data and the register, with no judgement about the equipment required.
It is not an inspection, a commissioning check or a fault-finding routine. Nothing here tells you whether a unit is operating correctly, whether a reading is physically reasonable for the conditions, or what any pattern implies about the plant. Those questions need somebody qualified on the equipment, and the most useful thing this audit does for them is hand over a list of data questions that would otherwise waste their time.
2. Inventory and identity, per unit
Start with what should be there against what is, one row per unit.
- Points expected, from the register, and points actually reporting. The difference is the coverage figure from completeness KPIs, and on a first pass it is rarely zero.
- Whether each reporting point is mapped to this unit in the maintenance system, and whether that mapping has been verified rather than inferred, per point-to-asset mapping.
- Which points exist on some units and not others. The most informative column in the whole table. Nominally identical units are routinely instrumented differently depending on who installed them and when.
- Whether the point identity is stable, or whether the join rests on a name that could be corrected tomorrow, which is the hazard in point naming and cross-system joins.
- Duplicates. Two points apparently measuring the same thing on the same unit, which is either a second instrument or a mapping error and needs resolving either way.
Lay it out one row per unit, and read down the columns
The temptation is to assess the estate in aggregate and report percentages. Do it per unit instead, with units as rows and checks as columns, and the useful information appears in the vertical comparison: three units out of forty missing a point the rest all have, one unit whose completeness is far below its siblings, two units whose values sit in a different range from everything else. Each of those is a specific, cheap question with a specific answer, and none of them is visible in an estate-wide figure. It also gives you a defensible way to scope any subsequent analysis, since the units that pass every column are the ones a pilot should start with, per data readiness.
3. Units, semantics and scaling
| Check | Question to answer per point | Why it bites |
|---|---|---|
| Unit recorded | Is the engineering unit stated somewhere authoritative? | An unrecorded unit is an unknown, not a default |
| Unit consistent across units | Do sibling units report the same quantity in the same unit? | Mixed units across an estate silently corrupt every comparison |
| Rate or quantity | Does this accumulate, or is it an instantaneous value? | Decides how it can be aggregated, per raw versus aggregated |
| Scaling applied where | Is a multiplier applied at the device, the gateway or the store? | Applied twice or not at all, and nothing reports an error, per units and scaling |
| State encodings | What do the values of a status or mode point mean? | Numeric state codes differ between units and are rarely documented |
| Sign conventions | For any signed quantity, which direction is positive? | Inverted on some units and not others is a common and invisible defect |
4. Arrival and completeness
Having established what the points mean, check that they turn up.
- Declared interval against observed interval, per point. A point reporting far more or less often than expected is usually a collection configuration difference rather than anything about the unit.
- Completeness over a long window, several months rather than a week, so that intermittent degradation shows up.
- Gap clustering. Gaps concentrated in time across all of a unit's points point at the collection path, which is the triage in communication versus equipment anomalies.
- Repeated identical values. A point reporting exactly the same value for an extended period may be stale rather than steady, and the two are worth distinguishing before analysis.
- Timestamp sanity. Readings in the future, readings out of order, or a controller whose clock disagrees with the rest, per timestamps and clock sync.
5. Flags and range plausibility
Two further checks, with an important difference between them in how much they can tell you.
Quality flags are the strong one. If the device reports that a value is unreliable, out of service or overridden, that is the instrument's own assessment and it is worth more than any inference. Check what proportion of each point's readings carry a flag, and check that the flags survived the pipeline at all, because many do not, per quality flags. A point that is substantially flagged is an instrumentation work order rather than an analysis input.
Range plausibility is the weak one, and it needs handling carefully. You can reasonably check whether a value falls outside the physical range the sensor is capable of reporting, or whether it sits at exactly the bottom or top of its scale, both of which are usually sensor or scaling problems rather than conditions. You cannot, from the data side, decide whether a reading is reasonable for the operating conditions, and attempting to do so is where a data audit starts making engineering claims it has no basis for. Where a value looks surprising but is within the sensor's range, the correct output is a question for the engineer, not a finding.
6. Change history and the handover to the engineer
The last column, and the one most often absent entirely: what has changed about this unit's instrumentation and mapping, and when.
- Sensor replacements and recalibrations, with dates, because they create legitimate discontinuities, per sensor replacement and history.
- Mapping or naming changes, which can mean a series describes two different things across its length.
- Controller or head-end changes, which can end or restart a series, per migrating point history.
- Known works periods, so that analysis can exclude them deliberately rather than discovering them as anomalies.
The output of the whole audit should be two lists. A data work list, of points to connect, map, label, fix or retire, which is actionable immediately and by the integration owner. And a short list of questions for the controls or mechanical engineer, phrased as questions: this point sits at the bottom of its scale continuously, is that expected; these two units report this quantity in different units, which is correct; this point exists on most units and not these three, should it. That handover is what keeps the audit useful and keeps it honest about the limits of what data alone can establish.
Limits
This checklist deliberately contains no expected values, operating ranges, setpoints, intervals or thresholds for any air handling unit measurement, and none should be inferred from it. What a reading should be under given conditions, whether a unit is operating correctly, and what any pattern indicates about the equipment are engineering questions requiring validation against the specific plant by somebody qualified, and they sit outside what a data audit can answer. Nothing here is a fault-finding or commissioning procedure, nor a substitute for one. Which points a control strategy requires, and how a unit should be instrumented, are decisions for the controls and mechanical engineers responsible. This is written from the data and integration side, which is where my work sits.
The idea to walk away with
Air handling unit data usually looks more uniform than it is, and the differences between nominally identical units are where analysis quietly goes wrong.
Audit per unit in a table, covering inventory, identity, units and semantics, arrival and completeness, flags and range plausibility, and change history. Read down the columns rather than across. Produce a data work list and a short list of questions for the engineer, and keep the two apart, because the audit establishes what the data is, not what the plant is doing.
Final thoughts
A single table built in an afternoon settles most of this: your units as rows, their points as columns, a mark for each point that reports at all.
The gaps in that grid are the finding. On most estates they are more numerous than expected and they explain a great deal about why a previous analysis produced odd results, and closing them is cheaper and more certain than anything that would have been built on top of the data as it stands.
Disclosure
Alongside advisory work I also build a CMMS and CAFM platform, so I have a commercial interest in this category. Nothing above is a recommendation for it, and no vendor named here has paid for inclusion or had any editorial input. Weigh the analysis accordingly.
About to analyse AHU data?
Independent help auditing the telemetry per unit, surfacing the variation between nominally identical units, and separating the data work list from the engineering questions. 22+ years across CMMS, CAFM, EAM and ERP implementations.
Book a conversationRelated reading: Signal consistency checks, Data readiness, Data completeness KPIs, Units and scaling, BMS point dictionary, What is an AHU.
Muhammad Abbas
CMMS / CAFM Manager & Independent Advisor · 22+ years across enterprise CMMS, EAM, CAFM and ERP implementations in utilities, oil and gas, manufacturing, government and facility operations.
Work with me