images du bandeau
ACCUEIL > Études & normalisation > Normalisation > Norme Transmodel > Tout savoir sur Transmodel et son utilisationIntroduction à Transmodel

Introduction à Transmodel

6 janvier 2012

Avant propos

Ce document a pour but de présenter l’information utile à une première approche de Transmodel, le Modèle de Données de Référence pour le Transport Public, devenu une norme européenne EN12896 en 2006.

Il présente :

- les objectifs de la norme,
- les grands principes de l’approche,
- quelques éléments de la méthodologie poursuivie,
- l’historique du développement,
- le périmètre fonctionnel de la norme,
- les avantages et limites d’un modèle conceptuel de données,
- les pays utilisateurs,
- quelques documents utiles,

Transmodel en bref

Pour quel type d’utilisateur ?

Le modèle de données de référence européen pour le transport public est destiné :

- aux entreprises de transport en commun,
- aux prestataires de services ayant un rapport avec le transport collectif,
- aux concepteurs de logiciels s’y rapportant ainsi qu’aux consultants,
- aux experts ayant une activité dans le domaine du transport collectif.

Pour quel type d’activité ?

Transmodel peut servir de support :

- au développement d’applications logicielles,
- à l’intégration d’applications dans un système d’information,
- à la communication inter-entreprises ou inter-systèmes.

Il peut donc servir de base à la gestion de l’information qui régit l’environnement télématique d’une entreprise ou d’un groupe d’entreprises où diverses applications informatiques supportent différentes activités du transport public.

Pour répondre à quel besoin ?

Bien que conçu à l’origine pour répondre besoin de définition et structuration des données d’une entreprise de transport collectif, Transmodel peut également servir de point de départ et de référence :

- à la définition du modèle logique et physique nécessaire à l’implantation physique d’une base de données , à laquelle seront reliées des applications soit directement, soit par l’intermédiaire des interfaces ;
- à la génération des messages d’échange, particulièrement lors de la mise en place des interfaces entre différents systèmes informatiques.

Pour quels domaines fonctionnels ?

Les domaines que couvre Transmodel dans sa version actuelle concernent essentiellement les métiers de base du secteur du transport public, plus particulièrement les fonctions qui ont un lien direct avec la planification et la régulation de l’exploitation. Les autres fonctions, plus générales, comme la comptabilité et l’administration, la gestion du personnel, la maintenance et l’installation des véhicules, n’ont pas fait l’objet d’une étude particulière et n’ont donc pas été prises en compte par les auteurs du modèle. Le modèle de données décrit donc les besoins en information des domaines fonctionnels énumérés ci-dessous :

- Conception des horaires
- Gestion du personnel roulant
- Suivi et contrôle de l’exploitation
- Information des usagers
- Perception des titres de transport
- Tableaux de bord / statistiques

Pour quels modes de transport ?

Le modèle prend en compte, dans un environnement multi-exploitants, les besoins d’une exploitation multimodale : bus, tramway, trolleybus, métro léger, métro ainsi que train longue distance pour certains domaines fonctionnels (horaires).


1. Objectifs de la norme EN12896

1.1. Besoins des utilisateurs

Depuis de nombreuses années les exploitants des transports collectifs ont identifié le besoin d’un standard qui faciliterait l’échange aisé de données entre applications c’est-à-dire l’interopérabilité des applications informatiques dans leurs entreprises. L’architecture de systèmes informatiques était en effet souvent très compliquée, car les applications échangeant des informations étaient liées par des interfaces deux à deux :

PNG - 70.7 ko
Schéma d’architecture d’un système avec interfaces spécifiques

La complexité d’une telle architecture a fréquemment comme conséquence une dépendance d’un unique fournisseur qui est le seul à connaître le système, le maintenir et détient d’une certaine façon le monopole auprès d’un ensemble d’exploitants. Il arrive également, que les interfaces " automatiques " n’existent pas, et une saisie multiple d’informations partagées par plusieurs applications est effectuée manuellement, ce qui cause des problèmes d’incohérence d’information et des coûts importants de saisie de données.

La solution recherchée ne devait en aucun cas restreindre les pratiques des exploitants ni la créativité des réalisateurs d’application, mais permettre l’interopérabilité des applications conçues par différents fournisseurs, en garantissant :

