Profil d’échange pour la description des informations temps-réel des réseaux de transport en commun

SIRI - Profil Français v1.7

BNTRA-CN03-GT7_NF Profil SIRI FR_v1.7 20230727

Avant-propos

Ce document présente de façon détaillée le profil SIRI National France (également appelé « local agreement SIRI France »), soit la déclinaison de la norme SIRI aux besoins métiers français. Il contient tous les éléments nécessaires à sa compréhension, mais ne propose ni une réécriture ni une traduction de l’ensemble des documents normatifs SIRI :

• Le lecteur devra donc se référer à la norme quand cela sera nécessaire, en particulier au niveau technique avant d’envisager toute implémentation de SIRI.

D’autre part, l’ensemble de la terminologie utilisée dans ce document est celle de SIRI, et par voie de conséquence de TRANSMODEL version 6.0.

• Le lecteur est donc invité à se référer au document TRANSMODEL pour de plus amples précisions sur la terminologie, les concepts ou modèles de données sous-jacents.

Plus généralement, les notions manipulées dans ce document sont décrites par l’ensemble de documents normatifs suivants :

• SIRI : Service Interface for Real-time Information relating to public transport operations (NF EN 15531- 1 à 3 et CEN/TS 15531-4 et 5)

• Partie 1: Context and framework

• Partie 2: Communications infrastructure

• Partie 3: Functional service interfaces

• Partie 4: Functional service interfaces - Facility Management

• Partie 5: Functional service interfaces - Situation Exchange

• TRANSMODEL : NF EN 12896, Transmodel (version 6.0), Reference Data Model for Public Transport et Transmodel in UML (projet SITP 2,version 0.1 04/09/2003)

• NEPTUNE : Projet de norme AFNOR - PR NF P99-506 Décembre 2009

Dans le document, les règles propres au profil sont présentées sur fond gris. Les autres règles ont plus un rôle d’explication, d’accompagnement ou de recommandation.

Ce document est structuré en quatre parties :

• Partie 1 : Contexte

  Cette partie présente la démarche de construction du profil SIRIFrance, les cas d’utilisation constatés ou présentés à titre d’exemple, et la liste des services SIRI retenus, en se basant sur ces cas d’utilisation.

• Partie 2 : Présentation des concepts fondamentaux du Profil

  Cette partie présente les particularités et les options du profil SIRI France : concepts fondamentaux, modélisation de cas spécifiques, référentiels de données, et modalités techniques d’échange.

• Partie 3 : Description du profil d’échange

  Cette partie décrit les conventions et les règles utilisées pour la rédaction de ce profil.

• Partie 4 : Description détaillée des messages

Cette partie présente le format des messages SIRI et les choix effectués dans le contexte national français (utilisation ou non des champs, cardinalités, …). Elle constitue à ce titre une description technique et essentiellement un cadre fonctionnel à destination des développeurs et intégrateurs.

Le lecteur dispose en annexe au présent document d’un glossaire composé des définitions et autres acronymes.

A noter : les extraits de normes figurant dans cet ouvrage sont reproduits avec l’accord de l’AFNOR. Seul le texte original et complet de la norme telle que diffusée par l’AFNOR – accessible via le site Internet www.afnor. org – possède une valeur normative.

Introduction

La norme SIRI (Service Interface for Real time Information) définit le protocole d’échange de l’information Temps Réel pour les transports collectifs (format XML). SIRI se base sur le modèle de données de référence du transport public : TRANSMODEL. SIRI a été élaborée avec la participation initiale de la France, l’Allemagne, la Norvège et le Royaume-Uni.

Le groupe de travail français, CN03/GT7 (miroir du groupe européen CEN TC278 / WG3 / SG7) a adopté le format d’échanges NEPTUNE (sous-ensemble, ou profil, du format TRIDENT issu d’un projet Européen) comme base pour les échanges de données de transport en commun. Le standard NEPTUNE, aborde essentiellement les aspects référentiels des données échangées. Il est normalisé à l’AFNOR sous la référence PR NF P99-506.

Afin de fournir aux transporteurs et aux industriels un cadre normalisé pour l’échange de données concernant l’information temps réel, le CEN TC278 / WG3 / SG7 a décidé de lancer le projet SIRI (Service Interface for Realtime Information) dès 2004.

Aujourd’hui, la norme SIRI version 2.1 peut servir de base à toute implémentation des échanges de données temps réel, elle assure une compatibilité ascendante avec la version 1.0 qu’elle précise et lui ajoute quelques fonctions et attributs issus des retours d’expérience de mise en œuvre de la version 1.0.

Le présent document contient le profil d’utilisation de cette spécification technique dans un contexte national français.

Il est complété par un ensemble de documents d’accompagnement : se reporter au paragraphe Documents d’accompagnement du présent document.

Domaine d’application

Le profil, objet du present document, s’applique à la spécification technique SIRI (documents [R5] à [R9] §2). Les objectifs de ce profil sont rappelés dans la suite de ce paragraphe.

Profils

La mise en place d’un profil normatif répond au constat suivant :

• Les normes sont par nature et définition des documents consensuels, en particulier pour les documents de normalisations publiés par le CEN, définis dans un contexte international. Dans le cas des normes du CEN/TC 278/WG03, cela signifie que d’une part elles prennent en compte de très nombreux besoins car elles ont été établies à un niveau européen, et d’autre part elles n’imposent pas une implémentation exhaustive immédiate, mais permettent une implémentation progressive et qui peut être limitée à un besoin bien identifié.

Ces normes prennent en compte des besoins d’implémentation qui vont au-delà des besoins nationaux.

• La contrepartie de cette ouverture est que l’on peut facilement aboutir à des systèmes SIRI incompatibles alors même qu’ils respectent la norme : par exemple, pour peu qu’ils n’implémentent pas les mêmes services.

• Les documents normatifs sont bien souvent très détaillés et volumineux, rendant leur consultation et lecture difficiles.

• Des éléments proposés par la norme sont optionnels, lors de l’implémentation d’une application conforme à la norme il doit être décidé s’ils sont ou non utilisés.

• Les spécifications techniques SIRI sont issues de ces processus de normalisation internationaux et intègrent des mécanismes répondant à des besoins Allemands ou Suisse par exemple y sont aussi intégrés des mécanismes pour faciliter la compatibilité avec le projet de norme française NEPTUNE, britannique TransXChange, NOPTIS suédoise, …

La norme SIRI recommande donc l’établissement d’un « Local Agreement » ou profil SIRI, qui permettra de contraindre et restreindre son implémentation dans le cadre d’un échange donné – ici, dans le cas présent, au niveau national français.

De plus, la norme SIRI fournit un guide pour l’établissement de ce profil.

Qualité et Cohérence des données

Un des objectifs du profil est de simplifier et d’améliorer l’interopérabilité. L’interopérabilité ne peut être atteinte uniquement sur la base de la conformité au profil sans s’assurer de la qualité des données véhiculées : cohérence des données, conforme au format et decrivant la réalité.

En conséquence le profil doit être accompagné d’un ensemble de règles de cohérence et de qualité spécifiquement conçues pour la mise en œuvre du profil SIRI. Le respect des règles ne garantie cependant pas à 100% la qualité d’un jeu de données mais va permettre de minimiser les problèmes de cohérence.

Références Normatives

Les documents de référence suivants sont indispensables pour l’application du présent document. Pour les références datées, seule l’édition citée s’applique. Pour les références non datées, la dernière édition du document de référence s’applique (y compris les éventuels amendements).

[R1] NF EN 12896 Public Transport Reference Data Model Partie 1 à Partie 4

• Partie 1 : Common Concepts (corresponds to NeTEx Part 1 -Framework)

• Partie 2: Public Transport Network Topology (corresponds to NeTEx Part 1- Topology)

• Partie 3 : Timing Information and Vehicle Scheduling (corresponds to NeTEx Part 2)

[R2] CEN/TS 16614-1 Network and Timetable Exchange (NeTEx) - Network description

[R3] CEN/TS 16614-2 Network and Timetable Exchange (NeTEx) - Timing information

[R4] CEN/TS 16614-3 Network and Timetable Exchange (NeTEx) - Fare description

[R5] EN 15531-1, Public transport - Service interface for real-time information relating to public transport operations - Part 1: Context and framework

[R6] EN 15531-2, Public transport - Service interface for real-time information relating to public transport operations - Part 2: Communications infrastructure

[R7] EN 15531-3, Public transport - Service interface for real-time information relating to public transport operations - Part 3: Functional service interfaces

