images du bandeau
ACCUEIL > Études & normalisation > Normalisation > Norme Transmodel > Tout savoir sur Transmodel et son utilisationLes développements liés à Transmodel

Les développements liés à Transmodel

6 janvier 2012

Dans cette partie sont présentés les développements normatifs basés sur la norme TRANSMODEL, ainsi que des exemples d’implémentations sur le terrain :

Présentation des développements normatifs :

- IFOPT : extension de la norme
- NeTEx : interfaces d’échange inter-systèmes sur l’offre théorique
- SIRI : interfaces d’échange inter-systèmes sur l’offre temps réel
- NEPTUNE : profil d’échange relatif à l’offre théorique
- l’outil CHOUETTE (enrichi des fonctionnalités BATERI pour la vérification de conformité), associé à la norme NEPTUNE.

Exemples d’implémentations :

- Base TITAN : Transmodel à Lyon
- Interfaces basées sur Transmodel :


IFOPT (TS 28701) – norme depuis septembre 2011

La codification et description des arrêts n’est par harmonisée, en particulier en France. Par exemple, les arrêts sont décrits plus au moins en détail, de différents points de vue fonctionnels : un concept nommé « point d’arrêt » peut recouvrir des réalités différentes selon la fonction considérée. Ce fait provoque une certaine difficulté de mise en place de systèmes d’information multimodale et télébillettique et de communication entre ces systèmes.

Il a donc été jugé indispensable, notamment dans le cadre de la problématique de l’information multimodale, de décrire et codifier de façon univoque et harmonisée le concept de « point d’ arrêt » avant d’implémenter un « référentiel des points d’arrêt » sur un territoire.

La spécification technique IFOPT (adoptée en tant que norme en Septembre 2011) a largement contribué à clarifier le problème et à apporter une solution. Un des objectifs principaux de ce standard est de considérer les arrêts de Transport Public et :
- de donner une définition précise de ce que l’on considère être un arrêt ou un point d’arrêt,
- de décrire la structure des arrêts,
- de décrire un mécanisme d’identification univoque des arrêts.

De la sorte, IFOPT facilite la création d’un référentiel des arrêts des Transport Public.

L’idée maîtresse du modèle IFOPT est celle du lieu d’arrêt.

IFOPT définit le lieu d’arrêt comme un endroit comprenant un ou plusieurs emplacements où les véhicules peuvent s’arrêter en vue de charger/décharger des voyageurs et où les voyageurs peuvent attendre les véhicules ou préparer leur déplacement.

Chaque lieu d’arrêt comprend un certain nombre de composants qui peuvent être des arrêts physiques, c’est-à-dire des positions d’embarquement, mais aussi des points d’accès (par exemple entrées/sorties des gares), des zones d’accès (par exemple des halls de gare ou des salles d’attente), des emplacements d’équipement, des quais, des voies, etc.

PNG - 441.3 ko
Vue schématique d’un point d’arrêt : exemple

Partant de là, le modèle IFOPT comprend quatre sous-modèles :
- Modèle des Lieux d’Arrêt : décrit les « lieux d’arrêt » et leurs composants (par exemple quais, poteaux, etc. mais aussi des cheminements piétons à l’intérieur d’un « lieu d’arrêt ») ;
- Modèle des Lieux Remarquables : développe la description des lieux situés à proximité des arrêts de TP, ce qui permet d’enrichir le modèle vers des fonctions de guidage à l’extérieur des arrêts ;
- Modèle des Lieux Topographiques : décrit le découpage du territoire en lieux topographiques. Ces lieux correspondent à des zones homogènes de différents niveaux (agglomération, commune, quartier, hameau…) permettant de repérer les extrémités d’un voyage. Un lieu topographique peut contenir un lieu d’arrêt, le desservir ou en être le terminus principal ;
- Modèle Administratif : décrit des zones à l’intérieur desquelles les responsabilités d’administration des données sont homogènes. Chaque objet localisé est affecté à une zone d’administration. Un Administrateur joue un ou plusieurs rôles d’administration (recueil, contrôle de cohérence, etc.) dans la zone considérée.

