HVAC building automation and DDC controls fundamentals field guide

What a BAS and DDC system is, and what it replaced

A building automation system is the network of digital controllers, sensors, and actuators that runs a commercial building's HVAC automatically, with a front-end computer for monitoring, trending, and alarms. The controllers read the sensors, compare the readings to setpoints, and drive the actuators and valves to hold the building where the sequence says it should be. Direct digital control, DDC, is the name for that digital control layer: the microprocessor-based controllers that do the deciding.

It replaced pneumatic and electric controls. The old way ran on compressed air. A pneumatic thermostat bled air pressure to a damper actuator, and a building full of those was a building full of air lines, leaks, and drift. DDC swapped the air pressure for a digital signal and a program. Now the logic lives in software you can read, change, trend, and alarm, instead of in a calibrated air stat behind a cover plate.

The part that matters on the job is that the BAS only does what the sequence of operations tells it to do, and it only works if every input and output was verified to read and drive the right thing. The hardware is rarely the problem. The sequence nobody finished writing and the points nobody checked point-to-point are. The thermostat in a single space does the same sense-and-switch job at the smallest scale, and a BAS is that idea grown up to run a whole building. See the thermostat guide for the single-room version.

BAS vs DDC vs EMS vs BMS

These four terms get used as if they mean the same thing, and they overlap enough that nobody corrects it, but they are not identical. Knowing which is which keeps you from talking past the engineer and the owner.

BAS, building automation system, is the whole HVAC control system: controllers, sensors, actuators, network, and front-end. DDC, direct digital control, is the technology inside it, the digital controllers and the control logic they run. You hear people say a building has DDC controls when they mean the controllers are digital rather than pneumatic. EMS, energy management system, is the slice of the BAS aimed at saving energy: the schedules, setbacks, resets, and optimal start that cut consumption. BMS, building management system, is the broadest term, a BAS plus the other building systems tied in, lighting, access, fire alarm monitoring, metering, sometimes elevators.

On a real project the line between them is fuzzy and the spec section number matters more than the acronym. What does not change is the core underneath all four: digital controllers running HVAC to a sequence. Get that and the labels sort themselves out.

The control loop: sense, decide, act

Every DDC system is built on one loop repeated thousands of times a second across the building: sense, decide, act. A sensor reads a condition. The controller compares that reading to a setpoint. If they do not match, the controller drives an output to close the gap, then reads again to see what happened. That last part, reading again, is the feedback that makes it a closed loop instead of a guess.

Take a cooling coil. The discharge air sensor reads 60 degrees F, the setpoint is 55, so the controller opens the chilled-water valve. The air gets colder, the sensor reads 56, the controller eases the valve back. It never stops. The loop runs continuously, nudging the output to hold the controlled variable at setpoint as the load shifts.

Open-loop control, by contrast, drives an output on a schedule or a rule with no measured feedback, like running a fan whenever the building is occupied. Most HVAC control that has to hold a value is closed-loop, because the load never sits still. When a loop will not settle and hunts around setpoint instead, the problem is almost always tuning or a sensor, not the equipment, and that is where PID tuning comes in later in this guide.

Inputs and outputs: AI, AO, BI, BO

A DDC controller talks to the physical world through four kinds of points, and every device in the building lands on one of them. Get the type wrong on the drawing and the point either reads garbage or refuses to drive.

An analog input, AI, is a varying signal from a sensor: a temperature, a humidity, a pressure, a CO2 level. It comes in as a resistance, a 0 to 10 V signal, or a 4 to 20 mA current loop that the controller scales into engineering units. An analog output, AO, is a varying signal out to a modulating device: a valve or damper actuator driven 0 to 10 V or 4 to 20 mA to sit anywhere from full closed to full open. A binary input, BI, is an on-or-off status coming back: a fan proof switch, a filter differential switch, a flow switch. A binary output, BO, is an on-or-off command going out: start the fan, energize the stage, open the isolation valve.

Count the points before you count anything else. The I/O list, the points list, is the spine of a controls job, because it sets the controller size, the wiring, and what the sequence has to work with. A point miscounted at takeoff is a controller short a terminal at startup.

