BMS Controls: Points Lists and Field Devices

Ask a facilities team for their building management system points list and watch what happens. In a well-run building you get a spreadsheet, current, versioned, with device tags that match the labels on the panels. In most buildings you get a tender-stage PDF from eight years ago and an offer to export something from the front end that will not match either. That gap is not a documentation problem. It is the reason nobody trusts the BMS, the reason every retrofit is priced as an unknown, and the reason the energy analytics project quietly died. The points list is the building's inventory of senses and reflexes, and when it is wrong, everything built on top of it is wrong too.

The message up front: a BMS points list is a commercial document, an engineering document and a data schema all at once. Treat it as any one of the three and the other two suffer. Get the point types, the naming convention and the status-versus-command distinction right at design stage, verify every point physically at handover, and you own a building that can be analysed. Skip that and you own a building that can only be guessed at.

1. What a point actually is, and why the list is the deliverable

A point is one discrete piece of information the control system either reads from the building or writes to it. A space temperature the controller reads. A valve position the controller commands. A fan run status the controller monitors. Each one occupies a physical terminal on a controller, consumes part of that controller's input or output capacity, requires a cable, a field device and a commissioning check, and appears in the software as an addressable object with a name, a unit, a range and an alarm behaviour.

Because every point carries that whole chain of cost and consequence, the points list becomes the project's centre of gravity. It is what the contractor prices against, what the commissioning engineer proves, what the graphics are drawn from, what the alarms are configured from, and what any future analytics platform reads. Nothing else in a BMS project is referenced by so many parties for so many different purposes.

This article is about the points and the devices behind them. It deliberately does not cover control sequences, loop tuning or how the points are combined into logic, because that belongs in the companion piece on BMS in HVAC: controls, points and sequences. Nor does it restate system architecture, controller tiers or protocol selection, which are covered in building automation systems explained. If you want the wider picture first, start with the complete guide to building management systems and come back here for the detail.

2. The four point types: AI, AO, DI, DO

Every hardwired point in a building management system is one of four things. The classification is not academic bookkeeping, it drives the controller hardware you need, the cabling, the field device and the commissioning method.

• AI, analogue input. A varying measured value read into the controller. Space temperature, chilled water supply temperature, duct static pressure, relative humidity, carbon dioxide concentration, flow rate, tank level. Physically this is usually a resistance signal from a thermistor or platinum resistance sensor, or a 0 to 10 volt or 4 to 20 milliamp signal from a transmitter. An AI is the only way the system knows anything about the physical world, so device accuracy and placement determine the quality of everything downstream.
• AO, analogue output. A varying command written out of the controller to a device that can modulate. Valve position, damper position, variable speed drive frequency reference, electric heater stage proportion. Again typically 0 to 10 volts or 4 to 20 milliamps. An AO is an instruction, not an observation, a distinction I will keep returning to because confusing the two is the most damaging error in points list design.
• DI, digital input. A two-state condition read into the controller. Fan running via a current sensor, filter dirty via a differential pressure switch, pump fault via a volt-free contact from the starter, valve proved closed via a limit switch, door open, level high. DIs are cheap, fast and hugely underused. A building with plenty of well-chosen DIs is a building where faults announce themselves.
• DO, digital output. A two-state command written out of the controller. Fan start or stop, pump enable, lighting circuit on or off, heater stage on, solenoid valve open. Usually a relay contact driving a starter coil, a drive enable terminal or a contactor.

A useful mental shortcut for reading any points list: inputs are what the building tells you, outputs are what you tell the building. Analogue means "how much", digital means "whether". Four combinations, and every hardwired point in a building fits one of them.

3. Virtual, calculated, network and integrated points

Not every point on a modern points list corresponds to a terminal and a cable. Four more categories exist in software, and they matter commercially because contractors and clients frequently disagree about whether they count.