Pour plus de détails : http://www.kizoom.com/standards/ifopt/

Une présentation didactique d’IFOPT : http://www.chouette.mobi/normes/


NeTEx – publication prévue en 2012

Le principal objectif de NeTEx est de définir un format d’échange de données :
- s’appuyant sur un modèle de données issu des standards Européens Transmodel / IFOPT, et prenant en compte les besoins spécifiques des trains longue distance,
- dédié à l’information voyageur, et à l’échange entre les systèmes de planification de l’offre (graphicage/habillage) et les SAE (Systèmes d’Aide à l’Exploitation), concernant la topologie des réseaux et l’information horaire.

PNG - 59.4 ko
Domaines des données de NeTEx

Cette information est nécessaire pour des systèmes d’information multimodaux proposant :
- des services d’information sur une offre de transport planifiée,
- des services d’information temps réel qui s’appuient sur l’offre théorique indispensable aux SAE qui l’utiliseront comme base pour les actions d’exploitation et de régulation.

Les modes de transport suivants sont pris en compte : train (périmètres urbain et interurbain), métro, bus, tramway, trolleybus.

Les concepts pris en considération avec une attention particulière dans le cas du mode lourd sont notamment, les données relatives aux exploitants des chemins de fer et organismes qui leur sont liés, aux gares (et équipements associés), aux couplages de courses, aux morceaux de courses, aux horaires théoriques et conditions de validité.

Dans le cas du mode lourd, on considère le lien avec les travaux de l’ERA (European Rail Agency), dans le cadre de TAP –TSI (Telematics Applications for Passenger – Technical Specification for Interoperability), qui s’appuient sur les directives de l’UIC (International Union of Railways).

Pour ce qui est des autres modes, une compatibilité formelle est assurée avec TransXChange (GB) , le VDV 452 (Allemagne) et NEPTUNE ( « mapping » détaillé avec chacun des standards nationaux).

Le format s’appuie sur un modèle de données détaillé directement extrait de Transmodel 5.1 et IFOPT. Il est implémenté en XML en respectant les conventions établies lors de la définition de SIRI.

L’échange de données peut être réalisé soit au sein de services dédiés (Web Services) soit par de simples échanges de fichiers, soit au travers d’un protocole spécifique.

Les principaux résultats de NeTEx sont
- descriptif des cas d’utilisation
- les diagrammes UML extraits de Transmodel/IFOPT décrivant un réseau multimodal (topologie, horaires théoriques ...)
- des services d’accès aux informations (Communication Infrastructure)
- une définition XSD des données, conforme aux diagrammes UML,
- une mise en correspondance (« mapping ») des standards/outils nationaux actuellement utilisés (NEPUNE, TransXChange, VDV 452, UIC).


SIRI (TS 278181)

L’objectif de la spécification technique SIRI1 est de définir un protocole pour l’échange (en temps réel) des informations relatives à l’offre de transport pour un jour d’exploitation donné ainsi que ses modifications.   SIRI et NeTEx sont donc complémentaires, NeTEx définissant des échanges d’informations relatives à l’offre théorique.

PNG - 207.2 ko
Lien NeTEx - SIRI

Il s’agit, comme dans le cas de NeTEx, des échanges inter systèmes, et non de la communication avec l’usager final ou le périphérique de restitution (afficheur).

SIRI définit de façon très large la notion de temps réel comme étant toute modification de l’information intervenant après la publication de « fiches horaires » (ou plan de production).

SIRI ne diffuse pas de description complète de l’offre de transport théorique, mais uniquement les modifications de cette offre (supposée connue), ou l’état des horaires attendus (pour un point d’arrêt ou une ligne) à un moment donné.

PNG - 123.9 ko
Représentation schématique du périmètre de SIRI

