A BMS points list — or points schedule — is the line-by-line inventory of every input and output a building management system monitors and controls. Points come in four types (AI, AO, DI, DO), split between hardware points physically wired to controllers and software points existing only in the control strategy. A four-pipe FCU carries 4–6 points; an AHU 15–25.
Somewhere on your project there is a spreadsheet that defines everything the BMS will ever do — and there's a decent chance nobody in the room can actually read it. The consultant issued it, the contractor priced it, the commissioning engineer will test against it, and the FM team will inherit it at handover; between those four hands, the points schedule is the single document where scope disputes, missing functionality and "we assumed that was included" arguments are born. We produce these schedules on every project we deliver, and we spend a surprising amount of time explaining them to the people they're issued to. So here's the working explanation: what the document is, what the codes mean, how to read a row, and who's supposed to own it at each stage.
A point is a single input or output the system monitors or controls — each temperature, humidity, CO2 or pressure sensor; each valve or damper actuator; each run status, fault signal and alarm. The points list (the terms points list and points schedule are used interchangeably in the UK) is the complete register of them: one row per point, identifying what it is, where it is, which controller it lands on, what signal type it uses, and what the system should do with it — display it, alarm on it, trend it, or all three. It is simultaneously a design document, a procurement document and a test document, which is exactly why it causes trouble: three different professions read the same spreadsheet for three different purposes. For what a building management system is more broadly, start with our plain-English BMS guide — this article is about the paperwork at its centre.
These three documents travel together and get conflated constantly. The points list / points schedule is the inventory: every point, its type and its attributes. The I/O schedule is the hardware allocation view of the same information: which physical input and output terminals on which controller each hardware point is wired to — the document the panel builder and the electrician actually work from. The description of operation (DoO, sometimes "control strategy description") is the narrative: how the system should behave — what the AHU does on a frost condition, how the heating circuit responds to occupancy, what happens on a fire signal. The relationship is simple once stated: the DoO says what the system does, the points list says what it does it with, and the I/O schedule says where each of those points physically connects. A project that has all three, consistent with each other, commissions cleanly. A project with only one of them commissions by archaeology.
Four codes cover almost every hardware point on a schedule. AI — analogue input: a continuously variable value read into the controller, such as a temperature, pressure, humidity or CO2 sensor. AO — analogue output: a continuously variable command sent out, typically 0–10V, 2–10V or 4–20mA, driving a valve actuator, damper actuator or fan speed reference. DI — digital input: an on/off state read in — run status, fault signal, switch position, occupancy contact. DO — digital output: an on/off command out — start/stop, enable, a relay driving a contactor. Some schedules add UI ("universal input") where the controller hardware accepts either analogue or digital signals on the same terminal — a convention Trend uses heavily, and one reason two schedules for the same plant can look different. The signal-type column matters as much as the point type: an actuator expecting 2–10V driven by a 0–10V output will sit partly open at rest, and that class of mismatch is found during commissioning at best, or during the first heating season at worst.
We'll assess your controls and provide a detailed quotation with energy savings estimates.
A hardware point is physically wired: a sensor or actuator, a cable, a terminal on a controller. A software point (soft point, virtual point) exists only inside the controller or supervisor: setpoints, calculated values, time schedules, alarm flags, an average of three space temperatures. The distinction matters commercially as much as technically — hardware points drive cabling, containment, controller I/O count and commissioning hours, which is why controls packages are priced per hardware point, while soft points cost a fraction as much. A schedule that doesn't separate the two invites exactly the quote divergence that makes tender comparisons meaningless. The pricing side of that story — what a point costs and why returns differ — is covered in our cost-per-point guide for quantity surveyors; this article stays on the technical side of the fence.
Take a typical row and walk it left to right. A point reference, usually coded by system and location — something like AHU1-SAT — which becomes the point's name in the supervisor and the label the commissioning engineer signs off against. A plain description ("AHU1 supply air temperature"). The plant item and location. The controller it lands on. The point type (AI) and signal type (thermistor, 0–10V, 4–20mA, volt-free contact). Then the attribute columns that define what the system does with the value: is it alarmed, and at what limits; is it trended, and at what interval; is it displayed on graphics; does it have a setpoint associated. Those attribute columns are the ones nobody reads and everybody should: a temperature sensor that is wired, commissioned and displayed but never alarmed or trended is a point you paid for and get almost nothing from. When we audit an existing building's schedule, the attribute columns are where the value leaks.
The count is driven by the terminal-unit strategy, not the floor area. A four-pipe fan coil unit carries roughly 4–6 points — space temperature, valve outputs, fan control and status. An AHU runs 15–25 depending on complexity. Boilers, chillers, pumps and metering add their own blocks. So a sixty-FCU office building starts at 240–360 points on the terminals alone before the central plant is counted, while a building of identical size on packaged rooftop plant might carry a tenth of that. If you want to see how those points map to physical terminals on real controllers, our guide to inputs and outputs on the Trend IQ4NC and IQ ECO 412 does the vendor-specific version of this exercise, FCU by FCU and AHU by AHU.
BSRIA BG 6, the UK's design framework for building services, exists to answer exactly this question: it defines which design deliverables are produced by whom at which project stage, with the current edition (BG 6/2018, fifth edition) aligned to the RIBA Plan of Work 2020. Applied to controls, the working split is the one we described from the pricing side in our QS guide: the design team should issue a points schedule with the tender so every bidder prices the same scope, and the contractor develops it through detailed design into the full I/O schedule and description of operation. When that sequence is honoured, tender returns are comparable and commissioning has a test basis. When it isn't — when the schedule first comes into existence as a contractor deliverable after award — every bidder priced a different guess, and the "scope gap" arguments that follow were baked in at tender issue.
Four patterns account for most of the trouble we see. Schedules missing at tender, as above — the single most expensive omission in the controls package. Soft points designed but never configured: the schedule says the system averages, alarms and optimises, but nobody built the logic, and no one notices because the graphics look complete. Attribute columns ignored: hundreds of points wired and displayed, alarms and trends configured for a fraction of them, so the building generates neither early warnings nor the data for any later commissioning problem diagnosis or energy work. And schedules that die at handover: the as-commissioned schedule never updated to as-built, so the FM team inherits a document that disagrees with the building. Point-to-point commissioning — physically proving every row of the schedule against the installed system — is the discipline that catches the first three; keeping the schedule live afterwards is what prevents the fourth.
Two references anchor the document set. BSRIA BG 6/2018 (fifth edition), aligned to the RIBA Plan of Work 2020, is the framework that allocates design deliverables — including the points schedule — by stage and by party, and it's the document to cite when a tender is missing one. CIBSE Guide H, the UK reference for building control systems, treats the detailed design and full specification as the basis for any controls tender — in practice a complete points schedule, defined architecture and commissioning requirements — and specifies the sensor accuracy those rows depend on: 0.6 K over the 15–25°C range for zone air temperature measurement, which is the accuracy the schedule's sensor rows exist to deliver. A schedule aligned to both is a controls package that can be priced, built, tested and defended.
Alpha Controls produces comprehensive points schedules as part of every project — it's the first document we build after survey, and the one our commissioning sign-off is tested against. We also read other people's: consultants send us schedules to sanity-check before tender, contractors send us schedules to price against, and FM teams send us the yellowing as-commissioned copy from 2009 and ask what their building actually does. In every one of those conversations, the same rule holds — the schedule is where controls scope lives, and the quality of the document predicts the quality of the installation with unsettling reliability.
Three triggers. If you're issuing a controls tender and there's no points schedule in the pack, stop and fix that first — it costs a fraction of the scope disputes it prevents. If you're comparing controls bids that came back far apart, put the schedules side by side before you assume the cheap one is a bargain. And if you operate a building and have never seen its points schedule, ask for it — and if what comes back doesn't match the building, that gap is measurable risk. Get in touch or request a survey — we'll build the schedule, check the one you have, or tell you honestly that yours is fine.
Specialist BMS installation, commissioning, and maintenance across London and the South East. SafeContractor Approved, BCIA Member.
Our team of building automation specialists is ready to help you optimise your building's performance and efficiency.
Get in Touch