• Virtual or software points. Values that live only in the controller: setpoints, occupancy schedules, mode flags, enable and disable switches, manual overrides, time delays, limit parameters. No hardware, but real configuration, real graphics presence and real commissioning effort. An air handling unit with twelve physical points can easily carry another fifteen virtual points once its setpoints, modes and overrides are counted.
• Calculated or derived points. Values computed from other points: total cooling load from flow and delta T, mixed air temperature calculated from damper position, runtime hour accumulators, efficiency ratios, differential pressure derived from two absolute pressure readings. These are the points analytics work depends on, and they are also where units and sign conventions go wrong silently.
• Network points. Values that arrive over a fieldbus from an intelligent device rather than a hardwired terminal. A variable speed drive on a communications trunk can present speed, current, power, torque, fault code, energy accumulator and dozens more registers over one cable. This is usually excellent value, but the points list must state exactly which registers are being mapped, exposed and trended, because "the drive is on the network" is not a scope statement.
• Integrated points. Values imported from another system entirely: energy meters over Modbus, chiller controllers over BACnet, lift monitoring, generator controllers, water treatment skids. High value, high risk. The risk is that the third-party device presents its data in registers the BMS contractor has never seen, with documentation that arrives late or not at all.

4. How to read and write a points schedule

A points schedule is the tabular form of the points list, one row per point, one column per attribute. It is the document the contractor prices, the commissioning engineer signs and the analytics engineer reads, and most disputes on BMS projects can be traced to a schedule that was missing columns. The columns I would insist on, at minimum:

Two habits separate schedules that stay useful from schedules that rot. First, keep it in a spreadsheet or database, never only in a PDF, so it can be filtered, counted and diffed. Second, make the commissioning status columns part of the same file rather than a separate snag list, so the document that priced the job is the document that proves the job. The relevant clauses to put this in writing belong in your BMS specification clauses.

5. Naming conventions, and why inconsistency is fatal

A point naming convention looks like bureaucratic tidiness and is actually the most consequential decision on the whole points list. A human operator can cope with mess. They learn that the third floor AHU is called AHU3 on one screen and AHU-03 on another, that room temperatures are sometimes RM_TEMP and sometimes SPACE_T, that some return air sensors are RAT and some are RA_TEMP. Software does not adapt. Every analytics rule, fault detection query, energy report and integration mapping has to be written point by point instead of once per point type, and that cost lands on every future project on the building.

A workable convention is a fixed sequence of segments with a controlled vocabulary for each:

The rules that make a convention survive contact with a real project are unexciting and non-negotiable. Fixed segment order. A published abbreviation list, so nobody invents RAT and RETAT on the same job. Zero-padded equipment numbers, so AHU-03 sorts before AHU-12. No spaces, no special characters beyond the separator. Measurement and function separated, so SAT-SENSOR and SAT-SP are obviously the same quantity in two different roles. And one authority who owns the vocabulary, because a convention with three authors is three conventions.

The industry has been trying to standardise this layer for years. Project Haystack tags points with semantic metadata rather than relying on the name string, and Brick Schema models the building as a graph of typed entities and relationships. Both are worth reading before you invent your own scheme. My practical advice: pick a structured naming scheme you can enforce on day one, and require tagging as a separate deliverable rather than hoping the name string carries all the meaning.

6. Point counts as the commercial basis of a tender

BMS tenders are priced largely per point, because points drive almost every cost line: controller capacity, input and output modules, panel space, cable, containment, field devices, engineering hours, graphics, commissioning time and software licensing. Some platforms are still licensed on point count directly. So the number on the points list is the number the price hangs from.

This creates two predictable behaviours. Contractors count conservatively, because an underestimated point count is money lost. Clients and consultants under-specify, because a smaller list wins budget approval. Both pressures push toward a list thinner than the building needs, and the shortfall surfaces during commissioning when someone discovers there is no way to prove the fan is running.

Then comes scope creep, which in BMS work almost always arrives as added points rather than added systems. The mechanical design changes and adds a valve, so an AO appears. Someone asks for filter monitoring, so DIs appear. The energy manager wants sub-metering, so integrated points appear. The tenant fit-out adds fan coil units. Each addition is small and defensible. Cumulatively they are the largest single source of variation on BMS packages, and by the time anyone tallies them the controllers are full and a new panel is needed, which is where cost stops being linear. What I would insist on:

• Specify spare capacity explicitly. Not "adequate spare" but a number: typically 15 to 20 percent spare terminals per type per controller, plus physical panel space and cable gland provision. Spare capacity is the cheapest thing you will ever buy on a BMS and the most expensive thing to add later.
• Price the point rate in the contract. Agree a rate per AI, AO, DI, DO, network and integrated point at tender stage, so additions are priced against a pre-agreed schedule rather than negotiated one at a time under programme pressure.
• Count virtual and network points separately. Never let a headline "800 point system" hide whether that is 800 hardwired points or 300 hardwired plus 500 software objects. They cost completely different amounts.
• Freeze the list at a named revision. One document, one revision number, referenced in the contract. Everything after that is a change.
• Keep a live variation register against the schedule. Point additions tracked in the same file, with date, originator and cost, so the cumulative picture is visible before the controllers fill up.

7. Field devices: what they measure and how they get installed wrong

A point is only as good as the device behind it. This is where a lot of BMS disappointment actually originates: the controller is fine, the software is fine, the logic is fine, and the sensor is in the wrong place reading something that is not the quantity anyone intended to measure.

None of these errors is exotic. Every one of them is something I would expect a proper witnessing regime to catch, and every one of them is something that routinely survives into occupation because the witnessing regime consisted of opening a graphic and confirming that a number appeared.

8. Status versus command, and the lie of proving from a command

This deserves its own section because it is the most consequential single design decision on a points list, and it is quietly wrong in an enormous number of buildings.

A command is what the controller told the plant to do. A status is what the plant is actually doing. They are not the same point, they are not equivalent, and one cannot substitute for the other. If your points list has a DO called "supply fan start" and no corresponding DI proving the fan is running, then your graphic showing the fan as green is not reporting reality. It is reporting an intention. The fan can be tripped, the belt can be snapped, the isolator can be locked off, and the system will display a running fan and cheerfully sequence the rest of the air handling unit around a fan that is doing nothing.

I have opened front ends where every item of plant showed healthy and a walk round the plant room found two fans stationary. Nothing was in alarm, because nothing was monitoring anything. The system was showing its own commands back to itself.

The practical rules I would apply:

• Every DO that starts rotating plant gets a matching DI status point. No exceptions on anything that matters. This is a cheap point and it is the foundation of trustworthy operation.
• Prove load, not contactor state. A current sensing relay set to the motor's actual running current proves the motor is loaded. An auxiliary contact on the starter proves only that a coil is energised. For belt-driven equipment the difference is the entire point of the exercise.
• Alarm on command and status disagreement, with a sensible delay. Command on and status off after a start delay is a genuine fault worth waking someone for. Status on with command off is equally interesting, and usually means someone has left a drive in hand.
• Keep hand/auto position as its own DI where the starter offers it. Plant left in hand is one of the most common causes of "the BMS is not controlling anything", and it is invisible unless you monitor it.
• For modulating devices, take position feedback, not just position command. A valve commanded to 60 percent that is mechanically stuck at 10 percent will otherwise look perfectly normal forever.

9. Accuracy, calibration and drift

Sensor accuracy on a BMS is usually specified badly or not at all, and the consequence is control that works acceptably at first and degrades invisibly. Three things need to be separated.

Accuracy is how close the device is to truth at manufacture, typically a tolerance over a range: plus or minus 0.3 degrees Celsius for a good immersion sensor, plus or minus 2 or 3 percent for a decent room humidity element, plus or minus 1 percent of span for a pressure transmitter. Specify it where the measurement does real work. A sensor used only to display a room value can be loose. A sensor used in a delta T energy calculation cannot, because a small error on each of two sensors compounds into a large error in the calculated load.

Resolution and scaling is how finely the value is represented once it reaches the controller. A pressure transmitter ranged 0 to 2500 Pa controlling a duct at 250 Pa throws away most of its usable precision. Range the device to the duty, not to the catalogue.

Drift is the slow departure from accuracy over time, and it is the one nobody plans for. Humidity elements drift fastest and worst, and are often the least checked. Many CO2 sensors rely on an automatic baseline correction that assumes the space reaches outdoor concentration periodically, which is untrue in a continuously occupied space. Thermistors and platinum resistance sensors are relatively stable but their terminations and signal conditioning are not. Pressure transmitters drift at zero, which matters most on low differential pressure duties.