La spécification technique SIRI est basée sur des projets nationaux et internationaux comme :
- TRIDENT : projet européen visant à définir des interfaces d’échange (basés pour ce qui est du transport public, sur Transmodel V4.1),
- Les travaux normatifs allemands (VDV 453 et 454) pour l’échange de données horaires temps réel,
- RTIG (normalisation anglaise, reposant déjà sur TRIDENT) pour l’échange de l’information en temps réel.

SIRI permet de faciliter l’interopérabilité entre les systèmes de suivi d’exploitation (SAE) afin de permettre une meilleure gestion des véhicules, une meilleure qualité de service aussi bien que la mise à disposition d’informations en temps réel aux utilisateurs.

SIRI est une spécification ouverte, qui :
- d’une part, prend en compte de très nombreux besoins car elle a été établie à un niveau européen,
- et d’autre part, n’impose pas une implémentation exhaustive immédiate, mais permet une implémentation progressive et qui peut être limitée à un besoin bien identifié.

Afin de rendre les systèmes interopérables lors de l’implémentation de SIRI, il est recommandé d’établir un « Local Agreement » (ce qui revient à définir un « profil SIRI »), qui permettra de contraindre et restreindre son implémentation dans le cadre d’un échange donné. SIRI fournit un guide pour l’établissement de ce profil.

PNG - 139.1 ko
Vue d’ensemble des services SIRI

Les principaux éléments constitutifs de SIRI sont :

- Une couche de communication, qui définit des procédures et mécanismes communs pour obtenir et échanger des données. Il s’agit :

  • de la gestion des Requêtes et des Réponses.
  • des mécanismes de publication et d’abonnement prenant en compte les retours d’expérience des méthodes d’abonnement mises en place dans les différents systèmes nationaux existants. Ces procédures de communication sont communes à tous les services et à l’ensemble de l’infrastructure d’interface (gestion des messages, gestion des erreurs, mécanismes de réinitialisation, etc.).

- Un ensemble de services permettant de diffuser ou d’accéder à l’information concernant :

  • les horaires planifiés (datés) (Production Timetable Service) : il s’agit d’un service centré sur la ligne qui, pour un jour d’exploitation donné, permet de diffuser :
    • la mise à jour des horaires théoriques “publiés”, donc des horaires « objectif »,
    • la mise à jour des missions et des itinéraires.
  • les horaires calculés sur la ligne (Estimated Timetable Service) : il s’agit d’un service centré sur la ligne qui, pour le jour d’exploitation en cours, permet de diffuser :
    • les horaires estimés pendant la course (par un SAE, grâce à un ensemble d’information, dont la localisation GPS des véhicules),
    • la mise à jour des missions et des itinéraires.
  • les horaires planifiés (datés) à l’arrêt (Stop Timetable Service) : il s’agit d’un service centré sur l’arrêt qui, pour un jour d’exploitation donné, donne accès à l’information horaire « objectif » à l’arrêt ,
  • les horaires de passage estimés à l’arrêt (Stop Monitoring Service) : il s’agit d’un service centré sur l’arrêt qui, pour le jour d’exploitation en cours, donne accès à l’information sur les prochains bus passant à un arrêt (calculé par un SAE, grâce à un ensemble d’information dont la localisation GPS des véhicules). Ce service est le service le plus attendu et le plus naturel dans le cadre des échanges de données temps réel,
  • la supervision des véhicules (Vehicle Monitoring Service) : il s’agit d’un service centré sur le véhicule qui, pour les courses en cours, donne accès à l’information de localisation des véhicules,
  • les correspondances planifiées (Connection Timetable Service) : il s’agit d’un service qui, pour un jour d’exploitation donné, permet la mise à jour des informations sur les correspondances (par rapport aux informations théoriques),
  • les correspondances calculées (Connection Monitoring Service) : il s’agit d’un service, pour la journée d’exploitation en cours, qui permet la mise à jour des informations sur les correspondances (maintien ou non de correspondances initialement planifiées, notification d’un bus en attente d’un train, etc.),
  • la messagerie (General Messaging Service) : il s’agit d’un service de messagerie « générale » permettant de diffuser des informations (généralement purement textuelles) de communications, commerciales ou concernant les perturbations en cours.
  • l’état des équipements et des services (Facility Monitoring Service) : il s’agit d’un service qui permet la mise à jour des informations sur l’état des équipements et des services (disponibilité des ascenseurs, des escaliers mécaniques, des guichets automatiques, des palettes dans les bus, etc.)
  • les événements et perturbations (Situation Exchange Service) : il s’agit d’un service qui permet de diffuser des informations détaillées et structurées sur les perturbations (cause et conséquences), aussi bien pour les perturbations planifiées (travaux, manifestation, etc.) que pour les perturbations intervenant en cours d’exploitation (incident voyageur, accident sur le réseau routier, conditions météo, etc.).

