In a data centre the BMS controls and monitors the mechanical and environmental plant (cooling, airflow, temperature, humidity, leak detection), the EPMS monitors the electrical path from utility incomer to rack (switchgear, generators, UPS, PDUs, busbar), and DCIM manages the IT assets, rack space, power capacity and network connectivity in the white space. DCIM doesn't replace the other two — it consumes their data. The outages happen in the gaps between them.
One of the usual points of confusion on a data centre project is whether DCIM sits on top of the BMS and the electrical monitoring, or replaces them. It tends to surface when a software team is trying to pull data out of controllers and breakers and finding it hard going. It's a fair question, and it keeps coming up because vendors tend to answer it in a way that puts their own product in the middle.
We're a controls contractor, not a software vendor, so we look at it from the plant room rather than the software catalogue. Here's that version.
The Park Royal data centre in London NW10, where Alpha Controls replaced the cooling-tower fans and upgraded their controls.
What is the difference between BMS and DCIM?
The BMS is a control system. DCIM is a management application.
A building management system reads sensors, runs control loops and drives plant. In a data centre that means it decides when a CRAC's fan speeds up, when a chiller stages on, when a cooling-tower fan bank goes from nine fans to six, and whether the supply air temperature is where the strategy says it should be. It talks BACnet, Modbus and hard-wired I/O to the plant, and it raises alarms when the plant misbehaves. It is real-time, it is deterministic, and if it fails the cooling either falls back to local control or stops. The CIBSE Guide H definition of a BMS applies unchanged; the difference in a data centre is the tolerance, not the function. Our data centre BMS overview covers the specifics.
Data Centre Infrastructure Management software manages the white space. It holds the rack elevations, the asset register, the power chain from PDU to rack to server, the network patching, and the capacity model that tells you whether there's room, power and cooling for the next ten racks. It reads live data — rack inlet temperatures, PDU loads, UPS load — but it reads it from the BMS, the EPMS and intelligent PDUs rather than from the sensors directly. DCIM does not control anything. If it goes down, the data centre carries on; the operations team just lose their view.
Basket tray going in under the floor beside a row of rack frames. Above the tiles is DCIM's territory. Below them run the services the BMS and EPMS monitor.
So the practical answer is no: DCIM does not replace the BMS or EPMS. It sits on top of them. If your software team can't get data out of the controllers, the problem is the integration layer between the BMS and the DCIM, not the DCIM.
What is an EPMS and how is it different from a BMS?
An Electrical Power Monitoring System watches the electrical path: incomer, HV/LV switchgear, generators, automatic transfer switches, UPS input and output, distribution boards, busbar and PDUs. It reads meters and protection relays at high resolution — typically Modbus TCP over its own network — and its job is to capture power quality events, sequence-of-events records and load trends that a BMS polling every few seconds would miss. On a Tier III or Tier IV site, the EPMS is also the evidence that the concurrently-maintainable or fault-tolerant power topology behaved as designed during a switching event.
The BMS can and often does monitor the electrical plant too, at lower resolution: UPS on battery, generator running, ATS position, main incomer status. On smaller sites the BMS is the electrical monitoring. On larger sites the two coexist, and the seam between them is where the problems live. A UPS with an SNMP card that the IT team monitor, a Modbus card the EPMS reads, and no connection to the BMS at all is a common arrangement on older sites, and it means the people watching the cooling have no idea the batteries are discharging.
The Uptime Institute's Annual Outage Analysis 2025, drawing on its 2024 survey, found power was the primary cause of impactful outages for 54% of the operators surveyed, with cooling at 13%. The 2026 edition still names power as the leading cause. Power is the bigger risk, which is an argument for the EPMS existing. It is also an argument for the BMS knowing what the EPMS knows, because the cooling has to respond to what the power is doing.
Where do BMS, DCIM and EPMS overlap?
Four places, and each is a decision that has to be made by a person, not a product.
Rack inlet temperature
The BMS needs it to control the CRACs. DCIM wants it to show hot spots in the rack view. Intelligent PDUs often have their own temperature probes. One physical sensor, three systems claiming it. Decide which system owns the sensor and the alarm; let the others read it from that system.
PDU and branch-circuit load
EPMS territory for power quality and events. DCIM territory for capacity planning per rack. BMS territory only for the alarm. If all three poll the same PDU directly, the PDU's network card falls over and all three lose it.
UPS status
The alarm belongs on the BMS because the cooling has to respond to it; the detailed event record belongs on the EPMS; the load figure belongs in DCIM's capacity model. One device, three consumers, one protocol gateway if the head end can't read SNMP natively. It is usually the hardest join in data centre BMS integration.
PUE
ISO/IEC 30134-2 defines PUE as total facility energy over IT energy across a year. The IT energy comes from the EPMS or PDUs; the total facility energy comes from the incomer meter; the cooling energy that explains the difference comes from the BMS. Whoever calculates it needs all three feeds. The standard also sets PUE measurement categories based on where the IT energy is metered, so two PUE figures are only comparable if they were measured at the same category.
Get a Free BMS Survey
We'll assess your controls and provide a detailed quotation.
What goes wrong at the boundaries?
Nobody owns the integration between them
The mechanical contractor delivers the BMS, the electrical contractor delivers the EPMS, the client's IT team buy the DCIM, and the integration between them is in nobody's scope. Every one of those systems is signed off working on its own. A common question is how much work it takes to bring UPS, PDU, CRAC, chiller, generator and ATS data into DCIM. The honest answer is: as much work as the BMS and EPMS integration took in the first place, because you're doing it again for a third consumer.
Three names for the same piece of plant
The BMS calls it CRAC-02-DH2. The EPMS calls the circuit feeding it DB-2A/14. DCIM calls the space DH2-Row-C. When the alarm comes in, three people look at three screens and argue about whether it's the same unit. A single asset naming convention across all three systems, agreed before any of them are configured, is worth more than any amount of software.
Nobody owns sensor calibration
Somebody has to own the calibration of the power meters, CTs and temperature sensors in switchgear and UPS rooms, and it often isn't written down anywhere. The right answer is: the BMS or EPMS maintainer, written into the maintenance contract, with the calibration interval in the alarm philosophy. Otherwise the alarm threshold is being compared to a number that drifted two years ago.
Three systems polling the same device
Three systems each polling the same Modbus device over the same RS-485 trunk, timing out on each other. The fix is one master per device, with the others reading from that master over IP.
The same alarm arrives three times
The UPS alarm arrives from the BMS, the EPMS and the DCIM, at three different priorities, to three different email lists. That's a data centre alarm management problem and it's caused by the boundaries not being drawn.
One of the two rooftop GRP distribution boards Alpha Controls installed at Park Royal, each feeding one cell of cooling-tower fans. Power runs through the board; the fan network runs on separate containment back to the BMS panel.
What standards define the boundaries between these systems?
The BS EN 50600 series does the most useful job here, because it's organised by the same boundaries.
BS EN 50600-2-2 covers power supply and distribution and BS EN 50600-2-3:2019 covers environmental control, each tied to the availability classes 1–4 defined in EN 50600-1. Those two parts map almost exactly onto the EPMS and BMS scopes. BS EN 50600-3-1 covers management and operational information — the processes for resilience, capacity planning, risk and energy efficiency, and the information that has to be handed over when a facility is accepted into service. That's the part DCIM is meant to support, and it's why a DCIM with no live feed from the BMS and EPMS doesn't satisfy it.
ISO/IEC 30134-2 (EN 50600-4-2) defines PUE and, by implication, which system has to supply which meter reading. IEC 62443 matters because the BMS and EPMS are OT networks and DCIM is usually an IT application; the standard's zones-and-conduits model is what stops a DCIM integration becoming a route from the corporate network into the plant controllers. The NCSC guidance on operational technology says the same in UK terms.
What does a well-drawn BMS, DCIM and EPMS architecture look like?
It looks like a one-page diagram with a name on every arrow.
The BMS owns the mechanical and environmental plant and is the system of record for those alarms. The EPMS owns the power path from incomer to PDU and is the system of record for electrical events and power quality. Each device has one master. The BMS reads the handful of electrical states it needs — UPS on battery, generator running, ATS position, mains healthy — from the EPMS or from the devices over a defined route, so that the cooling strategy can respond to the power state. DCIM reads from both over IP, through a defined conduit, and never polls a field device directly. One naming convention runs through all three. The alarm philosophy says which system raises which alarm, and the other two log it rather than duplicate it. Calibration and maintenance of every sensor and meter is assigned to a named contract.
None of that is expensive. All of it has to be decided before the systems are configured, which on most projects means at tender stage. Our data centre BMS guide covers how contractor selection fits into that.
When should you sort out the BMS, DCIM and EPMS boundaries?
Before a DCIM purchase, because a DCIM bought before the BMS and EPMS integration is defined will be fed by whatever is easiest, not whatever is right. Before a BMS replacement, because the new head end is the chance to fix the ownership of every shared point. And now, if your operations team need more than one screen to answer “is the site healthy?” — that's the symptom, and it doesn't improve on its own.
Drawing the lines between BMS, DCIM and EPMS
The three systems aren't competitors. They're three layers, and the failures happen where nobody drew the line between them. Alpha Controls install and integrate BMS systems on Trend, Distech, Siemens and Schneider platforms across London and the South East, and we've delivered controls work in a live data centre at Park Royal. If your systems don't talk to each other, talk to us or request a quote.
Alpha Controls Team
Specialist BMS installation, commissioning, and maintenance across London and the South East. SafeContractor Approved, BCIA Member.
