Blackstart Labs
blackstart_web
← Blog

Field notes · October 2026

Real-time simulation in practice: RTDS testing, time-steps, and how it compares to OPAL-RT and Typhoon HIL

Offline EMT tells you what a design should do. Real-time simulation tells you what a real relay, a real HVDC controller, or a real inverter firmware build actually does when the network around it misbehaves. This is a practitioner's guide: how RTDS testing is set up, how to pick and defend a time-step, where switching models lie to you, what published projects found, and how RTDS stacks up against OPAL-RT and Typhoon HIL.

What “real-time” actually means

A real-time EMT simulator solves the network with a fixed time-step and guarantees each step finishes—model solution, input sampling, output update—before the wall clock advances by that step. There is no catching up. A step that runs long is an overrun, and on a hard real-time platform an overrun is a failed test, not a slow one. Everything that follows is a consequence of that constraint: the step cannot shrink without the model shrinking, and the model cannot grow without more processors or a bigger step.

The point of meeting the constraint is to close the loop with physical equipment:

  • Controller hardware-in-the-loop (C-HIL): a real controller or relay receives low-level signals (±10 V analog, digital gate lines, or IEC 61850 sampled values) and its outputs drive the simulated breakers and converters. No real power flows.
  • Power hardware-in-the-loop (PHIL): a power amplifier turns simulated voltages into real ones at the terminals of a physical inverter, motor, or battery, and measured currents are fed back. NREL, for example, runs a 1.08 MVA grid simulator and a 7 MVA controllable grid interface for this.
  • Replica testing: a permanent copy of a site's control and protection cubicles lives in a lab, wired to a real-time model of the network, for the life of the asset.

An RTDS test bench, end to end

RTDS Technologies grew out of the Manitoba HVDC Research Centre, which produced the first real-time digital HVDC simulation in 1989; the company is now part of AMETEK. Its current hardware is the NovaCor 2.0 chassis, built on a custom-integrated IBM POWER9 processor with one to ten licensed cores, scaled across chassis with a global bus hub. The software is RSCAD FX, licensed per site with unlimited workstations—an unusual model that matters when a whole protection group needs to build cases.

A typical protection or controls bench looks like this:

  1. Model the network in RSCAD: sources, lines, transformers, CTs and CVTs with saturation, and the converters of interest in a small time-step subnetwork.
  2. Map the I/O. GTAO cards produce ±10 V analog signals for amplifiers or low-level relay inputs; GTAI reads analog back; GTDO and GTDI handle digital signals (5–30 V out, 0–50 V in); GTFPI provides dry contacts and breaker status up to 250 Vdc.
  3. Or go digital. GTNETv3 speaks IEC 61850 sampled values and GOOSE (including IEC 61869-9 profiles), DNP3, IEC 60870-5-104, Modbus, and C37.118 synchrophasors. For a digital substation, the relay never sees an analog signal at all.
  4. Bring in black boxes. GTSOC is a rack-mount FPGA unit for vendor converter controls that cannot be shared as source—useful when an inverter OEM will provide a compiled model but not its code.
  5. Automate. Protection testing is statistics: hundreds of fault types, locations, point-on-wave angles, and source strengths. The value of a real-time simulator is mostly in the scripted batch, not the single dramatic run.

Choosing a time-step

Every real-time study starts with the same question: what is the largest step that still represents the physics you care about? Too large and the answer is wrong; too small and the model does not fit. Four constraints usually decide it.

1. Bandwidth of the phenomena

A fixed step Δt cannot represent content above the Nyquist frequency of 1/(2Δt), and the trapezoidal rule used by most EMT solvers distorts frequencies well before that. At 50 µs the Nyquist limit is 10 kHz, which in practice means faithful results to a few kilohertz: plenty for fault transients, protection, and electromechanical behavior, but not for converter switching detail or very fast travelling-wave content. The RTDS Mainstep of 25–50 µs and HYPERSIM's 5–100 µs CPU range both live here.

2. Steps per switching period