The sensors: what the controller actually reads

Sensors are the inputs, and the whole control loop is only as good as them. A controller cannot hold a temperature it cannot read correctly, and a sensor that reads two degrees off does not announce it. It just holds the space two degrees off forever while everyone blames the equipment.

The common ones: temperature sensors, usually thermistors or RTDs, in spaces, ducts, and pipes; humidity sensors for return and outside air; pressure sensors for duct static and building pressure, in inches of water column; differential pressure across filters and across pumps; CO2 sensors for demand-control ventilation; flow sensors and water meters; and current sensors that prove a motor is actually drawing load rather than just being commanded on. That current-sensing proof is worth more than a contact across the starter, because it tells you the motor ran, not just that the relay closed.

Calibration is the part that gets skipped. A CO2 sensor drifts and needs periodic recalibration or replacement, an outside-air temperature sensor in the sun reads high, and a duct static sensor with a plugged tube reads low. Check the sensor against a known instrument during commissioning, not against the value the screen is already showing you. The screen showing 72 degrees F proves the point is wired, not that the space is 72.

The actuators and control valves: the outputs that move

Actuators are the muscle. They take the controller's output signal and move something: a damper, a valve, an inlet vane. A modulating actuator takes a 0 to 10 V or 4 to 20 mA signal and positions anywhere across its stroke, often sending a feedback signal back so the controller knows where it actually went. A two-position actuator just drives open or closed on a binary output. Spring-return models fail to a safe position on power loss, which is why the outside-air damper springs closed and a heating valve often springs open.

Control valves come in two-way and three-way. A two-way valve throttles flow through a coil, so it changes the system flow as it modulates, which is what variable-flow pumping wants. A three-way valve diverts or mixes to hold flow roughly constant through the main while it varies flow to the coil, the older constant-flow approach. Most new variable-flow plants use two-way valves at the coils.

Valve authority is the number that separates a valve that controls from one that just bangs around. Authority is the ratio of the valve's pressure drop wide open to the drop across the whole controlled branch, and you want it high, commonly 0.3 to 0.5 or better. Size a valve too big, with too little of the branch pressure drop across it, and authority drops, the valve does all its work in the first crack of travel, and the loop hunts. Size control valves to a target pressure drop and a calculated Cv, not to the pipe size. A line-size valve is usually the wrong valve.

The controllers: field, plant, and supervisory tiers

DDC controllers come in tiers, and the tier sets what the controller can do and how much it costs. Naming the tier on a drawing keeps the bid honest.

Field or equipment controllers, often called unitary controllers, sit on a single piece of equipment: a VAV box, a fan coil, a rooftop unit. Many are application-specific, sold preloaded with the logic for that one device, with a fixed point count you configure rather than program. Plant or building controllers are bigger and programmable, running an air handler with a dozen loops, or a central plant with chillers, pumps, and a cooling tower. They carry their own programs and keep running their sequence if the network drops, which is what you want when the head-end goes down at 2 a.m. The supervisory layer, the operator workstation or web server, sits on top: it coordinates, schedules, trends, and alarms, but it is not where the real-time control lives.

The split that matters is application-specific versus fully programmable. An application-specific controller is cheap and fast to deploy when the equipment matches the canned program, and a wall you hit hard the day the sequence needs something the canned logic does not offer. Programmable controllers cost more and take engineering time, and they bend to the sequence the project actually wrote. Match the controller tier to how custom the sequence is, not to the lowest line item.

What is a sequence of operations?

A sequence of operations, the SOO, is the written description of exactly how the HVAC is supposed to run: every mode, every setpoint, every interlock, every reset, in plain language and logic that a controls programmer turns into the program. It is the spec for the controls and the heart of the whole job. The hardware is generic. The sequence is what makes this building's system behave like this building needs.

A real SOO names the conditions and the responses. When the air handler is in occupied mode, hold the discharge air at setpoint by modulating the cooling valve and the heating valve in sequence with a deadband between them so they never fight. Reset the discharge setpoint up as the zones get satisfied. Run the supply fan to a duct static pressure setpoint and reset that setpoint down off the most-open VAV damper. Economize when the outside air is suitable. Each of those is a sentence in the sequence and a loop in the program.

