La vérification du modèle a pour but de s’assurer que le modèle informatique a été correctement développé, et vise donc à la fois les capacités du logiciel choisi, et les compétences du modélisateur. D’évidence, un utilisateur mal formé à un outil peu adapté compromet d’emblée la confiance que l’on peut avoir dans un modèle !

Nous listons ici des outils ou des tests pouvant servir pour la validation comme pour la vérification.

Encore des indicateurs

La multiplication d'indicateurs est un très bon outil pour aider à suivre et à comprendre ce qui se passe dans le modèle, en fonction de la question à laquelle doit répondre la simulation. En plus des indicateurs définis dans le document d’analyse fonctionnelle, de ceux que nous conseillons, vous pouvez en ajouter d’autres pour vérifier la cohérence des flux et des règles internes. Plus vous introduirez d'indicateurs pertinents dans votre modèle, plus vous arriverez à suivre ce qui s'y passe et détecter d'éventuels bugs, valeurs erronées ou blocages.

En phase de test, prévoir des outils de Trace et de suivi historique : à certains points de passage, pour effectuer un bilan matière, on pourra enregistrer dans des fichiers des heures de passages, des propriétés associées au flux. Leur analyse pourra confirmer la bonne exécution de règles internes au modèle, ou expliquer leur non-respect.

Au fur et à mesure des vérifications, certains indicateurs disparaîtront, bien entendu.

Des comparaisons

Des résultats du modèle auront avantage à être comparés :

• À des résultats de calculs analytiques et diverses analyses avec d’autres outils effectuées en préparation de la simulation des flux.
• À des modèles de simulation antérieurs, s’il en existe sur ce domaine d’application.
• À des données historiques conservées sur le système réel, quitte à jouer un scénario qui n’existe pas dans le cahier des charges mais sur lequel on a des données historiques.

Des techniques visuelles

Animation : Un modèle animé affiche graphiquement son comportement au cours du temps, et donne un retour immédiat et très intuitif. On peut généralement animer facilement le modèle en même temps qu’on le construit, et l’on vérifie que ce qu’on voit dans l’animation correspond bien au fonctionnement qu’on veut donner au modèle.

Graphiques : De nombreuses valeurs peuvent être mesurées dans le modèle et affichées sur un graphique pendant la simulation. On peut ainsi vérifier le comportement dynamique d’indicateurs, comme le nombre de personnes dans une file d’attente, le pourcentage de guichets occupés. Un coup d’œil sur l’allure d’une courbe permet de repérer une incohérence.

Des assortiments de tests

Il faut soumettre le modèle à une sélection de valeurs en entrée et de paramètres internes. Prenons l’exemple simple d’une simulation de file d’attente :

• Test de sensibilité : On modifie les valeurs des entrées et des paramètres internes pour voir comment réagit le modèle et l’effet sur les résultats. Exemple : si le taux d’arrivée des clients augmente alors on doit observer une augmentation du taux d’utilisation des guichets et un allongement du temps d’attente. On peut aussi analyser quantitativement l’écart dans les résultats.
• Test avec des valeurs constantes : On applique un taux d’arrivée de clients constant, d’où l’on peut calculer facilement le taux d’utilisation que doit fournir le modèle.
• Test de consistance : On vérifie la consistance du modèle en exécutant plusieurs fois la simulation ; on doit avoir des résultats presque identiques.
• Test de conditions extrêmes : Les résultats du modèle doivent rester plausibles même avec dans des conditions extrêmes, improbables, voire absurdes. Exemple : si le taux d’arrivée des clients est nul alors le nombre de clients traités doit être nul aussi. Par contre si le taux d’arrivée des clients est monté à l’infini alors le nombre de clients traité ne doit pas devenir infini.

Sur de gros modèles aux multiples paramètres, comme il n’est pas possible de réaliser tous les tests, on choisira les tests les plus critiques, notamment visant les indicateurs principaux ou les process essentiels du modèle.

Suffisamment de réplications

Il ne suffit pas que le modèle ait tourné une fois et que tous les indicateurs soient au vert pour déclarer un modèle valide. Si le modèle comporte de l’aléa, il faut s’assurer qu'il donne des résultats cohérents en faisant tourner plusieurs simulations avec une base aléatoire différente, jusqu’à observer une convergence de résultats. Par ailleurs, si plusieurs scénarios de modélisation sont envisagés, il faut au contraire figer la base aléatoire pour voir l'influence de chacun des paramètres testés séparément – mais en testant à nouveau avec d’autres bases aléatoires une fois confirmée l’influence de ces paramètres.

Conclusion

Avec rigueur et sens critique, avec consensus et bonne volonté, on parvient à ce degré de confiance suffisant que requiert la simulation de flux.

