A railway is a large distributed system with moving assets, shared infrastructure, strict timing, safety constraints and multiple operators. The useful engineering lesson is not to put train control in a web backend; it is to understand coordination, stale data, degraded operation and clear safety boundaries.
European high-speed rail depends on interoperable signaling, radio communication, traffic management, rolling stock and infrastructure. The European Union Agency for Railways describes ERTMS as a harmonized signaling and speed-control system that includes ETCS, railway mobile communications and operating rules. Meanwhile, the new Telematics Applications TSI that entered into force in March 2026 addresses data exchange, APIs, traffic management, passenger information and cybersecurity. These are not one software stack; they are connected systems with different assurance and timing requirements.
This is a systems-design analogy, not railway operational guidance. Safety-related train protection is governed by railway standards and certified components. A general-purpose backend, cloud service or AI model must never be presented as the controller for braking or movement authority.
Think of a timetable as a plan, not ground truth. Train position, infrastructure status and restrictions arrive asynchronously, may be delayed or duplicated, and can conflict across sources. Every update should carry source, observation time, validity interval, sequence/version and confidence or quality metadata. A consumer must know whether it is reading current state, a delayed event or a revised plan.
Different railway data has different deadlines. A passenger display can tolerate a short delay if it labels uncertainty; operational dispatch may require tighter freshness and acknowledgement; safety functions have dedicated deterministic communication and certified behavior. Do not use “real-time” as a vague product promise. Define end-to-end budgets, clock synchronization assumptions, stale-data thresholds and behavior when timing guarantees are missed.
| Data class | Engineering property | Degraded behavior |
|---|---|---|
| Passenger information | Freshness, source attribution, consistent platform/time updates. | Show “estimated” or last confirmed value; avoid inventing precision. |
| Traffic operations | Ordered changes, conflict detection, acknowledgement and audit trail. | Retain a safe known plan, flag uncertainty and require operational review. |
| Infrastructure restriction | Version, validity window, authoritative issuer and propagation status. | Do not silently discard; escalate stale or conflicting restriction data. |
| Safety-related control | Assurance, deterministic limits and approved subsystem behavior. | Follow the certified subsystem’s defined safe/degraded mode, not cloud fallback. |
Operational changes resemble event streams: delay notices, platform changes, restrictions, train handovers and recovery actions. Use immutable event IDs, idempotent consumers, explicit correction events and replayable histories. Keep observed facts separate from forecasts and operator decisions. When sources disagree, preserve both records and route the conflict to a defined authority rather than overwriting one with the latest timestamp.
Distributed state must account for network partitions and cross-border handoffs. A central traffic view can be temporarily incomplete; local operational systems may have newer information. Design ownership and reconciliation rules by data domain. Avoid a single mutable “train status” field that erases provenance and hides why a plan changed.
Rail systems distinguish safety (unacceptable risk to people/environment) from cybersecurity (protection from unauthorized or accidental access, change or loss). A cyber incident can affect safety or availability, but the controls and assurance cases are not identical. Segment operational technology, authenticate data sources, secure maintenance access, manage supplier changes and rehearse incident coordination across infrastructure managers and railway undertakings. Do not assume a successful penetration test proves a safety case, or that a safety approval covers every connected IT service.
For the non-safety operational data layer, I would build a versioned event platform with a canonical train/run identifier, source timestamp, observed-at timestamp, validity window, event sequence, provenance and correction linkage. Consumers would use idempotency keys and schema contracts; a projection service would expose current best-known state with freshness and uncertainty labels. A reconciliation worker would compare schedules with position and infrastructure updates, emit conflicts and create an operator review item.
Service objectives would differ by data product: event delivery delay, projection freshness, conflict resolution time, message loss, duplicate rate and recovery point. Dashboards would show data quality and provenance, not just API uptime. Safety-critical commands and movement authority would remain outside this general platform and within the certified railway control architecture.
Railway operations offer a powerful distributed-systems case study because timing, shared state, interoperability and safe degradation are visible in the real world. Model plans separately from observations, keep provenance and validity on every event, make conflict resolution explicit and test network partitions. Most importantly, keep general IT orchestration distinct from certified safety-related control.
Editorial note: This article is an engineering analogy, not advice for railway operations or safety certification. Consult the applicable TSI, ERA guidance, infrastructure manager and certified railway specialists for real deployments.