Poste d'aiguillage

Décrit le fonctionnement du poste d’aiguillage virtuel

Le modèle de simulation définit le rôle et comportement des différents objets simulés au sein d’OSRD.

Cette modélisation est un compromis entre de multiples enjeux:

  • fidélité de la simulation
  • interprétabilité des résultats
  • adaptabilité du modèle à différentes technologies et usages, que cela soit en terme de signalisation, de poste d’aiguillage, ou d’usage des données

En particulier, certaines subtilités propres aux systèmes pratiques ont été sacrifiées sur l’autel de la compatibilité et de l’interprétabilité:

  • un signal doit forcément s’addresser à un train en particulier: les signaux n’ont pas d’aspect par défaut; ils n’existent que pour être vus
  • les itinéraires / routes sont formées à destination d’un train en particulier

Ce document est une description du modèle de fonctionnement cible d’OSRD. Il a pour objectif de renseigner développeurs et experts métiers sur le fonctionnement du simulateur. Des changements y sont apportés au fil de l’évolution du projet.

Ce modèle est en cours d’implémentation

Architecture

flowchart TD
    %%%% NODES

    train[Train]
    %% ↓
    signaling[Signalisation]
    %% ↓
    routing[Routage]
    ordering[Ordonnancement]
    %% ↓
    reservation[Réservation]
    %% ↓
    location[Localisation]
    movable-elements["Éléments mobiles"]

    %%%% EDGES

    train -- réagit à --> signaling
    train -- réclame les itinéraires --> ordering
    ordering -- commande --> routing
    signaling -- observe --> reservation
    routing -- observe et réserve --> reservation
    reservation -- observe --> location
    reservation -- actionne --> movable-elements
    train -- informe --> location

    %%%% CLICKABLE LINKS

    click train href "./train/" _self
    click ordering href "./ordering/" _self
    click signaling href "./signaling/" _self
    click routing href "./routing/" _self
    click reservation href "./reservation/" _self
    click location href "./location/" _self
    click movable-elements href "./movable-elements/" _self

Remerciements

Par ordre alphabétique:

  • Christophe Mémin
  • Djamal Bellebia
  • Gilles Dessagne
  • Nathanaël Dias

1 - Éléments mobiles

Gère l’état des organes de commande des aiguilles, passages à niveau, …

Description

Chaque élément mobile, aiguille ou passage à niveau, a une liste d’états possibles. Ces états sont mutuellement exclusifs.

Dépendances

  • statique une liste d’élements mobiles
  • statique liste des états possibles de chaque élément mobile

Opérations possibles

  • observer un élément mobile
  • verrouiller / déverrouiller un élément mobile
  • bouger un élément mobile

2 - Localisation

Fournit les informations de position des trains sur le réseau

Description

La couche de localisation permet à d’autres modules de simulation de suivre le déplacement du train dans l’infrastructure. L’infrastructure ferroviaire est découpée en régions appelées zones. Quand on train entre dans une zone, ce module permet d’en être notifié.

Les zones (ou TVDSection / DetectionSection) sont des partitions physiques des voies :

  • capables de détecter la présence d’un train

Exigences de conception

  • il doit être possible de suivre les changements d’occupation d’une zone
  • il devra être possible de suivre les déplacements d’un train
  • il devra être possible d’implémenter un système de bloc mobile

Dépendances

  • statique une liste de zones

Opérations

  • Occuper une zone
  • Libérer une zone
  • Observer les changements d’occupation d’une zone

3 - Reservation

Gère l’état de réservation des zones

Description

Les zones (ou TVDSection / DetectionSection) sont des partitions physiques des voies :

  • capables de détecter la présence d’un train
  • qui fournissent un service de réservation à l’usage des routes

Chaque zone a un certain nombre de configurations différentes. Par exemple, une zone sans aiguille aura deux configurations :

  • sens pair
  • sens impair

Une zone avec une aiguille aura 4 configurations possibles :

  • sens pair voie principale
  • sens impair voie principale
  • sens pair voie déviation
  • sens impair voie déviation

Chaque zone ne peut être réservée que pour une configuration donnée à la fois, mais peut être réservée simultanément par plusieurs routes. Une zone ne peut changer de configuration que lorsqu’elle n’est pas réservée.

État dynamique d’une zone

enum ZoneState {
    /// A list of active reservations.
    /// Each reservation requires a particular configuration to be upheld.
    reservations: VecDeque<ZoneReservation>,
}

