BMS and DDC controls commissioning field guide for data centers

Controls commissioning, where the systems actually come together

The building management system, the BMS, is the supervisory layer that monitors and runs the building's mechanical and electrical equipment. Under it sits direct digital control, DDC, the field controllers and the logic they execute. People say BMS, BAS, building automation system, and DDC almost interchangeably, and the distinction that matters is layers: DDC controllers do the actual control loops at the equipment, and the BMS is the supervisory front end that schedules, trends, alarms, and shows it all on a screen.

Controls commissioning is where the building stops being a pile of equipment and becomes a system. The chillers make cold water, the gensets start, the CRAH units move air, but until the BMS reads them right, commands them right, and sequences them together right, none of it works as one plant. Every other discipline hands its equipment to the controls, so the integration is the last place a defect can hide, and it hides well.

Here is the opinion twenty years of these jobs earns: when a data center fails its integrated systems test, the cause is usually not the chiller and not the genset. It is the controls handoff. A point mapped to the wrong piece of gear, a sequence that does not match the written one, a sensor reading four degrees off so the economizer makes the wrong call, a damper that reads open while it is shut. The equipment is fine. The nervous system was never proven. That is the work this guide covers. The process and program view, the levels, and the deficiency log live in the data center commissioning operations overview; the airside and waterside scope lives in the cooling guide.

The points list and the I/O count

The points list is the inventory of every input and output the BMS touches, and it is the document everything else hangs off. It comes in four physical flavors. Analog inputs, AI, are the variable readings: temperatures, pressures, flows, humidity, valve and damper position feedback, coming in as 4 to 20 mA, 0 to 10 V, or a resistance from an RTD or thermistor. Analog outputs, AO, are the variable commands: valve and damper modulation, VFD speed reference. Binary inputs, BI, are the on or off states: run status, flow and pressure switches, fault contacts. Binary outputs, BO, are the on or off commands: start and stop, enable and disable.

The I/O count drives the controller count, the panel count, and a real chunk of the price, so it is fought over at buyout and it is what you reconcile first. A single CRAH or AHU can carry 30 to 60 points. A chiller plant runs into the hundreds. A full data center reaches thousands, and a large campus tens of thousands. Beyond the physical, or hard, points there are soft points: setpoints, calculated values, and the network points pulled in from integrated gear that has its own controller.

The check that opens controls commissioning is reconciling the as-built points list against the installed I/O and against the graphics, the points-to-graphics tie. Every physical point should exist in the controller, appear on a graphic, and read a live value. A point on the list with no I/O behind it, or an I/O point that never made it to a graphic, is the first thing to flag, because a point you cannot see is a point nobody will catch when it fails.

What is point-to-point checkout?

Point-to-point checkout is verifying every physical point one at a time: that each sensor reads correctly at the BMS and each output actually moves the device it is supposed to command, with the value at the field device matching the value on the screen. It is the foundation of controls commissioning, and skipping it is how every later test inherits a lie.

On the input side you read the field device with a calibrated reference and compare it to what the BMS displays. On the output side you command each point from the BMS, one at a time, and confirm the right thing physically moves: the valve strokes, the damper opens, the VFD ramps, the contactor pulls in and the fan starts. You are proving the wire, the termination, the I/O channel, the scaling, and the binding all the way through, not just that a number looks plausible.

The finds here are the boring ones that wreck an IST. Reversed actuators, where a valve commanded open drives closed. Swapped points, where two adjacent sensors are crossed and each reads the other's space. The classic one is whole-unit miswiring, where AHU-1 on the graphic is physically wired to AHU-2, so every command lands on the wrong machine and it tests fine until both run at once. None of these announce themselves. A thermistor reading 72 degrees looks perfect right up until you learn it is sensing the corridor, not the cold aisle. That is why point-to-point is hands-on the device, not eyes-on the screen. A realistic value is not a verified value.

Sensor calibration and drift

Every control decision is only as good as the sensor driving it, and sensors drift. The point-to-point pass is also the calibration pass: you check each sensor against a traceable reference and correct the offset before any sequence runs on it. Temperature is usually a two-point check against a calibrated reference, commonly held to a tolerance on the order of plus or minus 0.5 to 1 degree F, but the project specification sets the actual number. Pressure transmitters get a zero check and a span check across their range. Flow gets verified against the balancing data or a reference meter.