Here is the blunt part. A weak or missing sequence is the most expensive failure in controls, and it is invisible until the building runs wrong. If the SOO does not say what happens at the mode boundaries, in a sensor failure, on a freeze condition, the programmer guesses, and the guess runs the building for years. Read the sequence before you bid it, write it before you program it, and test it line by line at commissioning. ASHRAE Guideline 36 publishes vetted high-performance sequences, mainly for VAV systems with chilled-water and hot-water plants added, written to meet standards like ASHRAE 90.1, 62.1, and 55. Using a proven sequence beats reinventing one that nobody tested.

PID control and loop tuning

Modulating loops in DDC almost always run on PID, proportional plus integral plus derivative. It is the math that decides how hard to push the output based on how far the reading is from setpoint, how long it has been off, and how fast it is moving. Get it right and the loop holds steady. Get it wrong and the loop hunts, swinging above and below setpoint and wearing out the actuator.

The proportional term reacts to the current error: bigger gap, bigger push. Used alone it leaves a steady offset, the loop parks near setpoint but never quite on it. The integral term cures that offset by accumulating the error over time and pushing until it is gone, which is why most HVAC loops run PI. The derivative term reacts to the rate of change to damp overshoot, and on slow thermal loops it is often left out because it amplifies sensor noise more than it helps.

Tuning is matching those terms to how fast the process responds. A fast loop like duct static needs different gains than a slow one like a chilled-water coil. The field tell of bad tuning is hunting: a valve cycling open and closed, a damper breathing, a discharge temperature sawing across setpoint. Before you retune, check the mechanical side, an oversized valve with poor authority hunts no matter how you tune it. Tune one loop at a time, watch a trend of the controlled variable, and back off the gain until it settles. A loop that hunts is a loop that wears parts and never holds the space.

What is BACnet?

BACnet is the open communication protocol that lets building automation devices from different manufacturers talk to each other. It is an ASHRAE and ISO standard, ASHRAE Standard 135, which is the reason it matters: because it is open and vendor-neutral, a BACnet controller from one maker can share points with a front-end from another. That interoperability is the whole point, and it is what keeps an owner from being locked to one vendor forever.

BACnet runs over two physical layers you meet constantly. BACnet/IP rides on standard Ethernet and IP, fast and built for the building network and the supervisory tier. BACnet MS/TP, master-slave token-passing, runs on RS-485 twisted-pair wiring as a daisy-chained field bus, slower, with a top speed around 115 kbps, but cheap to install out to the equipment controllers. A typical building uses both: MS/TP trunks gathering the field controllers, IP carrying the data up to the head-end.

BACnet is the dominant protocol in commercial HVAC controls today, and most specs call for a BACnet system precisely so the owner can rebid the next service contract or add a controller without ripping out the system. When a spec says open system, it usually means native BACnet, not a proprietary protocol with a BACnet translator bolted on. Those are not the same thing, and the difference shows up the day you try to add a third-party controller.

Modbus, LonWorks, and the other protocols

BACnet is dominant but it is not alone, and a real building usually has more than one protocol on it. Knowing what you are looking at saves a day of confusion at integration.

Modbus is a simple, old, widely-used master-slave protocol, common on equipment-level gear: chillers, VFDs, power meters, boilers, generators. A manufacturer ships a packaged chiller with a Modbus interface and a register map, and the BAS reads it as a Modbus master. It carries no built-in meaning for its data, just numbered registers, so you map every register by hand against the manufacturer's table. That manual mapping is where integration time goes and where errors hide. LonWorks is an older building protocol built on peer-to-peer communication where devices talk directly to each other. You still find large LonWorks installations, and they work, but new design has largely moved to BACnet. Treat LonWorks as a legacy system you integrate or migrate, not one you design fresh.

Then there is the proprietary layer. Some manufacturers run their own protocol between their own controllers and expose only a BACnet or Modbus gateway to the outside. That gateway often hands over a thin slice of the points, not full access. When you integrate one of these, confirm which points actually come across the gateway before you promise the owner a graphic of everything inside the box.

