Datacenter
Integrated systems test (IST) field guide for data center commissioning
Load the plant to design, drop the utility, script the failures, hold the critical load, and sign the test that lets the IT come in.
Direct answer
An integrated systems test, or IST, is the Level 5 commissioning test that runs the whole power and cooling plant together at design load, then drops the utility and scripts failures to prove the building rides through without dropping the critical load. It is the last gate before IT load, and the commissioning plan controls the scenarios.
Key takeaways
- The integrated systems test (IST) is Level 5 commissioning: it runs the whole power and cooling plant at design load, drops the utility, and scripts failures.
- Run the IST at design load using electrical load banks plus heater load banks in the white space; a no-load test proves almost nothing.
- Cooling ride-through is the hardest part: centrifugal chillers commonly need 4 to 5 minutes to restart, so thermal energy storage must cover the gap while the room stays in band.
- The IST is passed only when the critical bus never drops AND rack inlet temperature stays inside the ASHRAE TC 9.9 allowable envelope through the restart.
- Gate go-live on a complete, continuous IST at design load with every critical deficiency closed and re-tested at load, not on paper.
The integrated systems test, and why it is the marquee test
An integrated systems test is the full-plant test that runs the power and cooling chains together at design load, then puts them through real failures to prove the building holds the critical load when something drops. It is the marquee test of data center commissioning because it is the only one that exercises the whole sequence under a clock and a load at the same time. Every other test proved a piece. The IST proves the pieces work as one machine.
By the time the IST runs, the lower commissioning levels have already passed. The factory tests proved the gear, the installation checks proved it was put in right, and the functional tests proved each system does what its own sequence says. None of that proves the seams. A generator that aces its own load bank and a UPS that holds its own runtime can still fail together, because the failure lives in the handoff: the transfer that takes a half-second too long, the chiller that does not restart in the order the controls expect, the breaker logic that trips a healthy bus. The IST is where those seams get found.
The framing to hold onto is that the IST is the last gate before go-live, not a demonstration. It exists to make the building fail on a scheduled afternoon with the right people watching, instead of at 2 a.m. six months in with live customers on the floor. The pull-the-plug, the failure-scenario script, the cooling ride-through, and how the load banks are sized and staged are covered below. The commissioning levels framework and the program-side mechanics of how all of this is planned and witnessed live in the data center commissioning operations guide, and the standalone generator side lives in the generator acceptance and load bank guide. The subject here is the test itself.
Where the IST sits in the commissioning levels
Most data center programs run commissioning in levels, commonly numbered Level 1 through Level 5, and the integrated systems test is Level 5. The levels are sequential gates that climb from the factory floor to the fully integrated plant, and Level 5 is the top of the ladder because it needs everything below it to be done first. You do not start the IST until the lower levels are signed off, because an unproven piece dropped into a system test is a finding you cannot isolate.
Level 1 is the factory test, where components are proven on the manufacturer's bench before shipment. Level 2 is site receiving, confirming the delivered gear matches the submittal and arrived undamaged. Level 3 is the installation and static check, verifying each system is installed, terminated, and ready to energize. Level 4 is functional testing, where each system energizes and runs its own sequence under normal and fault conditions, often on load banks. Level 5 is the IST, the whole plant together under a simulated failure at design load. Some sites mark the level with a colored tag and call the Level 5 completion the white tag, but tag colors and the exact boundary between levels shift from one program to the next, so the commissioning plan is the authority for what each level includes.
The reason the IST gets its own level is that nothing below it tests interaction. Level 4 can pass every system and the plant can still fail Level 5. That is not a flaw in the lower levels. It is the whole reason Level 5 exists, and it is why schedule pressure that eats the IST window is so much more dangerous than pressure that delays a functional test.
| Level | What it proves | Tested together? |
|---|---|---|
| Level 1 | Components meet spec on the factory bench | No, one component |
| Level 2 | Delivered gear matches submittal, undamaged | No |
| Level 3 | Installed, terminated, ready to energize | No, static |
| Level 4 | Each system runs its own sequence energized | No, one system |
| Level 5 (IST) | All systems ride a simulated failure at design load | Yes, the whole plant |
What is a pull-the-plug test?
A pull-the-plug test is the IST scenario where the utility feed is opened on purpose, with the plant running at load, to simulate a real outage and prove the building rides through it. It goes by a few names on a jobsite: pull-the-plug, black building, blackout test, or loss-of-utility test. They all mean the same thing. You take the normal source away for real and watch what the plant actually does, not what the drawings say it should do.
Here is the sequence the building has to survive in those first seconds. The utility opens and the building goes dark for an instant at the source. The UPS picks up the critical load with no break, carrying it on battery or stored energy through the gap. The generators sense the loss, crank, come up to speed and voltage, parallel if there is more than one, and the transfer scheme moves the load onto generator power. The mechanical plant restarts on generator: the pumps, the air handlers, and the chillers come back in the order the controls sequence them. Through all of it the critical bus never drops and the room temperature stays in band. Then the utility is restored and the plant transfers back, also without a drop.
The thing that makes the pull-the-plug worth more than any tabletop walkthrough is that it has no rehearsal. You cannot fake the transient. The real open contactor, the real battery sag, the real engine accepting block load, the real chiller fighting to restart against a hot loop. A plant that was only ever proven on paper and partial tests has never been proven at all, and the pull-the-plug is the test that says so out loud.
Loading the plant: load banks and the IT load you do not have yet
There are no servers in the building during the IST, so the load has to be manufactured. Load banks stand in for the IT load, and the test runs at the design load the plant was built to carry, not at no-load. On the electrical side, resistive and reactive load banks pull the design kW and kVA from the power chain. On the mechanical side, floor-standing heater load banks placed in the white space dump the same kW of heat the IT racks would, so the cooling plant has a real thermal load to reject and the room has a real temperature to hold.
The two have to run together, and that is the part a thin test skips. Electrical load banks alone prove the power chain can carry the current but tell you nothing about whether the cooling holds when the chillers restart. Heater load banks in the white space are what make the cooling ride-through a real test instead of a control-system animation. A serious IST stages both, matched to the design load and distributed across the floor the way the IT eventually will be, so the thermal map under test resembles the building in operation.
How the banks are sized, the difference between resistive and reactive, the connection and staging, and the wet-stacking concern on the generators are covered in depth in the generator acceptance and load bank guide. For the IST the point is narrower and blunt. If the plant was not loaded to design during the failure scenarios, the test did not prove the building. It sampled a quieter version of it, and the quiet version is not the one that fails.
Why test at full load instead of no-load?
Testing at full load matters because nearly every failure mode the IST is hunting for only appears under load. A no-load or light-load test is comfortable, fast, and close to worthless, because the conditions that break a plant during a real outage are exactly the conditions a light test removes.
Walk the physics. A generator picking up a small block of load comes up easy and the voltage and frequency barely dip. Hand it the full design step and the alternator sags while the regulator catches up and the engine bogs while the governor brings it back to speed, and that is where you find out whether the machine can actually accept the building in the steps the design assumed. The same is true of the thermal side. A lightly loaded room has a slow temperature rise and a generous ride-through, so the cooling can limp back and nothing overheats. Load the room to design and the temperature climbs fast the instant cooling drops, and the ride-through margin you thought you had gets measured in real minutes against a real slope.
The transfer scheme behaves differently under load too. Inrush, the order pieces restart in, the way the bus voltage holds while the mechanical plant restarts and re-loads the generators, none of it shows at no-load. The whole purpose of the IST is to recreate the outage the building will actually see, and the building does not fail empty. It fails full, on a hot day, which is why the test is run full and, where it can be, hot.
The failure-scenario script
The IST runs from a written script of failure scenarios, each one a branch with a defined trigger, an expected response, a timing window, and a pass or fail. The commissioning authority builds the script straight from the sequence of operations and the redundancy claimed on the one-line, and the owner reviews it before the test, because a scenario the owner did not agree is a scenario the owner can argue with later. You do not improvise an IST. You execute a script and record what the plant did against what the script said it should.
The scenarios trace the redundancy the owner is paying for. Loss of utility is the headline. On top of it the script layers the compound failures that prove fault tolerance and concurrent maintenance: a generator that fails to start during the utility event, a UPS module dropped while on generator, a chiller or CRAH unit failed mid-ride, a pump lost, an ATS or static switch transfer, a feeder or breaker opened to prove the alternate path picks up. Each one asks the same question in a different place. When this piece dies, does the redundant piece carry the load without the critical bus or the room temperature leaving its band?
The discipline that separates a real script from a checkbox is that every branch has an explicit expected outcome and a timing window written before the test, and the witness records the actual value against it, signed, at the moment it happens. A scenario watched once in a hurry and ticked off as a block proves almost nothing. Write the script so a stranger could run it and so the results stand on their own when the owner reads them two years later and asks whether the building was ever proven against a double failure.
The cooling ride-through is the part that bites
The cooling ride-through is the window between the power event and the cooling plant being fully back, and holding the room temperature through that window is the hardest part of the IST. Power transfers in seconds. Chillers do not. When the utility drops, a centrifugal chiller cannot just blink back; depending on the machine it needs minutes to restart and re-establish, commonly in the range of 4 to 5 minutes on newer chillers and longer on older ones. The room keeps making heat the whole time. Something has to cover the gap.
The common answer is to put the CRAH fans and the chilled water pumps on the generator or the UPS so air keeps moving and water keeps circulating, then add stored cooling to ride out the chiller restart. That stored cooling is thermal energy storage, a chilled water or ice tank sized to hold the loop temperature for the restart window. The IST proves the math is real. With the heater load banks at design load, you drop the utility and watch the chilled water supply temperature and the rack inlet temperature climb while the chillers are down, and you confirm the stored volume and the restart sequence bring cooling back before the room leaves its band. A TES tank sized on a spreadsheet and never tested at load is an assumption, not a ride-through.
The failure here is quiet and expensive. The power side can ride through perfectly, the generators carrying the whole building, and the room can still cook because the chillers came back a few minutes late against a fast thermal slope at full load. High-density floors make that window tighter, which is its own section below. The rule for the test is simple. The IST is not passed when the lights stay on. It is passed when the lights stay on and the rack inlet temperature never left the allowable envelope through the restart.
The power chain through the transfer
On the power side the IST proves the whole chain from the utility through to the critical bus moves the load between sources without ever dropping it. The chain is the utility, the UPS, the generators, the transfer scheme, and the distribution down to the PDUs and the static switches at the rack. Each link has a job during the transient, and the IST watches the handoffs between them, because that is where the chain breaks.
The critical move is that the UPS bridges the gap the generators cannot. When the utility opens, the generators are not making usable power yet, so the UPS carries the critical load on stored energy for those seconds until the generators are up and the transfer completes. The critical bus must never see a break. On the distribution end, a dual-corded load fed through a static transfer switch should ride a source loss on one cord by drawing from the other without the equipment seeing it, and the IST forces that transfer to confirm the static switch actually catches it. Time every transfer. The transfer that completes but takes longer than the sequence allowed is a finding, not a pass, because the next link downstream was sized around that timing.
What the IST adds over the standalone tests is coordination under a real event. The generator was already accepted on its own load bank and the UPS on its own runtime. Here they have to cooperate: the generators reach the bus before the UPS runs out of stored energy, the transfer scheme sequences the mechanical load back on without overloading the sets, the breakers coordinate so a downstream fault clears without dropping an upstream bus. The detailed power-QA mechanics belong to the broader commissioning scope, and the standalone generator and transfer testing is in the generator acceptance guide. The IST proves they all keep time together.
Watching the temperature through the event
The temperature data is the deliverable that proves the cooling ride-through, so the IST instruments the room before it drops anything. You watch the rack inlet temperature, the room temperature, and the chilled water supply and return across every failure scenario, on a fast enough time base to catch the climb during the gap, not just the steady state before and after. A reading every few minutes shows the calm and misses the excursion, and the excursion is the whole point.
Two numbers come out of it. The peak, meaning how high the hottest rack inlet got while cooling was down, judged against the allowable envelope the design and the ASHRAE thermal guidelines set for the equipment. And the recovery time, meaning how long it took the room to come back into band once cooling restarted. A plant that peaked just inside the envelope and recovered fast rode through. A plant that touched the top of the allowable range on a mild test day will blow past it on a design day, so the margin matters as much as the pass.
The honest read is that the temperature trend is the one piece of IST data an owner can understand at a glance and the one that matters most to the people who will run the floor. Power either held or it did not. Temperature is a curve, and the shape of that curve during the restart is the difference between a building with real thermal ride-through and one that got lucky on a cool afternoon.
The test team, the script discipline, and safety
An IST is run by a multi-trade team under one conductor, and the safety stakes are real because the test deliberately operates live electrical gear through faults at full load. The commissioning authority runs the script and calls the scenarios. The electrical and mechanical contractors, the controls integrator, and the equipment vendors staff the gear and the breakers. The owner and the CxA witness, and on a project chasing Uptime Institute Tier certification the constructed-facility demonstration is witnessed by the Institute, so the IST scenarios often do double duty as the Tier witness.
Run it off an emergency operating procedure, not off memory. Before anyone opens a breaker, the script defines who gives the command to initiate each scenario, who has hands on which gear, what the expected response is, and the abort criteria that stop the test cold and restore the plant if the building does not respond the way the script says. The abort criteria are not optional. A scenario that goes wrong with full load on the line and no agreed way to stop is how a commissioning test becomes an incident.
Treat the live-electrical work as exactly that. The people opening utility breakers and forcing transfers are working on energized gear under the project's electrical safety program, with the arc-flash and lockout discipline that applies, and the test conductor confirms the plant is in a known state before each scenario and restored to a known state after. The owner is watching their building get pushed to its failure points on purpose. The job of the team is to push it to the planned points and not one step past them.
Instrumentation and data capture
The IST stands or falls on its data, so the plant gets instrumented to capture the power, the temperature, and the timing fast enough to see the transient. The building's own systems carry part of it: the electrical power monitoring system, the EPMS, logs the bus voltages, currents, and the transfer events, and the DCIM or building management system trends the room and rack temperatures. Where the permanent systems are too slow or not yet commissioned, temporary data loggers and high-speed power analyzers get added at the points that matter, the transfer switches, the critical bus, and the chilled water loop.
Speed is the whole game on the transient. The block-load voltage and frequency dip when a generator picks up the building, and the chilled water temperature slope during the chiller restart, both happen faster than a once-a-minute log can see. The capture at those points has to be quick enough to record the depth of the dip and the time to recover, because the steady-state values before and after the event prove nothing about whether the plant rode the gap. A slow log of a fast event is a story about the test, not evidence of it.
Time-stamp everything to a common clock. The value of the IST data is the timeline, the sequence of who did what and when across the power and cooling chains, and that only reads as one story if every logger and every system shares a time base. Tie the instrument data to the scripted scenario it belongs to, so the trend that shows the room riding through the second generator failure is filed against that branch and not floating loose in a folder nobody can match to the test.
What happens when the IST finds a deficiency?
When a scenario fails, that is the IST doing its job, and the value of the whole test is finding the deficiency before go-live instead of after. A failed branch gets logged with its data, classified by severity, assigned to the party who owns the fix, and tracked until it is corrected and re-tested. The deficiency log carries it. A finding identified and never closed is a finding still in the building, waiting for the night the utility actually drops.
The step that gets skipped under schedule pressure, and the one that defines a weak test, is the re-test. A failed transfer marked resolved on the strength of a controls change nobody re-ran is not fixed. A chiller restart sequence retuned in software and never proven again at load is a guess. The rule is that a deficiency is closed only when the scenario that found it has been re-run under the same conditions, at load, and passed with the data to show it. Closing on paper is the quiet failure that every real outage later traces back to.
This is where an IST gets expensive in time, and where the schedule has to have room. Fixing a coordination or sequence problem can mean retuning controls, re-staging load banks, and re-running a scenario that takes hours to set up, and the building is not done until the critical findings are closed with re-test evidence. Keeping the finding, its data, the fix, and the re-test result attached to the same record across a multi-party test is exactly the field tracking the tradeos workflow is built to carry, so the closure evidence does not scatter between the integrator, the contractor, and the CxA and leave the owner with a log that looks clean and a plant that is not.
High-density and AI floors shorten the ride-through
High-density racks make the IST timing tighter, because the same cooling gap that was survivable at 5 kW a rack becomes a fast overheat at 50 or 100 kW a rack. AI training and inference floors push rack densities far past the legacy data hall, and the thermal mass of the air in the room no longer buys much time. The temperature slope during a cooling drop is steeper, so the ride-through window shrinks and the chiller restart that was comfortably inside the band on a sparse floor can run late on a dense one.
The test has to be honest about that. Loading the white space with heater load banks at the real high-density design figure, distributed the way the AI racks actually will be, is what exposes the tight window. A test run at a comfortable average density across the floor hides the hotspot that the dense pods create, and the hotspot is where the overheat starts. The cooling ride-through scenario on a high-density floor is less forgiving by physics, so the stored cooling has to be sized for the steeper slope and the IST has to prove it against that slope, not against a gentler one.
Liquid cooling changes the picture again on the densest floors, because direct-to-chip and immersion shift where the heat goes and how fast it builds, but the principle of the test does not move. Whatever cooling the design relies on, the IST loads it to the real density and drops the power to prove the temperature holds through the restart. The denser the floor, the less slack the test has to give, and the more the recovery time, not just the peak, decides the pass.
Testing the worst case, not the test-day weather
The cooling has to ride through on the hottest day the site will ever see, so the IST has to confront the design-day condition even when it runs on a mild afternoon. A pull-the-plug that passes at 60 degrees F outside tells you little about the same event at the design wet-bulb in August, when the heat rejection is hardest and the chiller restart fights the most. The weather on test day is not the test condition. The design day is.
There are a few honest ways to deal with it. The strongest is to schedule the heaviest cooling scenarios into the worst-case season when the ambient cooperates, so the plant is proven against real heat. Where the schedule cannot wait for summer, the test loads the cooling plant to its design heat rejection with the load banks and accounts for the ambient difference, and the CxA records that the test was run below design ambient and notes what that means for the margin. What you do not do is run a cool-day test, watch it pass with room to spare, and call the building proven for August. The margin you saw is not the margin you will have.
This is the seasonal case for the IST itself, separate from the ongoing seasonal and post-occupancy testing that the commissioning operations guide covers as its own level. The point at acceptance is to make sure the one number that matters, whether the room stays in band through a cooling gap at design heat, was proven against the worst case and not against the convenient one.
Can you run an IST on a live data center?
Running a true pull-the-plug on a live, occupied data center is possible, and it is genuinely risky, so it is done rarely and only with extreme care. The argument for it is real. The only way to know the redundancy still works is to test it, and a building that has drifted since its acceptance IST, with added load, changed setpoints, and updated firmware, may not ride through the way it did on day one. The argument against it is just as real. You are betting live customer load on the test passing.
When it is done on a live facility, the planning is heavier than a new-build IST in every respect. The scenarios are reviewed harder, the abort criteria are tighter, the team rehearses the recovery, and the test is often staged in pieces with the ability to fall back at each step rather than dropping the whole building at once. Some operators will only run the live test on one redundant path at a time, proving the alternate carries the load before touching the other, so a failure during the test does not take the floor down. The owner, not the contractor, owns that risk decision, because the owner is the one whose customers are on the line.
The blunt version is that a new building gets the full pull-the-plug because it is empty and the time to find the failure is now. A live building gets the test only when the owner has decided the risk of testing is smaller than the risk of not knowing, and even then it gets the most conservative version that still proves the point. If you cannot accept the chance the plant fails the test, you are not ready to run it live, and that is a real and defensible position.
The periodic re-test that keeps it proven
An IST proves the building once, on acceptance day, and a data center does not stay the way it was on acceptance day. Racks get added, loads grow, cooling setpoints get nudged, firmware gets pushed, and breakers and timers get touched during maintenance. The redundancy that rode through clean at turnover slowly stops matching the building as it actually runs, and the only way to know it still works is to prove it again on a defined interval.
The strong operators treat the acceptance IST as the baseline and re-run a version of it periodically, often annually or on a cycle the owner sets, to confirm the plant still rides through after a year of changes. The periodic test does not have to be the full new-build script every time, but it does have to include the pull-the-plug at load, because that is the scenario that cannot be inferred from component checks. A program that tests every component monthly and never re-runs the integrated failure has proven the parts and not the whole.
This is the ongoing-commissioning side of the IST, and it ties to the maintenance program the systems manual hands the owner, covered in the commissioning operations guide. The framing to keep is that the IST is not a one-time event that happens before go-live and is then filed away. It is the baseline a building is held to for its life, and a redundancy claim that has not been demonstrated under a real failure in years is a claim, not a proven capability.
The go-live gate
The IST is the gate that decides whether IT load comes into the building, and the gate is binary in a way most of construction is not. The plant is ready for production load when the integrated systems test has run complete and continuous at design load and every critical deficiency it produced is closed with re-test evidence. Not when the schedule says, and not when the percentage of scripts complete looks good. The gate is the failed-scenario list at zero against a real, finished IST.
The pressure on this gate is enormous, because the IST is the last thing standing between a late project and revenue, and the failure mode is predictable. The test hits a wall partway through, gets broken into pieces to save the night, and the pieces never get strung back into one continuous run. A plant that never had a complete, continuous integrated test has never actually been proven, and an IST that ran in fragments with the failures patched between them is not an IST. That is the result to refuse to sign, no matter what the move-in date wants.
When the gate passes for real, the handoff is clean. The IT load comes in against a building that has been proven to ride through the outage it will eventually see, on a witnessed test with the data to back it. That is the entire purpose of running the test before the servers arrive. The order is not negotiable. Prove the plant, then load it. A building that takes production load before a complete IST is a building running a live experiment with customers as the test subjects.
What to document
The IST record is judged by whether someone two years out can reconstruct what was proven, scenario by scenario, and check each result against what the script required. Capture every branch of the script with its trigger, its expected response, the actual result, the recovery time, and the pass or fail, along with the power and temperature trend data behind each one and who witnessed it. A run with the boxes ticked and no trend data is a story about a test, not evidence of one.
The report rolls those records into something the owner accepts. It states what was tested, which scenarios passed, which failed and were re-tested, what remains open, and the commissioning authority's professional opinion on whether the plant meets the owner's project requirements. The good reports are blunt about the open items, because the owner needs to know exactly what they are accepting at go-live. The report assembles cleanly only when it is built from the field records as the test runs, scenario data captured against its branch in the moment, rather than reconstructed from memory and scattered loggers in the last week before turnover.
The table below is the spine of an IST scenario record. Each row is one failure scenario, and the set of them is the proof the building rode through.
| Scenario | Expected response | Result | Recovery time | Pass/fail |
|---|---|---|---|---|
| Utility loss (pull-the-plug) | UPS holds critical bus, gens start and accept load, no critical drop | Record actual bus behavior and transfer time | Time to gens carrying full load | Pass / fail |
| Generator fails during event | Remaining gens carry load, critical bus holds | Record bus and load on remaining sets | Time to stable on remaining gens | Pass / fail |
| UPS module loss on generator | Redundant module carries load, no critical drop | Record critical bus continuity | N/A if no drop | Pass / fail |
| Chiller/CRAH unit fail mid-ride | Backup cooling holds room in band | Record peak rack inlet temperature | Time room returns to band | Pass / fail |
| Cooling ride-through (chiller restart) | Stored cooling covers gap, temp stays in envelope | Record peak chilled water and rack inlet temp | Time chillers fully restored | Pass / fail |
| ATS / static switch transfer | Load transfers without equipment seeing a break | Record transfer time and any drop | Transfer completion time | Pass / fail |
| Pump or feeder loss | Redundant path picks up, no loss of flow or bus | Record flow and bus continuity | Time alternate path stable | Pass / fail |
| Return to utility | Plant retransfers without dropping critical bus | Record retransfer behavior | Retransfer completion time | Pass / fail |
Common mistakes
- Running the IST at no-load or partial load instead of the design load the plant was built for.
- Skipping the real pull-the-plug and proving the transfer only by tabletop or controls simulation.
- Proving the power ride-through but never running the cooling ride-through at load with heater banks in the white space.
- Running the scenarios without a written script, defined timing windows, and abort criteria.
- Logging the steady-state values too slowly to capture the block-load dip and the temperature slope on the transient.
- Closing a failed scenario on a controls or settings change without re-running it at load to prove the fix.
- Breaking a stalled IST into fragments to save the night and never running it complete and continuous.
- Testing on a cool day and calling the cooling proven for the design-day summer condition.
- Loading a high-density floor to a comfortable average and hiding the dense-pod hotspot.
- Taking production IT load into the building before a complete IST passed with critical findings closed.
Field checklist
Want this checklist to run itself on every job — with photo proof and a signed record crews can hand the customer? That's FieldOS.
Standards and references
The IST sits inside the commissioning process framework, which comes from ASHRAE Guideline 0, the commissioning process, and ASHRAE Standard 202, which carry the process into an ANSI standard and put the owner's project requirements at the front. The IST is the integrated test that the commissioning plan defines, and the plan and the project specification, not a generic standard, set the actual scenarios, the load, and the acceptance criteria for a given building. Confirm the current edition of any standard against the project documents, because titles and numbers shift between cycles.
For projects pursuing an Uptime Institute Tier certification, the constructed-facility certification is a witnessed demonstration that the built plant performs to its claimed Tier, so the IST failure scenarios and redundancy demonstrations often serve as both the commissioning test and the Tier witness. The thermal envelope the room has to hold through the ride-through comes from the ASHRAE TC 9.9 thermal guidelines and the equipment's own allowable inlet range. The discipline standards that govern the underlying gear, NETA acceptance testing for the electrical scope, NFPA 110 for the standby power plant, and the IEEE references, are covered in the discipline and generator guides.
Above all of them sit the owner's project requirements, the commissioning plan, and the project specification, which control what the IST has to prove and what counts as a pass. When a standard and the project documents disagree, the stricter controlling document wins, and the commissioning authority writes the script to the requirement, not to a generic template.
Terms and acronyms
The IST carries vocabulary that crosses the power and cooling trades and the commissioning paperwork, and the same word can read differently across a script, a spec, and a Tier document. The terms below are the ones that travel across the whole test.
- IST
- Integrated systems test, the Level 5 full-plant test that proves all systems ride a simulated failure together at design load
- Pull-the-plug / black building test
- The IST scenario where the utility is opened on purpose at load to simulate a real outage and prove ride-through
- Level 5
- The top commissioning level, the integrated systems test, run after Levels 1 through 4 are signed off
- Ride-through
- The window between a power or cooling loss and full recovery, during which the critical load and room temperature must hold
- TES
- Thermal energy storage, a chilled water or ice tank that holds the cooling loop through the chiller restart
- Load bank
- Equipment that creates electrical or thermal load to stand in for the IT load during the test
- CRAH
- Computer room air handler, the chilled-water air mover whose fans are commonly kept on generator or UPS during the gap
- EPMS / DCIM
- Electrical power monitoring system and data center infrastructure management, the systems that log power and temperature during the test
- Static transfer switch
- The device that moves a dual-corded load between sources fast enough that the equipment does not see a break
- Rack inlet temperature
- The air temperature entering the equipment, judged against the ASHRAE TC 9.9 allowable envelope through the ride-through
FAQ
What is an integrated systems test?
An integrated systems test, or IST, is the data center commissioning test that runs the whole power and cooling plant together at design load and puts it through scripted failures to prove the systems keep the critical load up when something drops. It is the only test that exercises the handoffs between systems, where real failures hide.
What is a pull-the-plug test?
A pull-the-plug test, also called a black building or blackout test, opens the utility feed on purpose while the plant runs at load to simulate a real outage. The UPS holds the critical bus, the generators start and take the load, and the cooling restarts on generator, all proven for real rather than on paper.
What is Level 5 commissioning?
Level 5 is the top data center commissioning level, the integrated systems test, where every system is run together through a simulated failure at design load. It comes after Level 1 factory tests, Level 2 receiving, Level 3 installation, and Level 4 functional testing. The lower levels prove each piece alone; Level 5 proves they work as one.
Why test a data center at full load instead of no-load?
Most failure modes only appear under load. A generator picking up the full design step sags and bogs in a way a light load never shows, and a fully loaded room heats fast when cooling drops while a light one rides easy. The building fails full and hot, so the IST is run full and, where possible, hot.
What failure scenarios are in an IST?
The script covers utility loss, then compound failures that prove redundancy: a generator failing to start during the event, a UPS module dropped on generator, a chiller or pump lost mid-ride, an ATS or static switch transfer, and a feeder or breaker opened. Each asks whether the redundant path holds without dropping the bus or the room temperature.
What is cooling ride-through in a data center?
Cooling ride-through is the window between a power loss and the chillers being fully back, often several minutes, during which the room keeps making heat. CRAH fans and chilled water pumps on generator or UPS keep air and water moving, and thermal energy storage covers the gap until the chillers restart and the room stays in band.
Does the IST gate go-live for a data center?
Yes. IT production load should not come into the building until the IST has run complete and continuous at design load and every critical deficiency it found is closed with re-test evidence. An IST broken into fragments to save schedule, or patched and never re-run as one continuous test, has not actually proven the plant.
Can you run a pull-the-plug test on a live data center?
It is possible and risky, so it is done rarely and only with the owner accepting the risk. Live tests are staged in pieces with tight abort criteria, often proving one redundant path at a time so a failure does not take the floor down. If you cannot accept the plant failing, you are not ready to test it live.
How do high-density and AI racks change the IST?
Higher rack densities shorten the cooling ride-through, because a gap survivable at low density becomes a fast overheat at 50 or 100 kW a rack. The temperature slope is steeper, so the stored cooling must be sized for it and the IST has to load the white space to the real density to expose the tight window.
What happens when the IST finds a problem?
Finding problems before go-live is the point of the IST. A failed scenario is logged, classified, assigned, and fixed, then the scenario is re-run at load to confirm the fix. A deficiency closed on a controls change without a re-test is not closed, and the building is not done until the critical findings pass again with data.
People also ask
Codes cited in this guide
This guide is written and reviewed against the published standards below. Always confirm the current adopted edition with the authority having jurisdiction.