Two sensors deserve extra suspicion. CO2 sensors drift the worst and the fastest, so they get re-zeroed against a known gas or a verified fresh-air baseline, not assumed good out of the box. Differential pressure transmitters reading small numbers, like raised-floor plenum static near 0.05 in. wg or an aisle containment dP, live close to their own noise floor, so a small zero error is a large percentage error on the reading that runs the fan control.

The reason calibration is not paperwork is the decision riding on it. An economizer changeover is made on the outdoor air temperature or enthalpy sensor, so a three-degree error locks out free cooling when it should run or runs it when it should not, and the energy penalty is real and quiet. A VAV box meters airflow off a velocity-pressure sensor, so an uncalibrated input means the box delivers the wrong air no matter how good the sequence is. The economizer and VAV logic are covered in the cooling guide; the point here is that the smartest sequence in the building is wrong if the sensor under it is wrong.

What is a sequence of operations?

The sequence of operations, the SOO, is the written narrative and tables that define exactly what the controls do: the setpoints, the deadbands, the staging order, the reset schedules, the operating modes, the interlocks, the alarm limits, and the response to every failure. It lives in the specifications and on the controls drawings, and it is the contract for how the building behaves. The functional test is written straight from it, so no usable SOO means there is nothing to test against and every acceptance call becomes an argument.

A real sequence is specific. It says the chilled water valve modulates to hold 55 degrees F supply with a two-degree deadband, the lead chiller stages the lag on at a defined load and a defined delay, the economizer enables below a stated outdoor condition, and on loss of the lead unit the standby starts within a stated number of seconds. That is a sequence you can test.

What kills commissioning is the sequence that is a paragraph of intentions. "Maintain space temperature and stage equipment as required" is not a sequence. It has no number to verify, no timer to clock, no priority to resolve when two demands fight. When the SOO is that thin, flag it at the first controls meeting, not at the functional test, because by the test it is too late to argue what the building was supposed to do.

Verifying the sequence: driving every mode and writing the FPT

Sequence verification is the functional performance test, the FPT, and it means driving the system through every mode, setpoint, and alarm the written sequence describes and recording what the controls actually did against what they were supposed to do. The script is written straight from the SOO. Each step states the condition you force, the expected result, a pass or fail, and a witness signature on that step, not on the page. A script watched once in a hurry and checked off as a block proves almost nothing.

You do not wait for conditions, you force them. Override the outdoor air temperature to trip the economizer changeover and watch the dampers and the valve respond. Drop a sensor out of range to confirm the fault logic catches it and falls to the right safe state. Drive a space or a supply reading past its limit to fire the high-temperature alarm and confirm the staged response, the alarm routing, and the recovery. Step the load to walk the chiller and pump staging up and back down, and clock the timers.

Test every branch, and the branches that matter most are the ones nobody wants to run. Occupied and unoccupied, startup and normal, each stage of cooling, economizer in and out, and then the failure modes: a unit failure and the standby pickup, a sensor failure, a smoke event shutdown, the return to normal after each. The rookie tests the happy path because it is quick and it passes. The whole reason controls commissioning exists is the failure branches, because that is the behavior the building will need on the night the utility actually drops, and it is the behavior nobody will have a chance to fix once load is live.

The DDC controllers and the network

Underneath the BMS sits a hierarchy of controllers, and knowing the layer you are testing keeps the troubleshooting honest. At the equipment are field controllers, often application-specific for a CRAH, a VAV box, or a fan, and fully programmable controllers for plant logic. Above them sit supervisory controllers and gateways that route between networks and serve graphics, and at the top sit the servers and operator workstations. A fault can live at any layer, and a point that reads wrong at the workstation might be right at the field controller and lost in translation between them.

The networks carry it all. BACnet/IP rides the Ethernet backbone, BACnet MS/TP runs the field buses over RS-485 daisy chains, and Modbus RTU or TCP commonly brings in third-party equipment like chillers, power meters, and UPS. In a data center the controls network is itself a system that needs redundancy and clean power, because a controls network that drops takes your visibility and your sequencing with it at the worst time. Verify the controls panels are on UPS or standby power per the design, not on a convenience receptacle someone will trip a breaker on.

The integration architecture is a commissioning deliverable in its own right: the network diagram, the device addresses, the gateways, and the map of which protocol carries which gear. When a controller drops off the bus or two devices fight over an address, you want that diagram in hand, not reconstructed from memory at midnight.

