Knowledge base

Cross-border DAS and the interoperability problem

Running a driver advisory system across more than one country sounds like a data problem. It mostly is. But the real difficulty is not the formats. It is that every Infrastructure Manager interprets the same standard slightly differently, and each difference can quietly break advice quality.

Published: February 7, 2026

TopicsSFERAInteroperabilityCross-border railUIC 90940RailMLATOInfrastructure managers

Interoperability architecture

One server absorbs many IM differences

Each infrastructure manager implements SFERA slightly differently. The RU-TS handles those differences centrally so a data quirk discovered in live service gets fixed once, server-side, without pushing a new release to every train.

IM traffic servers

IM-TS DE

DB InfraGO

Sends: EBuLa + ZLR

IM-TS BE

Infrabel

Sends: JP + SP (v3), C-DAS-C

IM-TS NL

ProRail

Sends: JP + SP (v2), RelatedTrainInfo

RU Traffic Server

Normalise, aggregate, enrich, correct

Every IM connection is handled here. Per-IM quirks are resolved in one place so that issues found in live service are fixed once, server-side.

Driver trust

Fix in hours, not the months a train release or IM data fix takes.

Normalised

Onboard DAS

One device, every country

Same advisory logic regardless of how many IMs are involved.

Why cross-border rail is growing

  • The EU Green Deal targets transport emissions directly. Short-haul flights under roughly 1 000 km are the clearest substitution opportunity, and rail is the expected replacement on many corridors.
  • Night train services are expanding again. OBB Nightjet is now the largest night train operator in Europe, running across Austria, Germany, Italy, the Netherlands, Belgium, Switzerland, and France. European Sleeper, a newer private operator, launched Brussels to Prague and is planning Amsterdam to Barcelona.
  • Cross-border freight has always required multiple infrastructure managers to cooperate. A container train from Rotterdam to Milan can cross four or five borders in a single trip. That is not new, but the pressure to optimise those journeys with advisory systems is.
  • Automated Train Operation is a political priority at EU level. The investment behind ATO, through programmes such as ERA's System Pillar and SIP-CCS, is accelerating the ecosystem of standardised ground-to-onboard data interfaces. SFERA benefits directly from that momentum.
  • Each new cross-border service means a DAS provider must talk to multiple infrastructure managers simultaneously, each with its own data systems and operational rules.

The pain point: every IM is different

  • SFERA compliance does not mean identical implementations. Each infrastructure manager has its own data timing, message ordering, field interpretations, session startup sequences, and local extensions.
  • A SFERA handshake that works smoothly with one IM does not always behave identically with the next. Subtle differences in when data arrives, how segment boundaries are referenced, or how sessions restart after a disruption can all produce bad advice in the cab.
  • When a driver sees advice that is wrong, late, or missing, they stop following it. Trust breaks fast and rebuilds slowly. That means a data issue left unfixed for weeks is not a technical inconvenience. It is a rollout failure.
  • Historically, DAS suppliers handled this with per-country or per-IM software builds pushed to onboard devices. The train itself had to know about the quirks of each IM it might encounter.
  • Updating onboard software on trains is not quick. A release cycle requires a safety review, a rollout window, and coordination with the operator. In practice, fixes to IM-specific data issues have taken months or longer to reach the fleet through that route.
  • Waiting for the IM to fix the data source is not a realistic option either. Infrastructure managers have their own release cycles, internal priorities, and governance processes. A report from a DAS supplier may not result in a data fix for months, if at all during the deployment window.