struct ZoneReservation {
    /// The train which requires this reservation
    train: TrainHandle,
    // The configuration required for this reservation
    requirements: ZoneRequirements,
    /// The state of this reservation
    status: ZoneReservationStatus,
}

enum ZoneReservationStatus {
    /// In the process of being reserved, but not yet ready
    PRE_RESERVED,
    /// The train can arrive anytime
    RESERVED,
    /// The train is inside the zone
    OCCUPIED,
    /// The zone is pending release
    PENDING_RELEASE,
}

struct ZoneRequirements {
    entry: Option<DirDetector>,
    exit: Option<DirDetector>,
    movable_elements: Map<MovableElement, MovableElementConfig>,
}

impl ZoneState {
    /// Get the combined requirements for all the currently active reservations
    fn get_combined_requirements(&self) -> Option<ZoneRequirements> {
        return self.reservations
            .map(|res| &res.requirements)
            .reduce(|a, b| ZoneRequirements::combine(a, b))
    }
}

Exigences de conception

  • Les zones doivent pouvoir être verrouillées dans une configuration particulière.
  • Il doit être possible pour plusieurs routes de partager une réservation de configuration.
  • Il doit être possible d’observer l’évolution de statut d’une réservation.
  • Il doit être possible de faire évoluer le statut d’une réservation.

Dépendances

  • statique les détecteurs qui délimitent chaque zone
  • statique les aiguilles dans chaque zone
  • dynamique capacité d’observer l’occupation des zones
  • dynamique capacité d’actionner les éléments mobiles

Opérations

  • espacement: Observer l’état d’une zone
  • routage: Verrouiller et déverrouiller la zone : permet d’obtenir un droit d’action. Toutes les opérations en écriture nécessitent d’avoir acquis le verrou.
  • routage: Attendre que toutes les réservations d’une zone expirent
  • routage: Pré-réserver une configuration de zone
  • routage: Confirmer la réservation d’une zone
  • routage: Attendre que la réservation de la zone soit occupée par son train
  • routage: Relacher une réservation de zone

4 - Routage

Gère le cycle des routes

Description

  • Les routes ont pour responsabilité d’autoriser le déplacement des trains dans l’infrastructure. Elles doivent se terminer à un point où l’arrêt du train est prévu (en terme de signalisation, pas voyageur).
  • Les routes sont assimilables à des itinéraires, ou à des suites d’itinéraires et d’installations de pleine voie.
  • Les routes n’ont pas de lien direct avec le cantonnement et la signalisation. Elles nourissent des informations sur la disponibilité des voies qui sont utilisées par le cantonnement et la signalisation.
  • Une route est un chemin de détecteur en détecteur. Elle représente une portion de chemin qu’il est sûr pour un train d’emprunter.
  • Les routes ont des points de libération, qui sont des détecteurs qui délimitent quand détruire l’itinéraire, ce qui permet d’implémenter transit souple, rigide, et entre-deux.
  • Une route peut être à nouveau formée alors qu’un train est déjà en train de la parcourir. Cela permet à plusieurs trains de se suivre sur la même route.

Cycle de vie d’une route

Les routes n’ont pas d’état, mais leur commande donne lieu à une suite d’événements systématique :

  • le système commande toutes les routes sur le trajet du train dans l’ordre, sans attendre
    • la commande doit être acceptée par le régulateur
  • lorsque le régulateur accepte la commande, la formation commence
    • le droit d’action de chaque zone de la route est acquis, selon un ordre global
    • en parallèle pour toutes les zones:
      • si la zone n’est pas dans la configuration souhaitée:
        • si elle est déjà réservée, attendre que les réservations expirent
        • sinon, la mettre dans la configuration souhaitée en déplaçant les aiguilles
      • pré-réserver la zone pour le passage du train
      • le droit d’action de la zone est cédé
  • une fois que la formation est terminée, la route est établie
    • pour chaque zone, transformer la pré-réservation du train en réservation
  • dès que la route est établie, un processus de destruction de la route commence
    • pour chaque zone de la route donnant lieu à une libération
      • attendre que le train quitte la zone (que la réservation passe de l’état OCCUPIED à l’état PENDING_RELEASE)
      • libérer la réservation des zones du début de la route jusqu’à la zone actuelle

Exigences de conception

