Open Compute from the grid side: busbars, sidecars, and the first ride-through spec

What OCP is (and is not)

OCP is not one standard. It is a foundation, started by Facebook in 2011, that publishes contributed specifications under an open license. A base specification defines an interface several companies agree to build against; a design specification documents one company's implementation of it. Hardware that conforms shows up on the OCP Marketplace, and the working code—firmware, management tools, test suites—lives on GitHub.

The useful mental model for a power engineer: OCP specs are interface agreements between the people who buy the most hardware on earth. They are not IEEE standards and carry no regulatory weight. But when Google, Meta, Microsoft, and NVIDIA sign the same document, it tells you what the equipment at your next interconnection will look like, often two years before it arrives.

The power path, rack to POI

Read the OCP power work as a single path from the chip back to the utility. Each layer has its own specification, and the voltage keeps climbing as rack power does.

The driver is arithmetic. The Mt. Diablo spec frames its own scope as rack power moving “from 33kW to 100's of kW.” At 48 V, a megawatt is more than 20,000 amps of busbar. At ±400 V it is a cable you can actually route. Mt. Diablo pulls the AC-DC conversion, protection, and energy storage out of the IT rack into a neighboring power rack, so the compute rack can stay the same while the power rack scales—and gets swapped—on its own schedule.

Two details worth noticing as a protection engineer. First, Mt. Diablo spends real pages on mid-point grounding of the ±400 VDC bus versus grounding for differential 800 VDC—DC fault detection and clearing in a data hall is a problem the industry has not had at this scale before. Second, it requires that battery backup not be triggered during peak or dynamic loading. The storage is there for the grid, not for the GPUs' bad moods.

Why the grid-side spec exists: three events in Virginia

On July 10, 2024, a lightning arrester failure on a 230 kV line in the Eastern Interconnection produced a normally cleared fault. Nothing at the utility tripped. But the line's reclosing sequence produced several voltage dips in a short window, and data center protection schemes that count voltage disturbances decided the grid was unhealthy and transferred roughly 1,500 MW of load to backup power. Frequency and voltage rose; operators pulled shunt capacitors to bring voltage back. NERC's incident review is short and worth reading in full.

The follow-up is the encouraging part. Data center operators lengthened the time a dip must last to be “counted” and changed how many dips trigger transfer. On April 18, 2026, a fault in the same vicinity with similar characteristics cost only about 500 MW. Then, in July 2026, a customer-initiated load reduction of nearly 4 GW occurred in Virginia; NERC says it is still under analysis. Generation-loss events have Reliability Standards for ride-through. Simultaneous load loss of this size was not something planners were designing for, and every data center on a circuit sees the same disturbance at the same instant—a textbook common-mode failure.

What the OCP disturbance spec actually commits to

The Interface Specification Between Hyperscalers and Utility Grid for Disturbance Performance (v1.0.0, effective September 17, 2026) is authored by Google, Meta, Microsoft, and NVIDIA. It adopts MISO's convention, closely mirrors ERCOT's NOGRR 282, and applies at the POI regardless of connection voltage. Here is the core table:

Summarized from Table 1 of the OCP specification. Read the source before using it in a study.

What a planner should take from it:

• It covers the computational load only—which the spec puts at roughly 70–90% of the facility. Cooling is explicitly exempt. Chillers and pumps sit behind VFDs commonly set per IEEE 1566 (which typically allows shutdown below 0.65 p.u. for over 500 ms), can take minutes rather than seconds to restart, and come from too many OEMs for a firmware fix. ERCOT handles this by subtracting tripped cooling load from the pre-fault baseline. Your dynamic model should have two load components, not one.
• Below 0.5 p.u., it is momentary cessation for loads. Power may go to zero as long as 90% comes back within two seconds. The authors are blunt that true ride-through at 0 p.u. would need more capacitance in every PSU—and the inrush on recovery could then breach current limits that ERCOT and EirGrid impose. Anyone who lived through inverter-based resource momentary cessation will recognize the shape of this tradeoff.
• The fix is mostly PSU firmware. Rack rectifiers can use their own stored energy to hold the curve, but feasibility is OEM- and model-specific. MV-UPS retrofits are described as generally too costly to be practical. The spec also suggests utilities consider SVCs and E-STATCOMs in data center clusters to make the sag shallower in the first place.
• The thing that caused July 2024 is still future work. Counter-based protection schemes, frequency ride-through, rate of change of frequency, phase jump, ramp rates, and forced oscillations are all listed as items for a later version. The spec also asks utilities to standardize transmission reclosing practice, since fast reclosing can look like one long fault to a data center's protection.
• Grandfathering is proposed, not settled. Facilities operating or holding executed interconnection agreements as of an effective date would be exempt for life; only incremental load at existing sites would have to comply. Expect that to be argued over in every jurisdiction that writes its own rule.

The next problem: loads that oscillate on purpose

Ride-through is about faults. The harder long-term issue is normal operation. Large AI training jobs alternate between compute-heavy and communication-heavy phases in lockstep across thousands of GPUs, so the whole facility's demand swings together. Microsoft, OpenAI, and NVIDIA laid this out in Power Stabilization for AI Training Datacenters, along with the mitigation stack: software that fills the idle phases, GPU-level power floors and ramp limits, and energy storage at the rack.

That is the context for the capacitor-bank option in Mt. Diablo and for the OCP 800 VDC work explicitly listing power smoothing alongside power quality as a standards target. It is also why the disturbance spec names forced oscillations as future work. When that version lands, it will be the first time a load-side standards body has told the grid how fast its loads are allowed to move.

Using OCP on an interconnection

If you are on the utility or EOR side of a large-load study, OCP gives you a vocabulary for questions you should already be asking:

• Which rack and power architecture: 48 V ORv3, a ±400 VDC sidecar, or MV-to-DC? It changes the load model.
• Will the computational load meet the OCP disturbance table, and with what PSU firmware revision? Who controls that firmware after commissioning?
• What does the cooling plant do below 0.65 p.u., and how long does it take to come back?
• What are the voltage-disturbance counter settings on the transfer scheme—count window, dip duration, trip count?
• Is there rack- or row-level storage, and is any of it configured for power smoothing rather than backup?

Those answers belong in the study sequence long before commissioning. NERC's large-loads white paper is on our Resources page.