BBU and the generator: ride-through versus bridging

A standby generator and a rack battery are usually drawn on the same single-line diagram, which makes them look like alternatives. They are not. One waits for a machine to start; the other covers the wait. Get the boundary between those two duties wrong and you buy battery capacity you will never use, or a generator that trips on its first block load.

Two different jobs, often confused

Ride-through is surviving the transfer itself. Its duration is milliseconds to a few seconds, and its success condition is that no node loses state: no GPU context flushed, no BMC reboot, no PCIe retrain, no training step lost. Bridging is holding the load until another source actually carries it - minutes, not milliseconds, and a planned quantity rather than a race.

A rack BBU does the first unconditionally, because the transfer is solid-state and there is no AC conversion stage in the bridge path. It does the second only up to a defined window: the energy you paid for divided by the load you are carrying. That window is a specification, not a property of the chemistry. The distinction matters at the procurement table, because a vendor quoting "minutes" without naming the kW at which those minutes hold has quoted nothing.

A generator does neither. It produces power after it has started, reached rated voltage and frequency, synchronised where a synchroniser is used, and been connected to the load. Until that sequence completes, the generator is not a source. It is a machine with a crank cycle.

Our published position is deliberately narrow: a rack BBU is distributed DC backup at rack or node level that bridges the bus in under a millisecond and carries the load until generators or the UPS pick up. Coverage follows the rack, not the room. Nothing in that sentence claims the BBU replaces the generator, and nothing in it lets the generator replace the bridge.

There is an asymmetry worth putting in front of your operations team. A battery that has just bridged a transfer is typically back inside its readiness band within the recharge window, tens of minutes at most on the VB-5125. A generator that has just carried a load for two hours needs refuelling, checks and cool-down before it is a dependable source again. Backup layers are not interchangeable, and their recovery times are not comparable quantities.

The timeline of a grid loss

The sequence below is the part of the design most often hand-waved. The bands marked typical are field practice at that facility class, not published product figures; only the battery transfer rows are quoted product numbers. Confirm every band against your own switchgear and generator commissioning data before you size anything.

StepEdge roomColocation hallLarge AI campusBasis
Utility loss detection10-20 ms10-20 ms20-50 mstypical
Transfer to battery<1 ms<1 ms<2 ms (HV shelf)published
Generator start signal and crank1-3 s2-5 s5-15 stypical
Voltage and frequency in tolerance3-8 s5-12 s10-25 stypical
Synchronising to the busnot used5-20 s15-45 stypical
ATS or switchgear transfer and load pickup8-15 s10-25 s20-60 stypical
Return transfer to utility5-15 min10-30 min15-45 mintypical
Battery recharge to readiness bandtens of minutestens of minutestens of minutesoperational

Read the table by column, not by row. The bridge window is the distance from the transfer-to-battery row to the load-pickup row at your facility class. In an edge room that is 8-15 seconds. On an AI campus with a synchroniser, a 60-second window is not pessimistic; it is ordinary. And a first crank that fails adds another crank cycle, commonly 8-15 seconds, before the sequence restarts.

The load-step caution sits at the end of that sequence. When the ATS finally transfers, it transfers a block: chillers, pumps, air handlers and the IT load appear at once. A single step load above the generator's step-load capability produces a voltage dip and a frequency sag on pickup, and in the worst case an over-current trip that drops the load again. This is precisely the moment an operator wants the battery to still be online. A bridge that opened its contactor at the end of a nominal 30-second timer, before pickup was confirmed, has removed the cushion at the only instant it was needed.

Sizing the bridge window, not the outage

The arithmetic is one line: bridge energy equals bridged load multiplied by the transfer window, with margin. Worked example. A 60 kW rack load with a 90-second worst-case window covering generator crank, stabilise and transfer, plus one failed first crank attempt:

Worked calculation

60 kW x 90 s / 3600 = 1.5 kWh delivered. A VB-5125 shelf holds 5.12 kWh nominal; at 80% depth of discharge the usable figure is 5.12 x 0.8 = 4.096 kWh. One shelf covers 1.5 kWh with 2.6 kWh unused. Two shelves give N+1 and extend the same 60 kW load to 2 x 4.096 / 60 x 3600 = 491 s, which is why the second shelf buys coverage rather than redundancy alone.

Extend the same method across the window and load range you actually expect. Shelf counts below assume 4.096 kWh usable per VB-5125 shelf and are rounded up, since a fractional shelf cannot be installed.