- aux exploitants, la liberté de choisir différents fournisseurs de logiciels,
- aux concepteurs de systèmes informatiques, d’implanter leurs propres algorithmes et traitements.

1.2. Grands principes de la solution

Une base de données commune

La solution satisfaisant les besoins des exploitants des TC a pu être mise en œuvre à travers la standardisation des structures de données utilisées par les différents logiciels, permettant la mise en place des systèmes d’information intégrés.

En effet, dans le but de créer des systèmes intégrés permettant l’interopérabilité d’applications, il a été décidé dans les années 1989-90, lors du programme européen Drive I, de définir une structure des données commune aux applications informatiques utilisées par les exploitants européens des transports collectifs. L’idée des spécifications fonctionnelles standardisées a été définitivement abandonnée car elle ne prend pas en compte les invariants des systèmes informatiques que constituent incontestablement les données. Dans la solution choisie les données partagées par les différentes applications se trouvent dans une base de données, organisée conformément à un modèle (structure) de référence, appelé Transmodel. On peut représenter schématiquement l’architecture obtenue comme ceci :

PNG - 99.8 ko
Schéma d’architecture d’un système d’information intégré

La structure des données est décrite au niveau conceptuel : les différents domaines sont décrits à travers les concepts (objets) intervenant dans un domaine, les principales propriétés des concepts, les liens (relations) entre eux.

Génération des messages d’échange

Cependant, un autre besoin est apparu au cours des dernières années, celui de l’interopérabilité des systèmes. Les techniques telles que XML (Extensible Markup Language) et leurs liens avec la modélisation objet, en particulier UML (Unified Modelling Language), permettent de générer facilement des messages d’échange, à partir d’un modèle conceptuel de données développé, par exemple en UML. Transmodel se montre donc particulièrement utile dans le cadre d’élaboration d’interfaces d’échange entre systèmes, et dans ce sens est incontournable pour assurer l’interopérabilité des systèmes, à condition, bien évidemment, que ces systèmes « se comprennent », soient donc basés sur la norme EN12896.

PNG - 75.9 ko
Messages d’échange (ici XML) entre systèmes

2. Le contenu de la norme EN12896

2.1. Le document normatif

Transmodel est un modèle conceptuel de données (MCD).

La documentation de la norme (appelée aussi Transmodel V5.1) existe en anglais et peut être obtenue auprès de l’AFNOR. Elle est composée d’une partie normative et des annexes informatives. Elle comprend :

- un descriptif textuel des différents domaines de transports à travers les concepts utilisés,
- une représentation schématique sous forme de 61 diagrammes conceptuels représentant les concepts et leurs liens, le formalisme utilisé dans la partie normative est celui d’Entité/Relation),
- un dictionnaire de données donnant la définition d’environ 350 concepts et leurs principaux attributs,
- une documentation didactique comprenant une explication détaillée de la méthodologie, la présentation d’un modèle fonctionnel, la mise en évidence des différences entre la version 5.1 du modèle des données et la version précédente (V4.1),
- la version des diagrammes en formalisme UML ainsi que la documentation correspondante dans une annexe informative.

2.2. Le modèle conceptuel de données

La définition d’un MCD intervient dans la première phase de conception d’un système d’information : un MCD est indépendant de la solution d’implantation physique choisie par la suite, c’est-à-dire du choix du type de base de données (BD), des optimisations de la base, des règles organisationnelles ou du système de gestion de base de données (SGBD).

BMP - 458.7 ko
Conception d’une base de données en 3 étapes

Le formalisme utilisé dans le document normatif est celui de l’outil Oracle (R. Barker, CASE*METHOD / Entity Relationship Modelling, Addison Wesley 1990). Cependant la méthode orientée objet (en utilisant le formalisme UML – Unified Modelling Language) est actuellement la plus utilisée. Les diagrammes ont donc été « traduits » en UML : les « concepts » sont des « classes d’objets ». La correspondance entre les deux formalismes est relativement simple.

PDF - 36.5 ko
Correspondance

On retrouve des diagrammes basés sur le formalisme suivant :

PNG - 34.8 ko
Un exemple simple de modélisation en UML : un POINT comme début et fin d’un tronçon.

Bien évidemment, les diagrammes de Transmodel sont, en général, plus complexes.