CHOUETTE

CHOUETTE est un logiciel libre développé à l’initiative du Ministère français chargé des transports, dans le but de faciliter l’échange de données d’offre théorique de Transport Public (TP), en s’appuyant pour cela sur la norme NF P99-506, dite NEPTUNE, qui spécifie un profil d’échange XML.

Il se limite à la description de l’offre "théorique" et ne couvre donc pas l’information en temps réel.

Cet outil constitue un véritable support à la mise en œuvre d’un référentiel dans un contexte mono-partenaire, en permettant de structurer une base des données définie sur les concepts normalisés.

Le logiciel CHOUETTE a pour objectifs de permettre :
- à des exploitants (notamment de " petits réseaux ", qui ne se sont pas déjà outillés pour le faire) de transformer leurs fiches horaires en les saisissant au format TRIDENT (NEPTUNE), en vue de les transmettre à un Système d’Information Multimodale ou de produire un site web comprenant la description des lignes et des heures de passage ;
- à des Autorités Organisatrices, de mettre en place des centrales d’information décrivant l’offre combinée de plusieurs réseaux et de valider les échanges de données XML dont elles disposent ;
- à des acteurs déjà outillés, de télécharger le logiciel (exécutable et codes sources) afin de l’analyser et éventuellement de l’intégrer à leur chaîne d’information voyageurs ;
- à tous les acteurs qui le souhaitent (Autorités Organisatrices, industriels, exploitants, Bureaux d’Etudes, sociétés de service, opérateurs, chercheurs,...) de tester la conformité aux spécifications TRIDENT/NEPTUNE (PR NF P99-506 Décembre 2009) de données réelles, et éventuellement de faire des propositions d’amélioration qui pourront être prises en compte pour la normalisation de ce format d’échange.

L’outil CHOUETTE peut être utilisé de différentes façons pour effectuer des tâches telles que :
- la gestion des horaires théoriques d’un transporteur,
- la gestion des zones de correspondance entre transporteurs.
- la mise en œuvre d’un référentiel d’offre théorique de TP (mono-transporteur),
- la conversion de fichier CSV au format NEPTUNE,
- la vérification de fichiers au format NEPTUNE,
- l’agrégation de données pour générer des données au format NEPTUNE.

