Histoire de la modélisation par simulation

Le défi

par Stephen D. Roberts (North Carolina State University) et Dennis Pegden (Simio LLC)

Présenté lors de la Conférence d'hiver sur la simulation 2017

Au cours du dernier demi-siècle, la simulation a progressé en tant qu'outil de choix pour l'analyse des systèmes opérationnels. Les avancées technologiques ont stimulé de nouveaux produits et de nouveaux environnements sans normes logicielles ni communauté méthodologique. Chaque nouveau langage ou produit de simulation offre un ensemble unique de caractéristiques et de capacités. Pourtant, ces produits de simulation sont le fruit de l'évolution de la recherche, du développement et de l'application. Dans ce document, nous interprétons l'évolution historique de la modélisation de la simulation. Selon nous, la modélisation de simulation est la partie du processus de résolution des problèmes de simulation qui se concentre sur le développement du modèle. Il s'agit de l'interprétation d'un problème réel de production (ou de service) en termes de langage de simulation capable d'effectuer une simulation de ce processus réel. Bien que l'"interprétation" soit dans les "yeux de celui qui regarde" (c'est-à-dire nous), il existe certains points de vue et méthodes historiques qui influencent la conception du modèle de simulation.

Introduction

Modèles et modélisation

Des modèles mathématiques et statistiques formels des opérations ont été développés au cours de plusieurs décennies de recherche. Cependant, lorsqu'un modèle est appliqué au-delà de ses hypothèses, la question de son applicabilité reste ouverte et le modélisateur est confronté à l'adaptation du modèle ou au développement d'un nouveau modèle. L'adaptation ou la création d'un nouveau modèle analytique est une tâche importante qui met à l'épreuve les compétences analytiques du développeur et peut nécessiter beaucoup plus de temps et d'efforts, peut-être sans résultats tangibles.

La valeur d'un modèle réside dans son utilisation. Étant donné que les modèles individuels ont des limites et que leur extension peut être décourageante, certains chercheurs et praticiens préfèrent un environnement de modélisation plus souple. La simulation est depuis longtemps considérée comme un outil de modélisation qui dispose d'un environnement de développement très large et qui ne nécessite pas de sophistication mathématique ou statistique pour le développement et l'utilisation du modèle. En outre, pour alléger le fardeau du développement des modèles de simulation, divers langages de simulation ont été mis au point. Chaque langage de simulation offre ses propres constructions de modélisation à l'intérieur desquelles un modèle de simulation peut être construit, simulé et analysé. Bien que les langages aient évolué au fil du temps, l'approche de la modélisation est inextricablement liée à la perspective d'exécution de la simulation.

La modélisation

L'objectif de ce document est de fournir un historique personnalisé (et donc limité) de la modélisation de simulation telle qu'elle a été largement popularisée par la Winter Simulation Conference. L'utilisation de la simulation dans un contexte de résolution de problèmes requiert plusieurs compétences :

• Définir correctement le problème et définir les objets.
• Utiliser les concepts de modélisation pour abstraire les caractéristiques essentielles du système dans un modèle.
• Collecter et compiler les données et les informations pour le modèle.
• Convertir le modèle en un code lisible par l'ordinateur capable de simuler le système.
• Donner des instructions à l'ordinateur pour qu'il effectue la simulation correctement et efficacement pour différents scénarios.
• Résumer et analyser les résultats de la simulation en mesures de performance.

Kiviat (1967) a été l'un des premiers à décrire le processus de modélisation et les compétences requises. Un utilisateur ayant une connaissance approfondie de presque tous les langages de programmation à usage général peut fournir la plupart de ces compétences. Cependant, la charge de travail pour réaliser une simulation finale est considérable, car le programmeur doit fournir un logiciel pour réaliser tous les composants nécessaires, y compris la génération de nombres aléatoires, la génération de variables aléatoires, la mise à jour de l'état et l'avancement dans le temps, la collecte et l'affichage de statistiques, etc. Il existe des langages de simulation et des bibliothèques de simulation pour alléger le fardeau de la création de simulations.

Bien que de nombreux langages de simulation aient vu le jour et disparu, les approches fondamentales de la simulation sont similaires. Un langage de simulation exécute un modèle du système afin de reproduire dynamiquement le comportement de ce dernier au fil du temps. Pour ce faire, il modifie la valeur des variables d'état au cours du temps simulé. Les langages de simulation peuvent être classés en deux grandes familles : les langages discrets et les langages continus. Les outils discrets modélisent des systèmes dont l'état change en unités discrètes à des moments précis. Les outils continus modélisent des systèmes dont l'état change de manière continue sur des portions de temps. L'accent est mis ici sur les systèmes discrets, bien que les systèmes continus soient également pris en compte. De nos jours, la plupart des langages de simulation sont multimodaux et prennent en charge plusieurs paradigmes de modélisation qui combinent généralement des capacités discrètes et continues.

La solution

Modélisation des vues du monde

Une simulation discrète se compose d'un ensemble de variables d'état et d'un mécanisme permettant de modifier ces variables au moment de l'événement. Une vision du monde de la modélisation de la simulation fournit au praticien un cadre pour définir un système permettant d'atteindre les objectifs avec suffisamment de détails pour pouvoir simuler le comportement du système. Contrairement aux outils descriptifs statiques simples tels que l'organigramme(https://en.wikipedia.org/wiki/Flowchart), Visio(https://en.wikipedia.org/wiki/Microsoft_Visio), IDEF(https://en.wikipedia.org/wiki/IDEF), UML(https://en.wikipedia.org/wiki/Unified_Modeling_Language), etc., une vision du monde de la modélisation de simulation doit tenir compte avec précision des transitions d'état dynamiques qui se produisent au fil du temps. La vision du monde fournit un ensemble définitif de règles pour faire avancer le temps et modifier l'état discret (ou l'état continu) du modèle.

Au cours des 60 ans d'histoire de la simulation, nous jugeons que quatre visions du monde distinctes dominent dans l'utilisation : événement, activités, processus et objets (bien que d'autres terminologies et taxonomies aient été proposées - voir Overstreet et Nance 1986). Elles ont toutes été développées par les pionniers de la simulation dans les années 1960 (Gordon 1961 ; Markowitz et al. 1962 ; Tocher 1963 ; Dahl et Nygaard 1966). Bien que ces visions du monde aient été considérablement affinées au cours des 50 dernières années, les idées de base n'ont pas changé. L'évolution des outils de modélisation s'est concentrée sur la recherche d'un équilibre entre la facilité d'utilisation et la flexibilité. La vision du monde basée sur les événements offre la plus grande flexibilité, mais est plus difficile à utiliser. La vue du monde basée sur les activités donne plus de contexte aux activités, mais avec certaines restrictions dans la modélisation. La vue processus est plus facile à utiliser, mais au prix d'une flexibilité de modélisation réduite. La vue objet est la plus simple et la plus naturelle de toutes, mais elle implique également une plus grande complexité de modélisation. L'histoire du développement des langages de simulation s'est généralement attachée à rendre les vues processus et objet plus flexibles, tout en conservant leur avantage en termes de facilité d'utilisation. En même temps, la plupart des langages de simulation modernes mélangent leurs méthodes d'exécution (en utilisant le traitement des événements pour les événements futurs et le balayage des événements actuels) et emploient une représentation multimodale (réseaux, processus, dynamique), de sorte qu'ils ne se laissent pas facilement enfermer dans une taxonomie simple.

Modélisation à l'aide d'événements

Les événements sont des points séquentiels dans le temps où le système change d'état. Il incombe au modélisateur de s'assurer que les événements sont reconnus et que les changements d'état ont lieu. Le choix des événements relève du modélisateur et n'est pas toujours évident. Ce choix est régi en partie par le comportement du système, mais aussi par la nature des mesures de performance nécessaires à la simulation. Le choix des événements n'est qu'une partie du défi. Une fois qu'un événement se produit, il est nécessaire de cartographier la transition de l'état présent à l'état successeur. En outre, il faut disposer d'un moyen de maintenir et d'ajouter des événements en série. Enfin, les résultats appropriés doivent être collectés et affichés.

Le rôle du calendrier des événements futurs (dont la structure réelle des données a évolué et peut varier), qui conserve tous les événements futurs, est au cœur de la modélisation des événements. Un langage de simulation à événements discrets fonctionne souvent (1) en supprimant l'événement suivant dans le calendrier des événements et en mettant à jour le temps de simulation en fonction de cet événement, et (2) en exécutant ensuite les procédures de mise à jour de l'état associées à cet événement.

La logique événementielle peut être mise en œuvre dans n'importe quel langage de programmation général, tel que Fortran, C++, C#, etc. Toutefois, étant donné qu'un certain nombre de fonctions de simulation, telles que la génération de variables aléatoires et la programmation d'événements, sont communes à la plupart des simulations, l'utilisation d'une bibliothèque de ces fonctions dans le contexte d'un langage de programmation facilite grandement le développement du programme de simulation. Des exemples sont l'utilisation de Fortran augmentée par GASP (Pritsker et Kiviat 1969) et la programmation en langage C avec CSIM (Schwetman 1986). D'autre part, SIMSCRIPT II.5 (Russell 1983) a fourni son propre langage de programmation pour augmenter sa bibliothèque de simulation. Il a également ajouté des fonctions de base pour la définition des entités, l'attribution d'attributs aux entités et la collecte d'entités dans des ensembles.

Les outils de visualisation du monde événementiel ont été largement utilisés au cours des 20 premières années de la simulation. Ces outils ont été plébiscités car ils étaient très flexibles et pouvaient être utilisés pour modéliser efficacement un large éventail de systèmes complexes. Il convient de noter qu'à cette époque, l'efficacité était plus importante car les ordinateurs avaient moins de mémoire et étaient nettement plus lents. Cependant, les modèles basés sur les événements étaient souvent difficiles à comprendre et à déboguer et nécessitaient des compétences en programmation qui limitaient leur utilisation générale.

Peut-être en raison de sa généralité, il n'existe pas d'outils largement acceptés pour la modélisation à l'aide d'événements. En général, les modélisateurs utilisent des organigrammes et des dessins informels. Certains ont préconisé les réseaux de Petri (Haas 2002) et les diagrammes de flux de signaux. Les graphes d'événements, introduits par Schruben (Schruben 1983), constituent une méthode générale de modélisation visuelle des événements discrets. Bien que le graphe d'événements soit un outil précieux pour comprendre la simulation d'événements discrets, son utilisation en tant que véhicule de modélisation général est assez limitée et un certain nombre d'extensions et d'embellissements sont nécessaires pour son utilisation générale.

Modélisation à l'aide d'activités : L'approche en trois phases

La modélisation axée sur les événements a dominé le développement des modèles de simulation en général au sein de la communauté nord-américaine, tandis qu'une approche légèrement différente de la modélisation discrète, appelée approche en trois phases, a été lancée par K. D. Tocher en Angleterre (voir Hollocks 2008). Pidd (Pidd 2004) décrit une méthode connexe appelée analyse des activités. Les activités (opérations déclenchées par des événements) constituent la base des changements d'état lorsque des événements se produisent. La méthode en trois phases a évolué, mais elle consiste essentiellement à (1) avancer le temps jusqu'au prochain événement (appelé le prochain événement lié (dépendant du temps)), (2) traiter le ou les prochains événements liés, et (3) traiter toutes les autres actions qui sont conditionnées par l'occurrence des événements liés. Si un calendrier des événements futurs est nécessaire, il en va de même pour les listes d'événements liés et conditionnels. Ces listes d'événements conditionnels ultérieurs (dépendant de l'état) sont réexaminées jusqu'à ce qu'aucune activité ne puisse être lancée.

L'approche en trois phases repose sur l'utilisation d'un outil de modélisation conceptuelle appelé aujourd'hui "diagramme du cycle des activités" (appelé à l'origine "diagramme de la roue"). Pour identifier les activités d'un système, il est utile d'identifier d'abord les types d'entités qui participent aux activités. Par exemple, il peut s'agir de travaux et d'un opérateur. Les travaux arrivent, attendent la machine, puis repartent. L'opérateur installe la machine et la fait fonctionner. Sinon, l'opérateur est inactif lorsqu'il n'y a pas de travail à effectuer. L'usinage, le réglage et l'arrivée sont des activités liées, tandis que l'attente et l'inactivité sont des activités conditionnelles, qui dépendent des actions liées. Le diagramme de cycle d'activité est utilisé ici pour identifier les éléments de la simulation en trois phases.

Modélisation des processus

La modélisation des processus, principalement sous la forme du GPSS (Gordon 1961), est apparue parallèlement au développement de la modélisation des événements et des activités. Le GPSS, développé par IBM, était à la fois un outil de modélisation et un langage de simulation. Il considérait le monde comme des entités (appelées transactions) qui se déplaçaient dans un modèle composé de blocs spéciaux. Chaque bloc avait une certaine fonctionnalité. Il existe une correspondance quasi univoque entre le schéma fonctionnel et le code de simulation. Le modèle de simulation a donc une interprétation visuelle et écrite. Cette correspondance est importante car le modélisateur GPSS peut essentiellement traduire le modèle visuel presque directement en un modèle de "déclaration" et, au lieu d'une syntaxe de langage, une sémantique visuelle est devenue le principal moyen de modélisation. Cette approche signifie que le modélisateur de simulation n'a pas besoin d'être un programmeur et que le GPSS a permis à un grand nombre de personnes de s'essayer à la simulation alors qu'elles ne l'auraient pas fait autrement. L'intérêt pour le GPSS a été alimenté par le livre classique Simulation Using GPSS (Schriber 1974) de Tomas J. Schriber à l'université du Michigan en 1974. Ce livre a été l'un des premiers à affirmer que la modélisation de la simulation devait être effectuée de manière structurée.

Bien que GPSS ait été largement reconnu comme étant facile à apprendre et à utiliser, de nombreuses questions ont été soulevées quant à son efficacité d'exécution. Dans GPSS, la simulation est exécutée à partir de deux listes : un calendrier des événements futurs et un calendrier des événements actuels. Au fur et à mesure que les entités sont générées, elles progressent dans le schéma fonctionnel aussi loin qu'elles le peuvent. Si elles rencontrent un bloc qui peut programmer son départ à une date ultérieure, cette entité est placée dans le calendrier des événements futurs. Toutefois, si l'entité ne peut pas continuer (peut-être que les ressources ne sont pas disponibles), elle est placée dans le calendrier des événements en cours. Le calendrier des événements en cours est analysé et réétudié jusqu'à ce qu'il n'y ait plus d'actions (un peu comme l'analyse d'une activité), puis l'événement suivant est retiré du calendrier des événements et le temps est avancé. Ce balayage du calendrier des événements en cours, ainsi qu'un certain nombre d'autres problèmes, ont été à la base d'une version considérablement améliorée de GPSS en 1983, appelée GPSS/H (Henriksen et Crain 1983), qui a été en mesure de raccourcir l'exécution par un facteur de quatre ou plus, y compris le fait que GPSS/H a été compilé alors que les versions IBM ont été interprétées.

Inspirés par l'acceptation généralisée de la modélisation par blocs du GPSS, une série de nouveaux langages de processus (fin des années 1970, début des années 1980) ont été développés, basés sur des réseaux de blocs (nœuds). Il s'agit notamment de QGERT (Pritsker 1979) et de SLAM (Pegden et Pritsker 1979). Puis, au début des années 1980, l'ordinateur personnel est apparu et SIMAN (Pegden 1982) a été l'un des premiers langages de simulation à s'exécuter sur cette plate-forme. SIMAN utilisait également des blocs stylisés pour créer un modèle d'entités circulant dans un réseau de sites de traitement individuels.

Les langages de modélisation des processus ont généralement adopté l'utilisation du calendrier des événements futurs et du calendrier des événements actuels. Toutefois, afin de réduire le balayage du calendrier des événements en cours, des améliorations ont été apportées pour incorporer une heure réelle au lieu d'une heure entière et pour éliminer le balayage des entités et des événements en cours dont l'état ne changera pas (comme le fait d'être dans une file d'attente derrière d'autres). D'autres améliorations ont été apportées au cours des années 1980, notamment la génération de nombres et de variables aléatoires, la réduction de la variance, la gestion efficace du calendrier et la collecte plus efficace des statistiques. Peu de modélisateurs étaient au courant de ces améliorations, car les langages de simulation étaient de plus en plus étroitement liés aux organisations commerciales qui les développaient et les maintenaient, et qui considéraient leurs opérations internes comme une propriété intellectuelle. La relation univoque entre le langage de simulation et l'organisation commerciale se poursuit largement aujourd'hui.

L'un des principaux avantages de l'orientation processus est que le modèle de processus est défini graphiquement sous la forme d'un organigramme (voir (Fishman 1973). L'utilisateur n'a donc pas besoin d'être un programmeur pour pouvoir créer un modèle du système. Si l'on compare le modèle de processus à l'approche événementielle, la logique du modèle est beaucoup plus simple à définir et à comprendre/apprendre, et ne nécessite que peu de compétences en programmation. Néanmoins, les langages de simulation de processus ont des limites inhérentes puisque chaque situation n'a pas de bloc correspondant dans le langage. Par exemple, dans une salle d'urgence, le patient peut être vu comme une entité se déplaçant dans les blocs d'opération, mais il y a aussi des ressources qui se déplacent et qui ne sont pas bien modélisées par des entités. En fin de compte, le modélisateur de processus se heurte à un mur en termes de représentation et doit soit trouver une représentation moins acceptable dans le langage actuel, soit trouver un autre moyen d'ajouter la capacité nécessaire (généralement par le biais de la programmation).

Une autre avancée conceptuelle dans le domaine de la modélisation des processus a été l'introduction d'outils de modélisation hiérarchique qui ont soutenu l'idée de bibliothèques de processus spécifiques à un domaine. Le concept de base consiste à permettre à un utilisateur de définir ses propres étapes et blocs de processus en combinant des étapes et des blocs de processus existants. Le système de modélisation Arena(https://www.arenasimulation.com/), largement utilisé, est un bon exemple de cette capacité. En 1992, Cota et Sargent (Cota et Sargent 1992) ont ajouté la modularisation et l'encapsulation des processus, ce qui a donné lieu plus tard à des graphiques de flux de contrôle hiérarchiques qui ont permis la représentation graphique (et le calcul) des modèles de simulation (Sargent 1997). SLX (Henriksen 1995) est un exemple de langage orienté processus plus récent développé dans un cadre orienté objet.

Modélisation orientée objet

Un autre point de vue sur la modélisation des processus est qu'un modèle est un ensemble de processus en interaction ou, plus généralement, d'objets. Simula (Dahl et Nygaard 1966), développé dans les années 1960, a fourni une première implémentation promouvant l'idée d'objets en tant qu'éléments de la simulation et que ces objets peuvent inclure des actions décrites par la logique qui contrôle cet objet et qui peut interagir de manière synchrone ou asynchrone avec d'autres objets (certaines idées ont évolué à partir du langage d'intelligence artificielle List 2 - (voir Nygaard et Dahl 1981). Bien qu'il ait été développé au début des années 1960 en tant que langage de simulation, il a été rarement reconnu en Amérique du Nord et n'a pas été largement distribué aux États-Unis. La raison en est en partie qu'il s'agissait d'un langage de programmation de simulation basé sur Algol, qui, en plus d'offrir des concepts de simulation très particuliers, nécessitait un logiciel/matériel unique (pour les États-Unis). Rétrospectivement, Simula a apporté une contribution majeure à la simulation, mais il a d'abord été largement apprécié par la communauté des programmeurs. Avec le développement de la simulation orientée objet, Simula a été redécouvert en tant que précurseur de nombreux langages de simulation actuels.

La modélisation de simulation orientée objet se divise généralement en deux camps. Le premier, illustré par Simula, est que le langage de simulation doit contenir des concepts orientés objet qui permettent au modélisateur de développer des programmes de simulation sophistiqués. Dans cette approche, des concepts tels que les types de données abstraits, l'héritage, le polymorphisme, la composition, les types paramétrés, etc. sont pertinents car ils permettent une large gamme d'objets et de comportements. Les modèles sont compacts, efficaces et extensibles. En d'autres termes, ils constituent un meilleur environnement pour la programmation de simulations. De nos jours, les modèles sont typiquement construits en C++ ou Java dans le contexte des packages de simulation.

Les idées introduites par Simula sont à la base de certaines avancées récentes réalisées par les concepteurs de langages de simulation pour rendre l'approche orientée objet de la modélisation à la fois facile à utiliser et flexible. Bien que ces idées aient été introduites en tant que concepts de modélisation de simulation, elles ont complètement changé la conception et la mise en œuvre des outils de programmation en général. Les idées de Simula ont directement influencé de nombreux langages de programmation ultérieurs, notamment Smalltalk, LISP, C++, Java et C#. Les idées orientées objet introduites par Simula ne constituent pas seulement le développement le plus important dans le domaine des logiciels de simulation, mais peut-être aussi la plus grande avancée de l'informatique au cours des 50 dernières années.

Au-delà de la simulation en tant que défi de programmation, l'autre camp de modélisation de simulation orientée objet considère la simulation orientée objet comme composée d'une large gamme d'objets prédéfinis, chacun avec un ensemble de comportements considérés comme pertinents pour le contrôle et l'utilisation des objets. Cette orientation de la modélisation simplifie le processus de construction du modèle en fournissant un paradigme de modélisation plus naturel et, dans de nombreux cas, plus facile à utiliser. Dans une approche de modélisation basée sur les objets, nous créons notre modèle en plaçant des objets logiciels dans notre modèle qui représentent les composants physiques du système - par exemple un médecin, un opérateur de machine, un chariot élévateur, un convoyeur, etc. Ces objets peuvent être personnalisés en spécifiant les valeurs de leurs propriétés, telles que le temps de service, la vitesse de déplacement, etc. Par exemple, nous modélisons une usine en plaçant et en décrivant par le biais de propriétés les travailleurs, les machines, les convoyeurs, les robots et les autres objets qui composent notre usine. Avec l'orientation processus, le modélisateur décrit les actions qui ont lieu dans le système lorsque les entités se déplacent dans les processus. Il convient de noter que les étapes du processus sont décrites par des verbes (saisir, retarder, libérer), tandis que les objets sont décrits par des noms (machine, robot, travailleur). Dans l'orientation objet, le modélisateur décrit simplement les composants physiques du système, ainsi que les comportements et les actions de ces objets qui sont déjà intégrés dans les objets. Ainsi, un objet travailleur a des comportements prédéfinis qui lui permettent d'interagir avec les machines et les autres travailleurs du modèle.

Il est difficile d'envisager une manière plus naturelle de construire un modèle qu'en utilisant une collection de composants de modélisation préconstruits qui imitent les composants du système réel. Le problème de cette approche est que si nous voulons modéliser quoi que ce soit dans le monde réel, nous avons besoin d'une vaste bibliothèque d'objets pour pouvoir capturer la grande diversité d'objets réels que vous pouvez rencontrer. Par exemple, il ne suffit pas d'avoir un seul objet appelé robot, car il existe de nombreux types de robots dans le monde réel. Les efforts déployés par les développeurs de langages de simulation pour créer un outil de simulation pratique basé sur l'approche objet illustrent le défi que représente la flexibilité et la facilité d'utilisation d'un même outil de modélisation de simulation. Bien que la flexibilité offerte par l'orientation processus en fasse encore une approche largement utilisée pour la modélisation de simulation, un nombre croissant de produits de simulation réussis ont été introduits au cours des 20 dernières années sur la base de l'orientation objet. Tout comme les 20 dernières années ont été marquées par le passage de l'orientation événementielle à l'orientation processus, les 20 dernières années ont été marquées par le passage de l'orientation processus à l'orientation objet. Les outils orientés objet les plus récents disposent d'un riche ensemble de bibliothèques d'objets axées sur des domaines d'application spécifiques tels que la fabrication, la chaîne d'approvisionnement et les soins de santé. Certains de ces outils permettent également aux utilisateurs de créer et de personnaliser leurs propres bibliothèques d'objets pour des domaines d'application spécifiques. L'idée fondamentale de pouvoir créer des objets personnalisés en tant que concept formel a été introduite par OleJohan Dahl et Kristen Nygaard du Norwegian Computing Center d'Oslo dans les années 1960 dans Simula et Simula 67 (Dahl et al. 1967). Simula a introduit la notion de classes de comportement (par exemple, serveur, travailleur, robot) et leurs instances (objets, par exemple, Fred et Drill), dans le cadre d'un paradigme de modélisation explicite. Un modélisateur peut créer une classe d'objets telle que Car, puis placer plusieurs instances de cette classe dans son modèle et personnaliser le comportement de chaque instance en définissant les valeurs des propriétés. Ils ont également introduit la notion de sous-classement des objets. Ce concept puissant permet à un utilisateur de créer une nouvelle classe d'objets à partir d'une classe d'objets existante en héritant, en surchargeant et en étendant le comportement de la classe d'objets. Par exemple, une nouvelle classe d'objets nommée Camion peut être créée à partir de la classe d'objets nommée Voiture en redéfinissant certains comportements et en ajoutant de nouveaux comportements. La possibilité de créer une nouvelle classe d'objets à partir d'une classe d'objets existante ayant certains comportements souhaités simplifie grandement le développement des bibliothèques d'objets.

Une grande partie du travail innovant dans la conception de langages de simulation se produit dans les outils de simulation orientés objet. Ces outils deviennent plus flexibles tout en conservant leur avantage en termes de facilité d'utilisation, ce qui leur permet de supplanter les outils orientés processus. Ils présentent également un avantage clé en termes d'animation. Dans le cas des orientations événement et processus, l'ajout d'une animation est un processus en deux étapes, où l'utilisateur construit d'abord le modèle logique, puis crée l'animation en tant qu'étape distincte, et enfin lie ces deux composants ensemble. Dans l'orientation objet, les objets prédéfinis sont non seulement accompagnés de leurs propriétés, états et comportements, mais aussi de leurs animations 3D. Cela permet à l'utilisateur de construire rapidement la logique du modèle et l'animation en une seule étape.

Modélisation dynamique des systèmes

La dynamique des systèmes est une approche de modélisation développée au MIT à la fin des années 1950 par Jay Forrester (Forrester 1961). Il s'agit d'une forme de simulation continue, où les variables peuvent changer continuellement dans le temps. Parfois, la dynamique des systèmes est utilisée pour approximer des systèmes discrets à grande échelle (par exemple, pour modéliser des populations). Dans sa forme générale, la dynamique des systèmes comporte un ensemble de variables d'état liées dynamiquement à un ensemble d'équations différentielles. Cependant, pour la plupart des applications, les modèles consistent en des "niveaux" et des "taux" où les niveaux sont simplement des variables d'état et les taux sont des différentielles du premier ordre (Sterman 2000). En se limitant à cette forme simple, il est possible de modéliser un large éventail de problèmes de systèmes dynamiques. La dynamique des systèmes est souvent caractérisée par des diagrammes de boucles causales et des diagrammes de stocks et de flux.

Un diagramme de boucle causale est un moyen visuel d'afficher la structure et le comportement du système. Toutefois, la représentation des stocks et des flux constitue un modèle plus détaillé. Un stock peut être représenté comme un réservoir qui se remplit et se vide et qui mesure le niveau d'une variable d'état telle que le nombre de patients dans une salle d'urgence ou le nombre de personnes qui ont été exposées à une maladie. Un flux est représenté par une vanne qui contrôle le taux de variation d'un stock. Dans cet exemple, le flux de patients aux urgences peut être contrôlé par l'étendue de l'assurance. Lorsque le nombre de personnes assurées augmente, le nombre de visites aux urgences diminue. Mais tout cela peut être atténué par le coût qui augmente le nombre de personnes non assurées, ce qui accroît le recours aux urgences.

Forrester a publié en 1961 le premier ouvrage, toujours classique, dans ce domaine, intitulé Industrial Dynamics (Forrester 1961). L'un des modèles de dynamique des systèmes les plus connus est un modèle de croissance de la population mondiale, qui a été popularisé dans le best-seller de 1972, Limits to Growth (Meadows et al. 1972). Ce modèle prévoit une croissance exponentielle de la population et du capital, avec des ressources finies, conduisant à un effondrement économique dans une grande variété de scénarios. Le modèle original comportait cinq niveaux mesurant la population mondiale, l'industrialisation, la pollution, la production alimentaire et l'épuisement des ressources.

Bien que tout outil de simulation continue puisse être utilisé pour simuler des modèles de dynamique des systèmes, un certain nombre d'outils de modélisation spécifiques ont été développés. Par exemple, (voirhttps://en.wikipedia.org/wiki/Comparison_of_system_dynamics_software). À l'origine, le principal langage de simulation pour la dynamique des systèmes était Dynamo (aujourd'hui tombé en désuétude), mais des langages comme Stella(https://www.iseesystems.com/store/products/stella-architect.aspx) et Vensim(http://vensim.com/) sont aujourd'hui populaires dans la communauté de la dynamique des systèmes. D'autres langages de simulation comme PowerSim(http://www.powersim.com/) et AnyLogic(http://anylogic.com/) comportent des éléments de dynamique des systèmes, mais offrent désormais d'autres combinaisons avec des éléments d'événements et de processus. En outre, bien que les modèles de dynamique des systèmes soient exprimés en tant que systèmes continus, la plupart des applications impliquent la modélisation de systèmes discrets à grande échelle avec de nombreuses entités. Une alternative à la dynamique des systèmes pour les systèmes discrets à grande échelle est la modélisation d'agents.

Modélisation basée sur les agents

La modélisation basée sur les agents (ABM) étend l'idée d'objets aux "agents" dont les attributs sont fortement associés au comportement humain, bien qu'il n'y ait pas d'accord universel sur leur définition. Cette tendance à traiter les agents comme des personnes signifie que les agents doivent avoir des caractéristiques intelligentes et autonomes et la capacité de prendre des décisions indépendantes. Bien que les agents puissent être indépendants, ils se trouvent dans un environnement composé d'autres agents et il existe donc des règles qui régissent à la fois la prise de décision individuelle et l'interaction avec d'autres agents. En général, la GPA tend à être appliquée à des problèmes sociétaux qui reflètent un comportement social tel que l'essaimage, le regroupement, le suivi, etc. Certains éléments de la GPA incluent également la dynamique des systèmes.

Le concept de base de la modélisation basée sur les agents (voir North et Macal 2007) est qu'un système est modélisé en plaçant des agents dans le système et en laissant le système évoluer à partir de l'interaction de ces agents. Chaque agent est une entité autonome qui interagit avec d'autres entités du système. L'accent est mis sur la modélisation du comportement des agents par opposition au comportement du système. Dans une orientation processus traditionnelle, les entités suivent une séquence d'étapes de processus, qui sont définies à partir d'une perspective système descendante. En revanche, la modélisation basée sur les agents définit les règles de comportement locales (souvent simples) de chaque entité d'un point de vue ascendant. Le comportement du système est le résultat cumulatif de l'interaction des agents entre eux. Parmi les exemples d'applications, citons les foules se déplaçant dans une zone, les clients réagissant à l'introduction d'un nouveau produit ou les troupes au combat.

Le cadre de transition d'état des agents peut être modélisé à l'aide de n'importe quelle vision du monde. La modélisation basée sur les agents est souvent mise en œuvre à l'aide d'un outil de simulation orienté objet. Il ne s'agit donc pas d'une nouvelle vision du monde à événements discrets, mais plutôt d'un groupe d'applications qui sont souvent modélisées à l'aide de la vision du monde orientée objet. Des classes sont utilisées pour définir les états et les comportements des agents et des instances (souvent en grand nombre) sont placées dans le modèle. Les agents (objets) interagissent et l'état du système évolue dans le temps. Certains domaines d'application de la modélisation basée sur les agents présentent des défis uniques, en particulier lorsqu'un grand nombre d'agents est impliqué (par exemple, la modélisation de l'évacuation des supporters d'un stade).

Pour les applications simples de la modélisation basée sur les agents, le cadre orienté objet complet avec l'héritage et la sous-classification est parfois plus puissant que nécessaire et un simple diagramme d'état peut suffire à définir le comportement de la classe pour chaque agent. Le concept de diagramme d'état a été introduit par Shannon et Weaver (Shannon 1949) dans leur ouvrage de 1949 intitulé The Mathematical Theory of Communication (Théorie mathématique de la communication). Un diagramme d'états définit un ensemble fini d'états dans lesquels l'agent peut se trouver, ainsi que les conditions de transition qui entraînent une transition entre deux états. Chaque diagramme définit généralement le comportement d'un objet d'une classe donnée et les transitions d'état pour les instances d'objets de cette classe. Bien qu'il existe plusieurs variantes de diagrammes d'état, elles définissent toutes les états comme des nœuds et des arcs pour la transition entre les états. Par exemple, le diagramme d'état des agents peut montrer comment une population infectée est traitée et comment les changements d'état se produisent au fil du temps.

En raison de la capacité accrue des ordinateurs à gérer un grand nombre d'agents, certains modèles qui étaient auparavant réalisés sous forme d'approximations discrètes à l'aide d'une approche de dynamique des systèmes sont aujourd'hui mieux réalisés à l'aide d'une approche de modélisation basée sur les agents. Cela permet une plus grande flexibilité dans la logique au détriment d'un temps d'exécution plus long. L'un des premiers modèles basés sur les agents était le jeu de la vie développé par John Conway dans les années 1970 (Conway 1970). Le jeu de la vie est un modèle bidimensionnel impliquant une croissance cellulaire qui évolue en utilisant un pas de temps fixe, où chaque cellule a deux états, vivant et mort. L'état d'une cellule dépend de l'état de ses voisins au cours du pas de temps précédent. Le jeu de Conway a démontré le concept de base de l'émergence de la complexité à partir de règles simples.

L'intérêt pour la modélisation basée sur les agents a continué à croître et à se diversifier dans les années 1990 avec l'apparition de divers outils basés sur les agents, en particulier Swarm(https://en.wikipedia.org/wiki/Swarm_(app)), NetLogo(https://ccl.northwestern.edu/netlogo/), Recursive Porous Agent Simulation Toolkit (Repast)(http://repast.sourceforge.net/repast_3/), et AnyLogic (http://anylogic.com/).

Expériences personnelles en matière de modélisation

Nos propres expériences en matière de modélisation et de langages de simulation s'étendent de la fin des années 1970 à aujourd'hui. Bien que les approches de modélisation soient différentes et qu'elles s'étendent à partir des points de vue discutés précédemment, elles restent basées sur les techniques d'événements et de processus avec un intérêt plus récent pour les méthodes orientées objet et les perspectives multi-paradigmes que nous décrivons dans la section suivante. Nous présentons les observations pour leur éclairage historique.

Le développement du SLAM est né d'un cours de simulation donné par C. Dennis Pegden au printemps 1978 à l'université d'Alabama à Huntsville (UAH). Bien que Pegden ait suivi un cours de simulation dispensé par A. Alan B. Pritsker au cours de ses études supérieures à Purdue, son doctorat et sa spécialisation portaient sur l'optimisation mathématique, de sorte que l'enseignement de ce cours de simulation à l'UAH a été à la fois un défi et une expérience d'apprentissage pour Pegden. La classe comptait une douzaine d'étudiants diplômés à temps partiel, dont beaucoup utilisaient quotidiennement la simulation dans le cadre de leur emploi à temps plein à la NASA et chez plusieurs sous-traitants du secteur aérospatial. Certains étudiants étaient déjà des utilisateurs experts de GPSS, SIMSCRIPT et d'autres outils de simulation. Compte tenu de l'expérience impressionnante des étudiants diplômés, Pegden a décidé de tirer parti de l'expertise des étudiants en utilisant l'enseignement en équipe et en se concentrant sur une comparaison des approches par événement, par processus et par objet, ainsi que sur des algorithmes efficaces pour la mise en œuvre d'outils de simulation. Pendant ce cours, Pegden a appris les différences entre les approches par événement, par processus et par objet et a développé l'idée de fusionner un langage de modélisation d'événement et de processus dans un cadre unique. Le logiciel GASP IV étant dans le domaine public, Pegden a utilisé GASP IV comme composants événementiels et continus de SLAM, puis a étendu ce cadre pour y inclure une nouvelle capacité de modélisation de processus. Le langage SLAM a été développé parallèlement à l'enseignement de ce cours et en est le résultat direct.

À l'époque où SLAM a été achevé, Pritsker and Associates commercialisait le produit de simulation GASP IV, développé par Nicholas Hurst dans le cadre de sa thèse de doctorat sous la direction d'Alan Pritsker. Étant donné que SLAM offrait toutes les fonctionnalités de GASP IV, plus la capacité de modélisation des processus, il représentait une nette amélioration par rapport à GASP IV. Au cours de l'été 1978, Pegden s'est rendu chez Pritsker and Associated, où il a présenté les avantages du SLAM et suggéré que Pritsker and Associates commercialise le SLAM à la place de GASP IV. Un accord de commercialisation a été conclu, ainsi qu'un accord de co-rédaction d'un nouveau manuel sur la simulation à l'aide de SLAM. Grâce à ce nouveau livre et au soutien de Pritsker, SLAM est rapidement devenu un succès commercial.

Au cours des deux années suivantes, Pegden a réorienté ses recherches de l'optimisation vers la simulation et a commencé à utiliser SLAM pour modéliser des systèmes complexes. Il s'est rapidement rendu compte que, même si le produit fonctionnait bien pour de nombreux problèmes de manuels, les limites des fonctions de modélisation des processus obligeaient l'utilisateur à revenir à la vue des événements pour la plupart des applications complexes dans le monde réel. Ainsi, l'objectif initial de créer un outil de simulation plus facile à apprendre et à utiliser pour des applications réelles n'était pas atteint pour de nombreuses applications complexes, en particulier dans les environnements de fabrication. Il est apparu clairement qu'un langage de processus beaucoup plus riche et performant serait nécessaire pour atteindre cet objectif, et que des caractéristiques spéciales étaient nécessaires pour répondre à certaines applications de fabrication. Pegden a donc décidé de repartir de zéro et de développer le langage SIMAN.

Le développement du langage SIMAN a commencé au printemps 1981. L'objectif de la conception était à la fois d'étendre l'exhaustivité des caractéristiques du processus et d'améliorer l'efficacité de l'exécution. Au cours de l'été 1981, le premier PC IBM a été commercialisé et est devenu une plate-forme cible pour le développement de SIMAN, ce qui a ajouté des exigences supplémentaires en matière d'efficacité de la mémoire et de vitesse d'exécution. En août 1981, Pegden a pris un congé sabbatique d'un an chez Tektronix Inc. à Portland Oregon et s'est concentré à plein temps sur le développement du langage SIMAN. Au cours de cette période, plusieurs processus de fabrication ont été modélisés avec succès à l'aide de versions bêta du langage, ce qui a permis de valider l'idée que SIMAN offrait une amélioration significative de la capacité de modélisation des processus. Un manuel sur la simulation à l'aide de SIMAN a également été rédigé pendant ce congé sabbatique (Pegden 1982).

Au cours de l'été 1982, Pegden a contacté Pritsker and Associates pour s'enquérir de leur intérêt potentiel pour la commercialisation de SIMAN. Cependant, la société était très investie dans SLAM et n'a pas exprimé d'intérêt pour le nouveau produit SIMAN. C'est ainsi qu'en décembre 1982, Dennis et Lisa Pegden ont lancé System Modeling Corporation et mis le langage SIMAN sur le marché, avec un succès immédiat. Les trois facteurs clés qui ont favorisé la croissance initiale du marché sont les suivants : (1) l'amélioration significative de la capacité de modélisation des processus de SIMAN, (2) les caractéristiques axées sur les applications de fabrication et (3) la capacité de SIMAN à fonctionner sur le nouveau PC d'IBM. SIMAN a incorporé des constructions spécifiques pour modéliser des équipements de manutention complexes tels que les AGV et les convoyeurs. SIMAN a également mis en œuvre le concept de cadre expérimental promu par Zeigler (Zeigler 1984), qui consiste à séparer la logique du modèle de l'expérimentation.

Après l'introduction de SIMAN, Systems Modeling Corporation a développé le système d'animation Cinema sur PC (1985) pour fournir une animation en temps réel des modèles SIMAN. Ce système offrait un plus grand réalisme que les systèmes d'animation à base de personnages existants et, en s'exécutant parallèlement au modèle SIMAN, constituait une puissante plate-forme interactive de vérification/validation des modèles. Il s'agissait d'une étape importante dans l'exploitation de la puissance de l'animation dans la simulation. Microsoft Windows n'étant pas encore disponible, Cinema a été développé à l'aide d'un système de fenêtrage personnalisé. Le PC standard n'ayant qu'une résolution de 320 x 200, la version initiale de Cinema nécessitait une carte graphique et un moniteur haut de gamme de tiers pour fournir la résolution nécessaire à la production d'une animation de qualité. SIMAN et Cinema ont ensuite été combinés pour former le système de simulation Arena (1991), puis portés sur Microsoft Windows. Arena a introduit le concept de processus graphiques pour la construction de modèles à la place des déclarations, et a fourni une interface de boîte de dialogue pour la saisie des propriétés. Il prend également en charge l'analyse des entrées et des sorties. Arena est devenu largement populaire dans les applications commerciales et s'est imposé comme le principal produit de simulation utilisé par les universités pour enseigner les concepts de simulation. Cette popularité dans les universités est due à la souplesse de modélisation de SIMAN, à la facilité d'utilisation de l'interface graphique et aux manuels populaires "Simulation with Arena" de W. David Kelton, Randall P. Sadowski, Deborah A. Sadowski et David T. Sturrock. En 2000, System Modeling Corporation a été rachetée par Rockwell, qui commercialise actuellement le produit Arena et en assure le support.

Bien que SIMAN ait constitué un progrès en matière de flexibilité de la modélisation, il restait de nombreuses applications complexes difficiles à modéliser avec la vue processus. L'un des problèmes les plus fréquents était que les ressources (ainsi que les entités) dans SIMAN n'avaient pas de capacité de prise de décision personnalisée. Bien que les entités puissent saisir des ressources, celles-ci n'ont pas leur mot à dire dans le processus. Dans certains systèmes (par exemple les soins de santé), il est plus naturel que les ressources contrôlent leur propre logique. Le défi que représente la modélisation de systèmes nécessitant une logique de ressources complexe a été au centre des travaux de Stephen Roberts.

Roberts a été engagé comme membre de la faculté de l'université de Purdue en 1973 et a occupé un poste conjoint avec le Regenstrief Institute for Health Care, qui était situé dans les grandes cliniques de soins de santé généraux et multi-spécialités de l'Indiana University School of Medicine, située à Indianapolis, dans l'État de l'Indiana. L'analyse des caractéristiques de fonctionnement de ces cliniques pendant plusieurs années a montré que seule la simulation permettait d'analyser les composantes complexes et stochastiques de ces établissements. À Purdue, Alan Pritsker et ses étudiants développaient des langages de simulation de réseaux (processus) basés sur la partie simulation discrète de GASP IV. Alors que ces langages mettaient l'accent sur le flux d'entités à travers les processus, il était clair que, dans les services de santé, le "flux de patients et apparentés" n'était qu'une partie de l'environnement et que le flux de patients était sévèrement limité par des prestataires de soins et du personnel très occupés qui fournissaient des services dans un environnement dynamique, contrairement aux machines et aux équipements que l'on peut voir dans une installation de fabrication. En fait, le flux était presque toujours limité par des ressources humaines très actives qui décidaient de ce qui était fait en fonction de plusieurs facteurs.

Ainsi, à la fin des années 1970 et au début des années 1980, un produit de simulation appelé INSIGHT (anciennement INS) a été développé à l'Institut Regenstrief. Il incluait le flux d'entités (appelé alors transaction), mais était orienté vers les "descriptions de tâches" effectuées par les différentes ressources "humaines" disponibles. La modélisation utilisait une activité comme point de service pour les entités et les ressources. L'activité spécifiait le nombre, le type et la combinaison de ressources nécessaires ainsi que le temps d'activité associé, mais des files d'attente logiques devant une activité retenaient les entités jusqu'à ce que le service puisse commencer. Ainsi, les ressources servaient les activités mais servaient les entités dans les files d'attente. Les entités ne se déplaçaient pas dans une activité mais attendaient que les ressources les y amènent. Les ressources sont identifiées individuellement et, éventuellement, par type. Chaque ressource est associée à un nœud primaire dans un arbre de décision des ressources. Plusieurs arbres de décision des ressources peuvent être définis. Ce nœud primaire pouvait se référer aux files d'attente du modèle et/ou à d'autres nœuds primaires. Ces nœuds primaires exprimaient la méthode d'évaluation des files d'attente associées et des autres nœuds par des critères de recherche. Par exemple, le nœud de décision primaire d'une infirmière peut être de servir d'abord la file d'attente des patients dans les salles d'examen nécessitant le service d'une infirmière, puis de servir la file d'attente des patients qui attendent d'être placés dans une salle d'examen et que l'on prenne leurs constantes, puis d'exécuter un autre nœud de décision primaire qui dit d'aider à l'enregistrement ou à la sortie en fonction du temps d'attente des personnes. Ce processus de décision peut faire partie d'un autre processus de décision ou être propre à une ressource.

Dans tous les cas, le processus de décision concernant les ressources était dynamique et dépendait essentiellement de l'état du système. Ce qui a permis au processus de décision de fonctionner, c'est l'algorithme de mise à jour de l'état utilisé par le langage de simulation. Étant donné que les événements de fin d'activité dominent tous les autres événements, leur mise à jour est au cœur de la modélisation et est désignée comme un processus en deux étapes. Lorsqu'une activité se termine, les ressources sont placées dans un état d'attente temporaire appelé stockage tampon. À ce stade, l'étape 1 consistait à envoyer l'entité dans le réseau jusqu'à ce que sa progression soit interrompue par la nécessité d'acquérir des ressources, de commencer une activité ou de partir. Lorsque l'étape 1 est terminée, l'étape 2 est invoquée, au cours de laquelle chaque ressource en mémoire tampon utilise son arbre de décision pour déterminer ce qu'elle doit faire ensuite. Soit elle est occupée à une autre activité, soit elle devient inactive. Des spécifications permettaient aux entités d'identifier et de réclamer des ressources de la mémoire tampon et de permettre à la mise à jour d'une ressource d'amener les entités à démarrer des activités. Il convient de noter que les entités peuvent être retardées en raison d'exigences de synchronisation telles que le rassemblement ou le déplacement à distance. D'autres priorités parmi les ressources à utiliser pour les activités pourraient entraîner la préemption ou la reprise d'activités.

Le développement du langage de simulation INSIGHT s'est poursuivi tout au long des années 1980 et a été décrit dans des tutoriels au CSM. Il n'a jamais connu de succès commercial et l'Institut Regenstrief a suspendu son développement lorsque Roberts est parti pour l'Université d'État de Caroline du Nord en 1990. Dans les années 1990, Roberts, principalement avec Jeff Joines, a développé un langage de simulation orienté objet C++ dont les caractéristiques de simulation de processus ressemblent à celles d'INSIGHT. Grâce au polymorphisme des objets, cette simulation pouvait employer des "équipes" ainsi que des ressources individuelles et de type dans un processus de décision élargi. En outre, le développement a montré comment un langage comme INSIGHT pouvait être développé et étendu avec de véritables caractéristiques orientées objet. Cependant, son utilisation nécessitait une expérience substantielle de la programmation en C++, de sorte que son acceptation a été très limitée et que son développement a été abandonné dans les dix ans qui ont suivi. Bien qu'INSIGHT n'ait jamais connu de succès commercial, il a mis en évidence l'importance d'étendre la flexibilité de la modélisation au-delà des simples flux d'entités afin de soutenir également la modélisation de la logique complexe des ressources.

Après s'être éloigné du secteur de la simulation pendant quelques années, M. Pegden a été invité à donner la conférence Titan lors de la Winter Simulation Conference de 2005 sur les orientations futures de la simulation. Cet exposé a été l'occasion de réfléchir à l'état de la simulation et à ce qui pourrait être fait pour améliorer les outils existants. Cela a conduit Pegden à développer l'idée de modifier les concepts de base de l'orientation objet pour remplacer les méthodes codées par des processus, tout en conservant la notion de base de classes, sous-classes, héritage, polymorphisme, surcharge, etc. La motivation de cette idée était d'apporter les avantages de l'approche orientée objet en utilisant des processus graphiques, évitant ainsi le besoin de compétences complexes en programmation.

Pegden a utilisé ces concepts développés pour la conférence Titan pour créer le logiciel de simulation Simio, qui a été lancé sur le marché en 2008. Avec Simio, il est devenu beaucoup plus facile pour les utilisateurs d'étendre et de créer des bibliothèques d'objets sans avoir à coder dans un langage orienté objet tel que C++ ou Java. Simio a également étendu l'idée d'une ressource intelligente telle qu'elle a été introduite par INSIGHT. Dans Simio, les ressources (et les entités) sont également des objets qui peuvent répondre à des demandes en utilisant leur propre logique de processus. Il est ainsi beaucoup plus facile de modéliser des situations dans lesquelles l'entité ou la ressource contrôle son propre comportement.

Une autre avancée clé de Simio a été la notion d'utilisation de processus d'ajout pour les objets afin de modifier leur comportement instance par instance, sans modifier la définition de l'objet. Avant l'introduction de ce concept dans Simio, la principale méthode pour ajouter une logique personnalisée à une instance d'objet consistait à ajouter des événements codés personnalisés à l'objet. L'ajout de processus a constitué une avancée significative car ils sont à la fois plus faciles à utiliser et plus puissants. La puissance supplémentaire provient de la logique de processus qui peut représenter des activités qui s'étendent dans le temps, alors qu'un événement codé est limité à un instant dans le temps.

L'évolution de SLAM - SIMAN - Arena - Simio s'est déroulée sur une période de près de 40 ans. Au cours de cette période, le principal paradigme de modélisation est passé des événements aux processus, puis aux objets. Avec SLAM, la principale approche de modélisation était les événements, les processus étant utilisés dans la mesure du possible. Avec SIMAN, la principale approche de modélisation était les processus, les événements étant utilisés lorsque cela était nécessaire. Avec Cinema/Arena, l'animation est devenue un élément central du processus de modélisation et de vérification/validation. Avec Simio, l'approche de modélisation principale est basée sur les objets et les processus sont utilisés lorsque c'est nécessaire. Cette évolution a rendu la simulation plus facile à utiliser sans compromettre la flexibilité de la modélisation.

Modélisation multi-paradigme

Les premières approches de modélisation de la simulation étaient le reflet d'un paradigme de simulation unique, à savoir l'événement, l'activité, le processus et l'objet. Dans les années 1970 est apparu un paradigme de modélisation "combiné" permettant à l'utilisateur de choisir l'approche de modélisation la mieux adaptée au problème ou de combiner les approches de modélisation en fonction de la situation. GASP IV (Pritsker 1974) a popularisé l'idée de combiner des cadres discrets et continus dans le même modèle, bien que d'autres aient fait des efforts antérieurs (voir, par exemple, Tocher et Splaine 1966). Ce cadre permettait la modélisation d'événements discrets et la modélisation continue dans le même modèle de simulation. Il fournit à la fois des événements temporels et des événements d'état, de sorte que les événements discrets peuvent avoir un impact sur les variables continues et que les événements temporels peuvent avoir un impact sur les variables discrètes. SLAM (Pegden et Pritsker 1979) a fait progresser la combinaison pour inclure la modélisation des processus et a été l'un des premiers outils largement utilisés pour promouvoir l'idée de mélanger des approches de modélisation alternatives (processus et événements et continu) dans le même modèle. Dans le cas du SLAM, la modélisation de processus/continue a été utilisée pour la modélisation de base, et les événements ont été utilisés comme "porte dérobée" pour apporter une plus grande flexibilité.

L'idée d'utiliser la simulation en combinaison avec d'autres outils analytiques a été employée de manière informelle très tôt dans l'histoire de la simulation. En 1983, Shanthikumar et Sargent (1983) ont proposé une définition unifiée des modèles hybrides simulation/analyse. Ils ont présenté quatre classes de modèles hybrides qui représentent les façons dont les modèles de simulation et les modèles analytiques peuvent interagir. Swinerd et McNaught (2012) ont récemment utilisé une combinaison d'une simulation basée sur des agents avec un modèle analytique pour créer un cas de simulation hybride.

Les outils de simulation modernes orientés objet utilisent également une approche multi-paradigme. Ces outils combinent la facilité et la rapidité de modélisation offertes par les objets avec la flexibilité ajoutée par l'incorporation d'événements et/ou de processus spécifiés par l'utilisateur. Par exemple, un objet représentant un serveur peut avoir des points sélectionnés dans la logique de l'objet où l'utilisateur peut insérer sa propre logique d'événement ou de processus. La logique événementielle est généralement incorporée dans les objets à l'aide d'un langage de programmation tel que Java ou C++, ou d'un langage de script spécial qui peut être utilisé à la place du code. Cependant, dans les deux cas, la logique d'événement a une restriction majeure : le temps simulé ne peut pas avancer dans l'événement. Cela limite considérablement le type de logique qui peut être inséré dans une instance d'objet. Par exemple, il n'est pas possible d'attendre qu'un travailleur soit disponible au sein d'un événement, car cela nécessiterait de faire avancer le temps. Simio(https://www.simio.com/index.php) a introduit une approche beaucoup plus puissante qui permet aux utilisateurs de combiner des objets avec des processus. Comme les processus peuvent s'étendre dans le temps, ils donnent à l'utilisateur beaucoup plus de pouvoir pour étendre le comportement de ses objets. Ainsi, les processus peuvent être intégrés dans un objet pour attendre un temps ou une condition spécifique (par exemple, Fred est disponible). Cette approche combine la puissance et la flexibilité des processus avec la facilité et la capacité de modélisation rapide des objets.

AnyLogic(http://anylogic.com/) a combiné la modélisation basée sur les agents, la dynamique des systèmes et la modélisation des événements discrets en un seul outil. Un seul modèle AnyLogic peut combiner les trois approches de modélisation pour représenter le comportement du système.

En outre, en complément de l'intérêt pour le multi-paradigme, il existe un intérêt pour l'unification de la modélisation de la simulation dans un cadre spécifique ou une théorie de la simulation. En 1981, Nance (Nance 1981) a décrit les rôles fondamentaux du temps et de l'état dans les simulations d'événements discrets, ce qui a finalement conduit à la méthodologie conique (Overstreet et Nance 1985) qui fournit un cadre pour encapsuler les points de vue de modélisation de base de l'événement, de l'activité et du processus.

La théorie de la simulation la plus connue est le formalisme proposé pour la première fois par Zeigler en 1984 (Zeigler 1984), aujourd'hui connu sous le nom de DEVS (Discrete Event System Specification). Au fil des ans, cette théorie a été développée et appliquée à de nombreux cas (voir Zeigler et Muzy 2017). DEVS est une théorie formelle des systèmes composée d'entrées, d'états et de sorties en combinaison avec des fonctions d'avancement dans le temps pour modéliser les composants de systèmes discrets et continus (potentiellement hiérarchiques). L'abstraction fournit un cadre qui sépare la modélisation et l'exécution de la simulation pour mettre en évidence, par exemple, l'ordre et l'exécution potentiellement parallèle des événements. Le formalisme DEVS a suscité un intérêt mondial et sa formulation a fait l'objet d'un certain nombre d'extensions et d'interprétations.

En adoptant une approche fondée sur la théorie des graphes, Schruben et Yucesan (Schruben et Yücesan 1993) montrent qu'une vision de la simulation à événements discrets sous forme de graphe d'événements peut être utilisée pour créer un environnement complet et cohérent de développement de modèles (résolution de problèmes). Un modèle de graphe d'événements n'est pas seulement visuellement attrayant, mais fournit un cadre rigoureux pour la construction de modèles (Savage et al. 2005).

Modélisation avec animation

Pendant les 30 premières années de la simulation, les résultats se présentaient sous la forme de rapports textuels. Bien que l'animation visuelle de l'exécution de la simulation ait été envisagée dès 1970 (Reitman et al. 1970), l'animation a été intégrée dans la simulation commerciale dans les années 1980. Les mérites de l'animation ont fait l'objet d'un débat important. Nombreux étaient ceux qui estimaient que l'animation était un luxe qui n'avait pas d'impact réel sur la réussite d'un projet de simulation. Cependant, l'animation est aujourd'hui considérée comme un élément essentiel de la réussite des projets de simulation et joue un rôle clé dans l'expansion des applications de simulation au sein de l'entreprise. L'un des principaux avantages de l'animation est sa capacité à communiquer le comportement du modèle à toutes les parties prenantes du modèle. Tout le monde, de l'atelier à l'étage supérieur, peut voir le comportement intégré dans le modèle. L'animation clarifie les hypothèses de modélisation et constitue un outil puissant pour la vérification et la validation du modèle.

Avant l'animation, les décideurs devaient être convaincus que le modèle reproduisait fidèlement le comportement du système réel au niveau de détail approprié. Il pouvait souvent y avoir des bogues dans la logique du modèle, mais il n'y avait pas de moyen simple et visuel de détecter les erreurs dans la logique. Avec l'animation, le modèle prend vie et le comportement est clairement visible. L'animation combinée aux débogueurs interactifs a radicalement amélioré la capacité à trouver et à corriger les erreurs logiques dans un modèle. L'animation aide non seulement les modélisateurs à trouver et à corriger les erreurs non traitées dans la logique, mais aussi à communiquer les hypothèses simplificatrices planifiées qui font partie de tout modèle. L'animation est un élément essentiel pour établir la confiance dans les résultats du modèle.

L'un des premiers systèmes d'animation de simulation était le produit See Why, développé à la fin des années 80, qui utilisait une animation rudimentaire basée sur des personnages. Le logiciel de simulation Witness(https://www.lanner.com/technology/witness-simulation-software.html) a été développé à partir de See Why. Le système d'animation Cinema était un système d'animation vectorielle 2D développé à la même époque et était un système d'animation en temps réel pour les modèles SIMAN. Le système d'animation Cinema et le système de modélisation SIMAN ont ensuite été intégrés dans une plate-forme unique pour créer le produit Arena, largement utilisé. Un autre système d'animation 2D précoce était Proof(http://www.wolverinesoftware.com/ProofProducts.htm), développé par Jimes O. Henriksen de Wolverine Software en 1989.

Dans les années 90, les capacités d'animation 3D ont commencé à émerger. Parmi les premiers systèmes, citons AutoMod (axé sur les systèmes de manutention) (http://www.appliedmaterials.com/global-services/automationsoftware/automod), Taylor ED (précurseur de FlexSim(https://www.flexsim.com/)) et Simple++ (précurseur de PlantSim (https://www.plm.automation.siemens.com/)). Le débat sur l'animation s'est également étendu à la nécessité de disposer d'une animation 3D de haute fidélité par rapport à une animation 2D. Certains affirment que l'animation 2D est suffisante pour obtenir la plupart des avantages de l'animation, et que l'effort supplémentaire requis pour la 3D est de moins en moins rentable. Bien qu'une animation 3D de meilleure qualité ne modifie pas le modèle sous-jacent ou les résultats par rapport à une animation 2D, l'amélioration du réalisme peut aider à communiquer les résultats du modèle. En outre, grâce aux améliorations apportées à l'animation 3D et à la large disponibilité des symboles 3D, la création de l'animation 3D ne représente plus un coût important en termes de temps ou d'efforts. Ainsi, la plupart des outils de simulation modernes offrent un environnement d'animation 3D.

La combinaison du cadre orienté objet, d'un environnement de modélisation 3D immersif et de fonctions de dessin 3D améliorées s'est avérée être une combinaison très puissante pour faire entrer l'animation 3D dans le courant dominant de la modélisation de simulation. La plupart des outils de simulation modernes proposent désormais la 3D en standard.

La prochaine vague d'animation pour la simulation est le développement d'environnements de réalité virtuelle (VR) complets pour afficher les animations de simulation. Cela permet à l'observateur d'être immergé dans le modèle et de se promener dans le système dans un environnement VR qui imite le système réel, et éventuellement d'interagir avec la simulation en déplaçant des objets, en réorientant le trafic ou en modifiant l'activité de la simulation. Plusieurs systèmes de simulation (par exemple Simio, FlexSim, Emulate3D(https://www.demo3d.com/) prennent déjà en charge les environnements VR pour la visualisation des animations. Permettre à l'utilisateur d'interférer avec l'animation est la prochaine étape dans le développement de l'affichage RV.

L'impact sur les entreprises

Commentaire

L'histoire de la simulation est jalonnée de dizaines de langages et de progiciels de simulation, chacun revendiquant souvent des composants de modélisation uniques. Nombre d'entre eux ont été perdus sur le marché de la popularité en raison de leur incapacité à capter un public de simulateurs. Contrairement à la simulation continue, qui repose sur la résolution d'équations différentielles, les simulations discrètes n'ont pas de théorie fondamentale commune et acceptée. Par conséquent, la modélisation de la simulation relève plus souvent du domaine de l'"art". Dans la pratique, l'art de la simulation exige une connaissance assez complète de ce qui peut être simulé par l'outil utilisé, plutôt qu'une concentration débridée sur le problème à résoudre. Par conséquent, les simulations réussies sont généralement le produit d'un intérêt commercial soutenu par une abondance de documentation et d'outils d'apprentissage, le tout dans un cadre qui promeut les avantages de l'outil.

La traduction d'un problème en une simulation est largement reconnue comme étant un amalgame des objectifs de performance des systèmes, des données d'entrée disponibles et des compétences de modélisation du modélisateur. Il existe un certain nombre de façons de traiter les données d'entrée disponibles et les diverses mesures de performance (voir (Banks et al. 2010 ; Law 2015). La conceptualisation des modèles s'est généralement appuyée sur des représentations graphiques (schémas fonctionnels, organigrammes, diagrammes de cycle d'activité, etc.) qui sont généralement associées à des langages de simulation spécifiques, et il y a eu peu de discussions systématiques sur les approches générales. Robinson (Robinson 2008a, b) présente un cadre de modélisation conceptuelle en deux parties. La signification et les exigences du modèle conceptuel comprennent : la validité, la crédibilité, l'utilité et la faisabilité. L'activité de modélisation proprement dite est considérée comme consistant à : comprendre la situation problématique, déterminer la modélisation et les objectifs généraux du projet, identifier les résultats du modèle, identifier les entrées du modèle et déterminer le contenu du modèle. L'ensemble de ces éléments fournit un cadre de conceptualisation, mais n'aboutit pas encore à un modèle de calcul. La mise en œuvre du modèle conceptuel doit encore être réalisée au moyen d'un langage de simulation ou d'un progiciel de simulation accessible au modélisateur de simulation.

Le rôle du langage de simulation dans la modélisation de la simulation reste étroitement lié. Les efforts visant à rendre la modélisation plus transparente et visible grâce à des techniques graphiques et au langage naturel offrent un potentiel considérable pour la modélisation de simulation. Néanmoins, la technologie de simulation doit s'interfacer avec le stockage et l'analyse de grandes quantités de données pour réaliser son plus grand potentiel au fur et à mesure que la technologie informatique progresse.