Un Service Internet du Futur pour le suivi des voyages multimodaux

Transcription

1 Un Service Internet du Futur pour le suivi des voyages multimodaux Mahdi Zargayouna 1, Besma Zeddini 1, Gérard Scemama 1 1. Université Paris-Est, IFSTTAR, GRETTIA Boulevard Newton, Champs sur Marne F Marne la Vallée Cedex 2, France hamza-mahdi.zargayouna@ifsttar.fr Résumé Le projet Européen Instant Mobility a pour objectif de définir une architecture complète pour les applications de transport et de mobilité, en se fondant sur les technologies de l'internet du futur. Dans cet article, nous décrivons une plateforme de voyage multimodal fondée sur ces technologies qui fournit des informations et des services capables de supporter de nouveaux types d'applications de transport. Le scénario envisagé, un «assistant personnel», est centré sur les voyageurs multimodaux. Le projet définit les exigences pour les facilitateurs qui peuvent intégrer les services disponibles à tout voyageur connecté à Internet (en utilisant un terminal portable ou un ordinateur embarqué dans le véhicule). Les technologies de l'internet du futur offrent de nouveaux horizons pour les systèmes d'information de transport et sont à même de proposer aux voyageurs une expérience nouvelle avec les moyens de transport. Nous sommes en train de concevoir et de réaliser un prototype d'aide aux déplacements multimodaux en profitant de ces technologies. Mots Clés: Internet de futur, assistance au voyage multimodal, monitoring, optimisation en ligne I. Introduction L'Internet, les services web, le cloud computing, les réseaux sociaux et l'internet des objets offrent de nouvelles possibilités pour les applications de transport, qui n'étaient pas imaginables il y a de cela quelques années. L'utilisation des technologies de l Internet du futur nous permet désormais de fournir en temps réel des informations et des solutions mises à jour de mobilité pour les déplacements multimodaux. Désormais, les voyageurs doivent être en mesure d'accéder à des informations sur les modes de transport, leur disponibilité, les conditions tarifaires, le fonctionnement de leur exploitation, etc., ce qui permet la planification d'un itinéraire optimisé et mis à jour selon un grand nombre de critères. Il est maintenant possible de connecter tous les modes de transport et les véhicules en cas de besoin pour assister un voyageur lors d'un voyage

2 multimodal, l'informant de toute perturbation et lui délivrant un choix de solutions alternatives. L application cible guide le voyageur de transport en commun ou dirige le conducteur du véhicule privé tout au long de son itinéraire. Elle fournit également une application de paiement mobile sans billet, via le téléphone portable du voyageur, pour des services de mobilité tels que les transports en commun, le stationnement, les péages urbains, le covoiturage, etc. Dans ce papier, nous présentons la plateforme service de voyage multimodal (MMT) qui met à disposition le sous-ensemble essentiel de ces services. II. Scénario et hypothèse Dans le scénario que nous considérons, des services en ligne offrent à un voyageur un large éventail de voyages personnalisés et des options de transport, en fonction de ses préférences. Le voyage peut inclure divers modes, tels que les transports en commun, le vélo, la voiture, et le covoiturage. Lors de la planification d un trajet donné, le voyageur reçoit un certain nombre d itinéraires optimaux qui respectent ses préférences et qui prennent en compte les dernières informations en temps réel de tous les modes pertinents. Une fois l'itinéraire choisi, l'application délivre un reçu de billet intégré tout en préparant un paiement unique sur le compte du voyageur. Le voyageur est guidé tout au long de son voyage pour descendre au bon arrêt, traverser un pôle d'échange, trouver l arrêt suivant, etc. Pendant le voyage, l'itinéraire est vérifié en permanence, et le voyageur est alerté dès que les conditions de voyage changent. L'itinéraire courant est mis à jour en fonction de ces changements et des choix du voyageur. Le compte du voyageur est débité à la fin de son voyage. Cela signifie que s il y a un problème avec le voyage planifié, cela est pris en compte, et l'utilisateur n'aura pas à demander un remboursement en cas de changement. Il n a également à payer que pour le service qu'il a demandé et consommé. Cela signifie qu'un voyageur qui utilise un seul moyen de transport ne paye que pour ce service. Nous posons deux hypothèses principales dans le cadre de la plateforme MMT. D'une part, nous supposons que chaque équipement mobile des voyageurs connaît sa position et que chaque véhicule de transport (public et privé) est localisé et suivi en permanence. D'autre part, la plateforme doit être autant capable de traiter les réservations de service que de répondre aux requêtes instantanées. Elle doit être capable, en outre, de gérer les changements d itinéraires en temps réel, en intégrant toutes les nouvelles demandes de voyageurs ainsi que les incidents de trafic et les déviations. Le scénario est formalisé avec le diagramme de cas d'utilisation de la figure 1.

