Cas d’utilisation dans l’information client

Dans le domaine de l’information à la clientèle des transports publics, il existe différents cas d’utilisation des données.

Description spécifique
Informations supplémentaires

Description spécifique

Retard

On parle de retard lorsqu’un train circule n minutes plus tard que prévu dans l’indicateur. Dans les reportings et les statistiques, 2, 3, 5 et 6 minutes sont évaluées dans le trafic voyageurs comme limite entre l’heure et le retard. Pour les destinations du groupe au sein des CFF, la limite de 3 minutes s’applique. Via la plateforme Open Data TP Suisse, les trains de voyageurs et leurs arrêts commerciaux sont publiés.
Il n’y a pas de minimum interne à l’entreprise, même si les systèmes n’indiquent généralement pas les retards inférieurs à 3 minutes.

L’hystérésis est également importante pour les systèmes d’IA : ce n’est que lorsque le retard change d’une certaine valeur (objectif TP Suisse : 30 secondes) qu’un nouveau message de retard est généré.

Les services VDV431 de la plateforme Open Data disposent de ces informations lorsqu’elles sont fournies par les organisations commerciales.

Dans VDV 431:

<ServiceArrival>
<TimetabledTime>2017-07-19T16:21:00Z</TimetabledTime>
<EstimatedTime>2017-07-19T16:20:00Z</EstimatedTime>
</ServiceArrival>
<ServiceDeparture>
<TimetabledTime>2017-07-19T16:22:00Z</TimetabledTime>
<EstimatedTime>2017-07-19T16:25:00Z</EstimatedTime>
</ServiceDeparture>

</ServiceArrival>

</ServiceDeparture>

Dans VDV431, les retards ne peuvent pas être distingués des prévisions et des temps réels.

