FR 2860328 A1 20050401 FR 0311256 A 20030925 SYSTEME D'INFORMATION D'USAGERS D'UN RESEAU DE TRANSPORT La présente invention se rapporte au domaine des Technologies de l'Information et de la Communication. La présente invention se rapporte plus particulièrement à un système d'information d'usagers d'un réseau de transport équipés d'un équipement client. L'art antérieur connaît déjà, par la demande de brevet PCT WO 00/19170 (Global Research Systems), un système de déclenchement d'un dispositif de notification anticipée pour la surveillance et la communication des déplacements d'un véhicule. L'invention décrite dans ce document concerne un système de surveillance automatique des déplacements de véhicules en réponse à des demandes d'utilisateurs situés en des points éloignés. Un utilisateur éloigné soumet un indicateur de véhicule (par exemple un numéro d'autobus) et un indicateur de position (tel qu'un numéro d'arrêt d'autobus) à un système de suivi de véhicules comprenant un gestionnaire de données. Un capteur GPS couplé au système de suivi de véhicules détermine les coordonnées du véhicule par rapport à un point ou une position de référence déterminé. Un réseau cellulaire ou une interface de communications reliée au système de suivi de véhicules et à une unité de commande de station de base relaie la demande de l'utilisateur. L'unité de commande de la station de base comprend également un gestionnaire de station de base. Le gestionnaire de données extrait automatiquement les données de déplacement et de position à partir de l'indicateur de véhicules et de l'indicateur de position. En comparant ces deux types de données, le gestionnaire de données est à même de déterminer si le véhicule se trouve dans une zone prédéterminée de proximité du point représenté par les données de position. Lorsque le véhicule entre dans cette zone de proximité (c'est-à-dire lorsque l'arrivée du véhicule au point attendu est imminente), le gestionnaire de données envoie automatiquement un message de notification à l'utilisateur éloigné. La présente invention entend remédier aux inconvénients de l'art antérieur en proposant un système d'information d'usagers d'un réseau de transport équipés d'un équipement client, pour la communication du temps estimé DECii de passage d'un véhicule Vi à une position Pi possédant une architecture innovante composée d'un serveur d'exploitation, un module d'interfaçage, un serveur d'application et un serveur d'affichage. A cet effet, la présente invention concerne, dans son acception la plus générale, un système d'information d'usagers d'un réseau de transport équipés d'un équipement client, pour la communication du temps estimé DECii de passage d'un véhicule Vi à une position Pi comportant: É un serveur d'exploitation SEA délivrant des données numériques correspondant à l'heure réelle de passage d'une partie au moins des véhicules V à une partie au moins des positions de référence P É un module d'interfaçage SIC installé sur ledit serveur d'exploitation SAE, assurant une conversion desdites données numériques en un format spécifique à un serveur d'application, et la transmission desdites données converties DC au serveur d'application É un serveur d'application comportant une base de données horaires théoriques, filtrant les données DC pour ne transmettre au serveur d'affichage que les données présentant une différence D avec la donnée horaire théorique correspondante supérieure à une valeur prédéterminée É un serveur d'affichage comportant une table adressable rafraîchie périodiquement par les données transmises par le serveur d'application, et des moyens de requêtage et de transmission de l'information à un équipement client. Avantageusement, lesdites données converties DC sont constituées par l'intervalle entre le temps réel de passage d'un véhicule V à une position Pi, et le temps théorique de passage. De préférence, le système comporte des moyens pour le calcul des données pour une position Pi dont on ne connaît pas d'information sur les données réelles, par extrapolation d'une partie au moins des données réelles connues. Selon un mode de réalisation particulier, ladite table du serveur d'affichage est une table structurée en vues, ledit serveur d'affichage comportant des moyens de calcul de prérequêtes. Selon une variante, le serveur d'affichage comporte une librairie gérant l'affichage selon un protocole de mise en forme de contenu destiné à des téléphones mobiles. Avantageusement, le serveur d'affichage comporte des moyens de reconnaissance vocale. Selon un mode de mise en uvre particulier, le système comporte des moyens de géolocalisation de l'équipement mobile de l'utilisateur, et de calcul d'une requête fonction de l'information de géolocalisation et de l'heure de la communication. On comprendra mieux l'invention à l'aide de la description, faite ciaprès à titre purement explicatif, 30 d'un mode de réalisation de l'invention, en référence aux figures annexées: É la Figure 1 illustre l'architecture du système selon l'invention; É la Figure 2 représente le format horaire utilisé ; É la Figure 3 illustre l'architecture interne du système; É la Figure 4 illustre une architecture fonctionnelle mise en uvre dans le système selon 5 l'invention; É la Figure 5 représente un schéma de communication mise en uvre dans le système selon l'invention; É la Figure 6 représente la manière dont les différentes classes interfèrent au niveau du serveur 10 d'affichage. Nous allons décrire dans ce qui suit un mode de réalisation du système selon l'invention. Il est entendu que cette description ne saurait être limitative. Un SAE (Système d'Aide à l'Exploitation) répond en temps réel à des requêtes. On peut distinguer trois couches dans le système: É une couche applicative; É une couche d'affichage; É une couche de contrôle / supervision. La couche applicative est interrogeable par des équipements mobiles compatibles WAP. Le système de requêtes est utilisable pour des accès du type SMS, MMS, i-mode, Java. Le système selon l'invention met en uvre le SAE, en extrait des informations et compose un document XML et une base de données numériques. L'intérêt principal du format XML est que le flux XML est exploitable de manière indépendante pour d'autres interfaces. La base de données numériques est utilisée en continu dans le cadre de requêtes du type temps d'arrêts . La couche affichage comporte, au moins dans un mode de réalisation, une librairie. Cette couche permet de gérer la multitude de terminaux présents sur le marché. Ainsi, les pages de résultats sont optimisés pour chaque équipement mobile client. La couleur et le noir et blanc sont gérés de cette façon. La couche de contrôle/supervision comporte, au moins 5 dans un mode de réalisation, des interfaces d'administration. Ainsi, les statistiques de fréquentation sont connues en temps réel. Le parcours des utilisateurs est qualifié grâce au suivi de session mis en place sur le site. La Figure 1 illustre l'architecture du système selon 10 l'invention. La Figure 2 représente le format horaire utilisé. Ce format s'applique bien aux réseaux de transport. On entend par VIA une boucle temporaire rajoutée sur un trajet. Ces trajets sont utilisés à des fréquences 15 différentes de celles du trajet principal. Le calendrier prévisionnel fournit l'intégralité des lignes et des horaires disponibles sur un réseau. Considérons les étapes de transmissions de données: É le SAE transfère des données ASCII (temps réel) au 20 SIC; É le SIC formate les données ASCII à un format dit format Mobi sur un serveur FTP; É Un module extrait un flux XML des données ASCII toutes les n secondes et constitue une base de données 25 numériques; É A chaque insertion dans une première base de données, une autre base de données est mise à jour; É Le script d'affichage construit la page Wap finale en utilisant les vues présentes dans la base de données. L'interface est composée de trois fonctions principales: É Collecte des données SAE; É Réorganisation des données et création du fichier 35 des horaires; É Copie du fichier sur un sous-système dit mobi . La fréquence de transmission des informations sur le sous-système Mobi est basée sur la fréquence de réception des informations SAE soit toutes les 48 secondes pour les données Bus et toutes les 10 secondes pour les données tramway (par exemple). L'apparition d'événements asynchrones, tels que l'arrivée d'un tramway en station ne provoque pas d'émission particulière à destination du sous-système Mobi . Afin de ne pas perturber le fonctionnement du logiciel SIC standard, la fonctionnalité Mobi est assurée par un processus indépendant qui est lancé automatiquement au démarrage du serveur SIC. L'architecture interne est représentée sur la Figure 3. Le SIC récupère ses informations en parallèle sur les deux systèmes SAE. Le procédé algorithmique mis en uvre est le suivant: 1. Création d'un fichier. 2. Paramétrage de l'accès à ce fichier. 3. Activation du programme de création de fichiers. 4. Attente de l'heure de début de journée. 5. Création de la table des prochains horaires à afficher en mémoire partagée. 6. Gestion de début de service. 7. Pondération des horaires en mémoire avec les décalages issus des systèmes SAE et mise à jour des données sur disque. 8. Mise à jour du statut d'affichage de l'horaire pour chaque bloc lu puis écriture du bloc dans une file 30 FIFO. 9. Gestion du top d'affichage. 10. Traitement des requêtes de création/effacement de messages. 11. Elaboration des prochains départs en mémoire. 35 12. Gestion de fin de services. 1 3 Effacement du fichier transactions des transactions échues. 14. Gestion du changement de journée. Afin de ne pas charger inutilement le serveur SIC, il a été décidé de limiter le jeu de données aux seules lignes équipées de panneaux à terre. Le module d'exploitation va donc détecter des erreurs lors des contrôles de cohérence pour les nouvelles lignes de bus. Un module est chargé de la récupération, de la mise en forme et de la création du fichier des horaires. Le procédé algorithmique mis en uvre est le suivant: 1. Ouverture de fichier. 2. Initialisation des structures temporaires. 3. Lecture bloquante avec durée maximale de lecture paramétrable. 4. Stockage des blocs dans une structure temporaire. 5. Gestion de l'inter-trame par type de temps 20 d'attente. 6. Si un nouveau fichier horaires a été créé : transmission sur un serveur et initialisation de la structure intermédiaire correspondante. 7. Retour à l'étape 3. Le transfert du fichier des horaires consiste à copier un fichier texte vers un serveur dit serveur Mobi . Ce transfert est déclenché à l'issue de l'algorithme de création du fichier des horaires. De même que précédemment, un procédé algorithmique est mis en uvre. Les différentes étapes de ce procédé sont: connexion FTP, sélection d'un répertoire, test de présence d'un fichier, création d'un fichier, archivage d'un fichier de données puis effacement d'un fichier. Des mécanismes particuliers sont également mis en place pour le paramétrage du transfert FTP, la gestion de l'archivage et la gestion des erreurs. Les informations transmises à Mobi sont organisées sous forme de fichiers: un premier fichier pour les temps d'attente tramway et un second fichier pour les temps d'attente bus. Cette séparation permet d'optimiser la transmission des informations en fonction de la fréquence de rafraîchissement des informations SAE. Le serveur SIC indique au serveur Mobi qu'il peut prendre en compte les informations en créant un fichier marqueur . La présence de ce fichier bloque toute tentative ultérieure de transfert de la part du serveur SIC, le serveur Mobi se chargeant d'effacer le fichier dès que le fichier horaire correspondant a été intégré dans la base de données. La Figure 4 illustre une architecture fonctionnelle dans laquelle le format d'échange entre Mobi et Mobivillage . La Figure 5 représente un schéma de communication. Le flux XML permet de transmettre le référentiel géographique à chaque modification. Il est également généré toutes les n minutes avec les horaires temps réel afin de garantir une utilisation universelle de l'application. Le document appelé XML-data contient les informations pertinentes. La Figure 6 représente la manière dont les différentes classes interfèrent au niveau du serveur d'affichage. Le 30 serveur d'affichage utilise un moteur qui génère du code (WML, X-HTML) adapté aux caractéristiques du terminal. Dans une variante, le système selon l'invention est associé à un soussystème de géolocalisation. 2860328 9 L'invention est décrite dans ce qui précède à titre d'exemple. Il est entendu que l'homme du métier est à même de réaliser différentes variantes de l'invention sans pour autant sortir du cadre du brevet. REVENDICATIONS 1 - Système d'information d'usagers d'un réseau de transport équipés d'un équipement client, pour la communication du temps estimé DECii de passage d'un véhicule Vi à une position Pi comportant: É un serveur d'exploitation SEA délivrant des données numériques correspondant à l'heure réelle de passage d'une partie au moins des véhicules V à une partie au moins des positions de référence P É un module d'interfaçage SIC installé sur ledit serveur d'exploitation SAE, assurant une conversion desdites données numériques en un format spécifique à un serveur d'application, et la transmission desdites données converties DC au serveur d'application É un serveur d'application comportant une base de données horaires théoriques, filtrant les données DC pour ne transmettre au serveur d'affichage que les données présentant une différence D avec la donnée horaire théorique correspondante supérieure à une valeur prédéterminée É un serveur d'affichage comportant une table adressable rafraîchie périodiquement par les données transmises par le serveur d'application, et des moyens de requêtage et de transmission de l'information à un équipement client. 2 Système d'information selon la revendication 1, caractérisé en ce que lesdites données converties DC sont constituées par l'intervalle entre le temps réel de passage d'un véhicule V à une position Pi, et le temps théorique de passage. 3 Système d'information selon la revendication 1, 35 caractérisé en ce qu'il comporte des moyens pour le calcul 2860328 11 des données pour une position Pi dont on ne connaît pas d'information sur les données réelles, par extrapolation d'une partie au moins des données réelles connues. 4 Système d'information selon la revendication 1, caractérisé en ce que ladite table du serveur d'affichage est une table structurée en vues, ledit serveur d'affichage comportant des moyens de calcul de prérequêtes. 5 Système d'information selon la revendication 1, caractérisé en ce que le serveur d'affichage comporte une librairie gérant l'affichage selon un protocole de mise en forme de contenu destiné à des téléphones mobiles. 6 Système d'information selon la revendication 1, caractérisé en ce que le serveur d'affichage comporte des moyens de reconnaissance vocale. 7 Système d'information selon la revendication 1, caractérisé en ce qu'il comporte des moyens de géolocalisation de l'équipement mobile de l'utilisateur, et de calcul d'une requête fonction de l'information de géolocalisation et de l'heure de la communication.