3 uc Dynamic multi-modal journey UC1.X are associated with user application processes in "1. Dynamic multi-modal journey" Traveler User application processes UC1.01: Manage Subscribtion UC1.02: Request Journey Plan travel : Special Needs UC1.04: Execute Journey UC1.06: Rate Journey UC1.07: Set User Preferences UC1.03: Accept Journey UC1.07: Receive Ev ent Information UC1.05: Transfer Long-running processes «invokes» «invokes» UC1.10: Manage Instant Mobility User UC1.15: Charge User Journey UC1.11: Compute Multi-modal Journey UC1.13: Assist for Transfer UC1.12: Compute Profil UC1.14: Compute Rating for Statistics Ticketless Mobile Payment : Ticketless Mobile Payment Human activities «invokes» «invokes» Clear Billing:: External Process Retailers UC1.20: Accept User (Un)Subscription «invokes» «invokes» Transfer Funds:: External Process «invokes» «invokes» Financial Operator Short-running processes Consult Rating «extend» Statistics Driv er Transport Operator UC1.30: Validate Subscription UC1.31: Validate Unsubscription Credit Account? Debit Account? UC1.35: Set Journey Rate Figure 1 Scénario Le principal défi de ce scénario et de ces hypothèses est double: Du point de vue technologique, trouver les bonnes architectures et les fonctionnalités du système pour tirer pleinement profit des technologies de l'internet de futur, tout en respectant les préférences des voyageurs et des besoins de confidentialité des données; Du point de vue algorithmique, de trouver les bonnes procédures et les mécanismes d'équilibrage afin de guider chaque voyageur sur son 'itinéraire optimal, tout en évitant d'ajouter à la congestion du trafic et la surcharge dans les transports publics. III. Interface publique du service La figure 2 présente une vue de la plateforme multimodale d'un point de vue externe. Elle spécifie les exigences, pour une région particulière, pour la mise en place d un service de mobilité instantanée et les différents échanges qui devraient avoir lieu avec la plateforme. La plateforme interagit avec trois types d'acteurs: les opérateurs de transports publics, les opérateurs de transport routier et les voyageurs.

4 Figure 2 - Interface publique de la plateforme multimodale Chaque opérateur de transport public doit fournir à la plateforme une description de son réseau et leurs tableaux de marche théoriques. Comme le montre la figure, nul besoin d'avoir une base de données commune aux opérateurs de transport qui intègrent tous les moyens de transport publics et les réseaux. Chaque opérateur de mode de transport pourrait avoir sa propre base de données et la plateforme doit les intégrer et les gérer simultanément. Chaque opérateur de transport public doit fournir 3 types de données: La description de l'offre de transport La position, l'avance / le retard de toute sa flotte Les événements qui provoquent des perturbations des services de transport Comme pour les opérateurs de transport public, les opérateurs de transport routier doivent fournir à la plateforme MMT une description de leur réseau, ainsi que toute les informations statiques qui lui sont liées. Ils doivent également fournir 3 types de données: La description du réseau routier Les vitesses, les densités, les taux d'occupation ou les états des routes Les événements qui impactent l'offre de transport Toutes ces données échangées doivent être conformes aux dernières normes européennes. Pour notre application, les données concernant les réseaux multimodaux sont issues de la

5 plateforme intelligente multimodale ClaireSiti qui possède un modèle générique de représentation des réseaux multimodaux et joue le rôle d agrégateur de données (Scemama et al., 2004). ClaireSiti constitue un middleware entre les fournisseurs de données et la plateforme de service MMT. Les voyageurs interagissent avec la plateforme en utilisant des protocoles de communication standards. Chaque voyageur fournit au système son profil, qui contient des informations détaillées sur ses propriétés et ses préférences. Une fois qu'un plan est reçu à partir de la plateforme, l'appareil mobile de l'utilisateur envoie dynamiquement sa position courante à la plateforme. Si la différence entre la position réelle du voyageur et la position prévue (à savoir la position attendue selon le plan qui a été proposé pour le voyageur) est assez grande, selon les préférences du voyageur, ce dernier reçoit un nouveau plan en tenant en compte son nouveau contexte. cmp MMT Model Instant Mobility scope «device» Smartphone Traveler RT operator Communication Forecast PT operator Monitoring Planning Figure 3 Modules de l'application IV. Modèle On définit une représentation de haut niveau de la plateforme MMT d'un point de vue fonctionnel. Le modèle comprend quatre modules conçus comme des éléments indépendants et faiblement couplés (cf. Figure 3): Le module de communication (communication) est responsable de l'interaction de MMT avec le monde extérieur (les opérateurs de transport routier, transport public, et les voyageurs); Le module de planification (planning) est responsable de la planification et de la

6 re-planification des itinéraires de voyage (voir figure 4); Le module de prévision (forecast) gère la meilleure vision possible de l'état futur des réseaux. Le module de planification fonde son calcul sur le résultat de ce module; Enfin, le module de suivi (monitoring) surveille l'exécution des plans des voyageurs. Le dispositif mobile du voyageur peut stocker des informations qui pourraient accélérer le calcul et / ou améliorer la qualité des solutions qui lui sont fournies. Par exemple, il pourrait stocker des informations sur les habitudes de déplacement des usagers. Cela permettrait d'économiser beaucoup de temps des utilisateurs en leur proposant immédiatement des suggestions et des recommandations. cmp Planning Planning Forecast Trip planner Ride sharing Forecast::Traffic simulator Equilibrium manager Planner Forecast::Travel times forecast Optimizer MMT Model) Communication Communication:: Traveller agent «database» Itineraries «sync» «database» Itineraries index MMT Model) MMT Model) «device» MMT Model:: Smartphone Traveler Figure 4 Module de planification V. Expérimentations et résultats Nous avons mis en place une démonstration qui évalue l'impact de l'utilisation de la plateforme sur la qualité du trafic multimodal, notamment dans des conditions de circulation exceptionnelles (pannes, accidents, etc.). La démonstration valide également l'effet de la plateforme sur l'utilisation réelle du service de covoiturage.