PDF - 1.5 Mo
diagrammes de Transmodel
PDF - 44.8 ko
plus complexes

2.3. Le périmètre fonctionnel

Les domaines fonctionnels

La norme recouvre les besoins des domaines fonctionnels suivants :
- habillage / graphicage / conception des horaires,

PDF - 71.4 ko
habillage / graphicage / conception des horaires

- gestion du personnel roulant,

PDF - 18 ko
gestion du personnel roulant

- suivi et contrôle de l’exploitation (SAE),

PDF - 125.7 ko
suivi et contrôle de l’exploitation (SAE)

- information des usagers,

PDF - 33.2 ko
information des usagers

- perception des titres de transport (ou tarification / billettique),

PDF - 30.5 ko
perception des titres de transport

- tableaux de bord/statistiques.

PDF - 75.5 ko
tableaux de bord

Les applications relatives à ces domaines communiquent entre elles, sans risque d’incohérence en ce qui concerne les données communes. Cette solution laisse toute liberté aux exploitants de choisir les produits d’origines diverses et de les interconnecter entre eux, pourvu que les produits soient basés sur le modèle de données de référence, soit reliés à la base de données commune à travers des interfaces qui jouent le rôle de " convertisseur " entre la structure de données qui leur est propre et la structure de données décrite par le modèle de données de référence.

Les domaines de données

Cependant, les domaines de données (utilisés pour les domaines fonctionnels qui les partagent) sont les suivants :

Description du réseau

Cette partie du modèle comporte des définitions des entités qui concernent les différents types de points et tronçons, c’est-à-dire les éléments constitutifs de la topologie du réseau. Cette partie du modèle constitue une base pour la définition de l’offre, proposée aux usagers pour effectuer leurs déplacements, sous la forme de courses.

PDF - 77.1 ko
Description du réseau

Versions, Validité et Couches

Cette partie du modèle présente un mécanisme permettant de traiter les versions des données, par exemple les modifications des services théoriques.

PDF - 68.1 ko
Versions

Composants de Planification Tactique

Cette partie du modèle spécifie les informations de base nécessaires à la définition des courses des véhicules, faisant partie de l’offre théorique de service, ainsi qu’à la planification des services voiture et des services agent ainsi que des horaires correspondants permettant d’assurer l’offre planifiée.

PDF - 77.1 ko
planification tactique

Conception des Horaires

Les fonctions liées à la définition des services voitures et des services agent comptent parmi les fonctions principales de la planification des horaires théoriques. Les entités et relations correspondantes incluses dans le modèle de données de référence permettent une description exhaustive des besoins en données associés à ces fonctionnalités, indépendamment des méthodes et algorithmes utilisés dans les différents systèmes logiciels.

PDF - 71.4 ko
habillage / graphicage / conception des horaires

Roulements et Gestion du Personnel Roulant

On appelle « roulement » le processus d’ordonnancement en séquences des services agent de manière à équilibrer le partage des tâches entre les conducteurs sur la période planifiée tout en harmonisant le temps de travail qui en résulte avec la réglementation et les accords internes entre les conducteurs et la direction de l’entreprise. Le modèle de données de référence comporte une partie qui traite des besoins d’information liés à quelques méthodes classiques d’établissement des tableaux de roulement largement utilisées dans les pays européens.

Le domaine de la Gestion du Personnel Roulant traite essentiellement des données nécessaires pour les fonctions de gestion des agents de conduite suivantes :
- l’affectation de conducteurs physiques aux conducteurs « logiques » identifiés lors de la planification des services ;
- l’enregistrement des tâches exécutées par les conducteurs par jour d’exploitation.

PDF - 90.4 ko
Roulement

Suivi et Contrôle de l’Exploitation

Le domaine du Suivi et Contrôle de l’Exploitation concerne les activités « temps réel » relatives au processus de transport.

Il s’agit principalement de l’adaptation, à court terme, de l’offre théorique planifiée aux conditions d’exploitation pour un jour d’exploitation donné. Cette phase est souvent appelée contrôle « en temps réel ». Le processus de contrôle de l’exploitation suppose une détection fréquente des ressources (en particulier l’identification et suivi des véhicules). Les informations ainsi recueillies sont comparées aux données planifiées (par exemple horaires véhicules ou horaires conducteurs), ce qui permet un suivi de ces ressources.

