Controls Commissioning Commissioning
The sequence of operations is a promise: on a call for cooling the valve drives open, on a freeze trip the fan stops, at six in the morning the unit leaves unoccupied mode. Commissioning is where somebody proves the controller actually keeps that promise — not on the graphic, where a green readout costs nothing, but at the physical point. The core move is point-to-point checkout: walk every input and output end to end, exercise it, and confirm the controller does what the sequence claims. One question runs the whole page: how do you verify a controller actually does what its sequence of operations says?
"Commissioning" gets used for three different jobs that share a week on site and get conflated on the schedule. This page is one of them — controls functional testing, the point-by-point proof that the DDC does what the sequence says. The other two move fluids, not signals: hydronic balancing sets design flow to every water load, and air balancing does the same for the ductwork (a companion lesson). All three have to land before turnover, but they're different work with different tools — a manometer and a balancing report are not a laptop and a points list. Keep them separate in your head and the rest of this page stays about controls.
Point-to-point checkout — the whole idea
Point-to-point checkout is exactly what it sounds like: you take the points list — the I/O schedule from the submittal, the one that says UI3 is the mixed-air sensor and BO2 is the exhaust fan — and you verify every line of it against the physical world, one point at a time. The word that carries the weight is physical. You are not checking that the graphic shows 55 °F; you are checking that when the mixed-air sensor is really at 55 °F the controller reads it, that the wire on UI3 goes to the sensor the schedule names, and that the object the sequence references is the object that actually moves.
A graphic can be right for all the wrong reasons. A point mapped to the wrong object reads plausibly. A transmitter scaled on the wrong range tracks in the right direction and lies about the magnitude. Two swapped wires each report a believable number. None of that shows up from the front end — it shows up when you stand at the device, make something known happen, and watch whether the value the controller reports is the value the world is really doing. That's why checkout runs from the field toward the front end, not the other way around: the field is the ground truth, and the graphic is the thing on trial.
The method, per point type
Every point gets exercised in the same spirit — make a known thing happen at the field end, then confirm the controller agrees — but the mechanics differ by point type. The four you'll meet on almost any controller are the analog and binary inputs and outputs (AI / AO / BI / BO), and each has its own way of being lied to.
Analog input (AI). Apply a known input and confirm the engineering value. On a resistance sensor — an RTD or a 10K thermistor — that means a decade box or resistance substitution at the input, using the sensor's type curve to know which temperature a given resistance should represent. On a transmitter it means a signal source: a loop calibrator injecting a known current, or a voltage source for a 0–10 V device, stepped through the bottom, middle, and top of range while you confirm the controller shows the same. This is where scaling errors surface, and the signal-scaling tool is the arithmetic behind them — a transmitter read on an object scaled for the wrong range tracks correctly and reads wrong everywhere. Keep the live zero in mind: on a 4–20 mA loop, 4 mA is a real signal and 0 mA is a broken loop, so an AI parked at the very bottom of its range is a wiring question, not a reading.
Analog output (AO). Command the point to 0, 50, and 100 % and go watch the actuator, valve, or drive move. Two things get proven: direction and span. Direction catches the reversed action — an actuator wired or configured for the wrong sense strokes backwards, driving wide open on a 0 % command, and the loop fights itself all season. Span catches the actuator that only sweeps part of its travel because its range setting and the software range disagree. A drive gets the same three commands, and its direction of rotation is confirmed here too — once, during checkout, before it matters.
Binary input (BI). Actuate the actual field contact and confirm the point changes state — and that its sense is right. A proof-of-flow switch, a current switch on a motor lead, a differential-pressure status: make the real condition happen (or jump the contact at the device, knowing exactly what you've done) and confirm OPEN / CLOSED lands where the sequence expects. Polarity is the trap. A normally-closed contact read as normally-open inverts the whole meaning, so "fan running" annunciates as "fan failed," and the sequence dutifully reacts to a status that is precisely backwards.
Binary output (BO). Command on, command off, and confirm the intended load actually switches. The classic catch is the mislabeled or swapped pair: you command the exhaust fan and the supply fan starts, because the two outputs are landed backwards or the panel and the schedule disagree. You only find it by commanding the point and watching the equipment — the graphic will cheerfully show the exhaust fan running while the supply fan is the thing that spun up.
| Point | Exercise it by | Confirm | Common catch |
|---|---|---|---|
| AI | Decade box / resistance substitution on an RTD or thermistor; a mA or V source on a transmitter, stepped across range | Controller reads the correct engineering value at each point | Wrong scaling / range; wrong sensor type curve; a live-zero loop read as a real low value |
| AO | Command 0 / 50 / 100 % and watch the device | Actuator, valve, or drive strokes the right direction across the full span | Reversed action (backwards on a 0 % command); partial span; wrong rotation |
| BI | Actuate the real field contact (proof / status / current switch) | Point changes state, and the polarity matches the sequence | Normally-open vs normally-closed inverted — status reads backwards |
| BO | Command on / off | The relay or contactor energizes the load the schedule names | Mislabeled or swapped outputs driving the wrong equipment |
Override discipline — the safety spine
Every one of those tests is an override. You force the AO to 100 %, you put the BI out of service and toggle it, you command the BO on with the interlocks defeated so you can prove the wiring before you prove the logic. Overrides and forces are how checkout happens — there's no way to test an output without commanding it away from what the sequence wants. The discipline isn't avoiding them; it's accounting for them.
Two rules do the work. Log every override as you set it, so there is a written list of what is not currently under automatic control. Clear every one before turnover — walk that list back to zero and confirm each point is released to normal automatic operation. A forced point is a live hazard wearing a disguise: an AO left at 100 % holds a heating valve wide open into a summer coil; a defeated freeze interlock leaves nothing between a cold night and a burst coil; a BO forced on runs a motor the sequence believes is off. The reason it's worse than an ordinary bug is that it's invisible to the logic — the sequence is executing correctly and being ignored. A forgotten force is one of the classic turnover defects, and it's usually found weeks later by the equipment, not by the trend.
True story. I swapped a controller one winter with the outside air down around −20 °F. Before the swap I forced all the DX cooling off — you don't bump compressors at that kind of cold, and those units had only small crankcase heat bands, so starting them was a good way to hurt a compressor. That was the right call for the day. The trouble was the graphics: the forced-off cooling outputs never showed as overridden on the front end, so once the swap was done they slipped under the radar and nobody saw them. They rode along, quietly forced off, all the way to summer — when the first hot day came in as a no-cool call on that exact controller. Short drive to the site, quick fix once I was there: clear the overrides. The lesson isn't "don't override" — the override was correct. It's that an override placed for a good reason still has to be written down and cleared before turnover, and the ones that never surface on the graphics are exactly the ones that get you. A point-to-point pass over the swapped points would have caught a forced-off cooling output on the spot.
Interlocks and sequence logic, against design intent
Proving each point moves is necessary and not sufficient. The sequence is a set of relationships — this condition trips, so that output responds — and those get verified by making the triggering condition real and confirming the programmed reaction, not by confirming the trigger point merely reads. Trip the freezestat (a low-limit thermostat set just above freezing) and confirm the sequence does everything it promises: fan off, outside-air damper closed, heating valve driven open, alarm annunciated — the whole response, not just "the freeze point went to ALARM." Trip the high-static cutout and confirm the supply fan actually stops. Put the unit in unoccupied mode and confirm setbacks, damper positions, and fan state all follow. Drive a reset input across its range and confirm the reset output walks the way the sequence draws it.
Hardwired safeties get special attention, because they exist for exactly the moments the software can't be trusted. A freezestat or high-static switch wired to drop the fan through hardware has to be proven to drop the fan through hardware — controller watching, but not in the path. The whole point of a hardwired safety is that it works when the software's number is a lie: a railed sensor, a crashed controller, a value stuck where nothing downstream can see it's wrong. Test it the way it will be asked to work.
Trend logs — proof over time
A point-to-point walk proves a point moved once. It does not prove the loop holds setpoint at three in the morning, that the lead/lag rotation actually rotated on schedule, or that the static reset walked down on a mild evening and back up on a design afternoon. That proof lives in trends. Stand up trend logs — change-of-value or a short interval — on the points the sequence cares about, let them run across real operating swings, and read them back.
Trends catch the failures a snapshot cannot: a loop that tracks fine when you nudge it but hunts for twenty minutes after a load step, staging that short-cycles on a marginal deadband, a reset that never leaves its design value because the polling side was never enabled. A commissioning record that ends at the point-to-point walk has proven the plumbing; the trends are what prove the sequence. If you've tuned a loop in the PID tuner, you already know the shape of what a trend is showing you — the same overshoot and hunting, now on a real point over real hours.
Documentation and turnover
The deliverable of checkout is not a working building — it's the record that the building was proven to work, point by point, with a name and a date on it. The completed point-to-point checklist is that record: every I/O point, what it was exercised with, the observed value or state, pass or fail, and a note wherever something had to be corrected. Whatever is still open at turnover goes on the issues log — the punch list of deferred items — so nothing quietly falls through the seam between "commissioned" and "occupied."
The other half of a good record is that it lets the next tech re-verify. A year from now, when a sensor drifts or a controller gets swapped, the person standing at the panel should be able to read what "right" looked like on the day it was proven. Leave the checklist, leave the trends, and leave the overrides cleared — and listed as cleared. That last part is what turning a system over actually means: not "it runs," but "here is the proof it runs, and here is how you'll know when it stops."
One small loop, run once per point
Strip the page to its shape and it's a single loop, run once for every point on the list. The sequence of operations is the yardstick at the top; the loop beneath it is the work — exercise the point, watch the field device, confirm it against the sequence, then document it and clear the force before you move on. Do that for every line of the I/O schedule and you've commissioned the controls. Skip a line and you've left one for the equipment to find.
Two lessons sit on either side of this one. Controller Wiring is the landing that comes before checkout — the points have to be on the right terminals before you can prove they do the right thing, and the wiring simulator lets you trip the wiring faults this page is trying to catch. Function Blocks is the sequence itself — the logic your checkout is holding the controller to. Commissioning is the seam between them: the wiring made real, the sequence made true.