openrailassociation/osrd

Purpose and system entry points

OSRD is a railway infrastructure design, capacity-analysis, timetabling, simulation, and short-notice path-request platform. The browser application starts at front/src/index.tsx; its principal backend is the Rust Editoast service at editoast/src/main.rs. Simulation and pathfinding execute in the JVM Core worker, whose application entry point is core/src/main/java/fr/sncf/osrd/App.java. Deployment-facing ingress/auth proxy starts at gateway/src/main.rs.

Web client and user workflows

The TypeScript/React frontend provides separate operational domains: infrastructure editing, operational studies/timetables, rolling-stock editing, and STDCM requests. Key application roots are front/src/applications/editor/Editor.tsx, front/src/applications/operationalStudies/views/Scenario/ScenarioView.tsx, and front/src/applications/stdcm/StdcmView.tsx. It calls generated/API clients under front/src/common/api/, displays map layers and simulation visualizations, and maintains shared client state through front/src/store/index.ts.

Editoast: persistence and HTTP domain API

Editoast is the system-of-record API for infrastructure, rolling stock, projects/studies/scenarios, train schedules, timetables, search environments, and map-ready generated data. Routing and middleware live in editoast/src/views/server/router.rs and editoast/src/views/server/middlewares.rs; domain endpoints are organized in editoast/src/views/infra/, editoast/src/views/timetable/, and editoast/src/views/operational_studies/. Rust models and database mappings are centered in editoast/editoast_models/src/, with schema evolution in editoast/migrations/.

Simulation and railway computation core

The Gradle Java/Kotlin Core service owns computational semantics rather than business persistence. It exposes worker/API operations for standalone simulation, path properties, signal projection, conflict detection, ETCS braking, block pathfinding, and STDCM; representative endpoint boundaries are core/src/main/kotlin/fr/sncf/osrd/api/standalone_sim/SimulationEndpoint.kt, core/src/main/kotlin/fr/sncf/osrd/api/pathfinding/PathfindingBlocksEndpoint.kt, and core/src/main/kotlin/fr/sncf/osrd/api/stdcm/STDCMEndpoint.kt. The underlying physics uses speed/distance-time envelopes in core/envelope-sim/ and train/path representations in core/kt-osrd-path/.

Infrastructure, signaling, and routing pipeline

RailJSON is the shared railway-data model: schema types reside in core/osrd-railjson/src/main/java/fr/sncf/osrd/railjson/schema/infra/, while parsing and construction lead into simulation infrastructure abstractions under core/kt-osrd-sim-infra/src/main/kotlin/fr/sncf/osrd/sim_infra/. Signaling has a generic simulator in core/kt-osrd-signaling/src/main/kotlin/fr/sncf/osrd/signaling/ and SNCF-specific BAL/BAPR/ETCS/TVM implementations in core/kt-osrd-sncf-signaling/src/main/kotlin/fr/sncf/osrd/signaling/. Core pathfinding builds constrained graph searches through core/src/main/kotlin/fr/sncf/osrd/pathfinding/Pathfinding.kt.

Timetable conflicts and short-term capacity

Conflict detection converts simulated requirements into spacing/resource occupancies and incrementally detects conflicts; its main boundary is core/src/main/kotlin/fr/sncf/osrd/conflicts/IncrementalConflictDetector.kt. STDCM performs time-aware path search against timetable availability, combining graph exploration, block simulation, delay/backtracking, and post-processing in core/src/main/kotlin/fr/sncf/osrd/stdcm/graph/STDCMPathfinding.kt and core/src/main/kotlin/fr/sncf/osrd/stdcm/graph/STDCMSimulations.kt. Editoast prepares persisted timetable/scenario inputs and delegates computation through editoast/core_client/src/.

Runtime topology and external services

The gateway authenticates and proxies external requests; its auth providers include bearer and OIDC implementations under gateway/actix_auth/src/providers/. Editoast delegates Core work through message-queue clients (editoast/core_client/src/mq_client.rs); Core workers are provisioned/scaled by Osrdyne, whose queue controller and Docker/Kubernetes drivers are in osrdyne/src/queue_controller.rs and osrdyne/src/drivers/. Local and chart deployments define PostgreSQL/PostGIS persistence, RabbitMQ, Valkey cache, OpenFGA authorization, S3-compatible storage, and Jaeger telemetry in docker-compose.yml and chart/templates/.