The BAS network architecture

A BAS is a layered network, and the layers map to the controller tiers. Picture three levels stacked from the equipment up to the operator.

At the bottom is the field bus: MS/TP trunks or equivalent, RS-485 daisy chains running out to the unitary and equipment controllers on the VAV boxes, fan coils, and rooftop units. In the middle is the IP network, Ethernet carrying BACnet/IP between the plant controllers, the field bus routers, and the supervisory devices. At the top is the supervisory layer, the front-end server and the operator workstations where people watch and command the system. Data flows up for monitoring and trending and down for setpoints and overrides, but the real-time control stays low, in the controllers, so the building keeps running if the upper layers drop.

Two field rules come out of this. Keep the field bus within its device and length limits, because an overloaded or too-long MS/TP trunk gets slow and flaky in ways that look like random controller dropouts. And do not assume the BAS IP network and the building's business IT network are, or should be, the same wire. That is a cybersecurity question covered later, and the answer is usually separation.

The front-end: the operator workstation and web server

The front-end is the human side of the BAS: the operator workstation or web server that shows graphics, raises alarms, stores trends, and holds the schedules. It is where the building staff actually live with the system, and a good one is the difference between a system that gets run and one that gets ignored until it breaks.

Graphics are floor plans and equipment diagrams with live point values painted on them, so an operator sees the air handler's discharge temperature, valve position, and fan status at a glance and can command a setpoint from the same screen. The front-end coordinates schedules across the building, collects trend data from the controllers, and routes alarms to whoever is on call. What it is not is the controller. The real-time loops run down in the field and plant controllers. The front-end watches and directs.

The mistake owners make is buying a beautiful graphics package and skipping the part that earns its keep: trends and alarms set up to actually tell someone when the building is running wrong. A front-end with no useful alarms and no trends is a screen saver. The value is in the data it keeps and the warnings it sends, not the artwork.

Trending and alarms: where the diagnostics live

Trends and alarms are how a BAS earns its money after the install crew leaves. A trend is a logged history of a point over time, sampled on an interval or on change of value. An alarm is a notification when a point crosses a limit or a status goes wrong. Together they turn a control system into a diagnostic tool.

Trends are how you troubleshoot controls without standing at the equipment for hours. A space that gets warm every afternoon, a valve that hunts, a fan that short-cycles, all of it shows in a trend that a snapshot of the live value hides. Pull a week of trend on the discharge air temperature, the valve command, and the outside air, lay them over each other, and the story usually tells itself. This is the same move the economizer guide leans on to catch free cooling that quietly stopped working.

Alarms have one failure mode that wastes them: too many. Flood the operator with nuisance alarms and the real one gets buried, and the staff starts ignoring all of them. Set alarm limits and delays so an alarm means something needs attention, then route the important ones to someone who will act. An alarm nobody reads is the same as no alarm, except it trained the operator to look away.

Schedules, setpoints, and optimal start

Schedules and setpoints are where a BAS saves the most energy for the least money, because the cheapest conditioning is the conditioning you do not do. An occupancy schedule tells the equipment when the building is in use, and the setpoints tell it how warm or cool to hold during and outside those hours.

Outside occupied hours the system goes to setback in heating and setup in cooling, widening the deadband so the equipment loafs while the building is empty, then comes back to comfort before people arrive. Optimal start is the smart version of that return: instead of starting at a fixed time, the controller learns how long the building takes to recover and starts only as early as needed to hit setpoint at occupancy, no sooner. On a cold morning it starts earlier, on a mild one later, and the difference is energy you stop wasting pre-conditioning an empty building too soon.

The schedule is also the thing most likely to be quietly wrong. A holiday that was never entered runs the building full-tilt on a day nobody is in it. A schedule left in override after a weekend event conditions the place all week. Check the schedules against how the building is actually used, not against what they were set to on day one, because the use changes and the schedule rarely follows on its own.

Integration: tying the building together

Integration is bringing other systems and equipment onto the BAS so they can be monitored and controlled from one place. The HVAC controllers are the start. The value grows as you add the packaged equipment and the adjacent systems that share the same network and the same protocols.