[R8] CEN/TS 15531-4, Public transport - Service interface for real-time information relating to public transport operations - Part 4: Functional service interfaces: Facility Monitoring

[R9] CEN/TS 15531-5, Public transport - Service interface for real-time information relating to public transport operations - Part 5: Functional service interfaces - Situation Exchange

[R10] XSD SIRI 2.1

Autres documents

[R11] T1 Éléments communs aux profils d’échange pour les informations planifiées du transport en commun

[R11.1] T2 NeTEx - Profil Français de NETEx: éléments communs,

[R11.2] T2 NeTEx - Profil Français pour les Arrêts,

[R11.3] T2 NeTEx - Profil Français pour les horaires,

[R11.4] T2 NeTEx - Profil Français pour les réseaux.

Termes et définitions

Cas général

Dans le cadre de ce document, les termes et definitions applicables sont ceux définis dans le document CEN/EN 15531-1:2021 [R5].

Définition d’un point d’arrêt

La notion de point d’arrêt utilisée dans le cadre du présent profil fait référence aux concepts Transmodel [R1] suivants :

• Point d’arrêt logique,

• Point d’arrêt planifié (SCHEDULE STOP POINT),

• Point d’arrêt physique,

• Zone d’embarquement (QUAY),

• Lieu d’arrêt monomodal (STOP PLACE),

• Pole Monomodal (STOP PLACE).

Le point d’arrêt physique peut être ou non rattaché à un point d’arrêt logique, selon les implémentations, par l’intermédiaire d’une affectation (STOP ASSIGNMENT). La figure ci-après illustre ces relations (Profil NeTEx France [R11.4]).

Définitions de « Départ » et « Arrivée »

D’un point de vue fonctionnel les notions d’arrivée et de départ sont définies ci-dessous. Ces notions osnt utilisés par plusieurs services SIRI (ET, SM) pour échanger des heures d’arrivée et de départ, estimées ou échues.

Arrivée

Une arrivée correspond à un événement permettant au premier passager d’être en mesure de débarquer à un endroit particulier (par rapport au trajet et à l’arrêt donnés). En règle générale, il s’agit du moment où les portes du véhicule sont (ou pourraient être) ouvertes pour la première fois après leur deverrouillage. Peu importe que les passagers montent ou descendent effectivement à l’arrêt ou que les portes aient été ouvertes en premier lieu.

Départ

Un départ correspond à un événement permettant au dernier passager d’être en mesure d’embarquer à un endroit particulier (par rapport au trajet et à l’arrêt donnés). En règle générale, il s’agit du moment où les portes du véhicule sont (ou pourraient être) fermées pour la dernière fois avant l’enclenchement de la serrure.

Dans certains cas, la condition d’ouverture ou de fermeture d’une porte n’est pas satisfaite et donc un événement tel que défini ci-dessus ne peut pas être enregistré avec précision :

• Un véhicule passe par un arrêt sans réellement s’arrêter ou ne s’arrête que brièvement sans ouvrir ses portes, par exemple, dans le cas où l’arrêt était facultatif et que personne ne l’a demandé. Dans un tel cas, l’événement d’arrivée et de départ sont tous deux enregistrés en même temps lorsque le véhicule passe la position d’arrêt.

• Un événement d’arrivée à un arrêt où il est interdit de descendre est enregistré soit au moment où la serrure est déverrouillée pour la première fois, lorsque le véhicule s’arrête (si la serrure n’a jamais été déverrouillée) ou lorsque le véhicule passe la position d’arrêt (si le véhicule ne s’arrête pas réellement).

• Un événement de départ à un arrêt où l’embarquement est interdit est soit enregistré au moment où la serrure est enclenchée pour la dernière fois, lorsque le véhicule commence à rouler (si la serrure n’a jamais été déverrouillée) ou lorsque le véhicule franchit l’arrêt position (si le véhicule ne s’arrête pas réellement).

Définition de la structure LEADER

La description des services SIRI fait référence à une structure LEADER.

Le Leader est (indirectement) défini dans la spécification SIRI [R6] par les attributs suivants :

Référentiel théorique

Le référentiel théorique est l’objet d’un accord entre les parties.

Il repose sur des échanges :

• non définis par le présent profil (NeTEx par exemple),

• ou à base de service Discovery (cf paragraphe 5.6).

Description du profil d’échange

Règles de gestion du profil

Le present profil contient un ensemble de règles de gestion applicables. Ces règles de gestion sont présentées sous forme tabulaire et numérotées.

Des textes explicatifs viennent compléter les règles d’application du profil FR.

Conventions & Représention des messages

Les messages constituant ce profil d’échange sont décrits en adoptant un formalisme tabulaire. Les tableaux proposent ces colonnes:

La structure des tableaux présentée ici est exactement la même que celle des tableaux des documents SIRI de référence ceci afin de simplifier le passage d’un document à l’autre.

Les tableaux sont simplement complétés et enrichis des informations propres au profil SIRI France.

Une description détaillée de la structure de ces tableaux est présentée dans le document « SIRI- partie 1 - 4.3-Notation pour les structures de modélisation XML des messages SIRI ».

Pour mémoire les principaux éléments présentés sont les suivants :

• Dans la documentation SIRI, les structures sont présentées sous forme tabulaire. L’en-tête des colonnes est supposé connu et n’est donc pas systématiquement répété.

• Les tableaux utilisent un ensemble de conventions pour les éléments XML et leurs contraintes.

Les éléments constitutifs de ces tableaux sont présentés ci-dessous.

Classification (Organisational Group label)

Cette première colonne précise la catégorie de l’élément, par exemple ‘Payload’ (qui se traduit littéralement par « charge utile », et correspond à la description de l’objet lui-même indépendamment de toute donnée d’accompagnement, et autres en-têtes).

Par exemple :

• Attributes,

• Log,

• Endpoint,

• Status,

• Payload.

Nom de l’élément (Element Name)

Cet élément correspond naturellement au nom de l’élément présenté. Si l’élément appartient à une structure complexe, le nom de l’élément père (ou racine) est présenté en haut du tableau.

La notation « :: » fait référence à un groupe d’éléments défini à un autre endroit du document (la colonne Type de Données permettra de retrouver cette définition).

Dans les cas d’éléments composés, une indication « voir ci-dessous » figure dans la colonne type et les sous-éléments sont présentés en dessous avec une indentation (c’est le cas de ErrorCondition cf 3.2.5).

Cardinalité et choix (Multiplicity & Choice (Min:Max))

Cette colonne précise la cardinalité de l’élément sous la forme :

• [nombre minimal d’occurrences]:[nombre maximal d’occurrences],

• Un nombre d’occurrence valant « * » signifie « nombre illimité ».

Si cet indicateur est préfixé d’un tiret (par exemple « –1:1 ») cela signifie qu’il faut choisir un élément (ou plusieurs) parmi une liste indiquée (‘choice’ au niveau XSD).

Si la cardinalité SIRI est précisée pour le profil SIRI France, cela sera aussi noté, en complément dans cette colonne et surligné en gris.

Les différentes possibilités d’exprimer la cardinalité sont donc les suivantes :

• En noir sur fond blanc : la cardinalité est celle spécifiée par le document normatif SIRI (en particulier, toutes les notations de type « 1:1 » ou « 1:* » signifient que le champ est obligatoire). Ces champs font partie du profil SIRI France.

• En noir surligné en gris: la cardinalité du document normatif SIRI est précisée par le profil SIRI France (pour rendre un champ facultatif obligatoire ). C’est alors la version surlignée en gris qui s’applique.

• En noir surligné en vert : la cardinalité du document normatif SIRI est précisée par le profil SIRI France pour la mise en place des concentrateurs . En effet, les concentrateurs ont des spécificités, en particulier en terme de volumétrie et de mise en cohérence de données multi-sources qui nécessitent certaines adaptations par rapport au cas général. Les commentaires y attenant seront aussi surlignés en vert.

Type de données (Data Type)

Cette colonne indique le type de l’élément:

• soit un type simple (SIRI ou XSD) comme Positive­DurationType ou xsd:dateTime

• soit un type structuré, signalé par +Structure (la définition de la structure porte alors le nom de l’élément suffixé par le terme Structure),

• les références (par identifiant) sont signalées, sous la forme OperatorCodeRef (référence à un opérateur, dont on fournit le code ou identifiant, dans ce cas),

• dans le cas des énumérations, la liste des valeurs est indiquée (éléments séparés par une barre verticale : « | »),