7 La figure 5 montre la configuration de la démonstration. La plateforme et le simulateur s exécutent dans un serveur dédié. La plateforme interagit avec le serveur qui fait correspondre les itinéraires des conducteurs et les requêtes des passagers. Si un conducteur accepte de partager son véhicule avec un passager, le serveur vérifie la conformité de leurs préférences et propose aux deux acteurs de partager un trajet. Figure 5 la configuration de la démonstration L'interface graphique (GUI) s'exécute sur un serveur et affiche tous les passagers courants, les conducteurs et les véhicules privés et publics. Lorsque l'on clique sur un passager, on a accès à son itinéraire et tous les modes qu il prévoit d'utiliser. Une application mobile et une unité embarquée interagissent également avec le serveur de l interface graphique. Lorsque l'on clique sur un passager spécifique, l'application mobile se connecte au serveur et obtient son itinéraire. Si le passager a une partie de trajet en covoiturage qui lui est prévu, l'application de l'unité embarquée se connecte également au serveur et obtient l'itinéraire du véhicule privé. Les profils du conducteur et des passagers sont présentés dans

8 chacun des autres équipements, les deux acteurs peuvent accepter ou refuser l offre. Ce scénario rejoue en quelque sorte ce qui s'est préalablement passé entre le conducteur et le passager afin de planifier leur trajet commun. Enfin, le passager sera en mesure de suivre la position en temps réel du conducteur jusqu'à ce qu'ils se rencontrent. Figure 6 Simulation VI. Implémentation Nous démontrons l'utilisation de la plateforme pour la ville de Toulouse, pour laquelle nous disposons de données détaillées récupérée de la plateforme ClaireSITI (Scemama et al., 2004), y compris des modèles de demande de voyage urbain (voir figure 2). Nous avons considéré un réseau contenant les routes principales de Toulouse avec routes. Nous avons également considéré le réseau de transport public de Toulouse à 80 lignes, 359 itinéraires et arcs. Dans nos simulations actuelles, notre système est composé de agents : bus, voitures, conducteurs et passagers. La simulation des déplacements des voyageurs (piétons, cyclistes, passagers, etc.), des

9 conducteurs de voitures, des voitures et des moyens de transport est effectuée avec la plateforme de simulation multi-agent Repast (Tatara et al., 2009). Cette plateforme open source écrite en Java est équipé d'outils SIG (Système d Informations Géographique) qui permettent une représentation pertinente des applications de transport (voir figure 6). La distribution des traitements sur plusieurs hôtes est réalisée via le middleware Terracotta (Terracotta Inc., 2008), une API qui effectue la distribution au niveau de la JVM. L'interaction entre le simulateur, la plateforme et les différents services (GUI, l application mobile, et l'application de l'unité embarquée) est fondée sur des services Web REST (Richardson et al., 2007). VII. Perspectives Une question importante lors de l'élaboration de la plateforme de voyage multimodal est d'évaluer sa capacité à gérer un très grand nombre de voyageurs et de moyens de transport. En outre, elle doit conserver une grande réactivité lorsqu'il s'agit de grands réseaux et des grandes régions géographiques. Dans un proche avenir, nous planifions de développer des scénarios avec des centaines de milliers de passagers et de conducteurs pour vérifier que notre application passe bien à l échelle. Par ailleurs, des travaux restent à approfondir concernant les modules de planification, avec la prise en compte de l équilibre des réseaux et de la prévision du trafic. Remerciement Ce papier reflète seulement les opinions des auteurs, l'union européenne n'est pas responsable de l'usage qui pourrait être fait des informations qui y sont contenues. Le travail présenté est effectué dans le cadre du projet Instant Mobility, qui a reçu financement de recherche de l'union européenne, au titre du programme FP ICT-FI. Références 1. E. Tatara and J. Ozik (2009) How to Build an Agent-Based Model III -- Repast Simphony, In Applied Agent-based Modeling in Management Research, Academy of Management Annual Meeting, Chicago, Terracotta Inc (2008). The Definitive Guide to Terracotta: Cluster the JVM for Spring, Hibernate and POJO Scalability, Springer. 341 pages. 3. Richardson L, Ruby, S (2007) RESTful web services, O'Reilly Media, 421 pages.

10 4. G. Scemama, O. Carles (2004) CLAIRE-SITI, public and road transport network management control: a unified approach. 12th IEE International Conference on Road Transport Information and Control, London (UK), April 2004, pp11-18.