The standards landscape

  • SFERA (UIC 90940) is the primary standard for DAS data exchange between ground and onboard systems. It covers journey profiles, segment profiles, train characteristics, C-DAS advice messages, and session lifecycle. It is the most mature and actively deployed standard in this space.
  • ATO specifications (SUBSET-126 and the ETCS ATO profile) define the ground-to-onboard interface for automated train operation. SFERA explicitly builds on this work. As ATO investment grows, the broader ecosystem of standardised interfaces becomes stronger, and DAS benefits from the same infrastructure.
  • RailML is an XML schema family for timetable, infrastructure, and rolling stock data. It is commonly used for offline planning data exchange and is relevant as a source format for DAS journey profile input, though it does not define a live exchange protocol.
  • TAF-TAP (Telematics Application for Freight and Passengers) is an EU-mandated framework for cross-border freight wagon tracking and passenger journey information. It operates at the commercial logistics layer, but it demonstrates the same multi-IM coordination challenge that DAS faces.
  • ERA Technical Specifications for Interoperability (TSIs) provide the legal framework for cross-border rail equipment. DAS is not yet TSI-regulated, but it operates in the same policy environment, and the direction of travel is toward more standardised interfaces.

What SFERA actually does and does not do

  • SFERA defines the message envelope, not the data quality. It tells everyone how to format a Journey Profile, but it does not guarantee the IM has a good one ready when the train needs it.
  • It defines session startup and termination, but does not mandate what happens when the IM system is slower than expected or when a session drops mid-journey.
  • It supports both C-DAS-C advice messages (constant-speed, coasting instructions sent from the ground) and the data needed for C-DAS-O onboard calculation (journey profiles, segment profiles, train characteristics sent so the train can compute its own advice).
  • What it does not solve: data access governance, local field interpretations, timing of data availability, or the non-standard extensions that some IMs add for their own internal systems. These are the gaps where real deployment work happens.

The RU-TS answer

  • The RU-TS (Railway Undertaking Traffic Server) is the server-side component that sits between all infrastructure managers and the onboard device. Every IM connection is handled at this central layer, not at the train.
  • The RU-TS does four things with the data it receives: it normalises, aggregates, enriches, and corrects. Normalisation brings inconsistent field formats into a common model. Aggregation combines data from multiple sources when one alone is incomplete. Enrichment adds context the IM does not provide directly. Correction handles known data quality issues at the source.
  • When an IM changes something, or a new edge case appears in live service, the fix goes into the RU-TS. The onboard device receives a stable, clean interface regardless of what changed upstream.
  • Data issues found in live service can be corrected server-side within hours. That is the timeline that matters for driver trust, not the months that a train release or an IM data fix would take.
  • Issues are still reported back to the IM. The RU-TS is not a way to ignore source problems. But it means the driver does not have to wait for an IM governance process to run its course before getting reliable advice.
  • This is the architectural reason why cross-border operation does not have to mean per-country firmware variants. The complexity stays where it can be managed quickly, in the cloud, not on the train.

Where data issues come from in practice

  • Late or missing journey profile data: the IM system is not ready at departure time, and the train starts its run without a complete profile. The RU-TS can hold or reconstruct from adjacent data to give the driver something usable.
  • Inconsistent segment profile coverage: some track sections are well-described, others are sparse. Enrichment in the RU-TS can fill gaps from alternative sources.
  • Field interpretation gaps: speed unit conventions, segment boundary references, and authority identifiers that differ between IMs even within the same SFERA version. Normalisation resolves these before they reach the train.
  • Session restart edge cases: an IM disconnects mid-journey and reconnects with partial or inconsistent state. The RU-TS handles the reconnection logic without the driver noticing.
  • Multi-IM handoff: the train crosses a border and a new IM session must start while the previous one is still winding down. The RU-TS manages both sessions and keeps a stable interface to the onboard device throughout.
  • In each case, a traditional approach would require a firmware update or an IM data fix, both measured in months. The RU-TS resolves them server-side, measured in hours.

Limits

  • The RU-TS approach handles integration and data normalisation, but it still needs the IM to provide usable data. If an infrastructure manager does not have real-time journey information available, no architecture fixes that.
  • Cross-border operation also requires operational agreements between railway undertakings and infrastructure managers. Those agreements take time and are not a technical problem.
  • The standards, SFERA, RailML, and ATO specifications, are maturing but not universally adopted at the same depth everywhere. Real interoperability is a spectrum, not a checkbox.

Related articles

UIC 90940 SFERARailway DAS and signalling glossaryData sources by country