What is BACnet?

BACnet is the vendor-neutral data communication protocol for building automation, standardized as ANSI/ASHRAE Standard 135 and also published as ISO 16484-5. It became ASHRAE Standard 135 in 1995 and is maintained by ASHRAE's standing committee SSPC 135, with the 2024 edition current as of this review. Its job is interoperability: letting controllers and equipment from different vendors exchange values, schedules, alarms, and trends without a proprietary gateway for every pair.

BACnet models everything as objects with properties. Your AI, AO, BV, and the rest become BACnet objects with present-values and status flags, each device carries a unique device instance number, and the device's PICS, the protocol implementation conformance statement, declares what it actually supports. The common transports are BACnet/IP on the Ethernet backbone and BACnet MS/TP on the field buses.

Commissioning cares about BACnet because integration is where mappings break. You verify device instance numbers are unique, that every integrated point actually maps end to end with the right object and scaling, that change-of-value or polling is configured so values update at a useful rate, and that no duplicate addresses are quietly knocking a device off the network. The other protocol you will meet is Modbus, leaner and register-based, common on chillers, meters, and UPS. Modbus has no built-in object model, so its scaling and register maps are exactly where integration errors hide.

Integrating the chillers, gensets, UPS, and the EPMS

Integration is where each piece of third-party gear gets its points into the BMS, and on a data center that is most of the plant: the chiller plant controller, the CRAH and CRAC units, the gensets and their controllers, the automatic transfer switches, the UPS, the switchgear, and the PDUs. Each one speaks its own protocol over its own gateway, and each one needs an integration map: the source register or object, the scaling, the units, and the destination point. The classic find is integration points that were never mapped, or mapped with the wrong scaling, so a power reading lands a factor of a thousand off, or a temperature in Celsius gets shown as if it were Fahrenheit, and the operator trusts a number that is nonsense.

The EPMS, the electrical power monitoring system, is its own platform and worth separating cleanly from the BMS. The EPMS is dedicated to the power chain: revenue and branch metering, breaker and switch status, power quality, and the fast electrical alarms, often sampling far faster than a building controller and built around products tuned for power monitoring. The BMS runs the mechanical and supervisory side of the building. They overlap and they exchange data, but they are not the same system and they should not be treated as one.

The line to hold is which system owns which job. The EPMS does the fast metering and the protective and power-quality alarms; the BMS does the building control and the operator-facing summary. In a data center the EPMS is independently commissioned as part of the power scope, and the BMS typically takes summary points from it, so the commissioning task is to prove that handoff: the right points, the right scaling, the right update rate, and a clear understanding that a slow BMS poll is not a substitute for the EPMS's own fast capture. The power-chain testing itself lives in the electrical scope of the commissioning program.

Trends, and proving performance over time

A trend is the logged history of a point over time, and trends are how you prove what a one-shot functional test cannot. The FPT shows the sequence works for the twenty minutes you watched it. Trends show whether it still works at hour ten, whether a loop is hunting, whether the hall held envelope last Tuesday, and whether the economizer changed over when the weather said it should. Set the trends up before functional testing, not after, so the tests themselves are captured as evidence instead of remembered.

Decide what gets logged and how. Change-of-value logging captures a point when it moves past a threshold, which suits status and alarm points; interval logging samples on a clock, which suits temperatures and flows you want a smooth history of. Set the interval tight enough to catch the behavior you care about and the retention long enough to cover the seasons and the failures that matter, then confirm the storage actually holds it.

The gap that bites later is trends that were never set up. The owner asks whether the cold aisle stayed in envelope during a chiller swap three weeks ago, and there is no data, so the answer is a shrug. Trend the points that prove the sequence and the envelope, prove the trends are actually collecting before turnover, and the building hands over with a memory instead of a blank slate.

Alarms and the cause-and-effect matrix

Every point that can fail needs an alarm with the right limit, the right priority, a sensible delay, and a verified destination, and commissioning tests that each one actually annunciates and routes where it should. An alarm that exists in the database but never reaches an operator is not an alarm. You force the condition, confirm the alarm raises at the right value, confirm the priority and the routing, and confirm it clears on return to normal.