• Pour les types les plus classiques, l’abréviation est autorisée quand le nom est long (NLString pour NaturalLanguageString ou Error pour ErrorStructure).

  Ce type permet de définir les chaines de caractères associées à une langue. La structure est la suivante :

Description (Description)

On trouve dans cette colonne la description textuelle de l’élément.

Le tableau ci-dessous est un exemple de tableau SIRI (non traduit pour celui-ci, étant donné que son contenu n’a pas d’importance).

Indentation des données

La représentation des données imbriquées est représentée en utilisant les symboles ➞ et ⇉ pour indiquer le niveau d’imbrication.

Partie I - Description du cadre

Définition des concepts fondamentaux

Le présent profil s’appuie sur les concepts définis dans Transmodel [R1].

Cas d’usage

Les principaux cas d’usage SIRI, dans un environnement national français, sont synthétisés dans la suite de ce paragraphe. Ils sont détaillés dans le document d’accompagnement [A1].

Cette liste des cas d’usage ne se veut pas exhaustive et peut être complétée localement pour répondre à des besoins spécifiques.

Pour chaque cas d’usage, une préconisation de services SIRI à implémenter est présentée en conclusion du paragraphe. Les préconisations s’appuient sur les ‘bonnes pratiques’ d’implémentation SIRI [A3].

Dans ce cadre, chaque service SIRI d’un cas d’usage est qualifié ‘Indispensable’ ou ‘Facultatif’.

• Indispensable : indique que, pour le cas d’usage identifié, le respect des bonnes pratiques d’implémentation tend à l’utilisation de ce service. Dans le cas ou un autre service SIRI serait retenu, l’implémentation sortirait du contexte d’utilisation et correspondrait alors un autre cas d’usage.

• La non-implémentation d’un service ‘Indispensable’ ne veut pas dire que cette implémentation n’est pas conforme au profil SIRI France, seule la conformité aux règles de gestion et aux règles d’implémentation des services le sont.

• ‘Facultatif’ : indique que le service SIRI peut être utilisé en complément du ou des services SIRI obligatoires mais que le cas d’usage peut être respecté sans son implémentation.

Diffusion inter systèmes

Ce cas d’usage doit permettre à différents systèmes de transport d’échanger des flux d’information relatifs à l’information voyageur. Ces échanges leur permettent de réaliser des traitements de cette information indépendamment les uns des autres et en parfaite cohérence.

Dans ce cadre, SIRI permet l’échange d’informations multimodales et multi opérateurs. Ces flux ne sont pas à destination directe des usagers.

Les systèmes concernés peuvent être des SAE, des SIV, des systèmes d’affichage, …

Cet alignement repose sur un échange préalable de données théoriques (topologie et offre de transport) qui sont mises à jour entre les différents systèmes interconnectés via SIRI.

Ces échanges s’appuient sur le protocole de communication SIRI définis dans la partie 2 de la spécification [R6].

La description de ce cas d’usage est définie dans le document d’accompagnement [A1].

Diffusion Terminaux légers

Il s’agit ici de permettre à un utilisateur d’accéder aux informations horaires temps réel (prochains passages avec indications de ligne, de direction, ainsi que les éventuels messages) pour n’importe quel point d’arrêt, indépendamment du transporteur, et ce à partir d’un terminal mobile de type téléphone portable.

Ce service pourra ainsi être utilisé sur le réseau (à l’arrêt dans le cas où il n’y aurait pas d’afficheur, permettant ainsi à l’exploitant de mettre le service à disposition sans que les coûts ne soient trop importants, autorisant ainsi plus facilement la couverture de ligne ou zones à faible fréquentation) ou hors réseau (pour synchroniser son départ avec l’arrivée du train ou du bus par exemple).

SIRI est ici utilisé pour permettre au système de présentation qui gère le dialogue avec les terminaux mobiles d’accéder aux informations horaires temps réel de prochain passage.

Ce cas d’utilisation peut être généralisé à un accès avec tout autre type de terminal, en particulier via un accès de type Web, pour diffuser les informations horaires et les informations de perturbation.

A noter que pour ce cas d’usage les protocoles de communications SIRI lite sont à privilégier.

La description de ce cas d’usage est définie dans le document d’accompagnement [A1]

Centrale de mobilité

Les centrales de mobilité prennent en compte les transports en commun sur une échelle relativement large, impliquant ainsi quasi systématiquement plusieurs transporteurs.

L’un des services clés de ce type de centrale de mobilité est souvent le calcul d’itinéraires, qui se limite de moins en moins à la prise en compte des horaires théoriques (pour cause d’indisponibilité des données, et non pour des raisons techniques).

La prise en compte des informations temps réel est un besoin qui, dans ce contexte, s’exprime à deux niveaux:

1. la prise en compte des perturbations (prévues, c’est-à-dire connues plus ou moins longtemps avant le départ, ou inopinées) pour, d’une part, les signaler à l’usager et, d’autre part, lui proposer des solutions alternatives lui permettant de « sécuriser » son trajet,

2. la prise en compte des informations horaires temps réel pour optimiser le déplacement (le train que l’on ne pensait pas pouvoir prendre à une correspondance devient disponible suite à un léger retard ou encore un retard trop important impliquant une modification de l’itinéraire, etc).

L’apport de la norme SIRI est ici clairement de permettre aux SAE de diffuser vers la centrale de mobilité l’ensemble des informations temps réel nécessaires pour la mise en place des services.

La description de ce cas d’usage est définie dans le document d’accompagnement [A1].

Gestion des perturbations

La prise en compte des perturbations telle qu’elle est souvent mise en oeuvre dans les systèmes actuels se limite souvent à un message textuel libre ou pré-formaté et associé à un arrêt, une ligne, un itinéraire ou une mission. La norme SIRI permet de transmettre la perturbation de manière codifiée ; elle permet :

• de décrire finement la cause de la perturbation,

• de lister les conséquences liées à cette perturbation,

• de permettre une prise en compte par un calculateur d’itinéraires,

• de générer automatiquement des messages, avec prise en compte du type de périphérique (petits messages pour les SMS, longs messages pour le Web, etc.) ou de générer ces messages en plusieurs langues (il ne s’agit naturellement pas d’une fonction de SIRI mais d’une fonction qui pourra être mise en œuvre par l’émetteur ou par le récepteur sur la base des données structurées),

• d’associer la perturbation à un tronçon de ligne,

• de gérer des périodes de validité complexes (i.e. : du lundi au vendredi de 8 h à 18 h),

• de mettre à jour le « fil de perturbation » en ayant la possibilité d’identifier les mises à jour d’une perturbation.

La description de ce cas d’usage est définie dans le document d’accompagnement [A1].

Information PMR

Informer les PMR ou toute personne ayant des besoins particuliers (en particulier les handicaps auditifs, visuels, moteurs, etc., mais aussi à tous les besoins particuliers comme « utilisation d’une poussette », « lourdement chargé en bagage », « jambe dans le plâtre », etc.) est un besoin avéré.

Ce type de besoin comporte une composante temps réel afin de pouvoir informer sur l’état des équipements et des services (i.e. : disponibilité ou non d’un ascenseur, d’un escalier mécanique, d’une palette, d’un dispositif visuel, etc.).

Sur la base des services SIRI, des systèmes d’acquisition et de supervision ou des systèmes impliquant une saisie par un opérateur (la vérification d’état des équipements est aujourd’hui réalisée de façon manuelle dans de très nombreux cas) peuvent diffuser leurs informations de perturbation.

La description de ce cas d’usage est définie dans le document d’accompagnement [A1].

Concentrateur

Les concentrateurs permettent de rassembler au sein d’un même système un ensemble d’informations voyageur d’origine et de formes diverses dans un format pivot (en principe conforme aux concepts Transmodel) pour les mettre à disposition de systèmes clients.

Le flux entrant et sortant du concentrateur peuvent s’appuyer sur SIRI. En général les systèmes historiques peuvent fournir aux concentrateurs les informations dans des formats autres, le concentrateur redistribuant les données en utilisant SIRI :

• les centrales de mobilité,

• les systèmes pour les agents sur le terrain,

• les afficheurs,

• des terminaux dédiés (système prévu spécifiquement pour gérer un type de handicap),

• etc.

Conformité Directive EU

