etude metier trafic t réel

Rapprochement SICOT/Tipi :
Étude des besoins métier Trafic Temps Réel
31 juillet 2009
NOTICE ANALYTIQUE
Organisme commanditaire :
SETRA, DIT/GRT
Titre :
Rapprochement SICOT/Tipi : Étude des besoins métier Trafic Temps Réel
Sous-titre :
Date d’achèvement :
Langue :
version 31/07/09
Français
Organisme auteur :
Rédacteur :
CETE Méditerranée
Patrick GENDRE
Relecteur assurance qualité :
SETRA
Nicolas DITCHI
Pierre CHOURY
Résumé :
Remarques complémentaires éventuelles (rubrique facultative) :
prise en compte des remarques de C. Paquet du 28/07, C. André du 28/07, N. Crossonneau du 27/07
: 16
Mots clés : Information trafic
Diffusion : Publique ?
Nombre de pages
Confidentialité :
Bibliographie :
Non ?
oui
Besoins fonctionnels synoptique trafic
Sommaire
I.
1.
2.
3.
B.
C.
CONTEXTE
LA DEMANDE
II.
A.
1.
2.
3.
4.
5.
B.
1.
2.
C.
D.
E.
1.
2.
3.
4.
5.
F.
1.
2.
3.
4.
5.
6.
G.
1.
2.
H.
I.
FICHES FONCTIONNELLES (CAS D’UTILISATION)
ACQUERIR LES DONNEES DE TRAFIC
UTILISATEURS : ADMINISTRATEURS
FONCTIONS
UTILISATEURS
FONCTIONNALITES
METHODE DE TRAVAIL
CONTENU DU DOCUMENT
INTERFACES
DONNEES GEREES
PRIORITES
QUALIFIER LES DONNEES DE TRAFIC
UTILISATEUR
FONCTIONS
RECONSTITUER ET CORRIGER LES DONNEES DE TRAFIC
AGREGER LES DONNEES DE TRAFIC
CALCULER LES NIVEAUX DE SERVICE
UTILISATEURS : ADMINISTRATEURS
FONCTIONS
INTERFACES
DONNEES GEREES
PRIORITES
VISUALISER LES DONNEES DE TRAFIC
UTILISATEURS
FONCTIONS DE VISUALISATION
FONCTIONS D’ADMINISTRATION
INTERFACES
DONNEES NECESSAIRES
PRIORITES
ARCHIVER LES DONNEES
UTILISATEURS
FONCTIONS
ECHANGER LES DONNEES : ACQUISITION EXTERNE
ECHANGER LES DONNEES : DIFFUSION EXTERNE
3
3
4
4
5
5
6
6
6
7
7
7
8
8
8
8
9
9
9
9
10
10
10
10
10
10
11
12
12
12
12
13
13
13
13
13
III. MISE EN OEUVRE
A. INTERFACES FRONTAL
B. INTERFACE BDTD
C. PROCHAINES ETAPES
13
14
15
15
IV.
16
V.
A.
GLOSSAIRE :
ANNEXES
ANNEXE 1. PROPOSITION DU CETE
Besoins fonctionnels synoptique trafic
16
16
Résumé
Ce document décrit les fonctionnalités d’une application nationale d’observation des données de
trafic ‘temps réel’, baptisée provisoirement OTTR.
La première partie présente le contexte : reformulation de la demande de la maîtrise d’ouvrage, et
de la méthode de travail, qui prend en compte d’une part les applications existantes, d’autre part la
nécessité de réaliser rapidement une première version opérationnelle, intégrée dans un système
d’information, et en particulier dans le cadre du projet Tipi.
La seconde partie présente sous forme de ‘fiches fonctionnelles’ et constitue le coeur du
document.
Les utilisateurs sont d’une part des administrateurs nationaux ou locaux qui définissent les
(frontaux, points de mesure, vues pré-définies), d’autre part les utilisateurs de DIR et des CIR, voir
des partenaires extérieurs, qui visualisent les données de trafic temps réel au travers de cartes
interactives.
L’application OTTR récupère les données sur les frontaux de recueil trafic, en priorité les MI2. La
qualification, la détection de valeurs aberrantes et reconstitution, les agrégations spatiales ou
temporelles seront simplement implémentés en fonction des besoins temps réel. Dans une
première version, le Niveau de Service est calculé avec des paramètres identiques pour tous les
PM, selon les seuils d’une combinaison QTV. OTTR fournit une interface web aux administrateur
pour configurer les données, et une interface de visualisation cartographique interactive aux
utilisateurs des CIR et DIR, ou à des extérieurs, au travers de vues pré-définies, selon différents
formats, dont une IHM Tipi.
La troisième partie traite des questions de mise en oeuvre. Il nous semble prioritaire de réaliser
une interface web pour accéder aux données MI2. Il nous paraît utile de réaliser en parallèle du
DAF une implémentation prototype par exemple avec le CRICR de Lyon, qui permettra également
de consulter toutes les DIR sur une base concrète.
Après validation par la MOA (DIT/GRT – SETRA) et consultation des utilisateurs potentiels
(CIR/DIR), la prochaine étape serait la décomposition des besoins retenus en briques fonctionnelles
pour évaluation de la réutilisation ou de la mutualisation avec les autres applications existantes ou
futures du système d'information Tipi.
Une fois les conditions d'intégration arrêtées, l'étape suivante serait la rédaction de spécifications
en vue d’une réalisation informatique, éventuellement couplée à un développement pilote.
Au stade de la version actuelle provisoire, les éléments ne sont que des propositions qui doivent
être discutées et peuvent être largement remises en cause.
I. CONTEXTE
1.
La demande
Ce rapport fait l’objet d’une commande des services centraux (DIT/GRT, SETRA) sur la
base d’une proposition CETE Med. du 30/06. (cf. annexe I).
L’objectif est de construire une application prenant en compte les objectifs suivants :
- offrir aux opérateurs des CIR un outil de visualisation « temps réel » des données de trafic
en remplacement de GERICO ;
- offrir aux DIR un large accès aux informations, et donner notamment aux opérateurs des
CIGT un outil de visualisation « temps réel » des données de trafic en remplacement de
MIVISU ;
Besoins fonctionnels synoptique trafic
3
- centraliser les données de trafic ;
- mettre en cohérence l’application SICOT (application nationale dédiée à la connaissance
et à la diffusion des données statistiques de trafic) et le système d’information Tipi ;
- mutualiser au maximum les développements avec les autres applications du système
d'information ;
- partager autant que possible les données avec d'autres applications pour éviter les saisies
multiples par les utilisateurs ;
- permettre l’accès aux données en temps réel et leur diffusion ;
- publier les données en temps réel pour une réutilisation par d'autres gestionnaires et les
opérateurs de service en information routière ;
- fonctionner de manière cohérente avec les SAGT existants ;
- être développé rapidement et conçu pour évoluer en termes de fonctionnalités et de type
de données traitées ;
- la diffusion des données de trafic au public par des sites internet (Bison Futé ou autres) est
en dehors du périmètre ;
- la maintenance des stations de recueil est également en dehors du périmètre.
Pour des raisons pratiques, on propose de donner un nom à cette application : comme son
objet est de permettre l’observation de données de Trafic Temps Réel, on propose dans un 1er
temps faute de mieux de l’appeler OTTR.
2.
utilisateurs
Il y a deux grandes classes d’utilisateurs :
- les utilisateurs finaux qui visualisent le trafic temps réel sur un navigateur ;
- les administrateurs qui définissent les vues, la manière dont les données qui alimentent
ces vues sont collectées, et le cas échéant les droits d’accès à ces vues.
Par ailleurs, l’application échange des données avec d’autres applications :
- en premier lieu, des frontaux de recueil de données en général installés dans des PC de
trafic, CIGT ou centres d’exploitation ;
- l'application publie ses données en vue de leur récupération par des applications externes ;
- l'application transmet ses données à l'application générant les pages dynamiques et la
cartographie du site Bison Futé, consulté ensuite par les professionnels de la route et le grand
public ;
- l’application alimente par ailleurs une base de données en temps différé (voire plusieurs).
3.
fonctionnalités
La liste générale des fonctions pour notre périmètre d’étude est la suivante : (réf. : CERTU
« Faisabilité d'outils communs pour les SAGT de niveau 1 » de juillet 2000.)
- acquérir les données trafic ( acquisition externe auprès d'autres opérateurs y compris)
- qualifier les données trafic
- reconstituer les données trafic
- corriger les données trafic
- agréger les données trafic
- calculer les niveaux de service et des indices de circulation temps réel
Besoins fonctionnels synoptique trafic
4
- détecter automatiquement les bouchons : Hors périmètre
- calculer les temps de parcours Hors périmètre
- détecter automatiquement les incidents Hors périmètre.
- visualiser les données ( TR et archives)
- archiver les données : notamment les besoins spécifiques trafic non déjà décrit dans le
SICOT
- échanger les données : acquisition externe
- échanger les données : diffusion externe
En pratique, nous avons gardé la même classification mais essentiellement décrit les
fonctions ‘acquérir’, ‘visualiser’, ‘archiver’.
B. méthode de travail
La méthode de travail consiste à
- partir d’une analyse « sur le papier » des applications existantes, parce que ce type
d’applications a fait l’objet de nombreuses réalisations et est relativement mûr en termes tant
fonctionnels que techniques.
- soumettre ensuite une première version d’expression des besoins et de cahier des charges
fonctionnels à quelques utilisateurs potentiels ainsi qu’à la maîtrise d’ouvrage, afin d’aboutir à
un document validé qui puisse servir de base à la production de spécifications fonctionnelles
dont la réalisation puisse être confiée à un prestataire et recettée par des utilisateurs pilotes.
Les applications dont nous avons connaissance et que nous avons sommairement analysées
sont les suivantes :
- GERICO
- MELODIE/ARPEGES
- MIVISU
- ASTEC
- SAGT :
- DCE Gentiane ou DorBreizh (dans un contexte VRU), si besoin CCTP 2005 A75
- spécifications Marius, Coraly, Gutemberg
reconstitution des données : Inrets, Sirius2 / KIR
En termes d’interviews d’Utilisateurs, nous avons contacté le CRICR de Lyon (M
Crossonneau), et prévoyons de contacter le siège d'une DIR (Centre - Est à confirmer) et un
petit CIGT (Gap à confirmer).
C. contenu du document
La partie I présente le contexte (compréhension de la demande, méthode de travail).
La partie II présente notre analyse des besoins sous forme de « fiches fonctionnelles » (cas
d’utilisation). Le niveau de description des fonctions reste général : l’objectif est de décrire les
principes de fonctionnement, et de parvenir à une compréhension mutuelle de ces principes par
les parties prenantes (ce qui n’est pas évident car il s’agit d’une application qui a vocation à être
générique, et à pouvoir évoluer sur plusieurs années), puis un consensus sur le périmètre et les
priorités, afin de se lancer dans des développements.
Chaque fiche fonctionnelle comporte en général les items suivants :
1) utilisateurs
Besoins fonctionnels synoptique trafic
5
2) fonctionnalités : décrites sous forme de cas d’utilisation (interface utilisateur), le cas
échéant variantes envisageables
3) entrées / sorties (interfaces)
4) donnés gérées
5) contraintes et priorités
La partie III aborde la mise en oeuvre ; il nous semble utile dès ce document d’évoquer ces
questions d’architecture qui sont très liées aux principes de fonctionnement de l’application. Le
choix de priorités sur les fonctionnalités, les utilisateurs ciblés, les contraintes techniques
auront un impact important sur le service que pourra rendre l’application et ses évolutions, qui
doivent être explicités en amont.
L’application est conçue comme un logiciel modulaire permettant de se connecter à des
frontaux de recueil de données pour récupérer et visualiser en temps réel des mesures de trafic,
ainsi que pour alimenter d’autres applications.
L’application est générique et centralisée mais rien n’empêche qu’elle soit déployée en
plusieurs instances.
II. FICHES FONCTIONNELLES (CAS D’UTILISATION)
A. Acquérir les données de trafic
1.
utilisateurs : administrateurs
Plutôt que d’acquisition, au sens recueil de données sur le terrain, il faudrait plutôt parler de
récupération de données déjà recueillies par des systèmes de recueil et mises à disposition via
des frontaux MI2 ou autres, ou même déjà traitées par des applications SAGT ou autres. Les
données ne sont pas forcément celles des DIR : un CRICR comme celui de Lyon remonte
aujourd’hui dans son MI2 plus de données des SCA ou des CG que des DIR.
Les utilisateurs sont des administrateurs qui définissent les paramètres de configuration
nécessaires à la récupération et à la visualisation des données. On peut imaginer 2 modes de
fonctionnement :
- un ou des administrateurs centraux définissent les données recueillies auprès de chaque
frontal
- des administrateurs locaux définissent les données recueillies auprès des frontaux dont ils
assurent la gestion
Il nous semble préférable de prendre en compte ces 2 modes afin de garantir le maximum
de souplesse d’exploitation : les droits d’accès seraient alors définis par un super-utilisateur
administrant l’application. Un administrateur donné n’aurait accès qu’à un frontal, ou à une
liste bien définie de frontaux, s’il est administrateur local, ou à tous les frontaux s’il est
administrateur central. Le mode de fonctionnement pourra le cas échéant différer selon la DIR ;
il appartient à chaque DIR de s’organiser et de définir les droits d’accès des applications qu’elle
gère. A fortiori c’est vrai pour les exploitants hors ministère (SCA, Collectivités) qui s’organisent
comme bon leur semblent.
En outre, l’administrateur local qui gère le frontal définira sans doute quels sont les clients
(‘consommateurs’) qui auront le droit d’accéder aux données disponibles sur le frontal, et devra
évidemment s’assurer que l’application Trafic Temps Réel en fait partie.
Il faut prévoir un administrateur pour toute la DIR et un administrateur local. Au niveau
central, il y aura un super-administrateur du système d'information et un administrateur
d'application (le PND).
Besoins fonctionnels synoptique trafic
6
2.
Fonctions
En termes de cas d’utilisation, le fonctionnement est similaire pour un administrateur
central ou local :
- l’administrateur se connecte via son navigateur
- il choisit le frontal F parmi la liste de ceux qu’il gère
- il configure l’interrogation du frontal, avec une variante sur la manière de procéder :
- soit il met à jour un fichier texte de configuration (c’est le plus simple, à condition de
s’assurer que l'administrateur est le seul à l’instant t à gérer le frontal F, pour éviter tout conflit),
ce qui définira les données que l’application OTTR cherchera à récupérer auprès de F toutes les
X minutes (a priori 6 minutes, mais rien n’empêche de prévoir des interrogations, ou d’autres
fréquences de recueil si nécessaire : TP 3’ par exemple)
- soit il met à jour cette configuration via des formulaires web :
- choix d’un point de mesure à éditer ou création d’un nouveau point de mesure
- édition des attributs pour ce point de mesure
- si l’administrateur a également accès au frontal depuis son navigateur, ou du moins accès
au fichier de configuration définissant les données produites et mises à disposition par le
frontal, on peut également envisager que l’administrateur puisse recopier (tout ou partie de)
cette configuration du frontal dans la configuration du recueil OTTR pour ce frontal F. Il faut
réduire au maximum la charge des administrateurs ; néanmoins il nous semble plus simple que
ses mises à jour de configuration soient répercutées manuellement du frontal vers OTTR.
- l’administrateur a également accès à un écran de supervision des recueils (liste des
frontaux, indicateurs de bon fonctionnement, e-mail d’alerte en cas de problème sur l’un des
frontaux). Lorsqu’un dysfonctionnement sur un frontal est identifié, l’administrateur central
devra en général contacter le gestionnaire local du frontal. Sauf si ce point est remis en question
par la Maître d’Ouvrage, il ne nous semble pas utile de prévoir un mode reprise automatique
pour réinterroger le frontal sur des données qui auraient été perdues, car cette fonction peut être
(très) complexe à spécifier dans le cas général, et le besoin pas évident du point de vue Trafic
Temps Réel, ni même pour le Temps Différé.
3.
interfaces
L’acquisition des données implique une interface entre l’application OTTR et des frontaux
de recueil, en priorité les MI2. Les données échangées avec le frontal sont décrites au § suivant,
indépendamment du type de frontal.
Le choix du mode d’interrogation du frontal est discuté dans la partie III.
4.
données gérées
L’objectif de ce document n’est pas de produire un modèle conceptuel de données, on
pourra pour cela lors de la phase de spécifications s’inspirer d’applications existantes,
notamment Marius, Sirius2, Gutemberg, mais aussi bien sûr des formats FIME/LCR et Datex2
pour être sûr de ne pas oublier des informations utiles.
A priori la notion centrale est celle de Point de Mesure auxquelles sont attachées au
minimum les attributs suivants :
- identifiant du Point de Mesure (Code national, libellé)
- le cas échéant, utilisation ou niveau d'utilisation du PM, pour sélection en fonction du
besoin et pour affichage sur les cartes à petites échelles
- localisation du PM
- point (x,y) et autres attributs de localisation si nécessaire
Besoins fonctionnels synoptique trafic
7
- tronçon (linéaire auquel rattacher une représentation de type ‘traficolor’) Il faut
éventuellement prévoir plusieurs attributs de ce type afin de rendre possibles plusieurs
représentations graphiques des données (tronçon, section, sectionnement SETRA, synoptique
CIGT, diagramme iso-trafic, etc.)
- frontal fournissant les données pour ce PM : identifiant, adresse, gestionnaire...
- variables (nature de la mesure : Q, V, ...)
- séquence (6’, éventuellement 1’, ou intermittent si RTC, mais en pratique quel intérêt
de remonter dans l’application OTTR des données de station RTC ? ou alors il faut que ce soit
géré simplement : on considère que le PM d’une station RTC est en recueil 6’ et les données
sont vides, éventuellement 95% du temps, quand le frontal n’interroge pas le RTC)
- sens (il nous semble préférable de définir 2 points de mesure distincts fournissant les
données de trafic dans les 2 sens opposés d’une même route, néanmoins cela devra établi au
niveau des spécifications)
- voie(s)
- en principe les attributs associés aux valeurs des mesures (horodate, indicateur d’état :
HS, Valeur Aberrante, donnée agrégée, donnée reconstituée, donnée corrigée, etc.) seront
les mêmes pour tout type de mesure et tous les PM, mais si ce n’est pas le cas il faut prévoir
de pouvoir configurer le type de données / attributs attachés à chaque type de mesure (Q 6’,
V 6’, etc.)
Dans un 1er temps les données seront essentiellement des débits, taux, vitesses et niveaux de
service (Q, T, V,NS), , si possible taux de PL, mais il faut concevoir l’application pour qu’on
puisse progressivement enrichir les types de données : temps de parcours (qui ne sera rattaché
qu’à un tronçon, pas à un point), niveaux de service, bouchon, taux d’occupation, taux de PL,
etc.
Dans ce cas, le frontal fournissant les données traitées ne sera pas forcément un « frontal
stricto sensu » (qui interroge des stations de terrain), cela peut être une application SAGT ou un
serveur centralisé, qui effectue les traitements par exemple de calcul de temps de parcours, de
niveaux de service, ou autres.
Dans un 1er temps, l’application Observation du Trafic Temps Réel pourrait donc recueillir
les données des MI2, et dans un 2ème temps interroger d’autres types de frontaux.
5.
priorités
La priorité est clairement de pouvoir acquérir les données des MI2, ce qui donc peut
nécessiter de développer une interface avec le MI2 (cf. partie III). En termes de données, il faut
a minima pouvoir récupérer les débits et vitesses 6’.
B. Qualifier les données de trafic
1.
Utilisateur
L’utilisateur est l’administrateur qui définit pour chaque type de mesure le seuil de valeurs
en dehors desquelles la valeur est jugée aberrante.
2.
Fonctions
En pratique, la plupart des SAGT et même des frontaux possèdent des fonctions de
qualification et d’agrégation des données.
Soit le frontal effectue déjà une première qualification des données, que l’on peut alors
récupérer par un attribut indiquant si la donnée a été qualifiée, ou inversement si la valeur est
jugée aberrante, voire douteuse (si cette notion est définie par le frontal), charge alors à
l’application OTTR de mettre une valeur spéciale (HS, 0 ou autre).
Besoins fonctionnels synoptique trafic
8
Néanmoins on peut prévoir que l’application OTTR possède une fonction de qualification
minimale, par exemple par un filtre par seuil pour chaque type de mesure (e.g. 0 < V < 250
km/h). Pour être évolutif, on peut prévoir que l’administrateur puisse définir au niveau pour
chaque type de donnée (V6’, etc.) quelle est la fonction de qualification. Néanmoins les
fonctions de qualification (c’est-à-dire de détection des valeurs aberrantes) deviennent vite
compliquées dès qu’on essaie de faire mieux qu’un simple filtrage par seuil, on se ramène alors
à la question de la reconstitution et correction des données (ci-dessous).
En termes de cas d’utilisation, l’administrateur (central) définit les seuils via une interface
web (valeurs utilisées pour tous les frontaux).
C. Reconstituer et corriger les données de trafic
La reconstitution et correction est faisable mais complexe. Elle ne nous semble pas
indispensable pour une visualisation temps réel des données, la présence de quelques trous
‘gris’ dans un synoptique n’étant pas vraiment gênante. Cette fonction ne nous semble pas
relever de OTTR.
La reconstitution/correction en temps réel est en général effectuée au niveau de
l’application SAGT, ou une application séparée (cas de KIR à la DIRIF, à la conception duquel
l’INRETS a été associé, mais dont les algorithmes de reconstitution sont avérés à notre
connaissance complexes à mettre en oeuvre). En revanche à notre connaissance les frontaux
RDT en général et le MI2 en particulier n’effectuent pas de reconstitution des données 1’ ou 6’.
En temps différé la reconstitution peut être nécessaire afin d’être en mesure de calculer
certains indicateurs statistique, mais c’est à voir alors au niveau des applications
correspondantes et notamment du SICOT, où la reconstitution des données horaires est prévue
(sur la base d’ailleurs des fonctions existantes de Arpèges).
Il nous semble suffisant de prévoir un attribut au niveau des mesures pour indiquer si une
valeur est reconstituée ou corrigée.
D. Agréger les données de trafic
L’agrégation ne nous semble pas relever du périmètre de OTTR, ce qui simplifierait
d’autant l’application. Néanmoins ce point est à valider par la Maîtrise d’Ouvrage, qui peut
considérer que la donnée 6 minutes n'étant utile surtout que sous une ou deux heures, et qu’audelà de 2 heures, les données horaires sont sans doute plus pratiques à consulter.
L’agrégation temporelle a plutôt un intérêt pour le temps différé et relève alors du SICOT
(calcul de données horaires ou journalières). L’agrégation temporelle ‘temps réel’ consistant à
produire des données 6’ est déjà effectuée au niveau des frontaux voire des stations ellesmêmes.
L’agrégation spatiale peut avoir un intérêt pour améliorer la fiabilité des données quand le
recueil est dense, mais dans ce cas le réseau est généralement exploité via un SAGT déjà doté
de ces fonctions, en particulier pour le calcul de temps de parcours. Elle peut donc aussi être
effectuée en amont de OTTR au niveau du frontal qui fournit les données.
Le fait que la donnée soit agrégée ou pas ne change a priori rien pour l’application OTTR,
on peut simplement prévoir un attribut pour indiquer que la donnée est agrégée (ou 2 valeurs
d’attribut, en distinguant l’agrégation spatiale et l’agrégation temporelle).
E. Calculer les niveaux de service
1.
utilisateurs : administrateurs
Il s’agit de configurer le cas échéant les paramètres de calcul des niveaux de service, soit
globalement pour tous les PM, soit par groupes ou par catégories de PM (cf. attribut niveau
d’utilisation du PM ci-dessus), soit individuellement.
Besoins fonctionnels synoptique trafic
9
2.
fonctions
Ces niveaux de trafic peuvent être calculés par le frontal, notamment si ce frontal est un
SAGT qui met à disposition ses données. Il y a plusieurs méthodes de calcul. Dans l’application
MARIUS, ils dépendent de Q et de V, et c’est le cas dans la plupart des SAGT à notre
connaissance (mais certains indicateurs utilisent aussi le taux d'occupation).
A notre connaissance, dans l’application ASTEC/MIVISU, les couleurs de trafic dépendent
seulement de seuils de vitesse, et dans GERICO du taux d’occupation.
Néanmoins, on peut vouloir appliquer le même algorithme pour tous les points de mesure
connus de l’application OTTR, de manière centralisée, en vue d’harmoniser les pratiques. En
ce cas, on peut envisager plusieurs méthodes :
- la plus simple consiste à utiliser la même formule pour tous les points de mesure (basée
par exemple sur des seuils de Q, T et V pour des données 6’)
- une méthode plus complexe consisterait à s’appuyer sur la courbe débit- vitesse de chaque
point de mesure pour identifier dans quel régime se situent les valeurs QV à l’instant t. Cela
implique de calculer en temps différé les paramètres de cette courbe débit/vitesse et de les
définir comme attributs supplémentaires associés à un PM, ce qui ne pourra être fait en
pratique que par un administrateur local du frontal fournissant les données pour ce PM (ce n’est
ni envisageable ni souhaitable à notre avis de calculer cette courbe dynamiquement, en temps
réel). Cette méthode de calcul est tout à fait intéressante et pas très complexe à implémenter,
néanmoins compte-tenu de l’investissement qu’elle exige en termes de données, elle ne peut
être déployée que dans un 2ème temps.
Eventuellement, si on dispose de données QTV assez fréquentes (1’), le NS peut être lissé
(par exemple calculé toutes les minutes sur une fenêtre de 3 minutes).
Le cas échéant, on peut envisager que l’application plusieurs indicateurs de ce type
(traficolor, niveau de service, bouchon CIR...).
L’utilisateur est l’administrateur central qui définit la configuration du calcul des NS. Dans
le cas d’un algorithme prenant en compte les courbes Débits/Vitesses, l’utilisateur est un
administrateur local. En termes de cas d’utilisation, l’administrateur se connecte à des
formulaires web de paramétrage du calcul des NS, ou d’édition des PM.
3.
interfaces
Pour le calcul des NS, ce module de calcul des NS se comporte comme un frontal pour
l’application OTTR et met à disposition des NS toutes les x minutes, comme un frontal de
recueil met à disposition des débits ou des vitesses.
4.
données gérées
Les données sont soit des paramètres de l’algorithme global, soit des paramètres attachés à
chaque PM.
5.
priorités
Un algorithme global de calcul des NS sur la base de seuils identiques pour tous les PM.
F. visualiser les données de trafic
La fonction de visualisation est la raison d’être de l’application OTTR.
1.
utilisateurs
- les opérateurs : sélectionnent une vue via une IHM web (éventuellement certains
utilisateurs notamment externes n’ont accès qu’à certaines vues), la vue s’affiche, et est
interactive et mise à jour dynamiquement
- l’administrateur : gère les paramètres de vues (synoptiques) prédéfinies qui regroupent des
Besoins fonctionnels synoptique trafic
10
PM et avec des options d’affichage, une géométrie attachée à chaque PM (pas forcément celle
du référentiel routier, en vue d’optimiser l’affichage à une échelle particulière : néanmoins
l’orientation prise dans Tipi est clairement d’avoir des « synoptiques homothétiques », c’est-àdire « géographiques », et non « diagrammatiques », conçus à partir d'un fond adapté et d'un
tracé issu du référentiel. La raison en est la très forte réduction de la charge de maintenance et
la cohérence assurée en cas de modification du référentiel). Cette notion de vue correspond à
celle de couche d’information géographique, il est possible d’ajouter d’autres informations
temps réel si besoin (pour Tipi, ou d’autres applications). Plus largement la notion de vue peut
comprendre la publication des données selon plusieurs formats
2.
fonctions de visualisation
A vrai dire, les opérateurs s’intéressent peu aux données de trafic proprement dites, qui sont
pour l’essentiel utilisées en temps différé pour des études d’exploitation, ou des statistiques et
des études de déplacement ou de planification. En temps réel les données de trafic sont surtout
utilisées par des ‘boîtes noires logicielles’ afin de calculer des temps de parcours, ou d’alimenter
des algorithmes de régulation ou de détection d’incidents.
Le besoin de base de l’opérateur CIGT est d’arriver sur une carte interactive affichant les
niveaux de service, et à défaut, les vitesses ou les débits, mises à jour en temps réel. Une mise à
jour toutes les 6 minutes semble suffisant ; néanmoins si des données 1’ par exemple sont
disponibles, l’application doit permettre les utiliser. Le but est de voir rapidement les zones du
réseau où apparaissent des congestion anormales, qui peuvent nécessiter l’intervention de
l’opérateur (diagnostic complémentaire si caméras disponibles, appel radio, puis selon la
situation renseignement de la main-courante, diffusion d’info, éventuellement actions
manuelles de régulation ou de commande d’équipements de terrain).
Le besoin de l’opérateur CIR est similaire même si les actions d’exploitation diffèrent.
Néanmoins le CRICR a sans doute un besoin plus important d’accéder également aux données
historiques, ce qui a été pris en compte d’une part en proposant que OTTR conserve par
exemple les dernières 24 Heures de données, des données ‘typiques’, et permette de visualiser
des données issues d’une BD temps différé.
Le besoin des autres opérateurs (DDE, salles de crise, ) est également similaire.
Ces trois types d’utilisateurs souhaitent idéalement que ces fonctions de visualisation soient
intégrées à son outil informatique d’aide à l’exploitation : une IHM regroupant toutes les
informations disponibles (équipements dynamiques, images du terrain, position des patrouilles,
réseaux voisins...) pour la zone visualisée, avec bien sûr des informations plus fines pour les
opérateurs du CIGT que pour ceux du CIR, ou a fortiori que des autres utilisateurs, et la
possibilité pour les opérateurs de saisir des infos et d’activer des mesures (c’est l’application
« SAGT », ou sa déclinaison nationale « Tipi »).
La carte ou le synoptique temps réel doit être interactif (permettre de se déplacer ou
zoomer, de changer de vue, le cas échéant de choisir les couches d’information visibles),
d’afficher en un clic sur un objet (PM, tronçon) les informations temps réel et attributs relatifs à
cet objet (ou, variante : visualisation des données TR lors du survol d’un objet et des données
récentes – 2 dernières heures par ex. – sur double-clic de l’objet).
En complément :
- il peut être utile ponctuellement de visualiser la tendance des dernières heures (en cliquant
sur le PM ou l’historique pour afficher une courbe Q,V avec les mesures des 2, 10 ou 24
dernières heures par exemple, et si disponible une valeur ‘typique’ historique (cf. l’indice de
circulation Sytadin de la DIRIF); ces données récentes peuvent aussi servir à l’application
OTTR pour effectuer d’autres traitements dans le futur (lissage, prévision...) ;
- le synoptique n’est pas forcément une carte traficolor, il peut-être plus ergonomique de
présenter des vues schématiques (type « vague Gerico », ou Tipi dispose aussi
automatiquement de « synoptiques linéaires » de Tipi, où le tracé d'un axe ou d'un itinéraire est
généré automatiquement comme une droite horizontale ou verticale).
Besoins fonctionnels synoptique trafic
11
Une fonction complémentaire relatif au trafic temps réel souvent intégrée dans les logiciels
SAGT est de permettre à l’opérateur d’identifier des problèmes de fonctionnement du recueil
temps réel et d’en faire part au mainteneur. Néanmoins le mainteneur dispose lui aussi de ses
propres outils en accédant aux frontaux de recueil – frontal, banc de test - et éventuellement à
des outils de supervision ou de GMAO). Cette fonction ne nous semble pas pertinente pour
OTTR.
En revanche, si l’application a été conçue de manière assez générique, il nous semble
intéressant de prévoir de l’utiliser pour visualiser des données temps différé (fonction ‘rejeu de
données’). En termes d’utilisation, certaines vues seraient alimentées par un serveur temps
différé plutot que par les données courantes du serveur OTTR, l’utilisateur devrait alors choisir
une plage de temps parmi les archives disponibles, puis pourrait dérouler le temps par un
curseur comme sur un visualiseur vidéo. On peut aussi produire des images animées comme
disponibles sur le site Sytadin.
3.
fonctions d’administration
L’administrateur définit des vues, indiquant l’extension géographique, les points de mesure,
le types de données à afficher, le cas échéant le serveur d’archives (s’il s’agit d’une vue temps
différé), etc. Selon l’organisation retenue ces fonctions peuvent être gérées par un
administrateur national et/ou des admin locaux. A minima il y a une vue France entière
cartographique avec tous les PM et les V 6’ (ou les NS).
Il peut y avoir plusieurs ‘types de vues’, a minima le traficolor cartographique standard,
mais aussi par exemple une ‘vague Gerico’ ou tout autre type de vue, le dessin correspondant
étant stocké dans un attribut ‘tronçon’ au niveau de chaque PM.
Afin de rendre l’application aussi adaptable et ‘tout terrain’ que possible, il nous semble
également souhaitable d’envisager que selon le type de vue, la solution technique – le format de
diffusion – puisse être différente (par exemple IHM Tipi, IHM carto basique, pourquoi pas
KML, Flex ou d’autres si cela s’avère nécessaire pour diffusion vers des mobiles ou autres). Cela
permettrait également de considérer que la mise à disposition de données de trafic en XML ou
DATEX2 soit un cas particulier de vue OTTR (cf. ci-dessous diffusion externe).
4.
interfaces
Ce module de visualisation n’accède a priori qu’à des données locales ‘temps réel’ gérées
par le serveur OTTR (en base ‘temps réel’), mais si on décide, auquel cas OTTR devra
interroger un serveur temps différé.
5.
données nécessaires
configuration des vues (plusieurs types de synoptiques possibles)
configuration des Points de Mesure (Q, T, V, NS, taux PL si disponibles)
paramètres de légende
le cas échéant dernières 24h de données, données ‘typiques’ historisées de chaque PM
6.
priorités
Dans un 1er temps on préconise de développer la fonction d’affichage de manière autonome,
permettant de visualiser de façon minimale le OTTR sur un navigateur et d’envisager
l’intégration dans des IHM applicatives (en pratique celle de Tipi qui doit être prise en compte
dès la conception). Cette proposition doit être validée par la Maîtrise d’Ouvrage dans la mesure
où la plupart des fonctions correspondantes de Tipi sont réutilisables, ce qui pourrait éviter de
développer un moteur d'affichage spécifique.
Même si pour commencer on peut se contenter d’une seule carte traficolor « géographique »
pour toute la France dans laquelle on peut se déplacer et zoomer dynamiquement, il nous
semble important pour des raisons de facilité d’utilisation que l’utilisateur ait accès à des vues
Besoins fonctionnels synoptique trafic
12
pré-définies (par l’administrateur ou par lui-même – cette fonction étant déjà offerte à tous les
utilisateurs dans Tipi).
Au besoin, le stockage et la visualisation des dernières 24 heures (durée à valider) de
données d’un PM peuvent être développées dans un 2ème temps, tout comme la visualisation de
données historisées. Ces fonctionnalités doivent néanmoins être prises en compte lors de la
conception, tout comme la possibilité que les vues puissent être à des formats différents.
G. archiver les données
1.
utilisateurs
L’utilisateur est l’administrateur central OTTR qui définit quelles données sont mises à
disposition de qui à quelle fréquence (qui peut être seulement chaque 24H, cf. ci-dessous)
2.
fonctions
On considère par principe que OTTR n’est pas une base historique, mais alimente une ou
plusieurs bases, en mettant à disposition les données. Les ‘clients’ possibles sont un éventuel
infocentre Tipi, SICOT (selon les choix, cf partie III).
L’administrateur définit les adresses autorisées à se servir dans des fichiers mis à
disposition via le web, et la fréquence de mise à jour de ces fichiers.
Par ailleurs, l’application stocke les dernières 24 heures de données, afin de permettre leur
visualisation, ainsi que des paramètres (seuils pour calcul des NS, ou valeurs typiques,
éventuellement plusieurs selon le type de jour).
H. échanger les données : acquisition externe
L’acquisition de données « externes » (CIGT hors ministère : SCA, CG, autres gestionnaires
gestionnaires ou urbains) peut s’effectuer selon le même principe que celles de CIGT DIR tant
que les interfaces de communication avec les frontaux RDT (MI2 en premier lieu), à condition
que les accès réseau soient ouverts et de s’être avec les partenaires.
L’utilisateur est un administrateur.
I. échanger les données : diffusion externe
L’information des usagers sur le web (site Bison Futé, etc.) stricto sensu est hors du
périmètre, en revanche la diffusion de données relève bien de l’application OTTR, qui doit
publier les données en temps réel pour une réutilisation par d'autres gestionnaires et les
opérateurs de service en information routière. Cela peut donc recouvrir 2 types de fonctions :
- la visualisation de synoptique temps réel peut être ouverte sur internet dans des conditions
à préciser. Les utilisateurs concernés sont des internautes, typiquement autres exploitants
routiers, salle de crise en préfecture.
- la mise à disposition de données ‘bien formatées’ pour des tiers (opérateurs d’info trafic)
Comme on l’a indiqué au niveau de la fonction ‘visualiser les données’, la notion de vue
peut intégrer de manière générale différents formats, dont des formats texte de diffusion de
données, type XML, Datex2 ou autres.
La diffusion externe doit pouvoir s’effectuer selon le même principe qu’en interne, à
condition que les accès réseau soient ouverts
III.
MISE EN OEUVRE
Tipi n'est pas une application main un système d'information qui englobe plusieurs
applications (dont potentiellement OTTR) qui mutualisent certaines fonctions et certaines
Besoins fonctionnels synoptique trafic
13
données : le couplage entre les applications est donc non seulement souhaitable, mais
souhaité ! Toutefois, une approche très modulaire permet un partage des fonctions clair et
économique.
Il nous semble pertinent pour simplifier la conception et faciliter les évolutions, et faisable,
que l’application OTTR soit découplée des applications avec lesquelles elle interagit :
- frontal ou SAGT en amont
- l’IHM Tipi en aval
- BDTD (SICOT ou autre infocentre) en aval
Il nous semble utile que ce point soit discuté dès cette phase de conception générale, car la
discussion sur ces points permettra en même temps de bien définir le périmètre (frontière entre
temps réel et temps différé, frontière entre RRN et externe, besoins CIR / DIR / Centrale,
frontière entre données trafic / événements / référentiels / systèmes / autres) et de réfléchir à
moyen terme sur les évolutions à horizon 10 ans (ce qui est la durée de vie minimale d’une
application !).
A. interfaces frontal
La plupart des CIGT qui disposent de recueil 1’ ou 6’ permanent via un réseau fixe
propriétaire ont également mis en place le MI2 en vue d’être interrogé par un MI 2 installé au
CETE med ou par le SICOT Socle, ce MI2 étant alimenté par le frontal de recueil. Pour une
bonne moitié des CIGT (ceux qui sont dotés d’un SAGT, en général), les MI2 ne sont pas
utilisés pour l’interrogation des stations, mais en tant que relais pour fournir des données à
d’autres applications (Arpèges, Astec) ; les MI2 utilisés pour le recueil sont A20, A75, Caen,
Osiris, et sans doute Aliénor, plus tous les petits CIGT qui n’ont pas forcément de recueil 6’
permanent (Nimes, Gap pour la DIRMED, etc.). Les CIR se raccordent normalement aux
autres MI 2 des gestionnaires DIR ou SCA mais ne sont plus censés interroger directement les
stations (sauf celles des CG, parfois !).
Il existe une grande diversité de frontaux RDT. Il n’existe pas à notre connaissance
d’interface standard pour interroger un frontal, néanmoins la plupart des produits existants ont
des interfaces web, qui pourraient être adaptées si besoin à une spécification ministère.
Le frontal utilisé systématiquement dans les DIR actuellement est le MI2, accessible
uniquement en LCR, ce qui semble poser un problème lorsqu’il s’agit d’accéder fréquemment à
plusieurs centaines de stations. Il faudrait donc en priorité concevoir et développer une
interface web d’accès aux données MI2, puis utiliser les mêmes spécifications d’interface pour
développer progressivement l’accès à d’autres applications (SAGT ou autre).
En termes de modalité d’échange entre OTTR et un frontal, il nous semble le plus naturel
d’utiliser HTTP et fonctionner de manière asynchrone, sans traitement des échecs ni mode
reprise (comme cela est fait au niveau des frontaux), tant pis si on perd des données de temps
en temps :
- côté frontal : mise à disposition via une URL en HTTP chaque 6’ (ou chaque 1’) d’un
fichier contenant les nouvelles valeurs pour la minute en cours
- côté application trafic : récupération des données 1’ chaque minute auprès de chaque
frontal en HTTP, mise à jour de la donnée courante « temps réel » et alimentation d’un BDTD
En termes de données échangées, il faut a minima être capable de recueillir les données 6’
des MI2. On peut également s’inspirer des spécifications d’interface entre les SAGT Steria et les
frontaux RDT, qui sont quasiment standard d’un système à l’autre et couvrent une grande
diversité vu le nombre de systèmes déployés.
Besoins fonctionnels synoptique trafic
14
B. interface BDTD
En termes de données temps différé, chaque exploitant gère en général des archives voir
des serveurs de données temps différé en ligne. Les données des SAGT sont archivées, celles
des MI2 aussi, etc. Il existe parfois dans certaines agglomérations des observatoire des trafic ou
de déplacements, où sont mutualisées les données de plusieurs partenaires. Les données de
Tipi sont ou seront archivées. Les données de OTTR devront sans doute aussi être archivées.
Les besoins de données peuvent être différents, entre l’exploitant d’une DIR qui veut
analyser finement a posteriori le traitement d’un accident grave, une DRE ou la DIT qui veut
comparer la congestion ou le NS de plusieurs VRU d’agglomération, un chargé d’étude du
SETRA ou d’un CETE qui doit calculer des indicateurs statistiques nationaux ou observer
l’évolutions du trafic sur plusieurs années, etc. Il y aura donc en pratique selon les cas besoin
d’accéder à une plusieurs bases, via éventuellement une application, et il semble impossible
qu’il y ait un jour une seule base et application nationale gérant toutes les données historisées
du RRN.
En pratique, rien n’empêche que OTTR alimente plusieurs applications ou bases TD, par
exemple SICOT d’une part (si cette application se limite à récupérer sur les données brutes 6’
pour les agréger en données horaires et journalières), et d’autre part un éventuel ‘infocentre
Tipi’ qui pourrait aussi archiver aussi d’autres données (événements, messages PMV ou
autres).
En pratique cette alimentation peut se faire de la même manière qu’entre frontal et OTTR :
OTTR met à disposition sur un répertoire toutes les x minutes ou moins (toutes les nuits) une
série de données sous forme de fichier texte (XML ou autre) via HTTP. L’application temps
différé va les chercher à son rythme (toutes les nuits par exemple).
Néanmoins, pour ce concerne SICOT, il est également possible que SICOT s’alimente
aussi comme le fera OTTR directement auprès des frontaux, notamment si est développée une
interface web d’interrogation des MI2 (après validation que cette interface web « tient la
route »).
C. Prochaines étapes
Il nous semble possible de réaliser un prototype en parallèle et de l’élaboration du DAF
destiné à la réalisation ACAI de l’application.
Cela permettrait d’identifier (et résoudre) sans doute certains problèmes technique ou
fonctionnels, et de montrer quelque chose aux utilisateurs visés dans les DIR et CIR.
Après validation par la MOA (DIT/GRT – SETRA) et des utilisateurs potentiels
(CIR/DIR), la prochaine étape sera la décomposition des besoins retenus en briques
fonctionnelles, pour évaluation de la réutilisation ou de la mutualisation avec les autres
applications existantes ou futures du système d'information Tipi ; cette évaluation comprendra
bien sûr une estimation des coûts et délais et doit aboutir à des spécifications en vue d’une
réalisation ; une étape de prototypage pourra faciliter cette tâche. Les briques nous semblent
être :
- un moteur de visualisation trafic (qui pourrait être celui de TIPI, éventuellement adapté),
capable de lire les données TR produites par l’application TTR, mais aussi des données TD
- un serveur web d’accès au MI2 réutilisable pour interroger à termes d’autres types de
frontaux
- une application de gestion des données TTR : capable de recueillir les données du MI2 via
le web, administrable via le web, permettant en priorité le calcul des Niveaux de Service et
permettant leur publication à divers formats, notamment vers le moteur de visualisation, vers
une BDTD telle que SICOT, vers des outils de publication tels que la chaîne Bison Futé
Besoins fonctionnels synoptique trafic
15
Les questions qui se posent à court terme :
- quel est le calendrier et le processus de validation ?
- dans quelles conditions peut-on prévoir la reprise de l'activité Sicot?
- qui va effectuer l’étude technique de faisabilité des ‘briques fonctionnelles’ ?
- à quelle échéance des services tels que les CRICR peuvent-ils espérer commencer à
utiliser ce genre d’outils (TR + TD) en remplacement de GERICO (qui traite le TR et le TD) ?
A moyen terme, la question des conditions d’accès et d’utilisation des données TR des SCA
ou des Collectivités doit être également traitée si ce n’est pas encore le cas.
IV.
GLOSSAIRE :
DAF
Dossier d’Analyse Fonctionnelle
NS
niveau de service
PM
point de mesure
QV
débit vitesse
RDT
recueil de données de trafic
SICOT
TD
temps différé
Tipi
système d'information pour l'exploitation et l'information routières du ministère
TP
temps de parcours
TR
temps réel
OTTR
(application) observation du trafic temps réel
V. ANNEXES
A. Annexe 1. Proposition du CETE
version du 30/06 mise à jour suite aux mails de C André et C Paquet
Besoins fonctionnels synoptique trafic
16