Typhoon HIL vs RTDS for AI load smoothing: testing the stack from power supply to point of interconnection

Why smoothing is now something you have to prove

Microsoft, OpenAI, and NVIDIA showed in Power Stabilization for AI Training Datacenters that synchronized training jobs concentrate their power oscillation energy between 0.2 and 3 Hz—sub-synchronous, and close to the torsional modes of turbine-generator shafts, which the paper places at around 7 Hz and up. The same paper sketches what a utility specification could look like: a critical frequency range (for example 0.1–20 Hz), a cap on spectral magnitude inside it (for example 20%), plus ramp-rate limits and a dynamic power range.

Requirements are converging on that shape. NVIDIA's DSX battery qualification includes an AI-buffering test with a ≤2% ramp-tracking error at weak and strong grid strengths. The OCP disturbance spec lists ramp rates and forced oscillations as the next things it will standardize. Once a number is in an interconnection agreement, someone has to demonstrate the plant meets it before energization—and the only way to put the real controllers in front of a weak grid and a swinging load beforehand is in the lab.

The smoothing stack you are testing

Smoothing is not one device. It is five layers, each acting on a different timescale and each with different modeling needs:

The top of the table needs nanosecond-to-microsecond converter physics. The bottom needs a transmission network, machines, and hours of state-of-charge history. No single simulator setting covers both, and that is the whole reason this comparison is interesting.

What the best published study tells a test engineer

The most detailed public work on BESS smoothing is PNNL's Communication Delay Robust Control of BESS for AI Training Load Smoothing (September 2026). It models a data center with cooling, IT load, and a 300 MW BESS that combines droop-based grid-forming control with fast compensation driven by the measured load current, and evaluates it in EMT simulation across grid strengths and load profiles. In the base case at SCR 10 with a 10 ms delay and predictor compensation:

Three findings matter more for testing than the headline percentages:

• Communication delay is a first-order effect. The fast loop relies on load-current measurements reaching the BESS controller. PNNL notes that 10 ms is about 216° of phase lag at 60 Hz, which can misalign the compensation entirely; a predictor recovers most of it, but performance still drops between the 4.5–5.5 ms and 19–21 ms cases (weighted broadband reduction 95.9% vs 89.8%). In simulation that delay is a parameter. On a real site it is a network, a protocol stack, and a controller task rate.
• Smoothing can amplify higher frequencies. In the base case, fluctuation content was reduced 95.3% in the 0.1–5 Hz band, but amplified in the 10–30 Hz and 30–60 Hz bands:

From PNNL's Table III. The amplified bands carry little energy in this profile, but they sit right on top of torsional and control-interaction frequencies.

• Grid strength and profile change the answer. PNNL ran grid strengths from SCR 10 down to very weak grids around SCR 1–1.5, and several profiles, including NERC's example AI training profile and a high-frequency one with its dominant component near 5 Hz, where peak-to-peak reduction fell to 68.8%. A test plan that uses one profile at one SCR has not tested smoothing.

All of this was simulation. The obvious next step—putting a real BESS controller, its real communication path, and its real sampling behind the same cases—is a hardware-in-the-loop job.

Requirements for a smoothing test bench

Working back from the stack and the PNNL results, a credible test bench needs to provide:

1. Grid-side bandwidth from 0.1 Hz to at least 60 Hz, resolved cleanly enough to compute band reductions and spot amplification—plus switching-level detail wherever current limiting matters.
2. Weak-grid networks from SCR 1.5 to 20 with X/R from 2 to 10, matching DSX's envelope, and ideally the real collector system and transformers.
3. Real controllers over real links, with the communication delay measured end to end rather than assumed.
4. Load profile playback at millisecond resolution and MW scale—Microsoft's paper notes 100 ms counters are too slow to see 20 Hz swings and calls for 1 ms telemetry.
5. Rack-level detail when firmware is under test: the power supply's PFC and DC-DC stages if you are validating its smoothing or ride-through behavior.
6. Duration from seconds (ramps) to 24 hours (state-of-charge drift).
7. Automated metrics: peak-to-peak and percentile excursions, MW/s ramp rates, FFT band energies, and ramp-tracking error against the commanded profile.

Typhoon HIL for smoothing

Typhoon's architecture is FPGA-first. The HIL606 runs a typical step of 250 ns (25 ns minimum), samples gate drive signals at 3.5 ns, and updates 64 analog outputs at 200 ns. The 2026.1 release added an UltraCore solver that runs DC-DC converters—including dual active bridge and resonant topologies—at a single FPGA clock period, 3.5 ns on HIL606.

