There is a good chance that somewhere in your career, you have programmed a chiller skid, a pump station or a cooling loop. You have mapped analog inputs from temperature sensors, written PID loops for valve modulation, set up alarms for high pressure and low flow and wired up VFDs to control pump speed.
That work — the real, unglamorous, work — is exactly what the data center industry is now looking for.
The thermal wall is real
Data centers have a physics problem.
Traditional air cooling was designed for server racks drawing 3 to 5 kW. Modern AI training clusters run at 30, 60, sometimes 120 kW per rack. That is not an incremental increase. At those densities, air simply cannot move fast enough or carry enough heat. The numbers do not work.
The industry response has been liquid cooling — coolant distribution units (CDUs), direct-to-chip loops, rear-door heat exchangers, and immersion tanks. The concepts behind this equipment are not new to anyone who has worked on process cooling or industrial HVAC. The physics is the same: move a fluid, transfer heat, reject it somewhere.
What is new is the environment around the equipment.
The physics is the same: move a fluid, transfer heat, reject it somewhere. What is new is the environment around the equipment.
What changes when the machine goes into a data center
When a cooling skid goes into a factory or a commercial building, the integration story is relatively straightforward. You have Modbus to the BMS, maybe BACnet if the building system requires it, a local HMI for the operator, and an alarm relay or two. The site is managed by a facilities team that understands equipment.
A data center is different.
The people running it come from IT. The systems they use — for monitoring, asset management, energy tracking, and infrastructure management — are built around IT standards, not OT standards. They expect equipment to speak languages that most PLC programmers have never been asked to support.
They will ask your cooling OEM customer questions like:
- Does it support Redfish?
- Can we pull data over REST API?
- Is it IPv6 capable?
- Can it talk to our DCIM platform?
- Does it support SNMP?
If your control platform cannot answer yes to those questions, the project does not move forward — regardless of how well the cooling loop performs.
This is where many cooling OEMs hesitate. They understand the thermal side. They do not know what to do about the IT side.
This is not an IT problem. It is a control architecture problem.
Here is what the IT-fluent data center world often gets wrong: they assume the answer is software. Add a gateway. Add a cloud connector. Wrap the equipment in a middleware layer.
Any controls engineer who has been on a commissioning job knows where that ends up.
Gateways introduce latency. They add failure points. They require their own configuration, their own maintenance, and their own troubleshooting. When the cooling system throws an interlock at 2 a.m. because a gateway dropped its connection, nobody on the IT team knows how to fix it.
The right answer is not more middleware. It is a control platform that speaks both languages natively — OT on the machine side, IT on the facility side — without translation layers in between. That is an architecture decision. And it is a decision that gets made when the OEM chooses their PLC platform.
When the cooling system throws an interlock at 2 AM because a gateway dropped its connection, nobody on the IT team knows how to fix it.
What a data center-ready control platform looks like
For a controls engineer, the requirements are actually familiar. The data center just adds a few protocols to the stack you already know.
The OT side stays the same:
- Analog and digital I/O for sensors, valves, leak detectors and actuators
- Modbus TCP/RTU for VFDs, pumps and field devices
- PID loops for temperature and pressure control
- Interlocks, alarm logic, and failover sequences
- Local HMI for commissioning and maintenance
- EtherNet/IP or EtherCAT where high-speed device communication is needed
The IT side adds:
- Redfish: a REST-based standard that hyperscalers and colo operators use to monitor and manage connected infrastructure equipment, including cooling. Think of it as the IT world's way of doing what Modbus does for us.
- BACnet/IP: already familiar to anyone who has done building automation. Data centers still use BMS systems, and BACnet is the handshake.
- SNMP: The network management protocol that IT teams use to monitor devices on their network. Your PLC needs to respond to it.
- IPv6: Modern data center networks run on it. Equipment that only supports IPv4 gets flagged.
- MQTT and REST API: For cloud connectivity, telemetry publishing, and integration with monitoring dashboards.
- OPC UA: For SCADA integration and higher-level data exchange.
The difference between a cooling system that wins a data center project and one that does not often comes down to whether the controller can cover that full stack natively.
Redundancy looks familiar too
One area where industrial controls experience translates directly is redundancy. Data centers run N+1 and N+2 architectures. If one CDU goes offline, the next one picks up the load automatically. That is not exotic. Any controls engineer who has programmed a lead-lag pump station or a standby compressor arrangement has already done this work conceptually.
In a data center CDU application, this typically means:
- Group management across multiple CDU units — often over a CAN network between controllers
- Automatic failover when a unit faults
- Load balancing across active units
- Status reporting to the facility monitoring system so the operator can see which unit is primary and which is standby
The logic is not complicated. What it requires is a controller platform that supports group communication natively, without needing an external coordinator or a SCADA layer to manage the handoff.
What Unitronics brings to this application
One solution for controls engineers considering these issues is Unitronics technology. Unitronics has been building PLC and HMI platforms for industrial and infrastructure applications for decades — HVAC systems, pump stations, water treatment, energy management and facility automation. OT reliability is built into the company’s DNA.
The current generation of Unitronics controllers adds the IT-side protocol stack that data center projects require — Redfish, BACnet, Modbus, OPC UA, REST API, SNMP, IPv6, MQTT, EtherNet/IP and SQL — natively inside the platform, without external gateways. For a cooling OEM, this means the control architecture that handles the pump logic and the valve sequencing is the same architecture that handles Redfish responses and BACnet integration. One platform. One commissioning process. One support path.
Unitronics currently supports cooling OEM deployments for CDU applications ranging from 250 kW to 2 MW, with control packages that include PLC control, HMI, I/O configuration, alarm structures, remote access, and the full IT/OT communication stack.
Their in-house engineering team can review a cooling architecture and define what a data center-ready control package looks like for a specific product — without requiring the OEM to develop internal IT expertise.
The practical takeaway for controls engineers
If you are a controls engineer or an OEM product architect evaluating your platform for data center work, the questions to ask are straightforward:
- Does my platform handle the OT side well? Real-time control, flexible I/O, Modbus, EtherNet/IP, reliable ladder or structured text execution, local HMI, alarm handling. This is standard; your current platform probably already does.
- Does my platform handle the IT side natively? Redfish, BACnet, SNMP, IPv6, REST API, MQTT, OPC UA — without a gateway in front of it. This is where many platforms fall short.
- Can it handle redundancy group management? Controller-to-controller communication for lead-lag and failover, without needing an external coordinator.
- Can it support commissioning and remote diagnostics? Web server access, remote HMI, VPN-compatible connectivity, data logging, trend export. Data center operators run formal commissioning tests and expect remote visibility during operations.
- Can the same architecture scale across projects? The OEM benefit is repeatability. If the control package has to be re-engineered for every data center project, the market entry cost stays high.
Where this is going
The liquid cooling transition in data centers is not a niche trend. Every major hyperscaler is deploying it. Colocation providers are retrofitting facilities. Enterprise data centers are following. The volume of CDU projects, immersion systems, and rear-door heat exchanger deployments is going to grow significantly over the next several years. The cooling equipment manufacturers who will capture that market are the ones who already understand fluid dynamics, heat exchange, and process reliability. The only thing standing between them and those projects, in most cases, is the control architecture.
For controls engineers, this is familiar territory with a new set of protocols on top. The machine logic is the same. The physics is the same. The difference is that the controller now needs to speak to a data center operator's monitoring platform the same way it speaks to a pump. That is not a reason to hesitate. It is a reason to make sure the platform you recommend can do both.