For a switched converter, the useful figure is N = 1 / (fsw · Δt), the number of solver steps per switching period. If gate edges can only land on step boundaries, duty-cycle resolution is about 1/N, and the resulting error shows up as spurious low-order harmonics and a noisy DC link.

ΔtSwitching frequencySteps per period (N)Duty resolution (~1/N)Verdict
50 µs2 kHz1010%Unusable for switching detail; fine for average-value models
25 µs2 kHz205%Marginal; needs gate-edge compensation
2 µs10 kHz502%Typical small-step VSC territory
1 µs20 kHz502%Same ratio at double the frequency
250 ns20 kHz2000.5%FPGA territory; ripple and dead-time effects visible
250 ns100 kHz402.5%Wide-bandgap converters push FPGA solvers back to marginal

Illustrative arithmetic, before any sub-step compensation. Real platforms do better than this, as described next.

All three vendors attack the same problem the same way: sample gate signals far faster than the solver step and account for where within the step each edge occurred. Typhoon's HIL606 oversamples gate drive signals at 3.5 ns, and OPAL-RT's eHS quotes oversampling down to 625 ps. RTDS combines predictive switching with its Substep environment and quotes converter switching frequencies in the hundreds of kilohertz. This is why a 2 µs step can represent a 10–20 kHz converter well, and why the “minimum time-step” on a datasheet is a less useful number than it looks.

3. Travelling-wave lines and network decoupling

Real-time solvers parallelize by exploiting transmission-line delay. A distributed-parameter (Bergeron) line with travel time τ ≥ Δt decouples the two ends: each side only needs the other's history from a previous step, so the two subnetworks can be solved on different processors. With wave speed near 300,000 km/s, a 50 µs step needs roughly 15 km of overhead line; at 25 µs, roughly 7.5 km. Shorter lines must be PI sections, which couple their ends into one matrix.

When there is no line where you want to split the model, every platform offers an artificial one: RTDS subnetwork interfaces, OPAL-RT's state-space nodal decoupling, and Typhoon's coupling elements based on an ideal transformer or transmission-line model (TLM). Each introduces a one-step delay at the boundary. Place it where that delay is physically harmless—behind a real inductance, not in the middle of a control loop.

4. Matrix size and switch count

Each switching event changes the network admittance matrix. A solver either re-factorizes it, which is exact but costly, or pre-stores the inverses for every switch-state combination, which is fast but grows exponentially with the number of switches. That is why every platform limits switches per subnetwork. Typhoon documents it plainly: cores typically handle converters up to “weight 3,” and the number of ideal contactors is six per core. A microgrid model with many breakers runs into that ceiling long before it runs out of arithmetic.

A worked example

Suppose you are testing a 100 MW battery plant's plant controller against a 230 kV network with a weak-grid case at SCR 2. The plant controller acts in tens of milliseconds, so the transmission network can run at a 50 µs Mainstep. The inverters switch at a few kilohertz, and you care about their current limiting during faults, so model one aggregated inverter in detail in a 2 µs substep (N ≈ 100–250) and the rest as average-value models. Put the subnetwork boundary at the inverter transformer, where the leakage reactance makes the one-step delay harmless. Then confirm the whole case against an offline PSCAD or EMTP run before you trust any real-time result.

Switch models: where real-time EMT lies to you

The way a solver represents an IGBT or a thyristor is the biggest single source of disagreement between platforms—and between a platform and reality.

  • Resistive switching represents a switch as a small or large resistance. It is accurate, but every state change alters the matrix. RTDS pairs it with predictive switching and on-the-fly matrix decomposition so it can avoid artificial losses.
  • L/C or associated discrete circuit (ADC) switching represents an on-switch as a small inductor and an off-switch as a small capacitor, chosen so the conductance seen by the solver never changes. The matrix stays constant, which is why this approach dominates on FPGAs. The price is virtual power loss and small oscillations at each transition. OPAL-RT documents the effect and compensates for it on the FPGA; the IPST 2017 study of RTDS converter models used frequency scans to check how much the L/C approximation distorts a converter's response.
  • Numerical chatter is the third trap. Interrupting an inductor current under the trapezoidal rule produces a sustained, non-physical oscillation. Solvers suppress it with interpolation and a switch to backward Euler for a half step—the subject of the IPST 2023 paper below.
  • Average-value models skip switching entirely. They are the right choice for large networks and controller-level studies, and they run at much larger steps; a 2023 study reported roughly 50 µs for VSC models versus about 10 µs for detailed switching ones.

