BAS/DDC Basics for the Resi Tech Stepping Into Light Commercial

What it is

On residential work, the "control system" is a thermostat and some 24V switch legs. Step into light commercial and you'll meet a building automation system (BAS) running direct digital control (DDC). Instead of a thermostat throwing relays, a small computer (the DDC controller) reads sensors, runs a program, and drives the equipment's actuators and relays based on that program.

The good news for a resi tech: the underlying HVAC physics is identical — you're still managing temperature, airflow, staging, economizers, and ventilation. What's different is the control layer. Once you understand a handful of terms, a DDC system stops being a black box.

How it works

A DDC controller works on points — its connections to the real world. Two big categories:

• Inputs (what the controller senses): temperature sensors, pressure sensors, a CO2 sensor, a switch telling it a fan is proving airflow, etc. Inputs can be analog (a varying value, like 72.4°F or 0.8 in. w.c.) or digital/binary (on/off, like "fan status: running").
• Outputs (what the controller commands): a damper actuator, a valve actuator, a relay that energizes a contactor, a modulating signal to a VFD. Also analog (a modulating signal, like 0–10V to a damper) or digital/binary (a relay that's on or off).

The controller runs a program — the software version of the sequence of operation (the written description of what the equipment should do under each condition). It reads the inputs, applies its logic and setpoints, and writes the outputs. Example in plain terms: read space temp; if it's above the cooling setpoint, modulate the cooling valve open and ramp the fan; if the economizer is enabled and outdoor air is good, open the outdoor-air damper first. The thermostat-and-relays version of that lives in software now.

Controllers usually network together so an operator can see and adjust the whole building from one workstation, and so controllers can share data (the chiller plant controller tells the air handlers what's available, etc.). That network commonly runs an open protocol — BACnet is the most widespread — so equipment from different vendors can share data. (Note the contrast with proprietary communicating residential systems, which can't interoperate across brands; commercial BAS deliberately uses open protocols so they can.)

The hierarchy you'll typically see: field devices (sensors/actuators) → equipment-level controllers (one per RTU, AHU, VAV box) → a supervisory controller/workstation that ties the building together and holds schedules, trends, and alarms.

In the field

• Get the sequence of operation first. It's the single most useful document on a commercial job — it tells you exactly what the system is supposed to do. Diagnosing without it is guessing. Ask the customer or the controls contractor for it.
• Read the controller's points, don't just meter wires. The controller already knows the space temp, discharge temp, damper position, fan status, etc. Pull that data from the controller display or the workstation. That's often faster than putting a meter on anything.
• Separate a control problem from a mechanical problem. Is the controller commanding the right thing and the equipment not responding (mechanical/electrical), or is the controller commanding the wrong thing (sensor, programming, setpoint)? Compare the commanded output to what the equipment is actually doing.
• Check the sensors. A drifted or failed input makes the controller do the wrong thing while looking perfectly healthy. Compare a sensor's reported value to your own instrument. Garbage in, garbage out.
• Watch for overrides. Someone may have left a point in manual/override at the workstation (a damper forced open, a fan forced on). An override beats the program — always check whether a point is in auto or hand.
• Know your lane. You can usually diagnose, verify sensors, check actuators, and confirm the sequence. Reprogramming the controller or changing the control logic is typically the controls contractor's job unless you're trained and authorized on that platform.

Normal values & targets

• Control power: field controllers commonly run on 24V (AC or DC); sensors and actuators are low-voltage Class 2.
• Common analog signal ranges: 0–10V (or 2–10V) and 4–20 mA are the workhorse modulating signals to dampers and valves; some use a resistance input (like a 10k thermistor) for temperature.
• Setpoint examples: a space cooling setpoint might be ~74°F with a deadband to a heating setpoint of ~70°F; a discharge-air target on an AHU might be ~55°F. Exact values live in the sequence.
• Network: BACnet (MS/TP over twisted pair, or BACnet/IP over Ethernet) is the most common open protocol; you'll also encounter Modbus and proprietary buses.
• Trends/alarms: a good BAS logs historical "trends" of points and raises alarms on out-of-range values — use the trends to see what happened before you got there.

Common faults & what they mean

• Equipment not responding but the controller commands correctly: mechanical/electrical fault downstream — dead actuator, stuck damper, blown relay, no power to the load. The control side is fine; chase the equipment.
• Controller commands the wrong thing: bad sensor input, wrong setpoint, a point left in override, or a programming issue. Verify the inputs and check for overrides before blaming the program.
• A point reads obviously wrong (e.g., 300°F space temp): failed or shorted/open sensor, or wrong sensor type configured. Compare to a known-good instrument.
• Whole controller offline: lost power, blown controller fuse, network/comm fault, or failed controller. Confirm power and the network connection.
• Intermittent comfort complaints with no obvious fault: pull the trends — a sensor that drifts, a damper that hunts, or a schedule that's wrong often shows up clearly in the historical data.
• Nothing matches the drawings: field changes that never made it back to the documentation. Trust what the controller's points and the actual wiring tell you over an outdated print.

Tech tips & gotchas

• The HVAC is the same; only the control layer changed. Don't be intimidated — temperature, airflow, staging, economizer, and ventilation all still apply. Learn the point/sequence vocabulary and a DDC system becomes readable.
• The sequence of operation is your map. With it, troubleshooting is methodical; without it, you're guessing what "correct" even looks like. Get it.
• Always check for overrides. A forced point at the workstation will make a perfectly good controller drive the wrong output. It's one of the most common "ghost" problems on commercial jobs.
• Use the trends. Intermittent problems that vanish by the time you arrive are usually sitting right there in the historical data. Learn to pull a trend.
• Open protocol (BACnet) ≠ proprietary communicating resi. Commercial BAS is built to let different vendors interoperate; residential communicating systems are deliberately locked to one brand. Don't carry the "can't mix brands" rule over to a BACnet jobsite.
• Stay in your authorized scope. Verifying sensors, actuators, wiring, and the sequence is fair game. Rewriting control logic on a platform you're not trained/authorized on is how buildings break — loop in the controls contractor.

Safety / code notes

• DDC field wiring (sensors, actuators, controller power) is low-voltage Class 2 and must be installed and protected per the applicable Class 2 wiring provisions; the served equipment's line side is full voltage (often 3-phase) — lock out and verify zero energy before working on it.
• DDC controls operate equipment but do not replace required hard safeties (high-limit, freeze-stat, low-water cutoff, etc.); those must remain functional independent of the software per the applicable equipment and mechanical code sections.
• Required minimum ventilation and other code-mandated functions are implemented in the sequence of operation; verify the programmed setpoints actually meet the code minimums rather than assuming the software is compliant.