Meet Africa

CEMDAP se présente à l’utilisateur sous forme d’une interface graphique sous Windows, dans laquelle l’utilisateur peut modifier les valeurs des paramètres si elles sont disponibles pour la région dans laquelle CEMDAP va être appliqué. (l’interface contient par défaut les valeurs par des paramètres déduites des données DFW).

CEMDAP Binary est le composant exécutable de base qui incarne la fonctionnalité de CEMDAP. Il est conçu pour s’exécuter sur une seule machine hôte Microsoft Windows et fait usage de plusieurs composants et bibliothèques externes. Ces bibliothèques dépendantes sont fournies dans le package d'installation CEMDAP et aident à réduire le temps de développement.

Les données d’entrées sont stockées dans « Input Database » (la base de données ne pose pas de contraintes sur le format des données et offre jusqu’à plusieurs téraoctets de stockage),

Les données de sortie de CEMDAP sont enregistrées dans des fichiers plats (fichiers à onglets simples) qui sont sélectionnés via l'interface utilisateur graphique. La raison de choix des fichiers plats pour le stockage des données de sortie plutôt qu'un SGBD (système de gestion de base de données) était principalement pour maintenir la facilité et la flexibilité. Parce que la sortie est séquentielle, il est susceptible d'être transmis en flux continu vers un fichier plat (simple fichier). En outre, étant donné que les données de sortie peuvent être traitées par d'autres applications génériques ou importées à différents SGBD, un fichier formaté à onglet simple peut être lu par la plupart des autres logiciels et SGBD.

Formalisation technique du modèle

1.

La formalisation technique du modèle correspond au choix de la manière de « concrétiser » la formalisation conceptuelle du modèle. Il s’agit en quelques sortes de traduire des constructions abstraites (par ex. des villes dont la densité peut varier au fur et à mesure du temps) en modèle concret (par exemple : un ensemble de cellules caractérisées par une variable densité + la localisation d’un centre). Cela se fait en général en deux étapes : le choix d’un formalisme (mathématique, informatique, physique, etc.) et l’implémentation concrète (écrire d’un système d’équations mathématiques, code informatique, réalisation d’une maquette, etc.)

Guide de questionnement :

• Quel formalisme a été retenu pour la traduction du modèle conceptuel au modèle implémenté ?
• Par quel biais ce formalisme est-il concrètement implémenté dans le modèle (ex. : code informatique, équations aux dérivées partielles, etc.)
• Connaissez-vous d’autres modèles ayant procédé à des choix différents d’implémentation ?
• Le modèle étudié est-il à cet égard « standard » dans la littérature ou bien est-il original et le cas échéant pourquoi ce choix a été fait ?

Le modèle CEMDAP s’appuie sur un formalisme informatique. Il s’agit d’une micro simulation type ABM (Agent Based Modeling). L’approche utilisée pour le développement du modèle est l’approche orientée objet, implémentée par le biais du langage  C++. Dès lors, il n’y a pas besoin de conversions nécessaires en passant d’un stade à un autre pour tenir en compte des changements éventuels apportés au code. Ceci sert parfaitement la particularité de CEMDAP, qui est un code qui se veut en amélioration et développement continus.

Le modèle Tasha est très proche de CEMDAP en termes de choix d’implémentation : c’est également une micro simulation ABM qui utilise un formalisme informatique, implémenté par le biais de la programmation orientée objet avec le langage C#.

2.

La formalisation conceptuelle du modèle a amené à proposer des objets élémentaires dans le modèle (un champ, un agent, etc.) et des relations entre ces objets : par exemple dans un modèle agent représentant les déplacements de piétons, chaque agent « piéton » interagit avec chaque autre agent « piéton » et par ailleurs avec l'environnement physique (poteaux, murs, etc.). A l'étape de conception, il s'agit de transcrire ces principes en règles / équations / etc. qui soient précises et ne laissent pas de place à l'interprétation lors de l'exécution du modèle. La machine (dans le cas d'un modèle informatique) doit savoir à chaque instant quelle « règle » appliquer, que cette règle soit déterministe ou non. Il s'agit donc dans cette étape de décrire avec précision ces règles et de les resituer par rapport à d’autres implémentations existant dans la littérature (autrement dit d’autres manières de formaliser ou d’écrire ces mêmes règles dans d’autres modèles de la littérature). Vous pouvez par exemple vous demander quelles fonctions sont mises en œuvre lors de cette transcription [par ex. réseaux de neurones ?]