La loi n° 2019-1428 du 24 décembre 2019 d’orientation des mobilités (LOM : https://www.legifrance.gouv.fr/dossierlegislatif/JORFDOLE000037646678) et, au niveau Européen, le Règlement Délégué (UE) 2017/1926 de La Commission du 31 mai 2017 (complétant la directive 2010/40/UE du Parlement européen et du Conseil en ce qui concerne la mise à disposition, dans l’ensemble de l’Union, de services d’informations sur les déplacements multimodaux) rendent obligatoire la mise à disposition, quand elles existent, de certains types de données.

Le tableau ci-dessous résulte de l’analyse de la LOM et du règlement délégué et fournit la liste des concepts concernés dans le présent profil. Il sera donc nécessaire de fournir ces données pour être conforme à la législation (il s’agit bien de mettre à disposition toutes les données existantes dans les SI transport, et non de créer des données qui n’existeraient pas encore sous forme informatique).

Les concepts présents dans les tableaux sont ceux directement référencés à l’annexe du règlement européen Délégué (UE) 2017/1926 de La Commission du 31 mai 2017 (https://eur-lex.europa.eu/legal-content/FR/TXT/HTML/?uri=CELEX:32017R1926&from=FR) qui impliquent d’autres concepts (soit par héritage soit par relation, au sens UML des termes). Ces éléments d’héritage et de relations sont présentés dans les profils, mais pas dans ce tableau.

De plus, les noms des catégories (colonnes Catégorie et Détail) ont été conservés dans la langue originale du document (l’anglais) pour éviter tout risque de confusion. Pour la même raison, les noms des concepts concernés sont ceux de la version originale de Transmodel.

Pour certaines catégories de données, il peut arriver que les concepts correspondants soient multiples, mais aussi qu’ils soient différents suivant le niveau de précision porté par la donnée. La colonne « Services à minima » correspond alors au minimum à fournir pour répondre à la catégorie en question et les colonnes « Autres services » décrivent des informations complémentaires qui, si elles sont utiles, ne sont pas indispensables pour répondre à cette catégorie.

Il faut toutefois garder à l’esprit que toute information existante est supposée être mise à disposition (que cela relève de la première ou de la seconde colonne).

La première colonne reprend la notion de niveau tel qu’il est décrit et utilisé par le règlement européen et a notamment une incidence sur le calendrier de mise à disposition de la donnée (voir le règlement pour plus de détails).

Les différents concepts présentés ne sont bien sûr pas détaillés dans ce tableau mais dans le profil lui-même. C’est aussi dans la description du profil que l’on trouvera les détails concernant les attributs (obligatoire/facultatif, règles de remplissage, codification, etc.). Pour ce qui est des attributs facultatifs, la règle reste que, pour les objets ci-dessous, toute information disponible est supposée être fournie (mais on ne crée pas d’information si elle n’est pas disponible).

Table 1 – Concepts relatifs à la LOM et à la Règlementation Européenne

Services SIRI applicables

Règles de gestion

Protocoles d’échange des données SIRI

Les échanges de données SIRI entre Systèmes reposent l’echange de fichiers XML via la mise en œuvre du protocole SOAP. A noter que la mise en œuvre d’une interface SIRI Lite repose sur des échanges de fichiers XML ou JSON via une API REST.

Dans le cadre d’autres usages type OPEN DATA, l’utilisation d’autres mécanismes est possible : message broker type MQTT, XML sans SOAP, API REST, ….

Partie II - Application du Profil SIRI France

Modalités d’application

Après avoir retenu les services SIRI pour les cas d’utilisation identifiés (Partie 1), les principales actions à effectuer sont les suivantes:

1. Identifier les données de référence, objet de la partie 2 de ce document :

• Participants,

• Identifiants des lignes, des itinéraires et des missions,

• Identifiants des points d’arrêt (et type de point d’arrêt…),

• Identifiants des correspondances,

• Préciser les listes de valeurs supportées (ServiceCategory, ProductCategory, VehicleFeature) .

2. Définir le profil technique lui-même :

• Type d’abonnement (1 ou 2 phases),

• Support de la segmentation des messages,

• Confirmation ou non des notifications,

• Filtres simples ou multiples,

• Supervision de la disponibilité des partenaires,

• Signification des champs fonctionnels,

• …

3. Préciser l’utilisation des champs facultatifs dans les messages des services retenus (un champ facultatif dans la norme peut être supprimé, devenir obligatoire ou rester facultatif dans le profil…)

4. Définir éventuellement des extensions (ajout de champs non normalisés) propres à l’implémentation locale.

Implémentations locales: éléments à préciser dans les protocoles d’accord

Le paragraphe suivant présente les aspects techniques à traiter pour l’implémentation, il est à noter que ces aspects ne font pas partie intégrante du local agreement SIRI France et sont présentés ci-dessous à titre indicatif.

Le profil ne peut en effet pas définir tous les aspects nécessaires à la mise en place d’un échange. Ces éléments devront donc être définis dans le cadre des protocoles locaux établis entre les différents acteurs des échanges.

1. L’identification des infrastructures d’alimentation (et processus correspondant) : à définir spécifiquement pour chaque implémentation (par exemple le mode de connexion de l’interface SIRI au SAE…)

2. Le choix d’utilisation des champs laissés facultatifs par le profil France dans les messages et services retenus (un champ facultatif peut être supprimé, devenir obligatoire ou rester facultatif), sans que la WSDL SIRI France ne soit modifiée. 

3. Des préconisations pour la gestion et l’organisation des systèmes (annexe recommandée par la norme SIRI, à traiter dans le contexte de chaque protocole d’accord local) :

• Contacts et responsables opérationnels,

• Surveillance des services,

• Période d’interruption des services,

• Identification/gestion des anomalies.

Référentiels de données

Présentation du besoin

La mise en place d’un échange de données implique que les systèmes mis en relation puissent identifier de façon non ambiguë les objets auxquels ils font référence.

Cela est particulièrement vrai pour SIRI qui, de par sa vocation à échanger des informations temps réel, ne re-décrit pas le référentiel sous-jacent et le suppose donc connu.

Il sera donc indispensable, pour demander les prochains horaires de passage à un arrêt, de connaître l’identifiant de l’arrêt en question. Cela concerne tout un ensemble d’objets listés ci-dessous.

Il faut rappeler que l’identification de l’objet est une chose, mais que le concept sous-jacent en est une autre.

La cohérence doit porter sur ces deux aspects. Les principaux concepts utiles ont été évoqués au chapitre précédent. Pour les autres, TRANSMODEL fait référence.

Note: le nom des objets est donné en français et en anglais, de façon à simplifier une éventuelle recherche complémentaire dans les documents normatifs.

Références utilisées dans le cadre du profil SIRI France

Note : Il faut rappeler que, d’une façon générale, pour des échanges locaux, il n’est pas indispensable de disposer d’un référentiel complet pour échanger les données temps réel (notamment mission, course, …). Le sous-ensemble d’objets ci-dessus peut en effet suffire, tout dépendra du cas d’utilisation mis en œuvre.

Gestion des Identifiants

Structure des identifiants

L’objectif d’une codification est de s’assurer de l’unicité (au niveau national) et de la pérennité de l’identifiant. Toute solution, permettant d’assurer une unicité et une pérennité de l’identifiant est valable. En particulier, si un réfentiel de données (arrêts, lignes, etc.) propose des identifiants uiques et pérennes mais avec une structure différente de celle proposée par le Profil NeTEx France [R11.1], cela est tout à fait acceptable ;

Il est par contre impératif que l’identifiant d’un objet soit strictement le même quel que soit le flux de données utilisé (SIRI, NeTEx, tous profils confondus, et même GTFS ou tout autre format qui pourrait être utilisé pour l’échange de données).

NOTE IMPORTANTE : Un mécanisme de codification des identifiants est proposé par le profil NeTEx France « Eléments commun » [R11.1]. Ce mécanisme de construction a pour vocation d’assurer l’unicité de l’identifiant, mais en aucun cas l’identifiant ne peut être considéré comme porteur de sémantique. En conséquence toute analyse (segmentation, parsing, extraction d’information, etc.) de l’identifiant est à proscrire !

Identifiants SIRI

Cette liste non exhaustive devra être complétée si nécessaire lors des développements. Ces identifiants pourront aussi évoluer si nécessaire (ex : cas de doublon pour deux identifiants). Des précisions sur ces formats d’identifiant pourront être apportées dans les spécifications d’interface de chacun des systèmes.

Ajout d’identifiants alternatifs

Un mécanisme permet optionnellement de typer les identifiants (KeyList). L’implémentation des KeyList s’appuie sur une nouvelle structure de la table extensions de SIRI (Part2) présentée ci-dessous.

KeyList

Une Keylist est un ensemble de couples clé-valeur utilisé pour décrire les identifiants secondaires de l’objet (LIGNE, LIEU D’ARRÊT, ZONE D’EMBARQUEMENT, POINT D’ARRÊT PLANIFIÉ, COURSE, etc.): c’est-à-dire tel qu’il peut être identifié dans des systèmes tiers: billettique, information voyageur, etc. La clé permet de nommer l’identifiant (et donc de faire référence au système tiers), la valeur étant l’identifiant lui même.

Cette identification servira principalement d’identification croisée, permettant au fournisseur de retrouver facilement, dans ses systèmes, l’origine de l’objet.

La liste des identifiants secondaires est spécifique à chaque fournisseur. Voir aussi PrivateCode du GroupOfEntities pour les identifiants alternatifs:

Structure Extension

Structure KeyList

Choix du profil SIRI France

Gestion des abonnements

La spécification SIRI propose une couche de communication très complète (décrite dans le document « part-2: Communications infrastructure »), mais qui, comme le reste de la spécification, est ouverte et nécessite un certain nombre de précisions dans le cadre du profil France.

Ainsi, la norme SIRI propose deux méthodes pour accéder à l’information :

• 1 - Les requêtes directes, générant immédiatement une, et une seule, réponse portant les informations demandées ;
• 2 - Un mécanisme d’abonnement où la même requête est soumise, mais pour laquelle on recevra régulièrement des mises à jour des informations au fur et à mesure de leur évolution. Ce mécanisme d’abonnement propose lui-même deux variantes:
  • a) un mécanisme de notification à deux phases (fetched delivery) : lors d’une évolution des données on reçoit une indication de « mise à jour disponible » et on peut alors aller chercher les données en question auprès du serveur, via une nouvelle requête ;
  • b) un mécanisme de notification à une phase (direct delivery) : lors d’une évolution des données on reçoit directement les données mises à jour.