Common integration points: chillers and boilers over BACnet or Modbus, so the plant's own controls report up and take commands; VAV box controllers gathered on the field bus; power and water meters for energy tracking; lighting control; and sometimes access control and fire alarm monitoring on the broader BMS. The work is rarely the wiring. It is the point mapping, confirming that each register or object coming from the chiller or the meter means what the manufacturer's table says it means, and that it lands on the graphic correctly.

The trap is assuming integration is plug and play because both ends speak BACnet or Modbus. Speaking the protocol is not the same as exposing the points you need. A packaged unit might publish a handful of points over its gateway and keep the rest internal. Get the actual points list from the manufacturer before you promise the owner full visibility into a box you do not control. Metering integration in particular is where the energy story lives, so confirm those points read true.

Running the economizer and DCV from the BAS

The economizer and demand-control ventilation are two of the highest-value sequences the BAS runs, and they live in the controller like any other loop. The economizer drives the outside-air, return-air, and relief dampers to pull in cool outside air for free cooling when conditions allow. DCV modulates that outside air to real occupancy using a CO2 sensor, so the building stops conditioning ventilation air for people who are not there.

Both run off the BAS, both depend on a correct sequence and calibrated sensors, and both fail silently when nobody commissions them. A stuck damper or a drifted sensor does not throw a code on most equipment. The savings just stop. Because these two carry their own detailed sequences, high-limit changeover, minimum outside-air floor, CO2 differential, and a functional test, this guide points you to the economizer and demand-control ventilation guide rather than repeating it. The BAS fundamentals here, the loop, the I/O, the sensors, the SOO, are what those sequences are built from.

Commissioning the controls

Commissioning the controls is the work that turns a drawn and programmed system into one that actually runs the building right. It has three parts, and skipping any one of them is how a system gets handed over looking finished and running wrong. The order matters: you cannot test a sequence on points you have not verified.

First is the point-to-point checkout, verifying every input and output, covered in its own section next because it is the step most often shortchanged. Second is the functional test of the sequence: drive the system through every mode and condition in the SOO and confirm it responds the way the sequence says it should. Force an occupied-to-unoccupied transition and watch the setbacks take. Simulate a high outside-air temperature and confirm the economizer locks out. Drop a sensor and confirm the failure response. Third is the trend verification: set up trends, let the system run, and read the data to confirm the loops hold and the resets actually move over real operating days.

The blunt truth, the same one that haunts air balancing, is that most controls callbacks are not bad controllers. They are commissioning that nobody finished. A system that was never driven through its sequence and never trended will run wrong quietly, and the owner pays for it in energy and comfort complaints long after the contractor is gone. The commissioning agent's job is to make it run wrong loudly enough to fix before occupancy.

Why is point-to-point checkout the step you cannot skip?

Point-to-point checkout is verifying that every single I/O point reads the right value and drives the right device, one point at a time, before you trust any sequence to run on top of them. It is the number one controls commissioning step, and it is the one that gets rushed when the schedule is tight. Rush it and every problem downstream looks like a software problem when it is really a wire on the wrong terminal.

For an input, you confirm the sensor reads true: put a calibrated instrument on the actual condition and compare it to what the controller and the graphic show. The space sensor reading 72 means nothing until you confirm the space is 72. For an output, you command the point and confirm the real device moves: command the valve to 50 percent and verify the actuator is actually at half stroke, command the fan on and verify the fan runs and the proof comes back. You are checking three things at once: the point is wired to the right device, it is scaled and polarized correctly, and the device responds.

The failures this catches are the ones that ruin a startup. Two sensors swapped at the terminal strip, so the controller reads the return air as the discharge. A valve wired backward, closing on a signal to open. A damper that says it is at 100 percent on the graphic and is mechanically stuck at 40. None of that shows up in the program, and all of it makes the sequence behave like it is broken. Verify the points first. Then, and only then, does testing the sequence tell you anything true.

Open vs proprietary: who owns the system

