Base de connaissances

DAS transfrontalier et le probleme d interoperabilite

Faire fonctionner un Driver Advisory System dans plus d un pays ressemble a un probleme de donnees. C est surtout le cas. Mais la vraie difficulte n est pas les formats. C est que chaque gestionnaire d infrastructure interprete le meme standard de facon legerement differente, et chaque difference peut silencieusement degrader la qualite du conseil.

Publie: 7 février 2026

ThemesSFERAInteroperabiliteFerroviaire transfrontalierUIC 90940RailMLATOGestionnaires d infrastructure

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.

Pourquoi le ferroviaire transfrontalier se developpe

  • Le Green Deal de l UE vise directement les emissions du transport. Les vols court-courriers de moins d environ 1 000 km sont la substitution la plus evidente, et le rail est le remplacement attendu sur de nombreux corridors.
  • Les services de trains de nuit se developpent a nouveau. L OEBB Nightjet est aujourd hui le plus grand operateur de trains de nuit d Europe, circulant a travers l Autriche, l Allemagne, l Italie, les Pays-Bas, la Belgique, la Suisse et la France. European Sleeper, un operateur prive plus recent, a lance Bruxelles-Prague et prevoit Amsterdam-Barcelone.
  • Le fret transfrontalier a toujours exige la cooperation de plusieurs gestionnaires d infrastructure. Un train de conteneurs de Rotterdam a Milan peut franchir quatre ou cinq frontieres en un seul trajet. Ce n est pas nouveau, mais la pression pour optimiser ces trajets avec des systemes advisory l est.
  • L exploitation automatisee des trains est une priorite politique au niveau de l UE. L investissement derriere l ATO, via des programmes comme le System Pillar de l ERA et SIP-CCS, accelere l ecosysteme d interfaces de donnees sol-bord standardisees. SFERA en beneficie directement.
  • Chaque nouveau service transfrontalier signifie qu un fournisseur DAS doit dialoguer avec plusieurs gestionnaires d infrastructure simultanement, chacun avec ses propres systemes de donnees et regles d exploitation.

Le point de douleur : chaque GI est different

  • La conformite SFERA ne signifie pas des implementations identiques. Chaque gestionnaire d infrastructure a son propre timing de donnees, son ordre des messages, ses interpretations de champs, ses sequences de demarrage de session et ses extensions locales.
  • Un handshake SFERA qui se deroule sans accroc avec un GI ne se comporte pas toujours de facon identique avec le suivant. Des differences subtiles dans le moment ou les donnees arrivent, la facon dont les limites de segment sont referencees, ou la maniere dont les sessions redemarrent apres une perturbation peuvent toutes produire un mauvais conseil en cabine.
  • Quand un conducteur voit un conseil faux, tardif ou manquant, il cesse de le suivre. La confiance se brise vite et se reconstruit lentement. Un probleme de donnees laisse non resolu pendant des semaines n est donc pas un inconvenient technique. C est un echec de deploiement.
  • Historiquement, les fournisseurs DAS geraient cela avec des builds logiciels par pays ou par GI pousses sur les appareils embarques. Le train lui-meme devait connaitre les particularites de chaque GI qu il pouvait rencontrer.
  • Mettre a jour le logiciel embarque sur les trains n est pas rapide. Un cycle de release exige une revue de securite, une fenetre de deploiement et une coordination avec l operateur. En pratique, les corrections de problemes de donnees propres a un GI ont pris des mois ou plus pour atteindre la flotte par cette voie.
  • Attendre que le GI corrige la source de donnees n est pas non plus une option realiste. Les gestionnaires d infrastructure ont leurs propres cycles de release, priorites internes et processus de gouvernance. Un signalement d un fournisseur DAS peut ne donner lieu a une correction qu apres des mois, voire pas du tout pendant la fenetre de deploiement.

Le paysage des standards

  • SFERA (UIC 90940) est le standard principal d echange de donnees DAS entre systemes sol et bord. Il couvre les Journey Profiles, Segment Profiles, Train Characteristics, les messages de conseil C-DAS et le cycle de vie des sessions. C est le standard le plus mature et le plus activement deploye dans ce domaine.
  • Les specifications ATO (SUBSET-126 et le profil ATO ETCS) definissent l interface sol-bord pour l exploitation automatisee des trains. SFERA s appuie explicitement sur ce travail. A mesure que l investissement ATO croit, l ecosysteme plus large d interfaces standardisees se renforce, et le DAS beneficie de la meme infrastructure.
  • RailML est une famille de schemas XML pour les donnees d horaires, d infrastructure et de materiel roulant. Il est couramment utilise pour l echange de donnees de planification hors ligne et est pertinent comme format source pour l entree Journey Profile du DAS, mais il ne definit pas de protocole d echange en direct.
  • TAF-TAP (Telematics Application for Freight and Passengers) est un cadre impose par l UE pour le suivi transfrontalier des wagons de fret et l information voyageurs. Il agit a la couche logistique commerciale, mais il illustre le meme defi de coordination multi-GI que le DAS.
  • Les Specifications Techniques d Interoperabilite (STI) de l ERA fournissent le cadre legal pour les equipements ferroviaires transfrontaliers. Le DAS n est pas encore regule par les STI, mais il evolue dans le meme environnement politique, et la tendance va vers des interfaces plus standardisees.