Where that pays off for smoothing:

• The rack power supply is a natural Typhoon model. A PSU is a PFC stage feeding a resonant or bridge DC-DC stage, switching at tens to hundreds of kilohertz, with a capacitor bank in between. That is the class of circuit Typhoon's FPGA solvers were built for, and it is the layer where smoothing and ride-through firmware actually live.
• BESS inverter controllers at full switching detail. One or a few inverters with the real controller, real gate signals, and current limiting resolved to sub-microsecond timing is a standard Typhoon bench. The HIL Compatible program means some BESS controllers—Typhoon names EPC Power—already come packaged for it.
• Fast iteration. Schematic-plus-Python automation makes it quick to sweep delays, profiles, and SCR values, and TyphoonSim runs the same model offline with variable steps for long cases.
• Data center focus. Typhoon's data center page explicitly lists UPS, BESS, SST, and generator validation and load variability from AI and HPC workloads.

Where it strains:

• Network scale. Per-core limits are explicit—converters up to “weight 3” and six ideal contactors per core—so a site with many feeders, breakers, and a detailed transmission system has to be partitioned with coupling elements, each adding a one-step boundary delay.
• Bulk-system phenomena. Weak-grid interaction with a detailed transmission network and multiple synchronous machines is possible, but it is not where the platform's strengths are.

RTDS for smoothing

RTDS is network-first. Its Mainstep runs at 25–50 µs on NovaCor 2.0, scales across chassis, and runs power electronics in a Substep below 10 µs (typically 1–3 µs) as an integer fraction of the Mainstep. GTNETv3 handles IEC 61850, DNP3, IEC 60870-5-104, Modbus, and C37.118; GTSOC hosts vendor black-box controls on FPGA.

Where that pays off:

• The grid side of the problem. A transmission network, the 34.5 kV collector system, onsite generation, and the BESS inverters in Substep can all run in one closed-loop case. Weak-grid sweeps and interaction with nearby machines are core RTDS territory.
• Observing the plant like the utility will. Synchrophasor output over C37.118 lets a real PMU or oscillation-monitoring tool watch the simulated point of interconnection, which is how a 0.2–3 Hz issue would actually be detected in service.
• Protection during swings. Large repetitive power swings stress relay logic; RTDS is the usual home of utility relay testing, with IEC 61850 sampled values and GOOSE.
• Long and large runs. NovaCor 2.0's non-real-time mode runs ten times the nodes on the same hardware, which suits 24-hour SOC cases and very large sites when real-time hardware is not needed.
• Event reproduction. RTDS's sponsored data center article describes a test program that reproduced the Virginia large-load-loss event against a power management system with onsite storage.

Where it strains:

• Rack power supply physics. High-frequency resonant DC-DC stages are a stretch for a 1–3 µs Substep. If the device under test is PSU firmware, that layer belongs on an FPGA solver.
• Model detail to confirm. Torsional interaction studies need multi-mass shaft models for the onsite units; confirm the library detail and parameters for your machines before scoping the test.

Head to head, layer by layer

Our assessment from vendor specifications and architecture, not a measured benchmark.

A practical split: two benches, one aggregated model

The cleanest answer for most programs is not to choose. Run two benches that answer different questions and hand one validated model between them:

1. Device bench (Typhoon). Rack PSU and BESS inverter controllers at full switching detail. Verify ramp caps, power floors, capacitor smoothing, current limiting, and ride-through against the real firmware. Extract an aggregated, average-value response for each.
2. Validate the aggregate offline. Compare it against PSCAD, starting from PNNL's open data center model library (grid-level, aggregated, and explicitly not intended for harmonics).
3. System bench (RTDS). Real BESS plant controller and protection, the aggregated load and rack models, onsite generation, and the transmission network. Sweep SCR, X/R, profiles, and delays; record ramp rates, band energies, and PMU-observed oscillations at the point of interconnection.
4. Long-duration runs offline. State-of-charge drift over 24 hours in NovaCor 2.0 non-real-time mode or TyphoonSim, using the same models.

Splitting by question avoids the alternative—linking two simulators in real time through analog I/O or a protocol—which adds its own interface delay to a problem that is already delay-sensitive.

The bottom line

If the device under test is the rack power supply or the inverter firmware, Typhoon's FPGA solvers are the better tool. If the question is what the utility will see—weak-grid interaction, machines, protection, and oscillations at the point of interconnection—RTDS is. Most AI load smoothing programs need both answers. The PNNL results are the warning: the same battery that removes 95% of the 0.1–5 Hz swing can amplify the bands above it, and that only shows up if your test bench can see them.