Window40 kW60 kW80 kW
30 s0.33 kWh - 1 shelf0.50 kWh - 1 shelf0.67 kWh - 1 shelf
60 s0.67 kWh - 1 shelf1.00 kWh - 1 shelf1.33 kWh - 1 shelf
90 s1.00 kWh - 1 shelf1.50 kWh - 1 shelf2.00 kWh - 1 shelf
120 s1.33 kWh - 1 shelf2.00 kWh - 1 shelf2.67 kWh - 1 shelf
300 s3.33 kWh - 1 shelf5.00 kWh - 2 shelves6.67 kWh - 2 shelves

Two structural limits sit on top of the energy arithmetic. First, up to 15 shelves run as one group on one supervised bus; 15 shelves move roughly 77 kW, which is a sensible ceiling for an 80kW-class bay. A 300-second window at 80 kW needs 6.67 kWh, and a 15-shelf group holds 15 x 4.096 = 61.4 kWh usable, so energy is not the binding constraint - bus group count is. Second, the current limit binds before the energy limit on short windows: one VB-5125 delivers 100 A continuous at 1C on a 51.2 V bus, about 5.12 kW, with 200 A peak for 10 s. Fifteen shelves in parallel are what turn that into a bay-scale bridge, and the current sharing across the group is the thing to verify in test data rather than assume.

Sizing the battery for the full outage is a different project, and usually the wrong one. A 60 kW load for four hours is 240 kWh - roughly 59 shelves on the usable figure above, against the 15-shelf group limit, and it would need a room, thermal management and a replacement budget of its own. That is the generator's job. A battery bought to do it duplicates a source you already paid for and have to maintain either way.

Where the two overlap - and why that overlap is useful

The overlap is the transfer window itself, and it is deliberate rather than accidental. The battery covers the interval in which the generator is not yet a source. Because that interval is covered, the generator can be specified and maintained for steady-state load instead of instantaneous step response - a materially smaller machine, and one that is not being asked to accept a cold block load in its first seconds of life. On retrofit projects this is often the difference between keeping the existing generator and replacing it.

  • Generator maintenance windows. A planned service outage no longer has to be carried by a room UPS and its own battery string. The rack bridge covers the load through the maintenance transfer and back, which is a routine event rather than an emergency one.
  • Peak shaving. Because the bridge can supply part of a load step, the generator does not have to be sized for the highest transient the site can present. Sizing for a smoothed load profile rather than a worst-case step can mean a smaller machine, less fuel storage and less floor space.
  • Load-bank and transfer testing. A periodic transfer test is a real interruption at the load. With a bridge in front of it, the test stops being a scheduled risk to the IT load and becomes a maintenance activity - which is how it should have been treated all along.

None of these overlaps enlarge the battery's duty. They all sit inside the same window, which is why the energy figure in the previous section barely moves when you add them.

Where they do NOT overlap

This is the boundary that most often gets blurred in a kickoff meeting, so it is worth writing into the scope document.

  • Mechanical plant is outside the bridge. A rack-level DC bridge covers the IT and control load on a DC bus. Chillers, pumps, cooling towers and large air handlers sit outside it, on AC, and are the generator's problem. A liquid-cooled AI hall whose CDU pumps are not on the generator is a hall that will overheat while its GPUs stay powered.
  • Life safety is not a battery's role. A BBU is not a fire or life-safety supply and is not a substitute for the code-required emergency system. Emergency lighting, fire pump and egress systems have their own codes, their own listing paths and their own maintenance regimes.
  • Hours are not a bridge target. A BBU does not carry an outage for hours. Every hour of coverage is linear cost, and it competes for rack space with the equipment you are trying to protect.
  • Interconnect is a siting problem. A bridge does not resolve a utility interconnect or capacity queue constraint. US interconnection queues hold over 2,060 GW; that is a siting and contracting constraint, not a component issue, and no shelf count changes it.

Coordinating the controls

The electrical design is the easy half. The handover is where projects actually fail, and it is a controls problem.

  • One trigger, two actions. Generator start should be asserted on the same bus excursion that triggers the bridge - the same detection threshold, the same timestamp. If the generator only gets its start signal from the ATS after the transfer, you have serialised two events that should have started together and stretched the bridge window by seconds you did not budget.
  • A defined order. Bridge first, generator start confirmation second, transfer third. Write it down and test it in that order, because firmware default orders vary and a transfer-first sequence is the failure mode described above.
  • An anti-reclose or re-transfer delay. The generator must be stable before load returns. Coordinate that delay with the governor and synchroniser settings so a second excursion during stabilisation does not produce a second transfer inside the same minute.
  • A defined return path. When the source is restored, the battery recharges from it and the group returns to bridge-ready. Readiness is a state the BMS reports, not an inference from a green lamp: the telemetry layer publishes SOC, SOH and per-group state, and the group is not ready until the BMS says it is.
  • One event log. The excursion and the transfer must resolve to the same timestamp in the same log, or post-event review becomes archaeology across three systems that disagree by hundreds of milliseconds. The bridge architecture logs every event for exactly this reason.