En effet les protocoles de transport permettent aujourd’hui de s’assurer qu’une requête a bien été transmise, ce qui supprime tout besoin d’acquittement (il suffit donc de tester le code retour de l’appel fonctionnel SOAP).

Gestion de la segmentation des messages

La spécification SIRI offre la possibilité de segmenter les messages (découper un grand message en un ensemble de messages plus petits, qu’il faudra ré-assembler).

Vérification de la disponibilité des partenaires

Lors d’un échange, il est important de savoir si le système avec lequel on « dialogue » est disponible ou non. Cela est particulièrement important si un mécanisme d’abonnement est mis en place de façon à pouvoir faire la différence entre le fait de ne pas recevoir de mise à jour parce qu’il n’y a pas d’évolution des données, et le fait de ne pas recevoir de mises à jour parce que le système distant est « en panne » (ou qu’il y a un problème réseau -. ou toute autre défaillance).

Pour ce faire, la spécification SIRI propose deux mécanismes afin d’assurer cette surveillance :

1. Le « check Status » (requête de vérification d’état) : une requête spécifique permet de demander au système distant, quand on le souhaite, s’il est bien disponible. On déclare le système distant indisponible si l’on ne reçoit pas de réponse ou si l’on reçoit une erreur en réponse (ce mécanisme est similaire au « ping » classiquement utilisé sur les réseaux IP).

2. Le « heartbeat » (battement de cœur) qui consiste à ce que chacun des systèmes émette régulièrement (à intervalle paramétrable) un message signalant qu’il est disponible. Si l’on ne reçoit pas ce message pendant une durée supérieure au délai paramétré, c’est que la communication avec le système distant n’est plus possible.

Structure du CheckStatus

Dans le cadre du profil SIRI France :

Utilisation des WSDL

Les WSDL introduites ci-dessus, permettent de décrire complètement l’interface des services SIRI dans le contexte de Web Service de type SOAP.

Gestion des filtres multiples

Lors de la constitution d’une requête, les différents paramètres permettent, entre autres, de définir un filtre pour que le client ne puisse recevoir que les données qui lui sont utiles (« les 3 prochains passages à l’arrêt AAA dans la direction DDD», « le prochain passage à l’arrêt BBB », « toutes les informations temps réel pour la ligne LLL », etc.).

La gestion d’abonnement utilise le même mécanisme. Le cas des abonnements est un peu particulier car on peut, par exemple, souhaiter être abonné avec plusieurs paramètres de filtrage:

• « les 2 prochains passages à l’arrêt AAA dans la direction DDD»

et

• « le prochain passage à l’arrêt BBB ».

Pour limiter les échanges sur le réseau ainsi que la surcharge de traitement (overhead) pour la gestion de données, la norme SIRI propose un mécanisme de filtres multiples permettant aux clients de recevoir, dans une unique notification, les informations issues de l’ensemble des abonnements : c’est le mécanisme de filtres multiples sur un abonnement.

Structuration XML

La spécification SIRI propose, la possibilité de « déstructurer » l’arborescence XML pour la rendre « plate » (« flat XML »), et ce, afin de simplifier la compatibilité avec certains systèmes existants.

Identification de la version de SIRI

Réseau et sécurité

La gestion de la sécurité et du contrôle d’accès n’est pas à proprement parler du ressort de SIRI, mais repose sur la couche de transport réseau retenue.

SIRI étant un protocole inter-systèmes, la sécurité est plus facile à maîtriser.

Cette solution est peu coûteuse et simple à mettre en oeuvre, car elle ne repose que sur une configuration du serveur HTTP.

En complément de ces éléments, on retrouve tous les éléments de sécurité classique du monde du Web : firewall, architecture avec DMZ, etc. Cependant ces éléments n’ont pas d’impact sur les échanges SIRI eux-mêmes et sont du ressort de chaque intervenant (points sur lesquels ils auront une parfaite autonomie).

Ces recommandations valent de façon générale pour tous les accès SIRI indépendamment des cas d’utilisation : il est souhaitable que le mode d’accès soit toujours le même, et sans lien avec l’usage qui sera fait des données.

Si certains systèmes disposent déjà de mécanismes de gestion des accès sécurisés et ne correspondent pas à la description ci-dessus (type VPN par exemple), ils pourront être utilisés dans un premier temps de façon à ne pas pénaliser les temps de développement (puisque cela n’entraîne pas d’impact fonctionnel).

Contrôle d’accès (niveau applicatif)

La norme SIRI impose que tous les messages échangés contiennent l’identifiant de celui qui l’a émis.

Cet identifiant peut être utilisé pour réaliser un contrôle d’accès pour, par exemple, ne permettre à un système distant de n’accéder qu’à certaines lignes ou certains arrêts.

Les éventuelles informations de restrictions devront être communiquées aux personnes en charge de la gestion et de l’exploitation du système client concerné.

Gestion des erreurs

La gestion des erreurs constitue un point important, auquel SIRI apporte une réponse claire et précise.

Le tableau ci-dessous détaille chacun des codes d’erreur proposés par SIRI :

Dans le cadre du profil SIRI France :

Ce champ signale qu’un problème a été rencontré, et non qu’il n’y a pas de réponse : il peut donc être positionné à « false » alors qu’une information est bien retournée.