PDF - 137.7 ko
SAE

Information des Usagers

Cette partie du modèle ne décrit pas seulement les données nécessaires aux applications donnant aux usagers les renseignements sur le service théorique et le service en cours mais également les données résultant des processus de planification et de contrôle qui peuvent entraîner des modifications du service à communiquer éventuellement au public.

PDF - 90.2 ko
Information des usagers

Perception des Titres de Transport

Cette partie du modèle vise une description la plus générique possible des données élémentaires nécessaires aux fonctions telles que :
- la définition de la structure tarifaire et de ses paramètres,
- la gestion des ventes,
- la validation des consommations et du paiement.

PDF - 84.4 ko
Perception des titres de transport

Tableaux de Bord et Statistiques

Cette partie du modèle fournit quelques descriptions complémentaires qui peuvent être utiles en dehors des éléments déjà inclus dans les sous-modèles de Planification Tactique, de Suivi et Contrôle de l’Exploitation, d’Information des Usagers et de Perception des Titres de Transport. Des informations statistiques peuvent bien entendu être fournies pour tout objet intéressant inclus dans le modèle de données propre à l’entreprise et dont les éléments sont enregistrés dans une base de données, qu’il concerne la direction de l’entreprise ou toutes autres unités d’exploitation.

PDF - 88.1 ko
Statistiques

Multimodalité et Opérateurs Multiples

Transmodel V5.1 traite principalement des besoins des modes de transports publics suivants : autobus, trolleybus, modes ferrés légers (tramway, métro). Les besoins particuliers applicables à d’autres modes de transport (p.ex. train longue distance) sont pris en compte dans la mesure du possible.

Transmodel V5.1 prend en compte les situations dans lesquelles plusieurs opérateurs sont présents dans une même zone géographique. Cette situation nécessite la mise en place de solutions liées aux problèmes du partage des responsabilités en matière de ressources et de service entre les autorités organisatrices des transports et les exploitants (ou les unités d’exploitation).

PDF - 74.3 ko
Multimodalité

3. Historique

Le développement de Transmodel à débuté dans le cadre des projets européens, en 1989. Le premier projet fut Cassiope (1989_1992, DGXIII) avec , comme résultat final le « Modèle de données Européen pour le Transport Public V.0 ». Cette version était basée essentiellement sur :
- le modèle de données de la Régie des Transports de Marseille (RTM, France),
- le modèle allemand FIT,
- le produit anglais Busman,
- l’expertise et les besoins des réseaux européens, en particulier : Milton Keynes, South Yorkshire, Barcelone.

PNG - 49.6 ko
Historique du développement de la norme EN12896

Le successur de Cassiope, EuroBus/Transmodel (1992-1994, DGXIII), a développé Transmodel V3.

Il a modélisé les données des domaines :
- Graphicage/habillage/conception des horaires,
- Gestion du personnel roulant,
- Surveillance automatique de véhicules,
- Information des usagers (données théoriques et temps réel),
- Perception des titres de transport,
- Tableaux de bord / statistiques,

et décrit l’interface avec les systèmes d’information géographiques basés sur la norme GDF (Norme ISO 14825 : Intelligent transport systems_Geographic Data Files (GDF)_Overall data specification).

EuroBus s’est basé sur :
- les résultats du projet Cassiope,
- le modèle allemand ÖPNV (Öffentlicher PersonenNahVerkehr),
- l’expertise et les besoins de nombreux réseaux européens, par exemple : Le Havre, Toulon, London Transport, Birmingham, Hampshire CC, Amsterdam, Eindhoven...
- l’expertise des industriels, par exemple : CLI, Siemens- Häni, INIT...

Harpist , la continuation des travaux du projet EuroBus/Transmodel a analysé les besoins exprimés dans différents projets européens en ce qui concerne les données pour les TC.

Harpist a permis de compléter les résultats, de procéder à une première validation européenne de Transmodel et a abouti en Juillet 1995 à Transmodel V4. Cette version a été soumise au Comité Européen de Normalisation CEN TC278 WG3 pour commentaires.

Les commentaires des experts du CEN ont ensuite été traités dans TITAN qui a abouti à la publication de Transmodel V4.1.1 en 1996.