Guide de questionnement :

• Comment sont concrètement implémentés les objets / relations entre objets issus de la formalisation conceptuelle du modèle ?
• Cette « transcription » a-t-elle donné lieu à des modifications dans les objets / relations entre objets conceptuels présents dans le modèle ?
• Connaissez-vous d’autres modèles ayant procédé à des choix différents dans la transcription des objets / relations entre objets ?
• Est-ce que votre modèle est à la pointe de la connaissance du point de vue de son « implémentation technique » ?

Conceptuellement, les données d'entrées pour l'année en cours étaient composées des caractéristiques socio-démographiques agrégées, caractéristiques des déplacements-activités, actions politiques et les paramètres du modèle.

“Synthetic Population Generator” (SPG) et “Comprehensive Econometric Microsimulator for Socioeconomics, Land-Use, and Transportation System” (CEMSELTS) sont deux composants du modèle CEMDAP reliés au simulateur d’activités-déplacements individuels.

SPG permet de désagréger les données sociodémographiques à un niveau individuel pour l'année en cours.

CEMSELTS donne les caractéristiques socio-économiques et les attributs des activités-déplacements.

CEMDAP est composé de plusieurs sous-modèles économétriques qui permettent de déterminer les choix des déplacements-activités des individus. Lorsqu’un modèle est configuré sur l’interface, il possède toutes les données et les paramètres nécessaires pour prédire ces choix. Ces sous-modèles sont dérivés de six structures économétriques (regression, binary logit, multinomial logit, etc).

Dans CEMDAP, tous les individus doivent être classés dans l’une des catégories suivantes : étudiant, travailleur,  non-scolarisé, non-travailleur. Une limite de ce modèle est qu’il n’est pas possible pour un individu d’être dans 2 catégories en même temps (ex : travailleur et étudiant).

Les  programmes  d’activités  sont modélisés comme  une  succession  de  chaînes de déplacements.

L’accompagnement des enfants est modélisé  par  plusieurs  règles  déterministes.  A titre  d’exemple: (1) L’heure de départ et la durée du trajet jusqu’à l’arrêt du pick-up/dépôt est déterminé en se basant sur les horaires de début et de fin de l’école (2) Quand un membre du ménage accompagne un enfant à l’école, c’est considéré comme l’unique stop de ce trajet.

Des restrictions sont imposées sur le nombre maximum de tours et le nombre maximum d’arrêts dans chaque tour pour les personnes qui travaillent. Par exemple, CEMDAP est développé de telle façon à prendre en compte 3 tours durant chacune de ces phases : pré-travail, pendant le travail et post-travail et 5 arrêts durant chaque tour. Pour la période post-école, seulement un seul tour avec un seul arrêt est autorisé. 4 tours et 5 arrêts sont autorisés durant chaque tour pour les personnes qui ne travaillent pas.

CEMDAP est à la pointe en termes d’implémentation technique puisqu’il utilise :

• Un système de base de données stable face à une grande quantité de données.
• La programmation orientée objet qui facilite l’apport de changements au code.
• Techniques d’amélioration de la performance (multithreading, data caching..)

Le modèle TASHA se base sur les objets élémentaires suivants : ménages, personnes, projets, activités et déplacements. Pour les implémenter, TASHA utilise des classes (entités du modèle) qui sont schématisées ci-dessous :

[pic 1]

Source : A Prototype Model of Household Activity/Travel Scheduling, Eric J. Miller et al

Le schéma ci-dessus montre également les relations entre les objets : Chaque ménage est constitué de personnes et chaque personne a un programme qui contient des activités ainsi que les déplacements nécessaires pour les réaliser. Les ménages aussi bien que les personnes ont des projets. Chaque projet contient une série d’activités qui sont affectées aux personnes ou aux ménages.

Les dernières versions de TASHA (GTA model V4.0) représentent également les interactions au sein des ménages et le partage de responsabilités (exemple : accompagnement des enfants) et des ressources (exemple : voiture)

3.