The practical rule: if your result depends on harmonics, losses, or the exact moment a converter enters current limit, validate the switch model before you trust the result.

Interface latency and PHIL stability

C-HIL loops are forgiving because a controller's own sample time is usually far longer than the simulator's I/O delay. PHIL is not. In the common ideal transformer method, the simulator imposes a voltage through the amplifier and reads back current. Loop stability then depends on the ratio of the simulated network impedance to the hardware impedance, and every microsecond of delay in the DAC, amplifier, and measurement chain erodes the margin. A strong simulated grid (low impedance) in front of a stiff piece of hardware is the classic way to make a PHIL setup oscillate.

The fixes are well understood—damping-impedance interface algorithms, filtering, and a high-speed digital link to the amplifier, as in NREL's work on its 7 MVA interface—but each one changes what the hardware sees. A PHIL report that does not document its interface algorithm and loop delay is incomplete.

Case studies

Caithness–Moray HVDC, Scotland (RTDS)

The Caithness–Moray link—1,200 MW over a 113 km subsea cable, energized in January 2019—was tested in a way that has since become a template. ABB ran factory system tests on the actual control and protection cubicles against an RTDS model, then repeated the same tests on a set of replica cubicles delivered to the National HVDC Centre, which is part of SSEN and funded through Ofgem. The replicas stay connected to a real-time model in closed loop, so control changes can be tried before they reach the live link, and the link's design anticipates growing to three, four, or five terminals. The published case study is short on findings, but the structural point stands: the utility, not just the vendor, now owns a working copy of the controls.

Johan Sverdrup multi-vendor HVDC, Norway (RTDS)

Equinor's Johan Sverdrup field is supplied by two HVDC links from different vendors—a Hitachi Energy VSC link commissioned in 2018 and a Siemens MMC link—feeding an islanded offshore AC system with a Kongsberg power management system sharing load between them. The links were designed with little knowledge of each other, so RTE International tested all three replicas together on an RTDS: converter energization, load shedding and rejection, synchronization by droop alone and through the PMS, onshore and offshore symmetrical and unsymmetrical faults, single-link trips, operation alongside an offshore gas generator, and soft disconnection over a 33 kV cable. The testing led to changes in both the HVDC and PMS controls, and the hardware results matched an offline benchmark built with the vendors' models. Notably, no detailed offline model of the PMS existed—the replica was the only way to test it.

Hydro-Québec, HYPERSIM, and HVDC replicas (OPAL-RT)

HYPERSIM was built by Hydro-Québec's research institute, IREQ, starting in 1996 as an all-digital successor to its hybrid analog-digital simulator, and has been commercialized with OPAL-RT since 2012. Its heritage is large AC/DC networks, and Hydro-Québec's own published work frames replicas as the bridge between factory and site acceptance testing. In France, RTE built a replica facility with Hydro-Québec and OPAL-RT around HYPERSIM to test the controls of the INELFE France–Spain HVDC link for adverse interactions and multi-infeed behavior.

Hawaiian Electric feeders on PHIL (NREL, OPAL-RT)

NREL converted two Hawaiian Electric distribution feeder models to real-time models on OPAL-RT hardware and connected physical PV inverters through a power amplifier to evaluate their grid-support functions on those specific feeders. It is a good template for utility PHIL: real feeder data, real inverters, and a test that answers a question the utility actually had about high-penetration PV.

Microgrid controllers at MIT Lincoln Laboratory

