Analytical
A railway-aware statistical channel model that runs on any laptop in seconds — deterministic, seeded, and the golden baseline every other engine is cross-checked against. The classroom starts here.
Any hardware · secondsRailTwin‑FRMCS Lab
Rehearse the railway.
Before you build it.
A railway wireless digital twin and FRMCS research laboratory. Model a real corridor, design the radio network, run virtual trains through tunnels and cuttings at speed, break base stations on purpose — and keep every result as a reproducible experiment. One scenario model, selectable simulation engines: analytical, NVIDIA Sionna ray tracing, and NVIDIA Aerial Omniverse Digital Twin.
0guided labs — flagship · fleet · migration · three skies
0engines — incl. an ML surrogate at 0.3 dB vs its teacher
0train mobility, tunnels & Doppler
0reproducible — rerun any evidence package
One scenario model
Plan it once. Simulate it anywhere.
A RailTwin scenario is the whole story in one file: the route with chainage, stations, tunnels and cuttings; the radio plan with sites, sectors and tunnel DAS; the train with its braking curves and dwells; the FRMCS services riding on top; and the failures you want to inject.
Engines are adapters behind that model — swap the physics, keep the experiment. A classroom laptop, a Sionna GPU workstation and an AODT cluster all run the same scenario and produce the same result model, so studies compare across fidelity levels instead of being rebuilt for each tool.
- Railway-native: chainage, track-constrained mobility, portals, cuttings, forest bands, DAS heads and redundant coverage are first-class concepts.
- Radio-true: 3GPP-style sector patterns — parametric, measured, or grid-of-beams beamforming — correlated shadowing, tunnel portal decay, per-train Doppler, A3 handover with RLF.
- Service-aware: emergency voice, ETCS data and CCTV video with priority QoS — latency, loss and continuity per service.
- Evidence-first: every run preserves inputs, versions, seeds and results as a portable package that reruns exactly.
Selectable engines
Four ways to compute the same corridor.
NVIDIA Sionna RT
Site-specific ray tracing: the corridor becomes a 3D electromagnetic scene — terrain, tunnels, ITU materials — and every trace point gets physically computed propagation paths, folded into the shared result model.
GPU ray tracingNVIDIA Aerial Omniverse DT
The scenario exports as an OpenUSD stage — corridor terrain, stations, tunnels, radio units and the whole fleet as time-sampled trains — plus a job manifest for AODT's EM solver and RAN digital twin. Telemetry flows back into the same result model.
OpenUSD · EM/RAN twinML surrogate
Ray-trace a corridor once, train the surrogate on it, then sweep at analytical speed with site-specific physics. Pure NumPy — GPU-trained models run on any classroom laptop, and every model carries its holdout error.
0.3 dB vs its teacher
The OpenUSD substrate
Speaks the language of country-scale rail twins.
Deutsche Bahn's Digitale Schiene Deutschland is building a digital twin of the German rail network on NVIDIA Omniverse — on OpenUSD. RailTwin scenarios export to that same substrate: corridors, stations and rolling-stock motion as a USD stage that any Omniverse pipeline can open, compose and extend.
The division of labour is deliberate. Their twin simulates train operation; ours simulates the FRMCS radio network those trains need — and the wider FRMCS·AI platform operates it. Same substrate, adjacent layer: an operator's rolling-stock and infrastructure assets reference straight into our stage, and our radio scene rides along with theirs.
- Corridor: terrain mesh and track centreline — the same geometry the ray-tracing scene uses, so the visual and EM twins can't drift apart.
- Infrastructure: stations, tunnels and cuttings as chainage-annotated prims, oriented to the track bearing.
- Rolling stock: every fleet train as a time-sampled prim with heading, a placeholder consist and an antenna anchor — swap in real assets via USD referencing.
- Operations: a timetable scope with per-station arrivals and departures, and WGS84 georeferencing for absolute placement.
- Verified: exported stages are validated against a real USD runtime (usd-core) in the test suite.
The flagship labs
Eight experiments every railway asks for.
Guided, seeded and gradable — each lab is one scenario file, one parameter to vary, and an instructor note on what the corridor will teach.
1 · Site spacing
4, 6 or 9 km between masts? Watch redundant-server availability collapse before coverage does — the core FRMCS planning lesson.
2 · Speed vs handover
80 to 350 km/h on the same plan: Doppler scales, handover margins shrink, and time-to-trigger becomes a corridor-specific compromise.
3 · Tunnel continuity
A 1.5 km bore with and without DAS: portal decay, unprotected metres, and what ETCS feels when the mountain closes in.
4 · Site failure
A mast goes dark mid-run. Neighbours bridge the gap — but redundancy over the section is gone. Failure impact is a space-time intersection.
5 · Service priority
Emergency voice, ETCS data and CCTV video share a congested carrier. Capacity pressure lands on the lowest priority first — by design.
7 · GSM-R migration
A staged corridor: FRMCS built out to km 30, GSM-R holding the rest. Dual-radio fallback keeps coverage at 100% through every stage — and shows where RAT churn bites.
8 · Elastic Sky + NTN
A mast dies for twenty minutes; three skies answer. Measured: CCTV availability 87.6% on the ground tier alone, 92.1% with the drone cell, 98.2% with the satellite bonded in.
Yours · Any corridor
Import a real route from GIS, auto-plan the sites, and the same workflow runs your line — from first spacing study to calibrated twin.
One lab, three editions
From classroom to national lab.
| Edition | Audience | Simulation capability |
|---|---|---|
| Classroom | Colleges & teaching laboratories | Guided labs, analytical engine, instructor material — runs on any laptop |
| Core Research | Universities & applied R&D | Sionna RT workflows (GPU workstation), Python SDK, notebooks, batch runs |
| Advanced Digital Twin | Railway institutes & national labs | Core plus integration with NVIDIA Aerial Omniverse Digital Twin — OpenUSD scenes, EM/RAN runs, telemetry |
- The route strip: every result plotted against kilometres of track — tunnels, stations, serving cell, handovers, RSRP, SINR and speed on one railway-native diagram.
- Evidence packages: scenario, versions, seeds, traces, events, KPIs and the report — one portable folder per run.
- Exact reruns: replay any package and the KPIs must match — reproducibility is a release gate, not a hope.
- Five KPI groups: radio, mobility, service, railway-operational and research-quality — comparable across engines.
Evidence, not vibes
Results a thesis — or a tender — can stand on.
Railway engineers reason in kilometres and route sections, so RailTwin reports read like line diagrams, not heatmaps. And because every experiment is seeded and packaged, a student's submission, a researcher's paper and an operator's coverage study can all be re-executed and verified — years later, on different hardware.
RailTwin is a research, teaching and pre-engineering instrument: it evaluates FRMCS-oriented scenarios; it does not certify them. Conformance and safety assurance stay where they belong.
Three skies, rehearsed
The whole coverage story, simulated.
FRMCS.ai's architecture is three radio skies over every kilometre of track — and RailTwin now simulates all three. Elastic Sky drone cells sit dark on their docks until a mast dies; the nearest dock auto-launches, and three minutes later a gNB is serving the failed sector from 120 m, near-line-of-sight, on its own carrier. Above it, the NTN satellite tier bonds in at the service level: packets that fit the bearer ride the sky wherever the ground tiers leave a hole.
The twin already taught us something a slide never would: a co-channel drone cell blankets the corridor with interference from altitude — which is why the model (and the product) gives the aerial tier its own carrier. Rehearse the failure before it happens, and the drone plan is evidence, not a promise.
- Measured ladder on the demo corridor: CCTV availability 87.6% (ground) → 92.1% (+drone) → 98.2% (+satellite, 6% of packets offloaded).
- Auto-launch policy: a site_down failure triggers the nearest dock; launch and landing delays are part of the physics.
- Honest sky: the NTN tier sees open sky only — tunnels and cuttings block it, and the KPIs show exactly where.
- New KPIs: aerial airborne time, NTN visibility and per-service satellite offload — alongside the usual five groups.
LIVE — lab08 replayed: a mast dies, three skies answer
FRMCS·AI, literally
The twin that learns.
Ray-trace a corridor once on the GPU workstation, and RailTwin trains an ML surrogate of that physics: a small network that replays site-specific path loss in milliseconds. Sweeps, optimizers and whole classrooms then run at analytical speed with ray-traced fidelity — and because the surrogate is pure NumPy, a GPU-trained model runs untouched on any laptop. Every model file carries its teacher, its training recipe and its holdout error: a model is evidence, not a mystery.
The same twin is a synthetic data factory. It generates what a live railway never ethically could: thousands of labelled timesteps for handover-prediction models, seeded failure corpora for anomaly detectors, and chainage-anchored scene specs — trespass, obstacle-on-track, pantograph arcing — that Omniverse Replicator renders into labelled imagery. Every dataset ships with a card: schema, seeds, provenance, boundary. And because the twin knows every transmitter, it answers the ISAC question too: which kilometres of track can the network itself sense — a person on the line, radar-equation honest, tunnels excluded.
LIVE — surrogate training vs its teacher
LIVE — the data factory, streaming labels
railtwin surrogate-train
--engine surrogate
dataset handover
dataset anomaly
dataset vision-spec
Omniverse Replicator
beams: N
isac:
docker compose up
Part of the platform
The rehearsal room of the network that thinks.
RailTwin is where FRMCS.ai corridors are born: spacing studies before towers are ordered, tunnel DAS plans before boring finishes, failure drills before the first train runs. The same scenario later drives the live corridor twin in the intelligence layer — and the software-defined 5G lab (our O-RAN gNB, SA core and testers) turns simulated experiments into hardware-in-the-loop ones.
- Plan — corridor, sites, tunnels, services: simulated in RailTwin.
- Prove — the same scenario on Sionna and AODT physics.
- Practice — hardware-in-the-loop with the FRMCS.ai 5G SA stack.
- Operate — the corridor twin goes live in the intelligence layer.
Your corridor, simulated by Friday.
Send us a line diagram — we'll return the route strip: coverage, handovers, tunnel continuity and the site plan to fix them. Universities and railway institutes: ask about the Classroom edition.