Before microprocessors reached mechanical rooms, buildings were controlled by pneumatic devices - air-pressure signals nudging dampers and valves. Direct digital control replaced that with a small computer running the control math in software, and the DDC controller is the box that does it. This guide defines direct digital control, positions the DDC controller as the building-automation counterpart to a PLC, distinguishes application-specific from programmable field controllers, and shows how a cloud SCADA layer aggregates DDC points across many buildings.
DDC Controller in one line: A DDC (direct digital control) controller is a microprocessor-based device that reads sensors, runs control logic in software, and commands actuators to regulate building HVAC equipment. It is the building-automation analog to a PLC: it has physical input and output points, executes control loops and sequences, and can be programmed. DDC replaced pneumatic control by moving the control logic from air-pressure mechanisms into digital software.
Direct digital control means the control loop itself is executed digitally, in software running on a microprocessor, rather than by a mechanical or pneumatic device. The controller samples an input - a temperature, a pressure, a flow - computes the required response using logic and control algorithms, and drives an output to a valve, damper, or fan. Because the logic lives in software, the same hardware can implement a proportional-integral loop, a sequence of operations, and interlocks, and all of it can be changed by reprogramming rather than by rerouting air tubing.
The systems DDC replaced were pneumatic: a thermostat modulated an air-pressure signal that positioned an actuator, with everything calibrated mechanically. That approach worked but was hard to tune, drifted out of calibration, and could not easily coordinate multiple pieces of equipment or report what it was doing. DDC brought precise, repeatable control, the ability to trend and alarm, and remote visibility - a controller can report its inputs and outputs to a supervisory layer, which pneumatics never could.
It is fair to think of a DDC controller as a PLC tuned for buildings. Both read physical I/O, run control logic on a scan, and drive outputs; the differences are in emphasis. DDC controllers are optimized for HVAC-style analog control loops and slower building processes, they speak building protocols such as BACnet, and they are packaged and priced for the many small control tasks a building contains rather than for high-speed discrete manufacturing. The conceptual overlap is why an automation engineer moving from industrial to building controls finds the mental model familiar.
A DDC controller connects to the physical world through input and output points. Inputs read sensors - analog inputs for continuous values like temperature and pressure, digital inputs for on/off status such as a fan proof or a switch. Outputs drive actuators - analog outputs to modulate a valve or damper to a position, digital outputs to start and stop equipment. Many modern controllers offer universal I/O points that can be configured as either analog or digital, input or output, which gives an installer flexibility and reduces the number of controller variants that have to be stocked.
The value of the controller is what it does between reading inputs and writing outputs. It runs embedded control loops - most commonly proportional-integral loops that hold a temperature or pressure at setpoint by modulating an output - and it executes sequences of operation that coordinate a piece of equipment through its modes, such as bringing an air handler through startup, occupied cooling, economizer, and heating. Interlocks and safeties are part of the same logic, ensuring, for instance, that a fan is proven running before a heating stage is enabled.
This combination - I/O plus embedded loops and sequences - is exactly the PLC-like capability that makes DDC controllers the building blocks of a building automation system. Each controller owns a chunk of equipment and keeps it running correctly on its own, without needing a central computer in the loop for routine control. That local autonomy matters, because a building must keep conditioning its spaces even if the network or the supervisory layer is unavailable.
DDC controllers come in two broad classes. Application-specific controllers, sometimes called unitary controllers, are built and pre-loaded for a particular job - a VAV box, a fan coil, a heat pump - with a fixed sequence and a limited set of adjustable parameters. They are inexpensive, quick to commission, and ideal for the many repetitive terminal units in a building, but their logic is largely fixed. Programmable field controllers, by contrast, are general-purpose: an engineer writes custom logic for whatever equipment they serve, which suits central plant equipment and air handlers where the sequence is more involved and site-specific.
These field controllers sit beneath a supervisory controller, which is a more capable device that hosts trends, schedules, alarms, and the graphical interface, and that ties many field controllers together on a network. The supervisory layer does not usually run the fast local loops itself; it coordinates, stores history, and presents the system to operators, while the field controllers keep the equipment running. This tiered arrangement - application-specific and programmable field controllers beneath a supervisor - is the standard shape of a building automation system.
A cloud SCADA layer extends that hierarchy upward and outward. Rather than each building's supervisory system being an island, a platform such as Merobix can collect points from the DDC controllers - typically over BACnet through the supervisory layer - and aggregate them across an entire portfolio of buildings into one historian and dashboard. That lets an operator trend the same air handler across many sites, compare how each building's DDC controllers are performing, and receive alarms centrally, without logging into each front end. For an owner with many buildings, this cloud aggregation of DDC data is what turns a scattered collection of local systems into a portfolio that can be monitored and optimized as a whole.
They are close cousins. Both read physical I/O, run control logic on a scan cycle, and drive outputs, and the mental model transfers directly. The differences are in emphasis: DDC controllers are optimized for HVAC analog control loops and slower building processes, they speak building protocols like BACnet, and they are packaged for the many small control tasks in a building rather than for high-speed discrete manufacturing. A DDC controller can reasonably be described as a PLC tuned for buildings.
An application-specific (unitary) controller comes pre-loaded for one job, such as a VAV box or fan coil, with a fixed sequence and only a few adjustable parameters, making it cheap and fast to commission for repetitive terminal units. A programmable field controller is general-purpose, letting an engineer write custom logic, which suits air handlers and central plant equipment with more involved, site-specific sequences. Both sit beneath a supervisory controller.
DDC controllers usually communicate over BACnet and report to a supervisory controller that hosts trends and the operator interface. A cloud SCADA platform collects the controllers' points - typically through that supervisory layer over BACnet - and historizes them, so the same equipment can be trended and alarmed across many buildings from one dashboard. This lets an owner monitor a whole portfolio centrally instead of logging into each building's local front end separately.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.