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:
- Model the network in RSCAD: sources, lines, transformers, CTs and CVTs with saturation, and the converters of interest in a small time-step subnetwork.
- 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.
- 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.
- 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.
- 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.
| Δt | Switching frequency | Steps per period (N) | Duty resolution (~1/N) | Verdict |
|---|---|---|---|---|
| 50 µs | 2 kHz | 10 | 10% | Unusable for switching detail; fine for average-value models |
| 25 µs | 2 kHz | 20 | 5% | Marginal; needs gate-edge compensation |
| 2 µs | 10 kHz | 50 | 2% | Typical small-step VSC territory |
| 1 µs | 20 kHz | 50 | 2% | Same ratio at double the frequency |
| 250 ns | 20 kHz | 200 | 0.5% | FPGA territory; ripple and dead-time effects visible |
| 250 ns | 100 kHz | 40 | 2.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.
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.
| RTDS | OPAL-RT | Typhoon HIL | |
|---|---|---|---|
| Lineage | Manitoba HVDC Research Centre; first real-time digital HVDC simulation in 1989; now part of AMETEK | Montréal; RT-LAB built around Simulink. HYPERSIM began at Hydro-Québec's IREQ in 1996 and was commercialized with OPAL-RT from 2012 | Built around power electronics controller testing on FPGAs, extended toward microgrids |
| Compute | Custom NovaCor 2.0 chassis on IBM POWER9; 1–10 licensed cores per chassis; multi-chassis via Global Bus Hub | Commercial 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-step | Mainstep typically 25–50 µs | HYPERSIM CPU EMT 5–100 µs; phasor (ePHASORSIM) 1–10 ms | Typically 250 ns (HIL606); Typhoon's docs cite 4 µs for an IEEE 13-node feeder on one core |
| Small time-step | Substep below 10 µs (typically 1–3 µs) as an integer fraction of the Mainstep | eHS 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 resolution | Predictive switching in small-step converter models; Universal Converter Model quoted into the hundreds of kHz | Up to 625 ps oversampling (eHS) | 3.5 ns gate drive signal oversampling (HIL606) |
| Modeling environment | RSCAD FX, proprietary component library; PSCAD-RSCAD co-simulation in non-real-time mode | Simulink (RT-LAB) or HYPERSIM; eHS imports circuits from Simscape, PLECS, PSIM | Typhoon Schematic Editor; Python API |
| Large-network approach | Multiple network solutions per chassis; Superstep for less critical regions | Automatic task mapping across CPU cores; state-space nodal (SSN) decoupling | Split across cores with coupling elements (ideal transformer or TLM) |
| Protocols | GTNETv3: IEC 61850 SV/GOOSE (incl. 61869-9), DNP3, IEC 60870-5-104, Modbus, C37.118 | IEC 61850, DNP3, Modbus, IEC 60870, C37.118, CAN, EtherCAT | Ethernet, EtherCAT, CAN/CAN FD, RS232, IEC 61850 and others; strong on embedded buses |
| Black-box vendor code | GTSOC: rack-mount FPGA unit for vendor control models | S-functions, FMUs, user FPGA code (RT-XSG) | C functions and DLL-style integration in the schematic |
| Sweet spot | Protection and relay testing, HVDC/FACTS replicas, large transmission EMT | Breadth: power-electronics FPGA plus large-grid CPU, Simulink-centric R&D, PHIL | Converter 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.
RTDS
- RTDS Technologies FAQs ↗RTDS
Time-step ranges, core scaling, switching-frequency claims, and the site-license model, straight from the vendor.
- RTDS Simulator hardware and I/O ↗RTDS
NovaCor 2.0, the GTIO card family, GTNETv3 protocol list, and GTSOC for black-box vendor controls.
- Small time-step VSC models on the RTDS: R vs L/C switching ↗IPST 2017
Frequency-scan comparison of resistive and L/C switch models. Read before you trust a converter's harmonics.
- Case study: Caithness–Moray HVDC replicas ↗RTDS / National HVDC Centre
Factory tests on real cubicles, then the same tests on replicas that now live in a utility-side lab.
- Case study: Johan Sverdrup multi-vendor HVDC ↗RTDS / RTE International
Two HVDC vendors and a power management system tested together before they met offshore.
OPAL-RT
- HYPERSIM ↗OPAL-RT
CPU and FPGA time-step ranges, network size, the MMC solver, and the protocol list.
- eHS FPGA solver ↗OPAL-RT
Per-FPGA capacity (128 switches, ~344 states), oversampling, and supported circuit editors.
- Switches for EMT studies (HYPERSIM documentation) ↗OPAL-RT
A clear vendor explanation of constant-conductance (ADC) switching and its virtual losses.
- Hydro-Québec and OPAL-RT form a long-term alliance to commercialize HYPERSIM ↗Newswire · 2012
Where HYPERSIM came from and why it is strongest on utility-scale networks.
- PV inverter grid support on Hawaiian Electric feeders, tested with PHIL ↗NREL · OSTI
Real feeders modeled on OPAL-RT, real inverters on the amplifier. A model of how to do utility PHIL.
Typhoon HIL
- HIL606 specifications ↗Typhoon HIL
25 ns minimum step, 3.5 ns gate oversampling, and the I/O counts that make it a firmware test bench.
- Is there a need for circuit partitioning? ↗Typhoon HIL documentation
Converter weights, the six-contactor-per-core limit, and the 4 µs to 1 µs partitioning example.
- 2026.1 software highlights: UltraCore solver ↗Typhoon HIL
The single-FPGA-clock DC-DC solver for dual active bridges and resonant converters.
- Duke Energy case study ↗Typhoon HIL · 2021
A utility's microgrid integration lab and why open-loop Simulink was not enough.
Independent and cross-platform
- Cross-Platform Comparison of Standard Power System Components used in Real Time Simulation ↗Azimian, Adhikari, Vanfretti, Hooshyar · MSCPES 2019
OPAL-RT OP4520 vs Typhoon HIL603 on identical models: matching steady state, different transients, and why.
- Real-time HIL platform for evaluating commercial microgrid controllers ↗MIT Lincoln Laboratory · TR-1203
The HILLTOP platform and metrics that fed the IEEE P2030.8 microgrid controller test work.
- Lessons learned from hardware-in-the-loop testing of microgrid control systems ↗MIT Lincoln Laboratory and SEL · CIGRE 2017
What actually goes wrong when commercial controllers meet a real-time model.
- Advanced PHIL interface for multi-MW-scale inverter testing ↗NREL · OSTI
Interface algorithms and latency on NREL's 7 MVA controllable grid interface.
- HVDC control replicas: bridging factory and site acceptance testing ↗Hydro-Québec · IPST 2017
A utility's view of why replicas matter for commissioning and for the life of the asset.
- Removing spurious switching losses and chatter with fixed time-steps ↗IPST 2023
Interpolation with half-step backward Euler: the numerical problem every real-time solver has to solve.
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.