A calibration regime worth writing into the maintenance schedule: annual verification against a calibrated reference for any sensor feeding an energy calculation, a statutory function or a demand-controlled ventilation sequence; two-yearly for comfort control sensors; and replacement rather than recalibration for humidity elements, because replacement is usually cheaper than a credible field calibration. Record as-found and as-left values, because the as-found reading over several years is the only evidence you will ever have of how fast that device drifts. This should sit inside the wider BMS maintenance and lifecycle programme, alongside the plant-side routines in preventive maintenance for HVAC systems. For thermal comfort criteria the measurements ultimately serve, ASHRAE remains the reference point most specifications lean on.

10. Wiring, termination and loop checks

Between the device and the point object sits a cable, two terminations and a module, and any of them can quietly corrupt the reading. The failure modes are mundane and repetitive.

• Cable selection. Analogue signals and low-level resistance measurements want screened cable, screen earthed at one end only. Running unscreened sensor cable alongside a variable speed drive output is a reliable way to produce a reading that dances. Long resistance sensor runs need either an adequate conductor size or a transmitter at the device, because cable resistance adds directly to the measurement.
• Segregation. Control and power in the same containment, or drive output cables bundled with signal cables, produces induced noise that no amount of software filtering fixes properly.
• Terminations. Loose ferrules, cores under screws, screens left floating or earthed at both ends, unlabelled cores. Every one of these becomes an intermittent fault six months after handover, and intermittent faults are the most expensive kind to find.
• Polarity and legs. Reversed 4 to 20 milliamp polarity, swapped high and low differential pressure legs, reversed current transformers. Each produces a reading that looks like a reading.
• Labelling. Panel terminal labels, cable labels and field device tags must all match the points schedule reference. If they do not, the schedule is decorative.

The verification activity that catches all of this is the loop check, and it is not the same thing as a functional test. A loop check proves one point end to end, from the physical stimulus at the device to the value displayed on the operator front end.

• For an AI: apply or measure a known value at the device with a calibrated reference, confirm the front end shows it within tolerance, at two or three points across the range, not just one.
• For an AO: command 0, 50 and 100 percent, and physically verify the actuator position or drive frequency at each. Not the feedback value on the screen. The physical position.
• For a DI: operate the actual field contact, switch or condition and confirm the state change and any alarm behaviour. Do not short the terminals in the panel and call it proven, because that tests the wrong half of the loop.
• For a DO: command the output and confirm the plant physically responds, then confirm the corresponding status point follows.

Every loop check gets recorded against its row in the points schedule, with date, engineer, as-found value and as-left value. That record is the single most valuable document handed over on a BMS project, and it is the one most often reduced to a tick sheet with no readings on it.

11. What to demand at handover

Handover is the only moment you have real leverage, and points documentation is the thing most worth spending that leverage on. The list I would attach to any BMS handover requirement:

• The as-installed points schedule, in native spreadsheet or database form, matching the software exactly, with every column from section 4 populated. A PDF is a record, not a deliverable.
• Completed loop check records with actual as-found and as-left values, not ticks, signed by the commissioning engineer and witnessed.
• A point-by-point reconciliation against the contract revision of the schedule, listing every addition, omission and change with its reason. This is how you find out what quietly disappeared.
• Device schedule with makes, models, serial numbers, ranges and calibration certificates where applicable, so the asset register and spares list can be built from it.
• The alarm schedule: every alarm point, its limits, priority, delay and routing destination. An unreviewed alarm configuration is an alarm configuration that will be muted within a month.
• The trend configuration: which points are logged, at what interval, with what retention, and where the data is stored. Confirm it is actually running, and confirm you can export it.
• Spare capacity confirmation per controller per point type, against what was specified.
• Point naming documentation: the convention, the abbreviation vocabulary, and any tagging applied.
• Evidence that every status point disagrees when it should. Demonstrated, not asserted. Isolate a fan and watch the alarm appear.

Two of these deserve emphasis. The reconciliation, because it is the only mechanism that catches silent omissions. And the demonstrated status-disagreement test, because it is the only proof that the monitoring layer is real rather than cosmetic. Both belong in the wider commissioning and handover pack, and the graphics side of it in BMS commissioning, graphics and operator dashboards.