Plus particulièrement dans le cas de la réponse à un GetSiri, on obtient un « Status » au niveau de l’entête global de la réponse (dans le ServiceDeliveryRequestStatusGroup) et un autre pour chacune des réponses aux requêtes élémentaires (typiquement quand on a utilisé GetSiri pour effectuer une interrogation sur toute une liste d’arrêts. Dans ce cas aussi, un « Status » à « false » dans l’entête signifie qu’il y a une des réponses portant une erreur, et non qu’il n’y a pas de réponse.

La liste des codes prédéfinis est la suivante :

• [BAD_REQUEST] : impossible de décoder la requête.

• [BAD_PARAMETER] : la requête contient un paramètre inutilisable (le texte devra alors préciser le paramètre posant problème).

• [INTERNAL_ERROR] : erreur non identifiée, mais empêchant la fourniture d’un résultat.

Il n’y a pas d’obligation pour un système d’être en mesure de remonter chacune de ces erreurs.

La remontée d’erreur n’a en effet d’intérêt que si on l’utilise pour comprendre et corriger les causes des anomalies. Cela implique que ces erreurs soient reçues et traitées par les équipes d’exploitation puis dispatchées, après une première analyse, vers les partenaires, les industriels ou tout intervenant susceptible d’y apporter un remède.

Identification des services disponibles

La norme SIRI offre la possibilité de demander à un système la liste des services qu’il implémente (ceux qu’ils doivent normalement implémenter, indépendamment des éventuelles pannes), ce qui peut s’avérer utile du fait du caractère facultif d’implémentation de certains services (se référer à la partie 1 pour la liste des services à caractère obligatoire ou facultatif).

Il peut être utile pour des systèmes concentrateurs de pouvoir demander à un système distant les services qu’il implémente et ainsi se configurer automatiquement pour la gestion de l’échange.

Toutefois, cela peut aussi être réalisé au travers d’un simple mécanisme de configuration du serveur, qui sera de toute façon indispensable pour identifier la liste des serveurs SIRI à contacter (il suffit alors, pour chaque serveur, de préciser la liste des services disponibles).

Compression

Encodage des caractères

Techniquement cela se traduira, si l’on souhaite être explicite, par un <?xml version="1.0" encoding="UTF-8"?> en entête du document. Mais cela n’est pas indispensable car l’UTF-8 est la valeur par défaut quand l’encodage n’est pas précisé.

Voir https://fr.wikipedia.org/wiki/UTF-8 pour plus de détail sur UTF-8.

Modalité d’utilisation des versions

Les principales règles d’utilisation des versions sont les suivantes. Soit deux versions de profil N et N+ (N+ étant une version postérieure à N).

• Un client N peut s’adresser à un serveur N+. Le serveur N+ peut alors :

• (solution non recommandée) Indiquer qu’il ne supporte pas cette version en utilisant le code d’erreur CapabilityNotSupportedError en précisant dans le champ CapabilityRef le numéro de version qui a été demandé (donc N ici),

• adapter sa réponse pour la rendre conforme à la version N,

• Transférer la requête à un serveur en version N (le “transfert” peut, techniquement, être réalisé de différentes façons, comme l'URL Forwarding, mais ceci relève du choix d’implémentation technique),

• Un client N+ ne peut pas s’adresser à un serveur N en demandant la version N+ (le serveur ne supportant pas cette version N+). Si toutefois cela se produisait et que le serveur soit en mesure de décoder la requête sans générer d’erreur, il est recommandé de répondre qu’il ne supporte pas cette version en utilisant le code d’erreur CapabilityNotSupportedError en précisant dans le champ CapabilityRef le numéro de version qui a été demandé (donc N+ ici),

• Un client N+ peut s’adresser à un serveur N en demandant la version N. La réponse lui est alors retournée en version N.

Note: Cette gestion de version n’est en rien incompatible avec l’insertion d’un numéro de version dans l’URL d’accès au service (avec éventuellement plusieurs URL si plusieurs versions sont disponibles). Ce type de gestion des versions à travers les URL est à négocier entre les partenaires impliqués dans l’échange.

Cas des passages échus, à venir

L’utilisation des « OnwardCall » et « PreviousCall », « recordedCall » mérite d’être précisée car elle est légèrement différente suivant qu’on les utilise dans le service StopMonitoring ou le service VehicleMonitoring.

Dans le cas du service VehicleMonitoring le « MonitoredCall» correspond au dernier arrêt marqué ou à l’arrêt où se trouve le véhicule s’il est à l’arrêt. Les « OnwardCall » correspondent alors à tous les arrêts suivants pour ce véhicule dans le cadre de sa course.

Service SIRI Discovery

SIRI propose des services qui permettent d’effectuer l’échange de données référentielles (Discovery Services). Le tableau ci-dessous présente les services disponibles et ceux qui sont retenus pour le profil SIRI France :

Ces requêtes ne seront déployées que dans les cas où un référentiel théorique n’aura pas pu être identifié : leur implémentation est donc facultative et devra, autant que faire se peut, être temporaire.

Les services retenus sont donc : StopPointsRequest, LinesRequest, InfoChannelRequest et FacilityRequest. Les identifiants ainsi obtenus pourront être utilisés avec tous les Services SIRI disponibles sur le système les ayant fournis. On utilisera, par exemple, un même identifiant d’arrêt pour consulter les horaires à l’arrêt (avec le service « Stop Monitoring »), ou les informations de perturbation (service « Situation Exchange » et/ou « General Message »).

Les informations qu’ils procurent sont présentées ci-dessous :

Note: les services de découvertes SIRI permettent de connaître les noms des arrêts et lignes et l’appartenance des arrêts aux lignes mais en aucun cas la structure (itinéraire-Route, mission-Journey pattern et à fortiori course-vehicle Journey). Il conviendra donc de se tourner vers les données de référence de l’offre et un référentiel d’arrêt pour obtenir une information proprement structurée.

Discovery StopPoint

Requête StopPointsRequest

Note: Voir 3.2 pour les explications détaillées de lecture des tableaux qui suivent (codes couleurs, etc.).

Réponses aux StopPointsRequest

La structure ci-dessous présente la description d’un arrêt tel que retourné par le service (mais sans les entêtes génériques de réponse SIRI).

Discovery Line

Requête LinesDiscoveryRequest

Réponses aux LinesRequest

Discovery InfoChannel & Facility

Requêtes

Les requêtes ont toutes la même forme (l’exemple de la StopPointsRequest est fourni ci-dessous).

Dans le cadre du profil France :

• Le champ facultatif «address» ne sera jamais présent,

• Le champ facultatif «MessageIdentifier» sera toujours présent et instancié (utilisé en particulier pour la gestion des cas d’erreur).

Note: l’attribut « version » référence la version de SIRI utilisée (afin de permettre une gestion « sereine » des futures versions, voir 5.9).

La mise à jour des données de référence devra être réalisée périodiquement de façon à garantir la synchronisation des référentiels des différents systèmes. On pourra envisager différents modes de synchronisation :

• Des synchronisations à heures fixes (quotidiennement la nuit ou en milieu de journée pour les réseaux nocturnes),

• Des synchronisations à dates fixes (hebdomadaires, mensuelles, etc.),

• Des synchronisations manuelles.

Il est difficile d’envisager ici tous les cas et modes de synchronisation, car l’objectif traité dans ces paragraphes n’est pas de préconiser « comment faire » mais de s’adapter aux systèmes existants.

Il faudra donc envisager des adaptations au cas par cas, à formaliser dans le cadre de la contractualisation entre les intervenants. Il est important de rappeler que ces accords particuliers devront traiter de façon explicite et détaillée les différents cas d’erreur qui pourront intervenir :

• Impossibilité de consulter les référentiels à la date et/ou l’heure prévue,

• Identification d’une incohérence de référentiel en exploitation, alors que le système est utilisé,

• Modification tardive du référentiel par l’exploitant,

• Etc.

Un tel mécanisme peut sembler attrayant, et il peut être tentant de le pérenniser. Il faut toutefois bien garder à l’esprit que s’il est pertinent pour deux systèmes en communication, il est beaucoup plus délicat à mettre en place pour un grand nombre de systèmes du fait de la problématique de mise à jour et de synchronisation qu’il implique: on a en effet un nombre d’échanges à prévoir égal à N*(N-1) où N est le nombre de systèmes (donc 20 synchronisations quotidiennes pour cinq systèmes).

Et, même si l’on a qu’un fournisseur et N clients, il est clair que la mise en place d’un référentiel spécifique à l’information temps réel ne permettra pas la mise en place de systèmes d’information complets permettant à l’utilisateur de passer sans difficulté de l’information théorique à l’information temps réel.

Réponses aux InfoChannelRequest

Tous les champs étant obligatoires, il n’y a pas d’adaptation au cadre du profil France (on définit tout de même les codes possibles : « Perturbation », « Information » ou « Commercial »).

On peut toutefois noter que le champ « icon » pourra souvent rester vide.

Note: voir la description du service de messagerie pour plus de précisions.

Réponses aux FacilityRequest

Dans le cadre du profil France :

• le champ facultatif « Monitored » sera toujours présent et égal à « true » (inutile de traiter les équipements pour lesquels on n’a pas d’information temps réel ou au moins mis à jour quotidiennement.

• Le champ facultatif «Facility» sera toujours présent :

  • Le champ facultatif «FacilityRef» ne sera jamais présent (déjà disponible au niveau supérieur),

  • Le champ facultatif «Description» reste facultatif,

  • Le champ facultatif «FacilityClass» reste facultatif,

  • Le champ facultatif «Feature» sera toujours présent et instancié,

  • Le champ facultatif «FacilityLocation» sera toujours présent et instancié,

  • Les champs facultatifs «SuitableFor» et «NotSuitableFor» restent facultatifs,

• Le champ facultatif «Extension» ne sera jamais présent.

Les valeurs possibles pour ces différents champs seront celles proposées par SIRI, mais pourront être réduites aux valeurs jugées pertinentes dans le contexte France lors de l’implémentation du service , par exemple pour «SuitableFor» et «NotSuitableFor» on trouvera des possibilités comme :

• auditory,

• wheelChair,

• motorizedWheelChair,

• mobility,

• visual,

• cognitive,

• psychiatric,

• incapacitingdisease,

• youngPassenger,

• luggageEncumbered,

• stroller,

• elderly,

• otherSpecificNeed.

Gestion des versions du profil SIRI FR

L’évolution des normes et du profil SIRI France dans le temps nécéssite de définir les règles permettant d’identifier la version d’un profil France SIRI.

Une compatibilité ascendante devra être assurée entre les versions du profil. Il n’y a par contre aucune garantie de compatibilité “descendante” : on peut assurer qu’un client de version antérieure puisse toujours s’adresser à un serveur de version postérieure, mais l’inverse ne peut être réalisé.

Le profil SIRI France intègre un mécanisme de gestion de version qui a plusieurs objectifs:

• Permettre à un serveur de savoir suivant quel profil il doit répondre à une requête client (en supportant plusieurs versions ou en redirigeant les requêtes et donc sans contraindre tousles clients à changer de version en même temps que lui) ;

• Permettre à un serveur de signaler à un client qu’il ne supporte pas la version demandée (plutôt que de lui répondre avec une erreur) ;

• Permettre à un client de gérer les réponses d’un serveur d’une version antérieure.

Le principe de gestion de version est simple : il s’appuie sur les identifiants de version proposés par SIRI dans les en-têtes de toutes les requêtes de service (ce champ est disponible pour chacune des xxxxRequestStructure sous la forme d’un attribut nommé Version) ainsi que de chacune des réponses correspondantes (ce champs est disponible pour chacune des xxxxDeliveryStructure, là aussi sous la forme d’un attribut nommé Version).

Note : il s’agit bien ici de l’attribut Version au niveau des services et non de l’attribut que l’on trouve sur la racine Siri du schéma, cette dernière n’étant pas accessible dans le cadre des échanges SOAP.

La codification de version proposée par SIRI est de la forme x.y :

• x constitue le numéro de version majeure, soit en l’occurrence la version de la norme (spécification technique (TS) précédemment),

• y constitue le numéro de version mineure: il est potentiellement suivi d’une lettre (facultative) qui précise éventuellement la version de l’XSD utilisée, on aura par exemple une version 2.1n pour indiquer la version 2.1 de SIRI et la version n de l’XSD correspondant.

Par exemple pour SIRI 1, les versions 1.0, 1.2, 1.3 et 1.4, et pour SIRI 2, la version 2.1 est actuellement disponible.

La codification de la version de profil se fait de la façon suivante : x.y:FR-a.b-c-d (par exemple “2.1:FR-1.0").

• x.y étant la version de SIRI (obligatoire): le x est un entier et les y est un entier potentiellement suivi d’une lettre.

• : est un délimiteur obligatoire.

• FR le digramme de la France (ISO 3166-1 alpha-2) (obligatoire).

• - est un délimiteur obligatoire

• a.b est la version du profil (obligatoire). a et b sont des chiffres entiers.

• - est un délimiteur facultatif (doit être omis si ni c ni d ne sont présents, obligatoire sinon).

• c est le numéro de version du service concerné (facultatif). Il est constitué d’un ou deux caractères numériques. Il permettra d’identifier des possibles ajustements futurs spécifiques à ce service.

• - est un délimiteur facultatif (doit être omis si d n’est pas présent, mais est impératif si d est présent).

• d est le numéro de version le l’implémentation locale (numéro de version logicielle du serveur SNCF, Transdev, RATP, Keolis, du relais, etc.). d est constitué de chiffres et de “.” uniquement.

Les exemples ci-dessous sont valides au titre de cette codification :

• 2.1:FR-1.0,

• 2.0:FR-1.0-1.

Partie III. Description détaillée des messages

Les paragraphes ci-dessous présentent les services retenus dans le cadre du profil SIRI France d’un point de vue « description technique des messages ».

Le principe de ces services a déjà été présenté en amont dans ce document, ce qui est présenté ici correspond aux tableaux détaillés des services que l’on trouve dans le document « SIRI-Partie 3 », traduit en français (seules les descriptions sont traduites, les noms des éléments et leurs types restent en anglais, car c’est ainsi qu’on les retrouvera dans l’échange XML) et précisant l’utilisation des différents champs, le maintien ou non de leur caractère facultatif, etc.

• Les éléments retenus pour le profil sont surlignés en Gris.

• Les éléments non retenus pour le profil sont en texte masqué surligné bleu

• Les éléments ne comportant aucune marque font partie du profil conformément aux spécifications de la norme SIRI.

L’ensemble des services présentés s’appuie sur la norme SIRI en version 2.1.

Des mises à jour de version de SIRI pourront être envisagées, au fur et à mesure des évolutions et corrections de SIRI. Toutefois, la prise en compte d’une nouvelle version de SIRI ne pourra être réalisée que si elle a été validée par une mise à jour du présent document.

Estimated Timetable

La norme SIRI ne pose aucune hypothèse ni aucune limite sur la durée exacte des journées d’exploitation (possibilité de passer minuit), les informations pourront donc être remontées indépendamment de la durée de la journée d’exploitation.

Note : Les mécanismes de datation SIRI sont normalisés ISO. Un changement de jour se traduit par un incrément du jour et l’initialisation des heures, minutes et secondes.

Par contre si un système s’attend à recevoir des données après minuit et que le fournisseur n’est pas en mesure de les produire, cela peut poser problème : ce point sera donc à qualifier, si nécessaire, dans le cadre des protocoles d’accord entre AOT et OTP.

Requête d’informations horaires calculées sur la ligne

Abonnement aux horaires calculés sur la ligne

Les notifications sont gérées de façons très légèrement différentes en EstimatedTimetable et StopMonitoring (du fait des différences structurelles des services).

Le tableau ci-dessous précise les conditions de notification pour EstimatedTimetable.

Réponse aux requêtes d’horaires calculés sur la ligne

Structure EstimatedJourneyVersionFrame

Structure EstimatedVehicleJourney

Structure RecordedCall

Structure permettant de décrire les informations concernant un arrêt déjà desservi par une course.

Structure EstimatedCall

Il faut noter que le document SIRI donne des indications nombreuses et précises sur cette structure, en particulier en « partie 3 : 6.6 Handling of Predictions in the Estimated Timetable Service ».

ExpectedDepartureOccupancy

Structure ExpectedDepartureCapacity

Gestion des passages échus

Ce paragraphe a pour objectif de décrire la gestion de la transition entre un passage estimé (EstimatedCall) et un passage échu (RecordedCall).

La trame ET permet de transmettre pour chaque course les informations relatives aux prochaines passages (estimatedcall) à réaliser et ceux déjà réalisés (recordedcall).

Les EstimatedCall contiennent des informations horaires sur les arrivées et/ou départ à un arrêt : théorique (aimed) ou estimée (estimated).

Les RecordedCall permettent de renseigner les informations horaires sur les arrivées et/ou départ à un arrêt déjà réalisés par une course.

Tout événement ‘Véhicule arrivé’ ou ‘véhicule départ’ déclenche une mise à jour de l’EstimatedVehicleJourney des données réalisées (‘Actual’) du recordedCall.

La définition de l’évènement véhicule arrivé ou Véhicule parti n’est pas définie dans le cadre du profil France. A titre d’exemple les implémentations les plus répondues pour la détection :

• de l’arrivée d’un véhicule sont :

  • Libération du verrouillage des portes après arrêt du véhicule

  • déclenchement d’un evenement de signalisation d’entrée dans une zone d’arrêt ;

• du départ d’un véhicule sont :

  • Verrouillage des portes d’un véhicule à l’arrêt

  • déclenchement d’un evenement de signalisation de sortie de zone d’arrêt ;

Les schémas ci-dessous décrivent pour une course les structures Estimated/Recorded call utilisées en fonction de la localisation du véhicules.

1, 2, 3 et 4 representent des arrêts.

(E) indique que les information horaires de la course à un arrêt sont positionnées dans un EstimatedCall.

(R) indique que les information horaires de la course à un arrêt sont positionnées dans un RecordedCall.

Cas Général

Avant le départ de la course

Les trames ET ne contiennent que des EstimatedCall

Pendant la course

Les informations relatives aux arrêts déjà désservis sont transmises dans les structures RecordedCall.

A l’arrêt

Considérons un véhicule réalise une séquence d’arrêt 1 => 2 => 3.

1. Sur la route ou les rails entre l’arrêt 1 et 2 (le véhicule est déjà parti de l’arrêt 1 mais n’est pas encore arrivé à l’arrêt 2), les EstimatedCalls sont transmis pour tous les arrêts à venir. En particulier, les mises à jour SIRI ET sont transmises pour les ajustements de l’heure prévue à l’arrêt 2 (voir ci-dessus).

2. Dès que le véhicule arrive effectivement à l’arrêt 2 (le déclencheur est, par exemple, un événement de déverrouillage de porte), une mise à jour RecordedCall est transmise avec l’ActualArrivalTime correspondant.

3. Toujours à l’arrêt 2, si le véhicule doit attendre un peu plus longtemps que prévu, une mise à jour SIRI-ET correspondante doit être déclenchée avec un ajustement de la ExpectedDepartureTime du recordedCall pour le départ retardé à l’arrêt 2. La mise à jour SIRI-ET correspondant à cet événement doit au moins comprendre l’arrêt de référence RecordedCall de l’arrêt 2 (par StopPointRef) ainsi que le ExpectedDepartureTime ajusté de ce recordedcall.

4. Après le départ effectif du véhicule à l’arrêt 2 (le déclencheur est, par exemple, un événement de verrouillage de porte), le RecordedCall enregistré à l’étape 3 pour l’arrêt 2 est mis à jour avec ActualDepartureTime.

Comme règles générales dans ce contexte :

Cas particulier

Passage sans arrêt

Si un véhicule passe par un arrêt sans réellement s’arrêter ou ne s’arrête que brièvement sans ouvrir ses portes (en déverrouillant ses portes), le producteur de données définira les propriétés Arrival- et DepartureBoardingActivity sur ‘passThru’ indépendamment du fait que le passthrough était prévu, attendu ou exceptionnel (inconnu avant la survenance de l’événement).

À partir de SIRI 2.1, BoardingActivity peut également être spécifié dans un RecordedCall. Il est donc possible d’enregistrer explicitement un passage exceptionnel par rapport à l’interface SIRI-ET. Ainsi, au lieu d’une mise à jour du BoardingActivity présent dans l’EstimatedCall en tant qu’effet de l’événement passthrough, seule la mise à jour RecordedCall suivante est déclenchée avec les informations BoardingActivity requises.

Si les événements d’arrivée et de départ sont déclenchés par des signaux d’entrée et de sortie, les événements de passage sont généralement également pris en charge. Cependant, si les événements d’arrivée et de départ sont déclenchés par des signaux d’ouverture/fermeture de portes, alors un passage sans arrêt n’activera aucun événement permettant un enregistrement de l’heure réelle de passage, ni une mise à jour RecordedCall. Ce dernier ne sera généré qu’au prochain événement déclencheur de message y compris le prochain événement d’arrivée ou de départ à un arrêt ultérieur. Sans mécanismes supplémentaires (par exemple, déclenchés manuellement par le conducteur), cela retarde potentiellement, voire empêche, la suppression des messages des panneaux d’affichage (ce qui doit se produire immédiatement après le départ).

Arrêt Optionel

Si un véhicule ne s’arrête pas réellement dans le cas où RequestStop est “vrai” pour le passage estimé correspondant, alors le producteur doit se comporter comme si le véhicule s’était arrêté. En conséquence, non seulement un RecordedCall doit être généré avec des enregistrements des temps réels mais également la course immédiatement supprimée de tous les panneaux d’affichage.

Stop Monitoring

Matrice de capacité

Cette,matrice est présentée ici pour indiquer les principales fonctions retenues pour le service (les explications ne sont pas traduites dans ce tableau, mais on retrouve les traductions dans les tableaux qui suivent).

Requête d’information temps réel au point d’arrêt

Granularité des points d’arrêt

Note importante : Il est possible d’effectuer une requête sur un ensemble de points d’arrêt. On constatera, ci-dessous, que le champ « MonitoringRef », qui caractérise le point d’arrêt, a une cardinalité 1:1, cela vient du fait que c’est l’ensemble du bloc « StopMonitoringRequest » qui doit être répété au sein de la structure « ServiceRequest ». Cela se justifie par le fait que, dans un certain nombre de cas, la désignation du simple « MonitoringRef » peut s’avérer insuffisante (s‘il s’agit d’un ‘Lieu d’arrêt (multimodal), on pourra, par exemple, être amené à préciser la ligne et la destination en plus du « MonitoringRef »…).

Note concernant la granularité des objets interrogés :

Le « MonitoringRef » peut aussi bien référencer :

• Un lieu d’arrêt multimodal,

• Un pôle monomodal,

• Un lieu d’arrêt monomodal,

• une Zone d’Embarquement.

Statuts de départ & Arrivée

Note concernant les heures de passage :

SIRI propose plusieurs niveaux d’information sur les heures de passage:

• Aimed(Departure/Arrival)Time : Heure d’arrivée ou de départ théorique. Il s’agit là de l’heure planifiée (figurant dans les fichiers horaires). Il peut aussi s’agir de l’horaire replanifié du matin s’il est disponible (horaire commandé).

• Actual(Departure/Arrival)Time : Heure d’arrivée ou de départ effectivement mesurée (et donc disponible uniquement après le départ ou l’arrivée du véhicule).

• Expected(Departure/Arrival)Time : Heure d’arrivée ou de départ calculée par le SAE sur la base de la progression du véhicule et du commandé (ou modifié en cours d’exploitation).

SIRI propose des statuts de départ et d’arrivée pour qualifier l’horaire calculé par rapport à l’horaire planifié. Le tableau ci-dessous précise l’usage des différentes valeurs de statuts.

Derniers arrêts de course

Note concernant les derniers arrêts de course:

Il existe plusieurs façons d’identifier le dernier arrêt d’une course :

• La plus fiable consiste à faire la distinction des terminus par constat d’égalité dans le VehicleJourneyInfoGroup entre l’arrêt courant et l’arrêt de destination de la course.

• Toutefois, cela peut aussi être fait en constatant que l’on a un ArrivalTime mais pas de DepartureTime

• ou encore, quand cela est possible, en demandant des informations sur les arrêts suivants (onwardCall, en demandant au moins un arrêt) et en constatant qu’il n’y en a pas.

Note concernant les cas ou il n’y a pas ou plus d’information:

Note concernant les annulations de passage :

Concernant les informations permettant d’indiquer l’annulation d’un passage il est précisé que:

Requête multiple d’information temps réel au point d’arrêt en utilisant SOAP

Le service SOAP GetSiri (introduit par SIRI 2) est celui qui doit être utilisé pour les requêtes multiples d’information temps réel au point d’arrêt. Ce point d’accès fonctionnel est générique et permet de solliciter n’importe quel service SIRI avec une cardinalité de requête illimitée.

Abonnement aux informations temps réel au point d’arrêt

Les données sont réputées avoir changé et doivent donc être notifiées dès que :

• La valeur d’une des heures de passage (planifiée, mesurée ou constatée) est modifiée d’une valeur supérieure ou égale au seuil demandé (ChangeBeforeUpdates) ;

• Le véhicule quitte l’arrêt (ou arrive au dernier arrêt de la course);

• Un changement de quai intervient.

Résultat de la requête d’information temps réel au point d’arrêt

Attributs temps réel du point d’arrêt

Description d’un arrêt (ou point d’arrêt indiqué) sur une course

Attributs temps réel de la course : Monitored Vehicle Journey

L’arrêt

Arrêts suivants

Annulation d’arrêts

FramedVehicleJourneyRef

VehicleJourneyInfoGroup

ServiceInfoGroup

JourneyEndNamesGroup

JourneyPatternInfoGroup

DisruptionGroup

Ce groupe de paramètres fait partie des éléments qui vont être étendus dans le cadre des services « Facility Monitoring » et « Situation Exchange ».

JourneyProgressInfoGroup

Connection Monitoring

Requête d’information sur les correspondances

Structure ConnectingTimeFilter

Structure ConnectingJourneyFilter

Abonnement aux informations sur les correspondances

Réponse aux requêts d’information sur les correspondances

Connection MonitoringFeeder Delivery

Structure MonitoredFeederArrival