Open versus proprietary is the ownership question, and it is the one owners regret not asking until they are stuck. An open system, native BACnet, lets the owner rebid service, add controllers from other makers, and keep the front-end when they change contractors. A proprietary system locks the owner to one vendor for every change, every controller, and every service call, at that vendor's price.

The lock-in is rarely sold as lock-in. It shows up as a system that speaks a proprietary protocol internally and offers a BACnet gateway that exposes only some of the points, or a front-end that only programs that maker's controllers, or licensing that costs real money every time someone touches the programming. Each piece sounds reasonable at bid time. Together they mean the owner cannot get a competitive service price for the life of the building.

On a retrofit, this decision is sharper because you are choosing what to keep and what to replace. You can often reuse field wiring, sensors, and actuators and swap the controllers, which is where most of the cost is. If you are tearing out a proprietary system, the lesson already cost the owner money once. Specify native BACnet and full point access on the replacement so it does not cost them again. Write open-system requirements into the spec in plain terms, because the protocol logo on the brochure is not the same as full, documented point access.

BAS cybersecurity and the IT/OT line

A BAS is operational technology, OT, and the day it went onto IP networks it became something that can be attacked or used as a way into the rest of the building's network. The controls technician is not the security department, but the BAS network decisions you make are security decisions whether you treat them that way or not.

The core practice is separation. Keep the BAS network isolated from the general business IT network, behind a firewall, with controlled and logged access rather than wide-open remote connections. A BAS hung directly on the open internet for the convenience of remote access is a known way in, and BAS devices have shown up in breaches that started exactly there. Change default passwords on controllers and the front-end, because the defaults are published. Limit and document who has remote access. This is a place to bring in the owner's IT and a real OT security standard rather than improvising, and to coordinate the network design before the system goes live, not after.

Fault detection and analytics on BAS data

Fault detection and diagnostics, FDD, is software that watches the BAS data and flags faults automatically, the next step up from a human reading trends. It runs rules against the point data, simultaneous heating and cooling, a damper commanded shut but the mixed-air temperature still tracking outside air, a valve that never closes, and surfaces the fault with a likely cause instead of waiting for a complaint.

The point is that a BAS already collects the data FDD needs, so analytics turns trend logs nobody reads into a prioritized list of what is actually broken and what it is costing. It is most useful on a large portfolio where no one has time to read trends building by building. The catch is that FDD is only as good as the point data under it, which loops back to commissioning and calibrated sensors. Run analytics on uncommissioned points and you get confident, wrong faults. Verify the data first, then trust the analytics.

The data-center BMS tie

A data center runs a BMS that is the same DDC fundamentals turned up to a higher stakes level, because the cooling cannot stop. The controllers, sensors, and sequences look familiar, but the alarming and redundancy are built around the fact that a cooling failure becomes an IT outage in minutes, not hours.

The BMS monitors and controls the cooling, CRAC and CRAH units, chilled-water plant, containment, and pumps, and watches the conditions that the IT side cares about, supply air temperature and humidity to the racks within tight bands. Alarms are immediate and redundant because the response window is short. The control fundamentals are the ones in this guide. What changes is the consequence of a quiet failure, which is why data-center controls get commissioned and trended harder than almost anything else. For the thermal targets and the room-level approach, see the data-center cooling material rather than this general guide.

Where the energy savings actually come from

The reason a building pays for a BAS is energy, and the savings come from a short list of sequences that the system runs without anyone touching them. Knowing which ones pay tells you where to spend commissioning time.

Schedules and setbacks come first, because conditioning an empty building is pure waste and the schedule is what stops it. Optimal start trims the pre-conditioning to the minimum. Resets are the quiet winners: discharge-air temperature reset, duct-static-pressure reset, chilled-water and hot-water temperature reset, each one letting the plant back off when the load is light instead of running flat-out all day. The economizer adds free cooling when the weather gives it. Demand-control ventilation cuts the air you condition for people who are not there.

Here is the catch that ties this whole guide together. Every one of those savings depends on a correct sequence and verified points, and every one of them fails silently. A reset that was never commissioned, a schedule left in override, an economizer with a stuck damper, none of them throw a code. They just quietly stop saving while the meter keeps running. The energy case for a BAS is real, and it is only real if someone commissioned the sequences and keeps checking the trends.