Le système doit, indirectement ou directement:

  • permettre à la signalisation de déterminer si une section de voie est prête à être empruntée.
  • permettre l’ordonnancement des trains selon des critères configurables.
  • permettre la destruction progressive (transit souple) de l’itinéraire après le passage du train.
  • il doit être possible d’avoir plusieurs processus de commande actifs au même moment pour la même route, afin de supporter des trains qui se suivent

Dépendances

  • statique le chemin des routes de détecteur à détecteur

  • statique la position requise des aiguilles, par zone

  • statique les points de libération des zones (qui implémentent le transit souple / rigide)

  • dynamique régulateur soumettre des commandes

  • dynamique réservation acquérir et relacher un droit d’action par zone

  • dynamique réservation attendre que les réservations d’une zone expirent

  • dynamique éléments mobiles déplacer des aiguilles

  • dynamique réservation pré-réserver une zone

  • dynamique réservation promouvoir une pré-réservation en réservation

  • dynamique réservation lors de la destruction de la route, attendre qu’une réservation passe en PENDING_RELEASE

  • dynamique réservation libérer une réservation

Opérations

  • commander une route: démarre un processus asynchrone qui ne se terminera que lorsque la route aura été établie. Un processus de destruction doit démarrer dès que la route est établie.

Notes de conception

Ces notes permettent d’expliquer les décisions qui ont été prises, afin de pouvoir plus aisément les comprendre et évoluer.

Informer la signalisation

Sachant que:

  • il peut y avoir beaucoup de zones partant d’un même point, il est préférable d’éviter de contraindre les signaux à observer une liste de routes
  • il est potentiellement difficile d’associer un état clair à chaque route

Il en ressort plusieurs manières d’informer la signalisation de la navigabilité des voies:

  • soit directement, en faisant observer à la signalisation les points d’entrée des routes. Si plusieurs routes partent du même endroit, elles partageraient un objet entrée:
    • moins de complexité dans la couche de réservation, plus de complexité dans la couche de routage
  • soit indirectement, via la couche de réservation des zones, qui auraient un état supplémentaire pour marquer leur navigabilité:
    • moins de complexité dans la couche de routage, plus de complexité dans la couche de réservation
    • avantage le processus d’activation des routes n’aurait pas besoin d’attendre l’arrivée du train, la couche de réservation s’en occuperait.
    • avantage découplage entre routage et cantonnement / signalisation.

La seconde option a été choisie, car :

  • elle permet d’avoir un couplage moins fort entre la signalisation et les routes.
  • elle évite aussi au processus d’activation des routes d’attendre le passage du train alors que la couche de réservation le fait déjà.

Cycle de vie des routes et état des zones

Plusieurs enjeux motivent le cycle de vie des routes et l’état des zones :

  • d’une part, l’état des zones est au coeur de la détection de conflit : il doit être possible d’extraire d’une simulation d’un train seul ses besoins en ressources
  • d’autre part, il faut qu’une simulation multi-train fonctionne correctement : le temps de déplacement des aiguilles selon la configuration actuellement en place, en particulier, est un point de friction important

5 - Ordonnancement

Décide de l’ordre de formation des itinéraires

Définition

La couche d’ordonnancement a pour responsabilité d’établir l’ordre de commande des itinéraires, et par conséquent, l’ordre de passage des trains. La méthode exacte utilisée pour prendre cette décision n’importe pas, du moment qu’elle garanti que la simulation se termine (elle ne doit pas amener de trains en nez-à-nez, ou créer d’autre cas de figure de blocage).

Il est possible d’implémenter un module d’ordonnancement via des tableaux d’ordre de succession des trains aux aiguilles.

Exigences de conception

  • Il doit être possible de connecter n’importe quel algorithme d’ordonnancement
  • Le module d’ordonnancement doit approuver les commandes de routes.

Opérations

  • train: Des itinéraires sont commandés pour chaque trains, aussi loin et aussi tôt que possible. L’approbation de la commande est soumise au régulateur, qui peut la retarder indéfiniment, selon des critères de son choix.

6 - Train

Représente un train dans la simulation

Description

Les contraintes sur ce qu’est un train sont relativement faibles. Il doit seulement avoir un identifiant, qui permet aux autres systèmes de garder des références vers des trains.

Exigences de conception

  • Les trains occupent les zones.
  • Les trains doivent être suivis pour préserver leur ordre de passage.
  • Les trains ont pour responsabilité de demander les itinéraires devant eux.