Above the individual alarms sits the cause-and-effect matrix, the table that defines what happens to the mechanical and electrical systems when a major event fires. The fire alarm shuts down air handlers and closes or opens smoke dampers on the smoke-control sequence. A high-temperature event triggers a staged response. The emergency power off, the EPO, drops power to the space. These are tested live against the matrix, witnessed with the fire alarm and electrical teams in the room, because the controls are only one actor and the response has to be proven across all of them at once. The fire and EPO interfaces deserve extra care: confirm the scope and the downstream effect of an EPO before anyone pushes it, because that test is the one that actually kills the room.

The other failure is the opposite of silence. A system that floods the operator with nuisance alarms gets ignored, and the real one scrolls off the screen unread. Tune the limits, the delays, and the priorities so the alarms that matter stand out, because an alarm everyone has learned to dismiss is worse than no alarm at all.

Graphics and the operator interface

The graphics are how the operations team sees and runs the building, and they are commissioned, not assumed. Every graphic point should be bound to a live, real point, update at a useful rate, show the correct units, and reflect alarm and status states in color the way the operator expects. Setpoints adjustable from the screen should respect the permission scheme, so an operator can change what they are allowed to and cannot accidentally change what they are not.

The reconciliation that catches the gaps is the points-to-graphics pass run both directions. A point on the list with no graphic is a point nobody will watch. A graphic object bound to a dead or stale point is worse, because it shows a number that looks live and is frozen, and an operator will trust it. Walk every graphic against the plant and confirm the screen menu tree matches how the building is actually laid out.

This is not cosmetic. The trained operator runs the building from these screens, often alone at two in the morning, and a wrong label or a stale value sends them to the wrong machine while the right one is in trouble. Get the graphics honest before turnover, because after turnover they are the only view the operator has.

Why are points left in hand the classic commissioning find?

Points left in hand or override are the single most common and most dangerous controls finding, because a forced point hides in plain sight: it looks like it is running in auto until the sequence needs it to do something it is no longer listening for. Hand-off-auto, the HOA switch, is on the starter, the VFD, and many I/O modules. In the HAND position the device runs regardless of the BMS, and the automation is bypassed completely. There is a software version too: a point commanded or locked in the BMS overrides the sequence the same way, just from the keyboard instead of the panel.

They get left there honestly. During install and startup, techs put devices in hand to bump a motor, prove rotation, or run a fan while they balance, and on a job with a thousand devices and a moving schedule, some never get switched back. A point gets overridden in software to keep testing moving and the override never gets cleared. None of it is malice. All of it is a live defect.

The danger is specific. A standby fan forced on in hand makes the redundancy you proved on paper a fiction, because the unit that was supposed to be off and ready is already running, and the sequence that was supposed to start it on a failure does nothing visible. A device in hand will not stop on a smoke event when the cause-and-effect calls for it. So the controls CxA sweeps every HOA switch and every software override, before the integrated test and again after, returns them to auto, and documents any that have to stay forced and why. The integrated systems test is the great revealer here: the failure scenario commands a unit to do something, and the point in hand is the one that just sits there. Finding it on the test bench beats finding it on the night the utility drops.

Loop tuning, staging, and the hunting loop

A control loop that passed its functional test at one operating point can still be useless across the range if it is not tuned, and tuning is part of commissioning, not a thing the controls contractor waves at. PID loops drive the modulating outputs: the chilled water valve, the damper, the VFD. Tune them wrong and they hunt, the output swinging back and forth while the controlled value oscillates around setpoint and never settles, which wears the actuator out and leaves the space never quite right.

The hunting loop has two usual causes. Too much proportional gain and the loop overreacts to every wiggle and oscillates. Too much integral action and it overshoots and takes forever to recover. The fix is tuning at the conditions the loop actually runs under, with real load on it, not at startup with the plant empty, because a loop tuned with no load behaves nothing like the same loop at design.

Staging is the loop problem one level up. Chiller staging, pump staging, and the lead-lag rotation need deadbands and minimum on and off timers that keep equipment from short-cycling itself to death when load sits near a stage boundary. Commissioning catches the stage that chatters and the loop that hunts the same way: drive it across its range and read the trends. A loop that looks fine for the five minutes of the functional test and oscillates for the rest of the week is exactly what the trends are there to expose.

What is ASHRAE Guideline 36?

