Protocole standardisé pour une recherche d’itinéraire distribuée

Présentation au sujet: "Protocole standardisé pour une recherche d’itinéraire distribuée"— Transcription de la présentation:

1 Protocole standardisé pour une recherche d’itinéraire distribuée
APII-SIM Protocole standardisé pour une recherche d’itinéraire distribuée

2 Pourquoi ce projet ? Il n’existe pas en France de calculateur d’itinéraires réparti entre plusieurs SIM, alors que les besoins des usagers ne s’arrêtent pas aux frontières administratives. La seule solution d’interopérabilité actuelle est l’initiative privée EU-SPIRIT dont Canal TP et Cityway ont chacun constaté les limitations techniques et fonctionnelles. Eu-Spirit : association gérée par Hacon. Protocole Delfi sans instanciation serveurs actifs / passifs locaux. D’ou pb de traitement d’iti entre zones frontalières très interconnectées. Echanges des interconnexions par fichier Excel.

3 Les objectifs Rendre possible le calcul d’un itinéraire de porte à porte, principalement TC, mais à vocation multimodale A cet effet, élaborer des spécifications d’interface publiques: une API RI distribuée Illustrer l’utilisation de cette API RI à l’aide d’un démonstrateur fonctionnant sur quelques SIM le démonstrateur est constitué de briques élémentaires, dont des modules Open Source publics Faciliter l’adoption par les SIM existants Les SIM servent de point d’entrée à la requête de l’usager.

4 Les principes Une architecture technique dépassant l’état de l’art international : - éviter le recours à une base partagée de points d’interconnexion, sans compromettre les performances - offrir un résultat de qualité dans le cas de SIM adjacents Avantage : simplicité de maintenance des données du système central.

5 Comment ? Un partenariat privé Canal TP - Cityway pour étudier puis développer des standards de communication ouverts Soutien de l’AFIMB Présentation des propositions au groupe de normalisation et objectif de diffusion à tous les acteurs du marché

6 Le processus d’ensemble
Etape antérieure: API standard RI Disponibilité publique Le projet en phase de démarrage: APII - SIM Illustration à partir de plusieurs SIM : 2 SIM contigus 2 SIM distants La suite: toutes initiatives possibles à partir de l’APII -SIM

7 L’architecture générale
SIM régional 1 SIM régional 2 Interfaces exposées Interfaces exposées Serveur longue distance Interfaces exposées Composeur d’itinéraires Front Office Métadonnées Back Office

8 Les métadonnées : un annuaire technique des SIM
Pour chaque SIM : les paramètres d'accès au Web Service, les paramètres d'interface supportés, la couverture géographique du calculateur d'itinéraire, les modes supportés.

9 Les interfaces Élaborer les interfaces:
qui fournissent dynamiquement au composeur les points d’interconnexion où il sera possible de passer du périmètre d'un calculateur SIM ( ou serveur) à celui d'un autre. qui fournissent au composeur la partie d’itinéraire calculée par un SIM. Ce dernier interface s’appuiera sur les principes résultant de l’« API simple d’accès au calculateur d’itinéraires »

10 Le serveur longue distance
Simulé pour les besoin du prototype A terme tout serveur longue distance : Mappy Voyages Sncf Amadeus Motricity EU-SPIRIT ….

11 Le composeur d’itinéraires
Identification des départ et arrivée, ainsi que des paramètres de la demande, En s'appuyant sur des paramètres et les métadonnées, identification des calculateurs contribuant à l'élaboration des itinéraires correspondant à la demande, Sollicitation de ces calculateurs, en utilisant les spécifications d’interfaces Combinaison et agencement des résultats pour obtenir un ou plusieurs itinéraires Présentation de ces itinéraires

12 Le composeur d’itinéraires
Cas 1 : SIM distants Territoire 2 Offre gérée par le serveur longue distance Points d’interconnexion Territoire 1

13 Le composeur d’itinéraires
Cas 2 : SIM adjacents Territoire 1 Territoire 2 Offre dupliquée Points d’interconnexion Points d’interconnexion

14 Le composeur d’itinéraires
Le composeur sera en Open Source L’instanciation sera à déterminer en fonction de la gouvernance définie par les AOT Les réutilisateurs pourront l’adapter librement à leurs besoins (voire localement).

15 Illustration

16 Le planning T0 = Janvier 2013 Phase de lancement – 2 mois
Recherche préalable – Etat de l’art Formalisation des besoins utilisateurs Identification des contraintes techniques Synthèse- Formalisation des exigences fonctionnelles Présentation au GT7 Analyse des conclusions – 1 mois Phase de Conception – 3,5 mois Architecture générale du système - Architecture technique Spécification technique des composants Spécifications fonctionnelles Phase de Réalisation – 6 mois Des communications intermédiaires de chaque composant seront effectuées. Phase de résultat – 1,5 mois [ Exploitation – 3 mois

17 Merci Vos contacts : Guillaume CROUIGNEAU – Canal TP
Laurent BRIANT - Cityway