Après avoir appliqué tous nos conseils et toutes nos formules, il y a toutes les chances que votre modèle soit correct 😉

L’article Valider un modèle (II) est apparu en premier sur Simulation de Flux.

La validation du modèle cherche à montrer que le modèle informatique est une représentation suffisamment fiable du modèle réel dans le cadre du champ d’utilisation fixé pour la simulation.

Nous listons d’abord quelques principes, et mentionnerons en seconde partie des outils pour mener à bien la validation tout comme la vérification du modèle.

Valider par rapport aux objectifs

Nous avons vu qu’un modèle est construit avec des objectifs précis, et ainsi sa validité sera déterminée en fonction de ces objectifs. Si le modèle doit répondre à une série de questions, la validité du modèle doit être contrôlée pour chaque question. Il faut donc que les principaux indicateurs de résultat soient définis au préalable, et avec un certain niveau de précision.

En amont il importe que le modèle conceptuel (c’est-à-dire l’ensemble d’informations constitué par le cahier des charges, la description du process, les schémas et les paroles qui ont été échangées pour décrire le système réel et les objectifs de simulation) soit correct et suffisant pour faire face à l’objectif poursuivi. C’est souvent là qu’un prestataire devra asticoter l’utilisateur final pour qu’il fournisse des règles de pilotages fiables, des lois de distribution crédibles, des schémas de flux fidèles. Trop souvent hélas, par manque de temps ou de préparation, le commanditaire du modèle fournit des informations erronées sur la logique du système ou encore des hypothèses approximatives… La validation s’en trouve compliquée.

La validation des données

La désinvolture avec les données n’est possible à aucun stade du projet. Il faut déjà que les données soient correctes pour arriver à un modèle conceptuel fiable, nous venons de le dire.

Mais y compris au niveau de la validation opérationnelle puis des simulations, il arrive souvent que plus de la moitié des bugs et résultats de simulations incohérents sont dus à des données d'entrée erronées ou incomplètes. Il est très important de prendre le temps de remplir, de vérifier que toutes les données nécessaires au bon fonctionnement du modèle sont correctement renseignées (l'idéal étant de les ranger dans une base de données pour garantir une cohérence interne). Jouer avec les données pour mener des expériences implique d’avoir une bonne connaissance du processus simulé et une idée des bons ordres de grandeur pour valider les différentes valeurs.

Demander des avis

Le modélisateur expérimenté peut décider quand le modèle de simulation est valide, s’appuyant pour cela sur les tests effectués tout au long du développement du modèle. Il est souvent délicat d'analyser tout seul si les résultats sont corrects ou non, même après avoir vérifié dix fois des ordres de grandeur, même après avoir intégré au modèle les indicateurs les plus pertinents. Une bonne approche consiste à impliquer fortement les utilisateurs du modèle dans le processus de validation, dans l’estimation des résultats attendus, ce qui augmente au final la crédibilité du modèle.

Conclusion

La validation des modèles est sans doute une des étapes les plus délicates dans la vie du modélisateur. Il faut faire preuve de beaucoup de patience, de minutie, de prudence et d'analyse. C’est un processus qui ne devrait pas commencer lorsque le modèle informatique est terminé, mais dès la validation conjointe du document d’analyse fonctionnelle. Trouver en fin de projet des erreurs dans la logique du process ou dans le choix des indicateurs ne se fait pas sans dommages…

Valider un modèle à 100% reste compliqué et long à mettre en œuvre – donc cela coûte cher ! Une validation raisonnable reste possible : elle implique que le modélisateur ait de l’expérience, que les autres intervenants du projet aient une bonne compréhension de ce qu’implique un modèle de simulation, et aussi qu’un certain nombre de méthodes soient appliqués – et ceci fait l’objet d’un autre article.

L’article Valider un modèle (I) est apparu en premier sur Simulation de Flux.

La simulation de flux est souvent utilisée pour améliorer la performance d'un outil de production ou pour s'assurer de la capacité effective d'investissements avant leur réalisation. Une ligne de conditionnement sera par exemple performante quand elle produit des boites de 40g et beaucoup moins quand elle passera aux boites de 20g. Qu'est ce qui bloque ? Où faut-il agir ? La simulation permet de tester des solutions et d'en mesurer l'impact.

Dans l'industrie, l'indicateur utilisé pour mesurer la performance est le Taux de Rendement Synthétique (TRS). C'est le rapport entre le nombre de pièces bonnes produites et le nombre de pièces théoriquement produites à cadence normale pendant une période. Le TRS permet aussi de connaître les sources potentielles de productivité.

Pour gagner en productivité, il faut donc améliorer autant que possible les trois composantes du TRS : Disponibilité, Performance, Qualité.