La transcription de règles dans le modèle implémenté requiert des choix techniques : par exemple la plateforme (le langage /  logiciel dans lequel est codé le programme dans le cas d'un modèle informatique). Ce choix peut provenir pour partie de considérations techniques liées à la performance (besoin d’une certaine puissance de calcul, besoin de langages de programmation orientés agents, etc.) et pour partie de considérations externes à la « sphère du modèle » (licences logicielles déjà acquises, habitude de programmation, besoin de transférabilité avec d’autres modèles). Il convient ici de préciser les choix techniques qui ont été faits et de les comparer à la littérature existante.

Guide de questionnement :

• Sur quelle plateforme / logiciel / autre dispositif est codé le modèle étudié ?
• Le modèle ainsi constitué est-il dépendant d’un environnement technique (par exemples s’il s’agit d’un plugin dépendant d’un logiciel, etc.) ? Vous parait-il pérenne ?
• Quelles sont les performances du modèle ? (ex. temps pour une simulation)
• Comparez les arbitrages réalisés en termes de performance / pérennité / coût de production par rapport aux modèles proches.

Pour CEMDAP, le code a été écrit dans ‘Microsoft Visual Studio .NET’. .Ce choix de programmation offre l’avantage de réutilisation du code, l’extension du logiciel et l’implémentation rapide de nouvelles variantes.

Ce modèle n’est pas dépendant d’un environnement technique, ce qui garantit sa flexibilité et transférabilité. Cependant, CEMDAP doit interagir avec une base de données pour acquérir les données d’entrées. Cette base de données peut fonctionner sur une machine autre que celle où CEMDAP est utilisé sans rajouter plus de complexité à l’interaction avec la base de données (Microsoft Access et PostgreSQL). Elle permet de travailler avec une résolution spatiale fine et/ou sur de grandes régions et permet un gain de temps dans l’exécution des requêtes.

CEMDAP utilise les techniques de “multithreading” et “data caching” pour réduire les temps de calcul. “Multithreading” permet d’utiliser plusieurs processeurs pour exécuter les simulations, et “data caching” permet de stocker les données d’entrées fréquemment utilisées dans la RAM. Malgré toutes ces améliorations, le temps de calcul de CEMDAP pour toute la région DFW (1.8 millions de ménages et 4.7 millions d’individus) était de 25 jours surune seule machine. Le coût de production du modèle CEMDAP n’a pas été trouvé dans la littérature.

Pour le modèle TASHA, la plateforme utilisée pour coder la solution est la même que CEMDAP : Microsoft Visual Studio .NET. Le modèle est implémenté dans le logiciel XTMF (eXtensible Travel Modelling Framework) développé par l’université de Toronto. Pour les auteurs, le choix de la simulation ABM (Agent Based Modeling) permet d’avoir des temps de calcul très compétitifs. Nous n’avons pas réussi à avoir ces temps de calcul avec précision.

Quant aux coûts de production, nous avons très peu d’informations. Eric J. Miller, auteur du modèle, évoque ‘une somme d’argent ridicule’ et six mois de travail pour développer le modèle à partir de rien. Le secret, selon l’auteur, sont les très bonnes relations que l’université tient avec la région du grand Toronto. Par ailleurs, la solution semble être pérenne car depuis la première version du modèle en 1996 2 autres versions ont été développées (2001 et 2008). Actuellement la version V.4 est en cours de création.

4.

L’ergonomie du modèle renvoie à l’« expérience » de l’utilisateur du modèle. Le modèle peut être très simple d’utilisation (une interface web par exemple) ou plus « basique » (par exemple une macro VBA Excel qui implique que certaines cellules précises soient remplies selon une règle rigide). L’ergonomie concerne aussi les possibilités d’action sur l’objet « modèle » par exemple ce que l’utilisateur peut changer ou non, et les qualités visuelles du modèle. L’explicitation des choix faits sur l’ergonomie du modèle fait partie de l’étape de conception, que l’interface soit interactive ou non. Au niveau de la conception, les choix à faire portent principalement sur le confort d’utilisation et il convient que les choix soient en adéquation avec l’étape 1 (spécification) et l’étape 3 (utilisation).

Guide de questionnement :

• Comment se présente « concrètement » à l’utilisateur  le modèle étudié? Quelles qualités visuelles du modèle ? Quelle interface utilisateur ?
• Quel degré d’expertise est requis pour l’utilisation de ce modèle ?
• D’autres choix ont-ils été faits pour les modèles proches, et si oui pourquoi ?

Le modèle se présente à l’utilisateur sous forme d’une interface graphique. Les paramètres estimés pour la région DFW sont entrés par défaut. L’utilisateur peut modifier ces paramètres. Il n’est pas nécessaire d’être un expert pour utiliser ce modèle. Ceci sert en effet le caractère générique de CEMDAP.

Le modèle TASHA est implémenté dans le logiciel XTMF (eXtensible Travel Modelling Framework) développé à l’université de Toronto pour plusieurs raisons, entre autres, améliorer l’expérience utilisateurs et l’ergonomie du modèle. Ceci simplifie l’usage du modèle et ne le restreint pas aux experts.

5.

Les entrées / sorties du modèle ne sont pas qu’une question de spécification : à l’étape de la conception du modèle, il faut que le modèle implémenté soit capable d’utiliser effectivement les données fournies en entrée, ce qui impose souvent de préparer un petit module de « traduction » du fichier d’entrée en données attendues par le modèle. C’est la même chose en sortie, il y a une différence entre ce qu’on pourrait calculer à l’issue du modèle et ce que génère effectivement le modèle comme sorties. Une attention particulière doit être portée à la conception des entrées et des sorties, surtout lorsqu’il s’agit de travailler avec plusieurs modèles dont les sorties de l’un sont utilisées en entrée de l’autre.

Guide de questionnement :

• Comment les données d’entrée sont-elles concrètement « importées » dans le modèle étudié : des adaptations / compromis sont-ils faits par rapport à ce qui été attendu à l’issue de l’étape de spécification ? Pour les cas des modèles de simulation, nous vous encourageons à détailler ici comment sont générées les conditions initiales du modèle.
• Quelles données sont produites en sortie du modèle étudié ? S’agit-il d’indicateurs synthétiques ou sont-elles directement issues des objets / relations entre objets du modèle implémenté ? Y’a-t-il adéquation entre les données de sorties et les indicateurs attendus à l’étape de spécification ?
• Les entrées / sorties du modèle étudié diffèrent-elles beaucoup de celles des autres modèles proches ?
• Analyser quelles différences proviennent directement de l’étape de spécification et lesquelles proviennent de cette étape de conception.

CEMDAP prend comme données d’entrées les données socio-démographiques agrégées et les activités-déplacements pour l’année en cours, les actions politiques et scénarios pour les années futures, et les paramètres du modèle.

Ces données sociodémographiques agrégées sont d’abord entrées dans le “Synthetic Population Generator” (SPG) qui permet de créer une représentation désagrégée de tous les individus et les ménages dans la zone d’étude pour l’année en cours. .

SPG permet de désagréger ces données sociodémographiques à un niveau individuel pour l'année en cours.

CEMDAP prend alors comme données d’entrées ces données désagrégées et produit en sortie les caractéristiques détaillées des activités-déplacements de chaque individu. Ces résultats alimentent ensuite un simulateur de micro-affectation de trafic pour déterminer les débits et les vitesses des réseaux selon l’heure de la journée.  

L'évolution de la population et de l'environnement urbain est modélisée par le Comprehensive Econometric Microsimulator for Socioeconomics, Land-Use, and Transportation System (CEMSELTS). En tenant compte des caractéristiques sociodémographiques actuelles et des caractéristiques des déplacements-activités, des actions politiques prescrites et des caractéristiques de vitesses obtenues à partir du processeur de micro-affectation du trafic, CEMSELTS fournit comme résultat les caractéristiques sociodémographiques de la population et les attributs des activités-déplacements pour un incrément de temps (Par exemple, un an). Ces informations sont transmises au simulateur de déplacements-activités (CEMDAP) pour obtenir les caractéristiques individuelles détaillées des activités et des déplacements pour l'année à venir. La boucle est exécutée jusqu'à ce que les débits et vitesses soient obtenus pour l'année de prévision spécifiée par le modélisateur.

Le modèle TASHA prend en données d’entrée les données de population et d’emplois et les données d’activités sur une période de 24h. Le modèle TASHA contient des procédures de synthèse pour désagréger les données de population et d’emplois initialement disponibles par zones avant de les manipuler dans la simulation. Pour les formats des fichiers de sortie (programmes d’activités-déplacements), le modèle est complètement interfacé avec les logiciels usuels d’affectation de trafic comme EMME, MATSIM, VISUM… Ainsi, les données de sortie de TASHA peuvent être directement intégrées dans ces logiciels.

Calibration des paramètres

6.

La calibration du modèle consiste à évaluer les paramètres d’un modèle de sorte que le modèle corresponde au mieux à une situation donnée, dite situation de référence. Elle s’appuie donc sur une description de la situation reposant sur des données qu’il convient de détailler.

Guide de questionnement :

• Quels sont les paramètres du modèle qui font l’objet d’une calibration ?
• Quelles données sont utilisées pour la calibration ? Permettent-elles de décrire la situation de référence de façon satisfaisante ?
• Comparer les choix fait à cette étape par le modèle de référence et par les modèles proches.

La calibration du modèle est effectuée de la manière suivante : Les données d’enquête utilisées pour l’estimation du modèle (Enquête sur les ménages DFW) sont importées dans CEMDAP et les résultats des activités-déplacements simulés sont comparés aux données observées. 

La comparaison avec les données estimées a été effectuée à un niveau agrégé en comparant les pourcentages des choix discrets et les distributions des choix continus avec les pourcentages et les distributions observés dans l’échantillon de l’enquête d’estimation. 

Les résultats de cette comparaison portée sur les types et caractéristiques des chaînes de déplacement, les caractéristiques du déplacement, les tendances à faire plus d’une activité dans une chaîne de déplacement, les caractéristiques des activités et les distributions de l’horaire du travail montrent que CEMDAP donne des résultats cohérents avec les données observées dans l’enquête DFW. Seulement le nombre de chaînes de déplacement vers des endroits autres que l’école présentent une différence. Ceci pourrait être dû au petit échantillon à partir duquel les résultats du modèle étaient estimés.

Cette comparaison montre également que CEMDAP sous-estime le nombre moyen d’arrêts durant les trajets domicile-travail. Par contre, CEMDAP prédit bien le nombre moyen de déplacements journaliers par personne. En revanche, les résultats simulés sous-estiment légèrement la durée moyenne des trajets pour tous les types de déplacement, possiblement parce que CEMDAP utilise directement le temps de trajet interzonal tiré des fichiers LOS pour certains segments (comme le retour à la maison), contrairement aux enquêtes qui reportent la durée du trajet porte-à-porte.

La spécification et la structure du modèle sont examinées et révisés (en incluant des contrôles de cohérence supplémentaires, le débogage du code) jusqu’à ce que les tendances des données d’enquête soient répliquées par le modèle de manière précise.

Le modèle TASHA a été calibré en utilisant les données de l’enquête TTS 1996. Ce sont les résultats de cette enquête qui ont été utilisées pour estimer le modèle. Les chercheurs ont voulu tester l’intégration des 3 composantes du modèle : génération des activités, choix de l’emplacement des activités et programmation des activités. Pour la partie programmation des activités, elle est basée sur des règles issues de l'enquête Chase. Les auteurs ont choisi de ne pas procéder au calibrage des paramètres du modèle dans l’objectif d’évaluer la pertinence de ces règles comportementales et de les améliorer. Pour devenir complètement opérationnelle, la dernière version de TASHA est en train d’être calibrée en utilisant les résultats de l’enquête TTS 2011.  Nous avons très peu d’informations sur les paramètres calibrés et les méthodes utilisées.

7.

L’étape de calibration se fait par une méthode qu’il convient de préciser, puisque des progrès significatifs sont réalisés dans ce domaine dans la littérature scientifique).  La calibration peut être menée à bien par des méthodes        statistique (régression linéaire, etc.) ou informatiques (réseaux de neurones, etc.). Il s’agit donc ici de préciser la méthode d’estimation des paramètres (à la fois la technique mise en œuvre et le « cheminement » suivi (ordre dans lequel les paramètres sont calibrés, paramètres faisant l’objet d’un effort particulier, etc ).

Guide de questionnement :

• Quelle(s) méthode(s) sont utilisées pour mener à bien l’étape de calibration ?
• Comparer les choix fait à cette étape par le modèle de référence et par les modèles proches.

Concernant le modèle CEMDAP, puisque le temps de simulation prend plusieurs jours malgré les techniques d’amélioration de la performance utilisées et évoquées précédemment, il n’est pas pratique de réaliser les simulations pour chaque set de calibration pour les 1.8 millions de ménages.

Une alternative est de simuler pour seulement un échantillon aléatoire de la population. Une évaluation a permis de constater que la simulation pour 5% de la population permet de remplacer la simulation pour la population entière, afin de représenter les attributs des chaînes de déplacement et des arrêts. Un plus grand échantillonnage est requis si l’on voudrait se focaliser sur la représentation des emplacements des arrêts.  

Pour le  modèle Tasha, les documents techniques ne décrivent pas les paramètres estimés ni les méthodes utilisées pour l’estimation de ces paramètres