Harpist a étudié également la terminologie relative aux TC et a publié un glossaire français/anglais/allemand.

TITAN (1996-1998) est l’acronyme de Transmodel-based Integration of Transport Applications and Normalisation.

PDF - 222.7 ko
TITAN

Le principal résultat de ce projet a été de valider Transmodel, dorénavant connu sous le nom ENV 12896, norme expérimentale (prévue pour 3 ans).

Les objectifs suivants ont été poursuivis :
- valider Transmodel dans trois projets pilotes (Lyon, Hanovre et Salzbourg), afin qu’il puisse devenir un standard utile et reconnu par les opérateurs des transports collectifs et les industriels. En ce qui concerne le site pilote français, la Société Lyonnaise des Transports en Commun (SLTC) avait pour objectif de réorganiser l’architecture informatique pour créer un système d’information basé sur Transmodel. Cette rénovation devait fournir l’occasion d’une confrontation du modèle à la réalisation d’une base des données opérationnelle conforme à Transmodel et à son interfaçage avec des applications utilisées par la SLTC ;
- faire connaître ces résultats auprès du public intéressé et transférer la connaissance acquise pendant six années de recherche (1989-1995) ;
- être à l’écoute des besoins des utilisateurs dans chaque pays pour les étudier et les prendre en compte là où ils représenteraient un intérêt pour l’ensemble des réseaux européens, afin d’assurer l’évolution du modèle en ce qui concerne le nombre des domaines fonctionnels pris en compte,
- diffuser le modèle à travers l’Europe en participant au Comité Européen de Normalisation afin de permettre à Transmodel de devenir une norme définitive.

Le projet SITP (Système d’Information pour le Transport Public) est le projet qui, pour ce qui est de Transmodel, a finalisé la documentation de la norme EN12896 en ajoutant, en particulier, la conversion des diagrammes en formalisme UML. Cependant, les objectifs de ce projet ont été plus vastes voir le projet SITP .


4. Limites et avantages de la norme

4.1. Limites liées au contenu

Afin de représenter de façon plus explicite encore le contenu de la norme, une liste de 28 Domaines Fonctionnels (DF) caractérisant le transport collectif a été dressée et les Domaines Fonctionnels dont les besoins en ce qui concerne les données ont été pris en compte ont été identifiés. La distinction suivante a été faite :
- T : la quasi-totalité des données du DF prise en compte,
- P : DF partiellement décrit,
- N : DF non pris en compte dans le modèle de données.

4.2. Avantages et limites du niveau conceptuel

L’adoption d’une démarche de développement de systèmes d’information basée sur un modèle conceptuel de données de référence laisse une grande liberté aux concepteurs et réalisateurs de logiciels : l’approche basée sur Transmodel n’impose en aucune manière le côté fonctionnel des produits. Elle donne en revanche une référence commune de structure de données et représente donc une aide plutôt qu’un obstacle, crainte exprimée quelquefois dans le passé. Cette structure de référence est d’autre part purement conceptuelle et donc indépendante de l’environnement physique du système. Il est évident que la liberté laissée aux réalisateurs d’applications et aux exploitants engendre une diversité de situations :
- certains exploitants utiliseront, une partie du modèle de données uniquement,
- d’autres rajouteront des concepts ou des liens entre concepts spécifiques à leur pratique ou organisation,
- certaines optimisations spécifiques aux applications introduiront des différences entre les implémentations de bases de données, même si elles se réfèrent à un modèle conceptuel commun,
- le modèle conceptuel de données indique les concepts et leur principales propriétés, sans entrer dans le détail ni fixer le format des données.

Ces considérations sont à prendre en compte, par exemple lors d’intégration d’applications basées sur un même modèle conceptuel : en général, l’intégration va comprendre un certain travail d’analyse au niveau de l’implantation logique et physique de la base de données. Il ne sera pas possible d’intégrer instantanément des applications nouvelles...On remarquera que ceci ne pourra sans doute jamais être le cas, ne serait-ce que pour des raisons d’organisation différente des entreprises (que l’on ne saurait standardiser) au sein d’un même pays et à travers l’Europe.