La simulation de flux permet surtout de mesurer – et de donner les pistes pour agir ! – les taux de disponibilité et le taux de performance, tout ce qui touche à la capacité gaspillée. Quelques exemples de pertes pouvant être améliorées en optimisant les flux :

• temps d'arrêts pour manque de matière première en amont.
• temps d'arrêt à cause d'un goulet d'étranglement en aval.
• temps d'arrêt pour absence de personnel ou plus généralement absence d'une ressource non planifiée.
• temps de changement de série, réglages. La simulation permet d'en améliorer la planification.

Le schéma ci-dessous représente une ligne de conditionnement de boites de chips. Les convoyeurs servent de tampons entre les machines. Les arrêts inévitables sur une machine ne perturberont pas les autres machines si les convoyeurs sont bien dimensionnés.

Chez 1Point2, nous avons une forte expérience de l'analyse des indicateurs de performance dans une simulation dynamique.

L’article Améliorer le TRS est apparu en premier sur Simulation de Flux.

Nous avons eu l’occasion de mettre ceci en œuvre : il est possible pour un modèle discret de simulation de générer un fichier qui pourra être lu par Google Earth pour afficher les résultats et l’animation de la simulation. Le point sur cette approche.

Introduction

Les modèles à événements discrets s’appliquent souvent à des problématiques logistiques sur des systèmes à grande échelle. Par exemple une chaîne logistique incluant plusieurs sites et prenant en compte fournisseurs, clients, stocks et transporteurs dans une région. Ou encore bateaux ou avions circulant sur tout le globe, ou bien les transports en commun d’une grande métropole.

Dans ces modèles, la plupart du temps l’animation se résume à des objets qui se déplacent sur une carte dont l’image a été placée en toile de fond. Selon le logiciel, le talent du modélisateur et le budget alloué à l’étude, une telle animation sera soit laide soit scolaire soit fantaisiste…

Les modèles que nous développons sont fins, élaborés, ils ont demandé des centaines d’heures pour comprendre et reproduire ce qu’il fallait du système réel. Leur valeur ajoutée est grande, avec les plus récents algorithmes de calcul, l’optimisation de scénarios à analyser, des boîtes noires de décisions multicritères… et parfois une animation très primaire. L’animation n’est peut-être qu’un habillage des résultats, mais elle est aussi ce qui donne la puissance communicatrice, la force pédagogique, la capacité d’appréhension immédiate d’un modèle de simulation.

Principes techniques

Pour représenter les résultats de modèles ExtendSim sur une carte, on utilise un éditeur de cartes dynamiques 2D / 3D permettant l’interprétation et l’affichage des résultats.

À chaque déplacement pertinent, le modèle prévoit l’écriture dans une base de données des caractéristiques du déplacement. Ensuite vient l’écriture du fichier .kml contenant les informations lisibles via Google Earth (essentiellement des balises et des coordonnées). Nous avons pour cela codé un ensemble de fonctions dans des dlls qui peuvent être appelées par le langage ModL qu’utilise ExtendSim.

Avantages / inconvénients

Avantages

L’utilisateur est bluffé par l’interface : possibilité de faire un zoom avant ou arrière, de changer de point de vue alors que l’animation se déroule.

C’est davantage qu’une belle animation, car cela permet une grande variété de façons de présenter des résultats géolocalisés.

Le format KMZ (version compressée de KML) est un format autonome, le fichier d’animation peut être fourni au client sans qu’il dispose forcément du modèle lui-même.

L’interface utilisateur de Google Earth est à disposition, le logiciel est disponible gratuitement et extrêmement répandu.

La documentation en ligne et les tutoriaux sont faciles à comprendre.

Inconvénients

C’est une post-animation : la simulation a eu lieu, on rejoue le film de l’animation.

Il faut tout de même comprendre le format .kml.

Votre logiciel de simulation doit apprendre à générer des fichiers kmz. La réalisation avec ExtendSim était sans difficulté, mais relativement chronophage.

Cas d’application

Il s’agit d’un modèle réalisé pour la société qui exploite le métro de Lille, afin d’anticiper la croissance de fréquentation des transports en commun pour optimiser à la fois les horaires et le nombre de véhicules. Nous avons pu depuis appliquer la technique sur d’autres modèles.

L’article Google Earth pour animer des simulations est apparu en premier sur Simulation de Flux.

Nous avons a été amenés à simuler des flux de passagers pour l’aéroport de Roissy Charles de Gaulle (CDG), en prenant en compte des avions, valises, voyageurs, navettes, etc. sur plusieurs mois. Le modèle de simulation était relié à une base de données de passagers et de trafic, de sorte à produire un modèle de simulation prédictif des flux de passagers à l’intérieur de l’aéroport, et qui suivait chaque passager de son atterrissage (ou arrivée à l’aéroport), à son décollage (ou sa sortie de l’aérogare).