ASHRAE Guideline 36 is High-Performance Sequences of Operation for HVAC Systems, a set of standardized, vetted control sequences published by ASHRAE so that engineers and controls contractors are not reinventing the logic on every job. It was developed by ASHRAE Technical Committee 1.4 and is meant to meet or exceed the requirements of ASHRAE Standards 90.1, 62.1, and 55, with fault detection and diagnostics and trim-and-respond reset built into the sequences. The 2021 edition was followed by a 2024 edition that adds a substantial set of addenda.

The original and primary scope is airside VAV: single-zone VAV air handlers, multiple-zone VAV air handlers, and a range of VAV terminal units, with the sequence library expanding through addenda over time. A controls CxA cares about Guideline 36 for a simple reason: a G36 sequence is detailed enough to test directly, with the deadbands, resets, and timers spelled out, so the ambiguity that wrecks loosely written sequences is largely gone. It also bakes in the fault detection and the reset logic that you then have to commission and prove, which the VAV and economizer guides cover on the airside.

Two honest cautions. Guideline 36 is a guideline, not a mandate, and its coverage is mostly airside, so a chiller plant or a data center cooling sequence is not pure G36 just because the spec name-drops it. And a project that claims G36 has often modified it, so the project sequence of operations, as written and as built, is what you test against. Confirm the edition the design referenced, and read the actual sequence rather than assuming it matches the published guideline.

The integrated systems test, and why controls run it

The integrated systems test, the IST, is the full-plant test that simulates a real failure at load and proves every system reacts together, and the controls are the nervous system that makes it happen. Every other discipline can pass its own functional test and the plant can still fail the IST, because the failure lives in the handoff, and the handoff is controls. The mechanics of the IST, the load banks, and the failure scenarios are covered in the data center commissioning operations overview and the cooling guide; the point here is what the controls have to do inside it.

Walk the failure and the controls show up at every step. The utility drops, the UPS carries the gap, the gensets start and parallel and take block load within the sequence's time window, and the transfer scheme moves the load without dropping the critical bus. Through all of it the controls have to keep the cooling alive: re-enable the CRAH units, restart the chillers in the right order, and reload the loop before the hall climbs out of envelope. The thermal ride-through gap that the cooling guide describes, the minutes a chiller takes to restart and reload after a power blip, is as much a controls timing problem as a mechanical one. If the restart sequence is slow or out of order, the redundancy is real on the one-line and fictional in the room.

This is also where the points in hand, the unmapped integration points, and the untested failure branches all surface at once, because the IST is the first time the whole sequence runs live under a real simulated failure at load. A plant that never ran a complete, continuous integrated test with the controls driving it has not actually been proven, no matter how cleanly each piece tested alone. On a real facility the mechanical, electrical, and controls tests run together, because none of them rides through a failure the others have not.

Data center specifics: cooling control, redundancy, and the DCIM tie

Data center controls carry constraints an office building never sees. The cooling control is the critical sequence: holding the server inlet temperature and the aisle differential pressure, staging the CRAH units and the chillers to the load, switching the economizer over at the right outdoor condition, and rotating lead, lag, and standby so wear spreads and a failure has a ready unit. The cooling guide covers what those setpoints should be; the controls job is to prove the sequence holds them and recovers from a unit loss inside the time the hall can ride.

Redundancy is a controls problem as much as an equipment one. The plant can be N+1 on the drawings, but if the sequence does not detect the failure and start the standby within the window the load tolerates, the redundancy does not exist in practice. The controls network itself needs redundancy and clean power for the same reason, because losing the controls in a critical facility loses both the visibility and the automatic response at the moment they matter most. Verify the failover, do not assume it.

Above the BMS and the EPMS sits DCIM, data center infrastructure management, the layer that ties the facility systems to the IT asset, capacity, and power data so operations can see the whole picture in one place. The BMS and EPMS feed DCIM, and the commissioning task is to prove that data path: the points cross over, the scaling is right, and the picture DCIM shows matches the plant. And because a data center runs 24/7 with no seasonal downtime, you commission for the failure modes you will never get to test again with live load on the floor. The test bench is the only chance. Take it.

Field checklist

What to document

The controls record is what lets the next engineer tell a new problem from how the building always ran, and what proves the sequence was actually verified rather than waved through. Capture the as-built points list, the point-to-point and calibration results, the FPT scripts signed step by step, the integration map, the trend configuration, the alarm and cause-and-effect results, the override sweep, and the as-built sequence of operations. The table is the spine of a controls turnover set.