Dans GTFS-RT:

     "stop_time_update": [
          {
            "stop_sequence": 5,
            "arrival": {
              "delay": 60
            },
            "departure": {
              <strong>"delay": 60</strong>
            },
            "stop_id": "8506000:0:4",
            "schedule_relationship": "SCHEDULED"
          },

"stop_time_update": [

{

"stop_sequence": 5,

"arrival": {

"delay": 60

"departure": {

"delay": 60

"stop_id": "8506000:0:4",

"schedule_relationship": "SCHEDULED"

Les retards ne peuvent pas être distingués des prévisions et des temps réels dans GTFS-RT.

Données de position

La géoposition exacte du moyen de transport est relevée par différentes organisations commerciales (par exemple au moyen du GPS).

Ces données ne sont pas disponibles dans la plateforme Open Data.

Prévision

Les prévisions sont les heures de circulation futures d’un moyen de transport, calculées à partir de la position actuelle du train. Les conflits et leurs règlements actuels prévus dans les x prochaines minutes sont pris en compte. La suite du pronostic est calculée selon une méthode moins complexe. Toutes les organisations commerciales ne sont pas en mesure de fournir des informations prévisionnelles de qualité. Dans ces cas, le retard est utilisé et mis à jour (c’est-à-dire qu’il est supposé que le retard existant est maintenu).

Les services VDV431 de la plateforme Open Data disposent de ces informations lorsqu’elles sont fournies par les organisations commerciales.

Dans VDV 431:

<ServiceArrival>
<TimetabledTime>2017-07-19T16:21:00Z</TimetabledTime>
<EstimatedTime>2017-07-19T16:20:00Z</EstimatedTime>
</ServiceArrival>
<ServiceDeparture>
<TimetabledTime>2017-07-19T16:22:00Z</TimetabledTime>
<EstimatedTime>2017-07-19T16:25:00Z</EstimatedTime>
</ServiceDeparture>

</ServiceArrival>

</ServiceDeparture>

Dans VDV431, les prévisions ne peuvent pas être distinguées des temps réels et des retards.

Dans GTFS-RT:

     "stop_time_update": [
          {
            "stop_sequence": 5,
            "arrival": {
              "delay": 60
            },
            "departure": {
              <strong>"delay": 60</strong>
            },
            "stop_id": "8506000:0:4",
            "schedule_relationship": "SCHEDULED"
          },

"stop_time_update": [

{

"stop_sequence": 5,

"arrival": {

"delay": 60

"departure": {

"delay": 60

"stop_id": "8506000:0:4",

"schedule_relationship": "SCHEDULED"

Les prévisions ne peuvent pas être distinguées des temps réels et des retards dans GTFS-RT.

Changement de voie/de quai

Le changement de voie entraîne l’arrivée et/ou le départ d’un train sur une voie différente de celle indiquée sur l’affiche (arrivée = affiche blanche, départ = affiche jaune).

Les modifications de voies peuvent également se produire en cascade, notamment en cas de perturbations importantes de l’exploitation.

La communication des changements de voie diffère selon la situation locale et le support:

Dans les gares où les voies ne sont pas publiées (par exemple les gares situées sur des lignes à voie unique sans passage souterrain), la communication des voies est complètement absente. Par conséquent, aucun changement de voie n’est émis ici.
Seule la voie réelle effectivement empruntée est affichée sur les terminaux optiques de la gare (afficheur général, moniteurs) ainsi que sur l’écran de correspondance du véhicule de desserte. Il en va de même pour les indicateurs de voie.
Dans l’horaire en ligne, la voie réelle ainsi qu’un symbole indiquant le changement de voie sont édités.
Le changement de voie est signalé de manière acoustique, selon la situation:
En cas de changement de voie sur les quais avec utilisation alternée des voies (p. ex. Zurich, voies 21/22 et 23/24), il n’y a pas d’annonce. La voie concrète d’une paire de voies n’est une modification de voie que du point de vue des données.
En cas de changement de voie sur le même quai (p. ex. Berne ; voie de consigne 1 ; voie réelle 2), une annonce réduite est faite (p. ex. indication dans le cadre de l’annonce d’arrivée).
Pour les autres changements de voie, lorsque les deux voies ne sont reliées que par un passage souterrain, l’information sur le changement de voie se fait de manière cyclique.

Les services VDV431 de la plateforme Open Data disposent de ces informations lorsqu’elles sont fournies par les organisations commerciales.

Dans VDV 431:

<PlannedBay>
<Text>2</Text>
<Language>DE</Language>
</PlannedBay>
<EstimatedBay> <!-- Gleis als EstimatedBay -->
<Text>3</Text>
<Language>DE</Language>
</EstimatedBay>

</PlannedBay>

</EstimatedBay>

Dans GTFS-RT:

         {
            "stop_sequence": 2,
            "arrival": {
              "delay": 60
            },
            "departure": {
              "delay": 60
            },
            "stop_id": "8501605:0:5",
            "schedule_relationship": "SCHEDULED"
          },

{

"stop_sequence": 2,

"arrival": {

"delay": 60

"departure": {

"delay": 60

"stop_id": "8501605:0:5",

"schedule_relationship": "SCHEDULED"

Temps effectifs

Un temps réel VM (VM signifie ici trajet du moyen de transport) est le moment effectif qu’un moyen de transport en mouvement a, ou a eu, à un point défini. En règle générale, il s’agit de l’heure d’arrivée, de départ ou de passage. Outre l’heure et le , d’autres informations sont pertinentes (par exemple l’identification du trajet en mode de transport). Souvent, on écrit ‘temps réel’ pour le temps réel VM. On distingue le temps réel primaire et le temps réel secondaire.

Temps réel primaire

Le temps réel primaire VM est le temps réel mesuré à un endroit en raison d’un passage. Le temps réel secondaire peut être calculé à partir de ce moment.

Temps réel secondaire

Le temps réel secondaire VM est extrapolé à partir d’un temps réel primaire VM. Par exemple, le passage au signal d’entrée d’une gare est mesuré (= temps réel primaire VM), puis à partir de là, n secondes sont ajoutées pour gagner l’arrêt au quai (= temps réel secondaire VM). C’est nécessaire, car ce dernier temps est généralement beaucoup plus important pour l’entreprise, mais il n’y a pas de chronométrage à cet endroit. Au sens strict, il ne s’agit pas d’un temps réel, mais d’un temps prévisionnel, car il n’est pas déterminé directement, mais extrapolé à partir d’un autre temps.
Le temps réel secondaire est donc toujours accompagné d’un temps réel primaire d’un point précédent. Dès que le temps réel primaire est établi, le temps réel secondaire VM peut être calculé sur la base de celui-ci.
Entre-temps, on essaie d’obtenir des informations encore meilleures pour l’information des clients, en partie à l’aide de certains événements sur les véhicules : ouverture effective des portes, fermeture effective des portes.
Plus d’informations sur les données réelles de la plateforme open data sont disponibles ici.

Dans VDV 431:

<ServiceArrival>
<TimetabledTime>2017-07-19T16:21:00Z</TimetabledTime>
<EstimatedTime>2017-07-19T16:20:00Z</EstimatedTime>
</ServiceArrival>
<ServiceDeparture>
<TimetabledTime>2017-07-19T16:22:00Z</TimetabledTime>
<EstimatedTime>2017-07-19T16:25:00Z</EstimatedTime>
</ServiceDeparture>

</ServiceArrival>

</ServiceDeparture>

Dans VDV431, les temps réels ne peuvent pas être distingués des prévisions et des retards.

Dans GTFS-RT:

         {
            "stop_sequence": 2,
            "arrival": {
              "delay": 60
            },
            "departure": {
              "delay": 60
            },
            "stop_id": "8501605:0:5",
            <strong>"schedule_relationship": "SCHEDULED</strong>"
          },

{

"stop_sequence": 2,

"arrival": {

"delay": 60

"departure": {

"delay": 60

"stop_id": "8501605:0:5",

"schedule_relationship": "SCHEDULED"

Les temps réels ne peuvent pas être distingués des prévisions et des retards dans GTFS-RT.

Information sur les événements

Un événement peut être une action planifiée ou non planifiée, signalée, sur l’exploitation, qui a de fortes chances d’entraîner des perturbations des installations, des véhicules et des écarts primaires. Un événement fait en outre l’objet d’interventions de planification et est créé et clôturé par le gestionnaire dans le processus. Il se manifeste tout d’abord par la limitation de l’infrastructure sur la ligne et les nœuds ainsi que dans le nœud lui-même en raison de ruptures de connexion et de pannes.

Une annonce d’événement est alors l’information donnée aux voyageurs sur les événements prévus ou imprévus qui affectent les trains et/ou les correspondances.
Les événements planifiés sont par exemple des manifestations connues à l’avance (manifestations sportives ou musicales, expositions, fêtes, etc.)
En revanche, les événements non planifiés sont par exemple des manifestations organisées à court terme, des accidents, des phénomènes naturels, etc.

La plateforme Open Data ne dispose pour l’instant d’aucune information sur les événements.

Défaillance

Une panne désigne l’annulation / la suppression de trains.

Les services VDV431 de la plateforme Open Data disposent des informations sur les pannes, là où elles ont été livrées par les organisations commerciales.

Dans VDV 431:

<Service>
...
  <Cancelled>true</Cancelled>
</Service>

...

</Service>

Dans GTFS-RT:

 {
 "id": "4.TA.1-28-j17-1.2.H",
 "trip_update": {
 "trip": {
 "trip_id": "4.TA.1-28-j17-1.2.H",
 "start_time": "18:04:00",
 "start_date": "20170719",
"schedule_relationship": "CANCELED",
 "route_id": "1-28-j17-1"
 }

{

"id": "4.TA.1-28-j17-1.2.H",

"trip_update": {

"trip": {

"trip_id": "4.TA.1-28-j17-1.2.H",

"start_time": "18:04:00",

"start_date": "20170719",

"schedule_relationship": "CANCELED",

"route_id": "1-28-j17-1"

}

Suppression partielle

En cas de panne partielle, le moyen de transport tombe en panne sur une partie du parcours VM.

Dans VDV 431:

<ThisCall>
  <CallAtStop>
  ...
    <NotServicedStop>true</NotServicedStop>
  </CallAtStop>
</ThisCall>

...

</CallAtStop>

</ThisCall>

Dans GTFS-RT:

{
  "stop_sequence":7,
  "arrival":{"delay":0},
  "departure":{"delay":0},
  "stop_id":"8505213:0:2",
  "schedule_relationship":"SKIPPED"},
...

{

"stop_sequence":7,

"arrival":{"delay":0},

"departure":{"delay":0},

"stop_id":"8505213:0:2",

"schedule_relationship":"SKIPPED"},

...

Disposition

Correspond à des trajets supplémentaires qui n’étaient pas prévus dans l’horaire.

Les services VDV431 de la plateforme Open Data disposent de ces informations lorsqu’elles sont fournies par les organisations commerciales.

Dans VDV 431:

<Service>
...
  <Unplanned>true</Unplanned>
</Service>

...

</Service>

Dans GTFS-RT:

    {
      "id": "4.TA.1-28-j17-1.2.H",
      "trip_update": {
        "trip": {
          "trip_id": "4.TA.1-28-j17-1.2.H",
          "start_time": "18:04:00",
          "start_date": "20170719",
         <strong> "schedule_relationship": "Added",</strong>
          "route_id": "1-28-j17-1"
        }
       ....
      }

{

"id": "4.TA.1-28-j17-1.2.H",

"trip_update": {

"trip": {

"trip_id": "4.TA.1-28-j17-1.2.H",

"start_time": "18:04:00",

"start_date": "20170719",

"schedule_relationship": "Added",

"route_id": "1-28-j17-1"

}

....

}

Changement de formation

Le changement de formation est la formation d’un train qui diffère de la planification.

Formation : véhicules individuels d’un train énumérés dans le sens de la marche du train. Une formation contient également l’ordre des wagons par rapport au sens de circulation (un train qui fait demi-tour a donc une formation différente après le demi-tour qu’avant). Les indications spéciales selon la LHand, les classes, les voitures-restaurants, etc. font également partie de la formation.

La plateforme Open Data ne dispose pas pour l’instant d’un mécanisme de changement de formation.

Détournement

En cas de déviation, le trajet est modifié (par ex. en raison d’un chantier).

La plateforme Open Data ne prend pas en charge les redirections pour le moment.

Arrêt exceptionnel

Si un arrêt qui ne figurait pas dans l’horaire a lieu, nous parlons d’un arrêt extraordinaire. Par exemple, l’InterCity s’arrête à Olten alors qu’il devrait y passer.

Un arrêt exceptionnel correspond techniquement à une déviation.

Passage

Lors d’un passage, il n’y a pas d’arrêt à un arrêt prévu.

Un passage correspond techniquement à une panne partielle.

Modification de l’offre

Une offre telle que chariot de repos, bistrot n’est pas disponible comme prévu.

Ce cas d’utilisation n’est pas mis en œuvre dans la plateforme Open Data.

Informations supplémentaires

Github avec les cas de test OJP: https://github.com/openTdataCH/ojp-soapui-tests