Skip to content

02-12-2021 - Point avec Clara Buire et Geoffrey Scozzarro

Background et projet de Clara Buire

Clara a entrepris en 2021 une thèse ENSEIHTT, machine learning filière – HPC big data- info

Recherche opé : recuit simulé, optimisation linéaire, branch and bound – possible car on a du temps => stratégique

Post doc. : Philippe Monmousseau (évoqué, mais non présent)

Philippe, lors de son travail de thèse, avait récupéré les tweets concernant l'appréciation des passagers : mesurer la qualité du service offert – analyse de sentiments % compagnies aériennes.

Temps de trajet porte à porte – UBER

Mais depuis il est parti dans le privé (Compagnies assurances : prix assurance voiture).

Background et projet de Geoffrey Scozzarro

ENAC formation ingénieur – majeure OPS, mineure SITA (java, etc) – master recherche OPS en //

Pour le moment essentiellement, fouille de données, récupération automatique, BDD CDG, scan passagers aéroports, horaires reels/planifiés PCA livrables, pas de prédiction.

Initiation du projet de recherche : minimiser l'impact sonore des drones

Labo recherche EU – recuit simulé

2 scénarios :

  • Stratégique : Clara : bénéfices d’un ticket intégré – planifier aspects

  • Tactique : Geoffrey : optimiser l’intermodalité entre sol et aérien au niveau aéroport : pistes/portes assignées – ops terminal – zones check in/sécurité (files prioritaires ?)

fonction objectif orientée passagers (panne RER B => passagers en retard => information passagers => ttes les 20/30 min estimation sur arrivées passagers, individuellement,

agrégation, 1h avant, pour essayer attendre ces passagers et optimiser le taux de remplissage, mais risque de congestion, donc prendre les contraintes opérationnelles, et donc créer un nouveau planning, capacités pistes, retarder ou avancer avions en l’air changer pistes, ) – contrainte aéroportuaires

A besoin d’hypothèses => travail préexistant ancienne thèse = optimisation aéroport   Optimalisation stratégique, planning, TRANSIT * Planning commun train/avion – 1 an en avance * CDM étendu au sol * « Faire rentrer dans la boucle » le train * Contacts coté aérien = ADP ; montrer * Interface existante = passagers * On peut plus facilement arreter un train par rapport à un avion   Site web : django, Temps de connection     Clara :

« ya des gens qui voyagent mais ils n’osent pas, ils ne parlent pas la langue.. Tout est dématérialisé, les gens qui n’ont pas forcément l’habitude ne peuvent pas le faire.

Je me souviens aussi d'un problème concernant la connexion Le Bourget ticket RER zones dans Paris et les zones du RER. Un ticket intégré serait bienvenu !

Pour le « lost and found » : un service de bout en bout créerait de la confiance, de la sécurité...

Et sinon pour venir à l'ENAC je prends le train de Muret mais un jour sur 2 ya un pb d’aiguillage, les gens ne peuvent pas compter dessus.. j'ai fini par abandonner...

Une IA compagnon

J'évoque l'idée que l'IA aiderait le passager dans ses choix.

Nous entamons une discussion autour de l'idée.  

Métrique de connectivité = temps de transfert passager, en fonction du ressenti passager (plus prévoyant que d’autres), certains vont avoir besoin d’un temps de connection 40 min, d’autres 1H30 – temps de transfert minimum, si ya des vols après Par ex voyager le soir presente le risque

BDD OAG => aide au choix

Régularité du vol sur les derniers mois

Compagnie aérienne

Qualité de la connection

On voulait une loi asymétrique de 0 min à un temps max

Loi gamma => il vaut mieux une connection trop longue que trop courte

Soit on utilise les recom de l’aéroport

Passagers Schengen, non Schengen => différence = contrôle aux frontières

Et les avions sont des longs courriers

En fonction de prévoyance (âge…) il faut calibrer différemment

Avec PIF (poste inspection filtrage avant envol)

D5.1 : Vont récupérer les temps d’arrivée passager aéroport avec et sans disruption métro (ex : à/p de là vont calculer le planning optimisé pour la journée, sans supposer le nb de passagers)

Idée = algo relancé toutes les ½ heures pour les 2 à 3 prochaines heures tout en satisfaisant les contraintes

Dévier le moins possible du planning

D5 Transit = implémentation et description des mécanismes de synchronisation

ETH = outil de simulation – MATSIM a été modifié

Day replanning

Clarissa travaille avec C-TAP – demande de longue distance – En train d’évoluer vers JAVA en J-TAP

Planning => interfacée à J-TAP

Calé en MATSIM – Milos Balash

D6 = résoudre les mécanismes   Trajet porte à porte = avec et sans coordination   MATSIM ne prend pas en compte les horaires, mais que des liens OD.

(réflexion) - Echelle de temps : C-TAP à l’année pour les intentions de voyage, et à la semaine pour un voyage en Europe ?

Semaine => planning

Documents TRANSIT :

https://www.transit-h2020.eu/resources