Common mistakes

• Leaving points in hand or software override after startup, so forced devices defeat the sequence and the redundancy.
• Accepting uncalibrated or drifted sensors, so the economizer, the staging, and the VAV boxes all make decisions on bad readings.
• Testing only the happy path and never driving the sequence through its failure branches.
• Never setting up trends, so there is no record of whether the building held performance over time.
• Leaving integration points unmapped or scaled wrong, so an operator trusts a power or temperature value that is nonsense.
• Accepting a point because the value looked realistic, when the sensor is swapped, reversed, or wired to the wrong unit.
• Skipping the cause-and-effect test, so the fire shutdown and EPO interfaces are never proven across the trades.
• Leaving loops untuned, so they hunt across the operating range even though they passed a five-minute functional test.
• Binding graphics to dead or stale points, so the operator runs the building off a frozen number.
• Taking the controls contractor's word that it was tested instead of running independent point-to-point and witnessing the sequence.

Standards and references

The control sequences come from ASHRAE Guideline 36, High-Performance Sequences of Operation for HVAC Systems, developed by TC 1.4 and written to meet or exceed ASHRAE Standards 90.1 for energy, 62.1 for ventilation, and 55 for thermal comfort. The communication protocol is ANSI/ASHRAE Standard 135, BACnet, also published as ISO 16484-5, with the other common equipment protocol being Modbus, maintained by the Modbus Organization, and LonWorks, standardized as ISO/IEC 14908, still present on older systems. The commissioning process framework is ASHRAE Guideline 0 and ASHRAE Standard 202, covered in the data center commissioning operations overview, and the data center energy standard is ASHRAE 90.4. Confirm the current edition of any of these against the project documents, because the numbers and titles move between cycles.

The cause-and-effect interfaces reach into other codes. Fire alarm initiation and the smoke-control interface fall under NFPA 72 and the building code's smoke-control provisions, the emergency power off and the electrical installation fall under NFPA 70, the NEC, and standby power generation falls under NFPA 110. Commissioning best practice comes from NEBB and the Building Commissioning Association, the BCxA. For data centers chasing an Uptime Institute Tier, the witnessed integrated test and the redundancy demonstrations carry controls evidence into the Tier review.

Above all of these sits the project. The specification and the written sequence of operations, as designed and as built, are what acceptance is measured against. Guideline 36 and the standards give the framework; the project sequence and the contract documents control the actual test.

Terms and acronyms

Controls work carries vocabulary from the BMS side, the protocol side, and the commissioning side, and the same word can read differently across a points list, an integration map, and a sequence narrative. The terms below travel across the whole controls scope.

BMS / BAS / DDC

Building management or automation system, the supervisory layer; direct digital control, the field controllers and logic underneath it

SOO

Sequence of operations, the written definition of setpoints, staging, modes, interlocks, alarms, and failure response the controls must follow

FPT

Functional performance test, the witnessed demonstration that a system performs its sequence under normal and fault conditions

AI / AO / BI / BO

Analog input and output for variable readings and commands; binary input and output for on or off status and commands

Point-to-point

Verifying each physical point one at a time so the field device matches the BMS value and each output moves the right equipment

BACnet

ANSI/ASHRAE Standard 135, the vendor-neutral building automation protocol, with BACnet/IP and MS/TP transports and an object model

Modbus

A register-based protocol common on chillers, meters, and UPS; no built-in object model, so scaling and register maps must be verified

HOA

Hand-off-auto switch; in hand the device runs regardless of the BMS, bypassing the automation, the classic commissioning find

PID / hunting

Proportional-integral-derivative control of modulating outputs; hunting is the oscillation of a mistuned loop around setpoint

EPMS

Electrical power monitoring system, the dedicated platform for power-chain metering and alarms, separate from the BMS

DCIM

Data center infrastructure management, the layer tying facility systems to IT asset, capacity, and power data

COV

Change of value, logging or reporting a point only when it moves past a threshold rather than on a fixed interval

Related tools

Calculators and readiness checks for this work

Compare your options

FAQ

People also ask

• What is commissioning in construction?
• What is bypass airflow in a data center?
• What is a building automation system?
• What is in-row cooling?
• What is a leak detection system in a data center?