What to document

A controls job that is not documented is a controls job the next technician has to reverse-engineer, usually at 11 p.m. with the building too hot. The record is what lets someone who was not there understand and fix the system. It is also what proves the work was actually done at commissioning.

Capture the as-built points list with the verified I/O, the final sequence of operations as programmed, the network architecture and addresses, the point-to-point checkout results, the functional test results against the sequence, the controller and front-end passwords held securely, and the trend setup. When a point was overridden or a value forced during startup, write it down and confirm it was released, because a point left in hand is the failure mode that hides for months.

Common mistakes

• No sequence of operations, or a weak one that goes silent at mode boundaries and failure conditions, so the programmer guesses and the guess runs the building.
• Skipping the point-to-point checkout, so swapped sensors and backward valves get chased as software problems.
• Leaving loops un-tuned so valves and dampers hunt, wearing out actuators and never holding setpoint.
• Specifying or accepting a proprietary system with limited point access, locking the owner to one vendor for the life of the building.
• Trusting sensor readings that were never calibrated against a known instrument, so the system holds the space wrong while the screen looks right.
• Leaving points overridden or in hand after startup, so the building runs on a forced value nobody remembers setting.
• Setting up no useful trends or alarms, or so many nuisance alarms that the operator stops reading all of them.
• Hanging the BAS on the open business IT network with default passwords instead of an isolated, controlled OT network.

Field checklist

Standards and references

The controls world leans on a few documents, and citing the right one for the point is what separates a spec that holds up from one that waves at standards. Confirm the edition the project adopted before you quote a number on a submittal.

ASHRAE Guideline 36, high-performance sequences of operation for HVAC systems, publishes vetted control sequences, mainly for VAV systems with chilled-water and hot-water plants added, written to meet ASHRAE standards including 90.1, 62.1, and 55. When a project calls for Guideline 36 sequences, you are getting tested logic instead of one engineer's guess. BACnet is ASHRAE Standard 135, also an ISO standard, and it is what a spec means by an open, interoperable controls protocol. ASHRAE Standard 90.1, the energy standard, drives many of the controls requirements that show up in the sequence, the schedules, setbacks, economizer, DCV, and resets, though the adopted energy code in a given jurisdiction may be 90.1 or a state code based on it.

Beyond those, the controls manufacturer's own documentation governs the specific controller, its point capacity, and its protocol behavior, and the project specification and the design engineer's sequence govern what this building's system has to do. Cite the standard that controls the point, hedge to the adopted edition and the project documents, and never quote a sequence requirement off memory when the engineer wrote one for the job.

Units, terms, and signals

Controls work spans a few unit systems and a pile of acronyms, and the same idea reads differently across a sequence, a submittal, and a controller manual.

Modulating signals are voltage or current: 0 to 10 V, sometimes 2 to 10 V, and 4 to 20 mA current loops, with actuators often sending a 2 to 10 V feedback. Pressure shows up as inches of water column, in. w.c. or in. wg, for air, and psi for water. Temperature is degrees F on most U.S. jobs, degrees C on metric ones. CO2 is parts per million, ppm. Valve flow capacity is Cv. Network speed on MS/TP is bits per second, commonly up to about 115 kbps.

BAS / DDC

Building automation system; direct digital control, the digital controllers inside it

AI / AO / BI / BO

Analog input, analog output, binary input, binary output, the four I/O point types

SOO

Sequence of operations, the written description of how the system is to run

PID

Proportional-integral-derivative, the math that tunes a modulating control loop

BACnet (ASHRAE 135)

The open, interoperable controls protocol; BACnet/IP and BACnet MS/TP physical layers

Valve authority

Ratio of the valve's pressure drop to the controlled branch drop; aim high, commonly 0.3 to 0.5 or better

Optimal start

Starting equipment only as early as needed to reach setpoint by occupancy

Related tools

Calculators and readiness checks for this work

Compare your options

FAQ

People also ask

• What is a C-wire?
• What is an air-side economizer?
• What is BMS commissioning?
• What is fault detection and diagnostics?
• What is HVAC zoning?