Un modèle de données de référence devra être d’une certaine façon adapté aux besoins spécifiques de chaque exploitant et quelquefois élargi lorsqu’il sera implanté : une référence ne contient que ce qui est de nature générique. Cependant, les avantages d’un modèle conceptuel de données de référence sont nombreux :
- la structure des données ainsi décrite est indépendante de l’environnement physique,
- l’architecture des systèmes d’information basés sur une structure des données de référence rend plus facile la maintenance du système, car le nombre d’interfaces entre applications décroît : les applications échangent les données à travers la base de données de référence et non pas par de liens directs,
- l’interopérabilité des applications est assurée, ·
- la définition de bases de données devient plus " standardisée " tout en permettant aux exploitants et concepteurs d’applications une certaine liberté en ce qui concerne l’implantation physique, c’est-à-dire la réalisation de leurs applications et même l’implantation de la base de données,
- l’adhésion d’un certain nombre d’exploitants et de fournisseurs de logiciels à la démarche laisse prévoir une baisse de prix d’outils informatiques, du moins à long terme,
- la cohérence d’information est assurée, ce qui contribue à la fiabilité des systèmes,
- le fait de décrire une référence commune facilite les spécifications de nouvelles applications : la structure des principales données peut être fournie aux concepteurs d’applications réduisant ainsi le temps de conception et d’analyse,
- pour les exploitants désireux de réorganiser leur système d’information, le modèle conceptuel des données sera le point de départ et la référence pour décrire les interfaces nécessaires avec l’existant.

Avantages en termes économiques

Les décideurs et gestionnaires désirent connaître les implications financières lorsque apparaît l’ éventualité d’un système intégré, basé sur Transmodel.

Il existe un nombre considérable de cas ou de conditions de départ différentes et cela n’aurait donc pas beaucoup de sens de décrire une situation particulière. Cependant, il est possible de présenter les mécanismes principaux ainsi que l’impact de l’évolution d’une architecture de système mettant en jeu un ensemble complexe de flux de données, difficiles à maintenir et non automatisés, vers un système d’information intégré, s’appuyant sur un échange de données automatisé au travers d’une base de données basée sur Transmodel.

Un modèle économique assez simple a été développé et appliqué à quatre cas typiques, caractérisant une multitude de situations dans lesquelles Transmodel peut être utilisé.

PDF - 139.6 ko
Modèle économique

Le retour d’investissement (en considérant un système avec 5 applications) pour un scénario comportant l’investissement dans une base de données basée sur Transmodel, par rapport à l’option « minimale » (un transfert de données entre les applications non automatisé), est atteint après la troisième année du projet et un an après la mise en exploitation du système d’information vraie grandeur.

4.3. Interopérabilité des systèmes

Les problèmes d’interopérabilité apparaissent à différents niveaux. Un premier niveau, celui de l’interopérabilité d’applications au sein d’un système informatique, a constitué la problématique principale traitée lors du développement de Transmodel. Cependant, l’interopérabilité des systèmes est d’un autre ordre. Il s’agit, de développer des interfaces d’échange inter-systèmes. Les techniques telles que XML sont particulièrement adaptées à cette problématique. Des spécifications techniques (propositions de norme) européennes telles que SIRI (System Interface for Real-time Information) ou NeTEx (Network and Timetable Exchange, en cours de développement) sont entièrement basés sur les structures de données issues de Transmodel. En ce sens, Transmodel contribue à l’interopérabilité des systèmes, problématique apparaissant également lors de l’interconnexion des Systèmes d’Information Multimodale (SIM).


5. Utilisateurs

Les premiers utilisateurs ont été identifiés dans le projet TITAN (1996 - 1998). Cependant, cette liste n’a pas été réactualisée dans le sens, où le suivi de ces différentes utilisations n’a pas été effectué. Par ailleurs, la liste des références peut être enrichie (2010) mais n’est pas exhaustive, car aucun recensement systématique et contrôlé n’a eu lieu ces dernières années.

PDF - 108.1 ko
Utilisateurs
PNG - 33.7 ko
Premiers pays utilisateurs de Transmodel fin des années 90

On peut compter parmi les utilisateurs de Transmodel tous ceux qui sont des utilisateurs de la spécification technique SIRI (Service Interfaces for Real-time Information), étant donné que cette interface est largement basée sur Transmodel.

PNG - 103.3 ko
Premiers utilisateurs de SIRI (2010)

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