Chaque jour 100 000 passagers passent l’aéroport CGD, ce qui en fait le second HUB en Europe pour le nombre de passagers. La moitié de ceux-ci sont des voyageurs en transit qui descendent d’un avion pour aller en prendre un autre, via un ensemble complexe de tapis roulants, escalators, contrôles de sécurité, plus un réseau de bus et navettes.

Ce qui est très gratifiant pour nous, c’est que grâce à son interface et à ses liens en entrée comme en sortie avec la base de données, ce modèle a pu aider et aide encore, saison après saison, à réduire le pourcentage de correspondances manquées et à mieux organiser les services de transport de terminaux.

Les problèmes liés au volume des données

L’aéroport CDG se compose de sept terminaux reliés par un réseau de couloirs, bus, escalators etc. Chaque terminal dessert dix aires de stationnement pour tous types d’avions, ce qui complique la vie des passagers ayant peu de temps pour effectuer leur correspondance. Les files d’attentes qui se forment aux postes de sécurité ou aux arrêts de bus dépendent très directement de l’affectation des avions aux parkings dans les terminaux, de la taille des équipes de contrôle de sécurité, de la capacité des bus et de leurs horaires. Seule une simulation très exhaustive, prenant en compte chaque passage individuellement, pouvait aider à comprendre et évaluer l’impact des petites ou grosses modifications dans l’organisation de ce trafic complexe.

Le tableau ci-dessous donne une idée de la quantité de données à prendre en compte dans le modèle de simulation.

Le modèle avait pour objectif de contribuer à plusieurs types de décisions à court et long terme. Mais d’autres décisions sont prises deux fois par an, avant chaque “saison” aérienne, ce qui implique que le modèle soit utilisé régulièrement par des novices en simulation qui devront être autonomes dans l’usage du modèle. D’où l’importance de la qualité d’interface, et des temps de calcul relativement courts.

Une simulation à événements discrets associée à une base de données

Deux contraintes ont dicté le choix des logiciels utilisés :

• Un très gros volume de données à organiser et utiliser à tout moment dans le modèle,
• Le besoin d’un modèle flexible et évolutif

Le modèle de simulation de flux a été bâti avec ExtendSim, où nous avons pu construire une bibliothèque d’objets spécifiques très personnalisables (aires de stationnement, escalators, bus, postes de contrôle etc.) que nous avons assemblés pour former le réseau de l’aéroport CDG. ExtendSim possédant sa propre base de données, il a été envisagé d’y faire figurer toutes les données – assurément un gain en accessibilité en lecture comme en écriture tout au long de la simulation.

Cependant les données client étaient stockées dans Microsoft Access, outil déjà employé par les futurs utilisateurs du modèle et proposant déjà des formulaires de saisie et d’analyse. L’application ExtendSim a donc été liée à MS Access, et le codage d’interface effectué sous MS Access.

Big résultats !

L’opérateur de l’aéroport fait appel à un outil permettant d’importer automatiquement les prévisions de trafic détaillées dans sa base de données et de définir à partir de là les paramètres du modèle via les formulaires sur mesure d’une application Microsoft Access. Faire tourner une simulation prend moins de 5 minutes pour une journée d’exploitation avec 100 000 passagers. Le modèle exporte les données résultantes brutes, avec tous les événements concernant chaque passager, et l’utilisateur final utilise aussi les utilitaires de data mining de MS Access pour une fine analyse des résultats, par exemple filtrer les passagers ayant raté leur correspondance.

L’utilisation du simulateur a permis aux opérateurs de l’aéroport de faire modifier les horaires des lignes de bus et de renégocier les plannings du personnel aux postes de contrôle. Chaque saison, des affectations avions-terminal différentes sont testées, et leur impact sur le succès des correspondances est calculé avec le simulateur. Le modèle est devenu un outil clé dans la procédure d’organisation de la saison, et participe directement à plus de 1% d’augmentation du nombre de correspondances réussies. Une correspondance ratée revient à plus de 50€ par passager, donc 1% de correspondances ratées représente plus de 500 passagers par jour – soit dans les 7 M€ par an ! CQFD…

Vous pourrez retrouver une communication sur ce thème dans les Proceedings of the 2014 Winter Simulation Conference, A. Tolk, S. D. Diallo, I. O. Ryzhov, L. Yilmaz, S. Buckley, and J. A. Miller, eds., http://dl.acm.org/citation.cfm?id=2693848

L’article Simulation et Big Data : De nouveaux défis est apparu en premier sur Simulation de Flux.