12. The honest part: most buildings are running dead points

Here is the thing the industry does not put in brochures. In a large proportion of the buildings I have looked at, there are points that have not worked correctly since the day they were commissioned, and nobody knows. Not a handful. Often a meaningful percentage of the list.

The reason is structural. A BMS alarms on values crossing limits. It does not, by default, alarm on values that have stopped changing. A space temperature sensor whose element has failed to a mid-scale resistance will sit at 22.4 degrees forever. That value is entirely plausible, inside every limit, and will never generate an alarm. The control loop reading it holds a valve at whatever position that fictional 22.4 demands, indefinitely, while the actual room drifts wherever it likes. Occupants complain, someone adjusts a setpoint, the complaint moves elsewhere, and nobody suspects the sensor because the sensor is reporting a reasonable number.

The same failure mode hits every point type. A differential pressure switch stuck closed proves a fan is running forever. A flow meter reading zero looks like plant that is off rather than an instrument that has failed. A valve position command with no feedback reports whatever it was told. An integrated energy meter whose communications dropped will often hold its last value rather than go offline visibly, so the energy report flatlines and looks like excellent consistency.

What actually works, in order of cost:

• Stale value detection. Flag any analogue point that has not changed by more than a small tolerance over a defined window while its associated plant is running. This is the single highest-value rule you can add, it catches the failure mode described above, and it can be configured in most modern platforms without additional software.
• Plausibility limits distinct from alarm limits. A space temperature of 22.4 is plausible; a chilled water supply temperature of 22.4 is not. Range-sanity rules per point type catch failed sensors that land inside comfort limits.
• Cross-point consistency. Mixed air temperature should sit between outside and return. Supply fan status should agree with supply fan command. Measured flow should bear some relation to drive speed. Disagreement between points that are physically related is strong evidence one of them is lying.
• Communications and point health monitoring. Explicitly alarm on lost devices, offline controllers and integrated points that stop updating, rather than allowing last-known-value to persist silently.
• An annual sampled physical verification. Not every point, a random sample stratified by point type and by system. If the sample failure rate is low, you have evidence. If it is high, you have a business case for proper remediation.
• A fault detection and diagnostics layer if the estate is large enough to justify it, because these rules are exactly what an FDD engine exists to run continuously. That is the subject of the BMS energy optimisation, FDD and analytics piece, and the platform capability to look for when you are evaluating BMS software and platforms.

If you take one operational action from this article, make it the stale value rule. It is cheap, it is quick, and the first time you run it across an existing building it will find things. In my experience it always finds things, and the people who commissioned the building are always surprised.

The idea to walk away with

The points list is not paperwork that follows the engineering. It is the engineering, expressed in the only form that everyone downstream can use. It sets what the building is able to know about itself, and nothing you build later, no analytics platform, no optimisation project, no energy strategy, can exceed what the points list allows.

So the disciplines that matter are the ones applied early and cheaply. Classify every point honestly, including the software and network ones. Give the schedule the columns it needs. Enforce one naming convention with one owner. Pair every command with a real, load-proving status. Size and place devices for the duty rather than the pipe. Loop check with recorded values rather than ticks. Specify spare capacity as a number. And add stale value detection on day one, because the alternative is a building that lies to you politely for years.

Final thoughts

BMS quality is decided far earlier and far lower down than most people assume. Not in the platform selection, not in the graphics, not even in the control sequences, but in a spreadsheet of a few thousand rows describing what the building will be able to sense and command, and in the physical craft of putting devices in the right place and proving them properly.

That work is systematically under-resourced because it is invisible when it goes right. It only becomes visible years later, as a building where the analytics project works and the retrofit is priced with confidence, or as a building where none of that is possible and nobody can quite explain why. If you are commissioning, inheriting or auditing a building management system, ask for the points schedule first. What comes back, and how quickly, tells you most of what you need to know.

Related reading: BMS in HVAC: controls, points and sequences, Building automation systems explained, BMS specification clauses, BMS commissioning, graphics and dashboards, BMS energy optimisation, FDD and analytics, BMS maintenance, servicing and lifecycle.