MIT Lincoln Laboratory built HILLTOP, a controller-HIL platform for evaluating commercial microgrid controllers on islanding, short-circuit, and cyber-attack scenarios, and released it as open source. Its test feeder, code-named “Banshee,” became a reference feeder used by IEEE P2030.8, NREL, and universities, and its metrics—fuel consumption, power-flow precision at the point of common coupling, load not served while islanded—are a useful checklist for any microgrid acceptance test. A companion CIGRE paper with SEL collects the lessons learned.

Duke Energy microgrid integration (Typhoon HIL)

Duke Energy's Mount Holly lab used Typhoon HIL to study inverter-based resource fault response in grid-connected and islanded modes, battery behavior through islanding, synchronization, and reconnection, and new control schemes before rollout. Duke's earlier open-loop Simulink models showed “large discrepancies” against real equipment; closing the loop on the actual controllers was the point.

Same model, two simulators (independent)

The most useful paper for anyone comparing platforms is a 2019 study from RPI, Alfred University, and EPRI that built identical models on an OPAL-RT OP4520 and a Typhoon HIL603. Steady-state results agreed closely; a load at 1 µs drew 201,718 W on OPAL-RT and 201,739 W on Typhoon against a theoretical 201,729 W. Transient responses did not agree, and the authors trace that to architecture rather than error. Typhoon runs its circuit solver and its signal-processing blocks at two different rates, so the two models could never be made truly identical. The platforms also decouple networks differently (Typhoon coupling cores versus OPAL-RT's state-space nodal method), and model libraries differ enough that the only fair comparison was to drop to trapezoidal integration on both. Their conclusion: the field needs open model-exchange standards, because a result that depends on the simulator is not yet a result.

RTDS, OPAL-RT, and Typhoon HIL compared

The three platforms come from different problems, and it shows. RTDS started with HVDC and protection on custom hardware. OPAL-RT built on commercial CPUs and FPGAs and grew outward from Simulink, then absorbed Hydro-Québec's grid-scale HYPERSIM. Typhoon's platform is built around power-electronics controller testing on FPGAs and has grown toward microgrids. The table summarizes vendor-published figures as of October 2026.

RTDSOPAL-RTTyphoon HIL
LineageManitoba HVDC Research Centre; first real-time digital HVDC simulation in 1989; now part of AMETEKMontréal; RT-LAB built around Simulink. HYPERSIM began at Hydro-Québec's IREQ in 1996 and was commercialized with OPAL-RT from 2012Built around power electronics controller testing on FPGAs, extended toward microgrids
ComputeCustom NovaCor 2.0 chassis on IBM POWER9; 1–10 licensed cores per chassis; multi-chassis via Global Bus HubCommercial Intel Xeon CPUs plus Xilinx FPGAs (e.g. OP5707XG2: Xeon Gold 8 or 16 cores, Virtex-7 485T)FPGA-centric (HIL606: Zynq UltraScale+ ZU9EG, up to 8 processing cores); multiple units for larger models
Network time-stepMainstep typically 25–50 µsHYPERSIM CPU EMT 5–100 µs; phasor (ePHASORSIM) 1–10 msTypically 250 ns (HIL606); Typhoon's docs cite 4 µs for an IEEE 13-node feeder on one core
Small time-stepSubstep below 10 µs (typically 1–3 µs) as an integer fraction of the MainstepeHS FPGA solver from tens of ns to 4 µs depending on generation and circuit (vendor figures range 32–90 ns minimum)Minimum 25 ns on HIL606; the 2026.1 UltraCore DC-DC solver runs at one FPGA clock (3.5 ns)
Gate-signal resolutionPredictive switching in small-step converter models; Universal Converter Model quoted into the hundreds of kHzUp to 625 ps oversampling (eHS)3.5 ns gate drive signal oversampling (HIL606)
Modeling environmentRSCAD FX, proprietary component library; PSCAD-RSCAD co-simulation in non-real-time modeSimulink (RT-LAB) or HYPERSIM; eHS imports circuits from Simscape, PLECS, PSIMTyphoon Schematic Editor; Python API
Large-network approachMultiple network solutions per chassis; Superstep for less critical regionsAutomatic task mapping across CPU cores; state-space nodal (SSN) decouplingSplit across cores with coupling elements (ideal transformer or TLM)
ProtocolsGTNETv3: IEC 61850 SV/GOOSE (incl. 61869-9), DNP3, IEC 60870-5-104, Modbus, C37.118IEC 61850, DNP3, Modbus, IEC 60870, C37.118, CAN, EtherCATEthernet, EtherCAT, CAN/CAN FD, RS232, IEC 61850 and others; strong on embedded buses
Black-box vendor codeGTSOC: rack-mount FPGA unit for vendor control modelsS-functions, FMUs, user FPGA code (RT-XSG)C functions and DLL-style integration in the schematic
Sweet spotProtection and relay testing, HVDC/FACTS replicas, large transmission EMTBreadth: power-electronics FPGA plus large-grid CPU, Simulink-centric R&D, PHILConverter firmware and microgrid controller C-HIL, fast turnaround

Vendor figures, not benchmarks. Minimum time-steps in particular depend on circuit size, solver generation, and license, and the vendors do not measure them the same way.

How the differences play out

  • Protection engineering favors RTDS. Its relay-test I/O, CT and CVT models, IEC 61850 tooling, and long installed base in utility protection labs make it the default for relay and scheme testing. HYPERSIM is the main alternative at utility scale.
  • Converter firmware favors the FPGA-first platforms. When the device under test is an inverter controller switching at tens of kilohertz, Typhoon's 250 ns-class steps and nanosecond gate sampling, or OPAL-RT's eHS, put the switching physics on the FPGA where it belongs. RTDS covers this with its Substep and converter models, but it is not where the platform was born.
  • Grid-scale EMT with large converter fleets is contested. RTDS (multi-chassis NovaCor) and HYPERSIM (automatic task mapping, MMC solver to 6,000 cells per converter) both target thousands of nodes with detailed HVDC. Typhoon scales by adding units and coupling them, which is more natural for distribution and microgrids than for a bulk transmission system.
  • Workflow matters as much as hardware. Simulink-centric controls teams move fastest on RT-LAB. Utilities with protection departments tend to standardize on RSCAD. Typhoon's schematic-and-Python workflow is the quickest from zero to a running converter test.
  • Models are not portable. As the cross-platform study showed, the same circuit on two simulators gives the same steady state and different transients. Budget for re-validation whenever a model moves between platforms.

Testing IBRs against the new large-load and storage requirements

The industry documents covered in earlier posts lean directly on this kind of testing. NVIDIA's DSX battery qualification allows its IEEE 2800-aligned ride-through test to run on hardware or HIL, and requires runnable EMT models, impedance scans, and weak-grid validation at SCR 2. The OCP disturbance-performance spec rests on rack power supply firmware riding through voltage sags and recovering 90% of load within two seconds. Both are exactly what a C-HIL bench with the real controller, a weak-grid real-time model, and an automated fault sweep is built to prove—and what an offline simulation with a vendor black box cannot.

A pre-test checklist

  • Validate the real-time case against an offline EMT run before connecting any hardware.
  • Document the time-step for every subnetwork and the reasoning behind it, including steps per switching period.
  • Record where the network is decoupled and confirm the boundary delay sits behind physical inductance.
  • Check overrun margins at the worst case—most faults, most switching—not the steady state.
  • Measure end-to-end I/O latency; for PHIL, record the interface algorithm and loop delay.
  • Calibrate analog scaling and confirm CT and VT ratios in the relay match the simulated secondaries.
  • Keep firmware and settings versions of every device under test in the test record.
  • Script the batch. One run is a demonstration; a few hundred is a test.

Open these tabs

Vendor documentation, case studies, and independent papers behind this note. Links open the source directly.

Independent and cross-platform

Educational overview, not a procurement recommendation, and not affiliated with any vendor named. Specifications are vendor-published figures as of October 2026 and change with each hardware and software release; confirm them with the vendor for your configuration.