La finalité de l’outil CHOUETTE est donc tout à la fois :
- de promouvoir le profil d’échanges normalisé TRIDENT/ NEPTUNE (PR NF P99-506 Décembre 2009). Les acteurs qui adopteront ce profil d’échange pourront valider la conformité des fichiers au format XML-TRIDENT profil NEPTUNE (NF P99-506, Décembre 2009) grâce à l’outil de validation BATERI (voir http://www.chouette.mobi) incorporé dans CHOUETTE.
- de mettre à disposition sur le web, libres de droits, les codes sources de l’application, le profil d’échanges, la documentation. Les prestataires de services pourront ainsi récupérer ces outils et les intégrer dans leurs propres développements.

De plus amples informations sur l’outil CHOUETTE sont disponibles sur le site Internet http://www.chouette.mobi/, où sont notamment disponibles en téléchargement les manuels d’utilisation et de référence qui permettent aux utilisateurs de se familiariser et de maîtriser l’outil CHOUETTE.

Depuis 2007, cet outil bénéficie d’une amélioration constante et il est maintenu dans le cadre d’un marché de maintenance / accompagnement des outils associés à la normalisation des échanges de données concernant l’offre de transport public.

EXEMPLES D’UTILISATION

On trouvera des exemples variés de mise en œuvre opérationnel des profils TRIDENT/NEPTUNE, de SIRI et de l’outil CHOUETTE dans le document suivant : support d’exposé de Christophe Duquesne, Dryade, Avril 2011.

PDF - 490.1 ko
Support d’exposé de Christophe Duquesne _ Avril 2011

NEPTUNE (NF P99-506)

NEPTUNE est une spécification de format de référence pour l’échange de données relatives à l’offre théorique. Elle est issue en grande partie du projet Européen TRIDENT puis de travaux réalisés pour spécifier un profil d’échanges adapté à la description de l’offre théorique de transport, dans le cadre des développements en France.

Le profil d’échange NEPTUNE est devenu Norme Française NF P 99506 après avoir suivi le processus normal d’élaboration d’une norme (notamment enquête probatoire au niveau national).

Le projet TRIDENT (Final Report v1.0 du 17/03/2003 et Draft Specifications for the Object Oriented Approach v2.0 du 25/11/2002) fournit un ensemble de documents de spécification qui décrivent d’une part un modèle de données du domaine du transport en commun et du transport routier, d’autre part un format et protocole d’échange des données.

La modélisation des données de TRIDENT se base sur Transmodel et même si TRIDENT n’a pas pris en compte les évolutions de Transmodel V5.1 (EN12896) et se base sur une version antérieure (Transmodel V4), la documentation de Transmodel décrit en détail les évolutions de la norme. Il est ainsi possible, en utilisant la terminologie normalisée, de faire le lien avec les concepts de TRIDENT. Ce travail a été réalisé pour tracer également les différences pouvant exister entre NEPTUNE et la Transmodel V5.1.

Le projet TRIDENT a été conçu afin de faciliter le développement des services d’échange de données de transport entre différents partenaires. La modélisation TRIDENT utilise le formalisme de modélisation de données UML pour présenter le modèle de données global.   Dans le cadre du transport public, un sous-ensemble des concepts TRIDENT relatifs à l’offre théorique a été reprise et complétée pour permettre l’implémentation des échanges en utilisant le formalisme XML (on parle alors du « profil TRIDENT »).

Le profil TRIDENT est rédigé en anglais. Il n’a pas fait l’objet d’une utilisation systématique en Europe, et ceci même dans les pays représentés dans les groupes de travail (Grande-Bretagne, Allemagne, Suède…). En revanche, il a été utilisé en France à partir de 2003 dans le cadre du développement des applications informatiques :
- format d’échange entre RATP et STIF,
- CHOUETTE.

Le profil TRIDENT a ensuite été enrichi, pour devenir NEPTUNE. Les extensions concernent essentiellement les concepts relatifs à la modélisation plus précise des arrêts, des équipements et de l’accessibilité en lien avec la spécification technique IFOPT (Identification of Fixed Objects for Public Transport).

L’adoption de NEPTUNE en tant que norme est d’autant plus importante aujourd’hui, que les outils précités vont connaître des périodes d’évolution et d’adaptation.

Les spécifications du profil NEPTUNE se composent :
- d’un modèle conceptuel de données en UML permettant une implémentation en tant que base de données relationnelle ou orientée-objet,
- de schémas (en XML Schema (XSD)), spécifiant notamment le format d’échanges en tant que documents XML,
- des définitions des structures des données,

  • qui établissent l’organisation hiérarchique des données décrivant l’offre TC, par exemple : un réseau est composé des lignes, une ligne est un regroupement d’itinéraires, etc...
  • qui fixent des contraintes sur les relations entre données, par exemple, les données de topologie respectent des contraintes fonctionnelles particulières autres que les relations d’inclusion propre à l’organisation hiérarchique. Exemple : un itinéraire est une suite ordonnée de tronçons contigus.

NEPTUNE sera par la suite amené à évoluer en fonction des travaux réalisés dans le cadre des travaux de normalisation européens ou internationaux en cours. Ces derniers touchent tout à la fois la représentation topologique des réseaux de transports, les interfaces entre les données d’exploitation et l’information diffusée vers le voyageur avant et pendant le voyage (NeTEx, SIRI), la description des points d’arrêts et points fixes (IFOPT), les interfaces avec la billettique et les autres échanges de données envisageables dans les métiers des transports publics.


Base TITAN : Transmodel à Lyon

Le projet TITAN

En 1996 les travaux relatifs à Transmodel arrivent à une étape où une implémentation « vraie grandeur » permettrait de valider les développements d’une spécification qui est en voie de devenir une norme européenne.

Sous la conduite française et avec l’aide du Ministère français chargé des transports, le projet européen TITAN voit le jour. Ses objectifs principaux sont :
- valider Transmodel sur trois sites pilotes : Lyon (France), Hanovre (Allemagne) et Salzbourg (Autriche),
- démontrer son intérêt,
- donner des orientations pour son évolution future.

Le site pilote Lyon en 1996

En 1996 La Société Lyonnaise de Transports en Commun (SLTC, filiale du groupe VIA-GTI) exploite le réseau urbain de transport en commun (TCL) de la Communauté Urbaine de Lyon, sous l’autorité du Syndicat mixte des transports pour le Rhône et l’agglomération lyonnaise (SYTRAL).

Le réseau de la SLTC se compose alors de 4 lignes de métro, 100 lignes de transport de surface et 2 lignes de funiculaire, représentant une offre de 45 millions de km commerciaux par an, empruntés par 255 millions de passagers.

Le réseau de surface est assuré par 1000 véhicules. La SLTC emploie 3500 personnes dont 2000 conducteurs. La gestion de l’exploitation est répartie entre 12 Unités de Transport décentralisées (dont 3 pour le métro).

Le projet d’implémentation de Transmodel à Lyon 1996-1998

Le projet de Lyon consiste en une refonte du système d’information de l’exploitation, c’est-à-dire de l’ensemble des outils informatisés permettant aux départements opérationnels d’assurer les principales fonctions d’exploitation.

La conception du système repose sur l’utilisation de la norme Transmodel V4.1, notamment en respectant le principe suivant : les concepts utilisés par les applications des domaines fonctionnels considérés s’appuient sur le Modèle de Données de Référence et si un écart est effectué, les distorsions sont décrites par référence à Transmodel.

Le système final est un système d’information intégré pour les domaines fonctionnels relatifs à la définition de l’offre théorique de transport (itinéraires, horaires), à l’information des clients et à la gestion du personnel (services agent, roulements) : la base de données développée suivant les structures de Transmodel V4.1 assure l’intégration des applications sous-jacentes, en lieu et place d’interfaçages deux à deux.

Toutes ces fonctions étaient précédemment assurées grâce à un ensemble d’applications et de bases de données, distribuées parmi les différents sites de la société et reliées entre elles par un réseau de transmissions propriétaire.

Une première version du système, destinée à être étendue par la suite peut être représentée de la façon suivante :

PNG - 48.8 ko
Le projet pilote de Lyon

Les diverses applications implémentent différemment leurs liens avec la base de données TITAN : certaines sont nativement alimentées par TITAN, d’autres (issues de contextes extérieurs indépendants, comme le graphicage/habillage assuré par l’application Hastus), font objet d’une interface spécifique.

Un progiciel dédié à l’infocentre permet aux utilisateurs de formuler des requêtes sur les données enregistrées dans la base de production.

En résumé...

Le modèle conceptuel spécifique au réseau de Lyon a été développé en partant de la norme Transmodel V4.1.

La conception des modèles de données logique et physique a fait suite à l’étape conceptuelle, en tenant compte notamment des besoins en performances du système et de la facilité d’accès pour les utilisateurs.

La conception de la base TITAN a été effectuée à l’aide de l’atelier de génie logiciel Oracle Designer 2000.

L’intégration d’autres domaines fonctionnels a été envisagée à court et moyen terme, notamment des interfaces avec un système d’information géographique et des systèmes de gestion de la billetterie.

Les raisons qui ont conduit à l’implémentation de Transmodel à Lyon

L’objectif principal du projet de Lyon est de remplacer un système antérieur, complexe, constitué d’une quantité d’applications, fichiers, bases de données, répartis sur 12 sites et interfacés entre eux par un lourd système d’échanges propre à la SLTC.

Parmi les raisons qui ont conduit la SLTC à s’engager dans la refonte du système, on peut citer :
- la croissance du volume d’informations à traiter et du nombre d’utilisateurs ;
- l’apparition de besoins nouveaux, notamment le souhait d’informatiser de nouvelles fonctions ;
- la nécessité de renouveler un certain nombre de matériels, devenus obsolètes et causant des problèmes de maintenance ;
- le besoin d’accroître l’évolutivité du système et de garantir sa pérennité ;
- le besoin d’indépendance des fournisseurs particuliers ;
- la nécessité de faciliter l’accès à l’information ;
- le besoin de rendre l’information plus cohérente afin de permettre les échanges de données entre applications et d’éviter les doublons.

La SLTC a inscrit son projet dans le contexte de la validation de la norme Transmodel au sein du projet européen TITAN, ce qui a permis :

- d’appliquer le modèle conceptuel de référence dans des conditions de terrain réelles ;
- d’évaluer Transmodel en démontrant sa validité technique (en suscitant au passage des ajouts ou des extensions) ;
- de mettre en évidence des avantages et les inconvénients de l’utilisation de Transmodel, à partir de l’expérimentation réalisée ;
- de formuler des recommandations pour l’implémentation, susceptibles de bénéficier aux futurs utilisateurs de la norme.

Pour plus d’information : « L’application de Transmodel de Lyon - Rapport final d’évaluation », février 2000, SLTC.


TransXChange

TransXChange est un ensemble d’interfaces ayant pour objectif principal l’échange des horaires théoriques.

La version 2.0 a été développée en concertation avec l’ensemble des parties prenantes et mise à disposition le 06/05/2005. Une mise à jour (v2.1) a ensuite été publiée le 29/09/2005. La version V2.4, rendue disponible en 2010 est en exploitation pour le système ESBR de l’agence VOSA (Vehicle and Operator Services Agency) visant l’enregistrement des horaires.

TransXChange est conçu de façon à former un ensemble harmonisé, partageant des modules communs, par exemple relatifs aux arrêts ou aux courses, avec d’autres implémentations, telles que NaPTAN ou JourneyWeb. L’offre théorique de transport au Royaume Uni est distribuée au format TransXChange.

Transmodel est le modèle de données de référence pour TransXChange. Plus précisément, il s’agit des parties de Transmodel relatives à la Description du Réseau ainsi que de la Planification Tactique (à moyen terme). Cependant, certaines simplifications ont été mises en œuvre ainsi que des extensions prenant en compte les spécificités nationales.

TransXChange permet d’échanger les données suivantes :
- horaires des bus, points d’arrêt, itinéraires, lignes, parcours, heures de passage, fréquences, notes ;
- topologies complexes des itinéraires ;
- correspondances ;
- disponibilité des services en fonction des jours d’exploitation ;
- services scolaires ;
- enregistrement des services théoriques ainsi que leurs éventuelles modifications de dernière minute auprès des autorités de transport de la zone desservie ;
- exploitants de transport ;
- données d’exploitation nécessaires à la billettique embarquée (sections) ainsi qu’au SAE (ex : dépôts, temps de battement, services agent, etc).

Un outil opensource TransXChange Publisher est disponible pour valider et imprimer les données au format TransXChange.

Pour plus d’informations, voir : http://www.dft.gov.uk/transxchange/overview.htm

http://interim.cabinetoffice.gov.uk/govtalk/schemasstandards/xmlschemas/schemalibrary/transport/transxghange_schemas.aspx


NOPTIS

Le programme NOPTIS (NOrdic Public Transport Interface Standard – Standard d’Interface pour le Transport Public Scandinave) a été mis en œuvre par quatre des plus importantes Autorités Organisatrices de Transport en Suède et au Danemark : Movia (Copenhague et sa région), Skånetrafiken (Malmo et sa région), Storstockholms Lokaltrafik (Stockholm et sa région) anisi que Västtrafik (Goteborg et sa région). Cette initiative a été soutenue par l’Association Suédoise des Transports (SLTF) ainsi que par l’Union des Bus et Cars Suédois (BR).

PNG - 82.1 ko
Exemple d’implémentation de NOPTIS : Copenhague
PNG - 99.3 ko
Exemple d’implémentation de NOPTIS : Stockholm

Les échanges mis en œuvre par NOPTIS permettent d’interconnecter les sous-systèmes d’un système d’information de transport public, comprenant des composantes relatifs à la planification à long ou moyen terme, à la conception des horaires théoriques, à l’information géographique, au suivi et contrôle de l’exploitation, à l’information des voyageurs et au calcul de l’itinéraire.

PNG - 97.9 ko
TRANSMODEL est utilisé comme modèle de données de référence

NOPTIS est actuellement mis en œuvre dans la plupart des entreprises de transport en Suède et au Danemark.

Les cinq interfaces mises en œuvre par NOPTIS sont conçues de façon à respecter les différents types de données échangées et à éviter les redondances ou des échanges de données superflus.

PNG - 52.7 ko
NOPTIS

NOPTIS Data Input Interface (DII)

Cette interface permet d’échanger une partie des données relatives à l’offre théorique de transport. Elle concerne les courses, les horaires, les calendriers ainsi que la topologie du réseau. On peut échanger séparément, en option, les données relatives aux services voitures ainsi qu’aux ressources.

Cette interface permet une gestion des données en parallèle par plusieurs organismes. Les responsabilités sur les données sont définies de telle sorte que les données peuvent être mises à jour par différents organismes ou unités organisationnelles.

Le concept de cadre de version est utilisé pour délimiter les ensembles de données ayant des objectifs distincts. Ainsi les objets sont regroupés en cadres de versions suivant les différentes responsabilités. Par exemple, un cadre de version peut correspondre à un ensemble d’objets tels que “arrêts de la ville X”, “courses commerciales de la ligne 201 pour les jours ouvrables”.

NOPTIS Data Output Interface (DOI)

Cette interface est prévue pour échanger les données consolidées relatives à l’offre théorique de transport.

L’interface est conçue de façon à optimiser les échanges. Elle est structurée de telle manière qu’elle informe les applications cibles sur les données inchangées et qui peuvent être donc réutilisées. En se servant du mécanisme des versions, l’interface fournit l’information sur les modifications effectuées, réduisant ainsi le volume des données échangées.

NOPTIS Report Input Interface (RII)

Cette interface permet des échanges entre un centre de contrôle ou un SAE vers une plateforme d’intégration, relatifs aux modifications temporaires ou à court terme de l’exploitation (actions de régulation). En complément, il est possible de fournir l’information sur les modifications de service aux usagers ainsi qu’au personnel.

L’interface est conçue de manière à rendre possible une gestion des modifications en parallèle par différentes unités organisationnelles ou applications en fonction des responsablitiés.

NOPTIS Vehicle System Interface (VSI)

Cette interface concerne essentiellement les données de suivi de véhicules (localisation ainsi que les heures de passage observées). En complément peuvent également être échangées les données relatives à l’affectation des ressources.

L’interface est conçue de façon à permettre la gestion des données par différentes unités opérationnelles ou applications.

NOPTIS Realtime Output Interface (ROI)

Cette interface permet la distribution des données consolidées et mises à jour en temps réel relatives au plan de production.

L’interface est structurée de façon à optimiser les échanges des données concernant un point d’arrêt particulier ou une course.

Des informations plus détaillées sur les interfaces NOPTIS se trouvent aux adresses suivantes : www.noptis.org ou www.noptis.eu.


Contact - Mentions légales - Lettres d’info - Plan du site - admin