Ce que SFERA fait reellement et ce qu il ne fait pas

  • SFERA definit l enveloppe du message, pas la qualite des donnees. Il indique a tous comment formater un Journey Profile, mais ne garantit pas que le GI en ait un bon pret quand le train en a besoin.
  • Il definit le demarrage et la fin de session, mais n impose pas ce qui se passe quand le systeme du GI est plus lent que prevu ou quand une session tombe en cours de trajet.
  • Il prend en charge a la fois les messages de conseil C-DAS-C (instructions de vitesse constante et de marche sur l erre envoyees du sol) et les donnees necessaires au calcul C-DAS-O a bord (Journey Profiles, Segment Profiles, Train Characteristics envoyes pour que le train calcule son propre conseil).
  • Ce qu il ne resout pas : la gouvernance d acces aux donnees, les interpretations de champs locales, le timing de disponibilite des donnees, ou les extensions non standard que certains GI ajoutent pour leurs systemes internes. Ce sont les ecarts ou se fait le vrai travail de deploiement.

La reponse du RU-TS

  • Le RU-TS (Railway Undertaking Traffic Server) est le composant cote serveur qui se place entre tous les gestionnaires d infrastructure et l appareil embarque. Chaque connexion GI est geree a cette couche centrale, pas au train.
  • Le RU-TS fait quatre choses avec les donnees recues : normaliser, agreger, enrichir et corriger. La normalisation amene des formats de champs incoherents dans un modele commun. L agregation combine des donnees de plusieurs sources quand une seule est incomplete. L enrichissement ajoute le contexte que le GI ne fournit pas directement. La correction traite les problemes connus de qualite de donnees a la source.
  • Quand un GI change quelque chose, ou qu un nouveau cas limite apparait en service reel, la correction va dans le RU-TS. L appareil embarque recoit une interface stable et propre, quel que soit le changement en amont.
  • Les problemes de donnees trouves en service reel peuvent etre corriges cote serveur en quelques heures. C est l echelle de temps qui compte pour la confiance des conducteurs, pas les mois qu exigeraient une release de train ou une correction de donnees du GI.
  • Les problemes sont tout de meme signales au GI. Le RU-TS n est pas un moyen d ignorer les problemes a la source. Mais cela signifie que le conducteur n a pas a attendre la fin d un processus de gouvernance du GI pour obtenir un conseil fiable.
  • C est la raison architecturale pour laquelle l exploitation transfrontaliere n a pas a signifier des variantes de firmware par pays. La complexite reste la ou elle peut etre geree vite, dans le cloud, pas dans le train.

D ou viennent les problemes de donnees en pratique

  • Donnees de Journey Profile tardives ou manquantes : le systeme du GI n est pas pret a l heure de depart, et le train commence son parcours sans profil complet. Le RU-TS peut le conserver ou le reconstruire a partir de donnees adjacentes pour donner au conducteur quelque chose d utilisable.
  • Couverture incoherente des Segment Profiles : certaines sections sont bien decrites, d autres clairsemees. L enrichissement dans le RU-TS peut combler les ecarts a partir de sources alternatives.
  • Ecarts d interpretation des champs : conventions d unites de vitesse, references aux limites de segment et identifiants d autorisation qui different entre GI meme au sein de la meme version SFERA. La normalisation les resout avant qu ils n atteignent le train.
  • Cas limites de redemarrage de session : un GI se deconnecte en cours de trajet et se reconnecte avec un etat partiel ou incoherent. Le RU-TS gere la logique de reconnexion sans que le conducteur ne s en apercoive.
  • Passage multi-GI : le train franchit une frontiere et une nouvelle session GI doit demarrer pendant que la precedente s acheve. Le RU-TS gere les deux sessions et garde une interface stable vers l appareil embarque tout du long.
  • Dans chaque cas, une approche classique exigerait une mise a jour de firmware ou une correction de donnees du GI, toutes deux mesurees en mois. Le RU-TS les resout cote serveur, en heures.

Limites

  • L approche RU-TS gere l integration et la normalisation des donnees, mais elle a toujours besoin que le GI fournisse des donnees utilisables. Si un gestionnaire d infrastructure n a pas d information de trajet en temps reel disponible, aucune architecture n y remedie.
  • L exploitation transfrontaliere exige aussi des accords operationnels entre entreprises ferroviaires et gestionnaires d infrastructure. Ces accords prennent du temps et ne sont pas un probleme technique.
  • Les standards, SFERA, RailML et specifications ATO, murissent mais ne sont pas adoptes partout a la meme profondeur. La vraie interoperabilite est un spectre, pas une case a cocher.

Articles lies

UIC 90940 SFERAGlossaire ferroviaire DAS et signalisationSources de donnees par pays