Two cautions on the same theme. First, two devices must not fight over the same bus: if a room UPS and a rack bridge both try to hold the DC bus during the same window, the result is circulating current and confused status, not redundancy. Decide which layer owns the bus at which point in the sequence. Second, ATS logic that transfers before the generator is within its voltage and frequency limits asks the battery to cover two events in one minute - the original gap and the failed pickup - which is the sizing case almost nobody models and the one that empties a marginal battery.

Key takeaway

The generator waits for a machine to start. The battery covers the wait. Size the battery on the worst observed transfer window, not on a published start time, and size the generator on steady-state load rather than on the step it will see at pickup. Buy hours of battery only if the outage is the design case - usually it is not.

Four coordination failures worth designing out

  • Bridging sized on the generator's published start time rather than the worst observed window. Published start times describe a warm machine under favourable conditions. Commissioning logs, cold starts and a failed first crank do not obey them. Fix: size on the worst case including one failed first crank, and take the window from your own commissioning records rather than the generator data sheet.
  • State of charge allowed to sit low because the bus is "protected by the generator". When the generator is treated as the primary defence, battery readiness decays quietly: maintenance discharges, an incomplete recharge after a test, a string left offline. Fix: alarm on the readiness band and block maintenance actions below it, so a battery cannot be taken out of service without a recorded reason.
  • ATS transfer before the generator has stabilised. The battery is then asked to cover the original gap and a failed pickup inside the same minute, which frequently exceeds a window sized on a single event. Fix: coordinate the transfer delay with the governor and synchroniser settings, and verify the delay with a live transfer test rather than a settings review.
  • Return transfer that drops the battery without a recharge cycle. The site looks normal and is not: a second event an hour later finds the battery at reduced SOC. Fix: verify recharge completion in the event log, by timestamp, rather than by assuming that a closed contactor means a full battery.

How this maps to tiers and to the UPS question

Seen as three layers, the division is clean. A room UPS carries the whole room through a short outage and needs its own battery replacement cycle on a fixed schedule. A generator carries a long outage for whatever it is sized to feed, at the cost of a start sequence and a fuel supply. A rack BBU closes the millisecond gap in front of both, at the load - and the phrase "at the load" is the whole argument.

A room-level UPS sits in a power room, behind switchgear, busway and one or more conversion stages. Whatever it does to the bus, the rack's own DC conversion stage still sees a transient, and a transient that reaches the silicon is the event that loses state. A distributed BBU follows the rack instead of the room: the bridge happens on the bus that feeds the servers, so the transfer is invisible to them. That is the difference between a UPS that is electrically upstream and a bridge that is electrically adjacent.

This is also why the generator/BBU question and the UPS/BBU question have different answers. The generator is a duration layer and the battery is a continuity layer; they interlock, and neither substitutes for the other. A UPS and a rack BBU are both continuity layers, which means they overlap - and overlapping layers need an ownership rule rather than a diagram that shows both.

What to put in the RFQ

Five inputs turn this article into a quote. Send them and the shelf count, the group configuration and the telemetry mapping are determined rather than negotiated.

  • Measured load. kW per rack or per node, measured rather than nameplate, with the load step the rack can present on pickup.
  • Worst-case transfer window. Seconds, taken from commissioning records, including one failed first crank attempt.
  • Generator start and transfer sequence. What asserts the start, in what order the bridge, start confirmation and transfer occur, and the existing anti-reclose or re-transfer delay.
  • Mechanical load boundary. Which loads are on the generator and which sit behind the DC bridge, so the scope document and the single-line diagram agree.
  • Destination market. Because it sets the compliance path and the shipping documents: UN 38.3 tested cells with the Test Summary on request, packs designed and tested to IEC 62619:2022, the UL 1973 certification path through accredited labs for North America, CE marking with a DoC available under LVD 2014/35/EU and EMC 2014/30/EU for the EU, and Class 9 lithium transport documentation for the shipment itself.

Send those five and you get a shelf count with the arithmetic attached, a group configuration inside the 15-shelf supervised bus limit, and a bridge window quoted in seconds at a named load rather than in minutes at an unnamed one.

Sources

  • Uptime Institute — Annual Outage Analysis 2026 (outage cost distribution)
  • LBNL — “Queued Up” interconnection queue data (over 2,060 GW of active requests)
  • NVIDIA Developer Blog — 800 VDC architecture for Kyber-generation racks; GTC 2025 800V sidecar demonstration

Send us your worst-case transfer window.

Give us the measured rack load in kW and the seconds between utility loss and confirmed load pickup, and we will return the shelf count and the group configuration with the arithmetic shown.